Hi,

I've noticed that in some cases, when I compare the results from SMath to other calculations, there are visible differences in accuracy (even for simple calculations). I suspect that this is due to round-off error but I'm not sure and I don't know if the accuracy of SMath can be adjusted in such case. Here's an example:



The result in SMath is 140,71565 cm^2 while in Wolfram Alpha and Maxima it's 144,03092 cm^2. Quite a significant difference.

What causes this discrepancy and is there a way to fix this so that SMath shows the result closer to the one from Wolfram/Maxima ?

By the way, it was quite problematic to enter the formula for A_2 because it's meant to be used with degrees while SMath works with radians. Is there a better way to implement this equation here ?

I've also attached the sm file with this example.

Thanks in advance for your help.


Problem with accuracy.sm (4 KiB) downloaded 30 time(s).

It isn't the area of a circular segment? I don't notice accuracy issues.

File not found.File not found.

Yes, that's the formula for area of circular segment. I wanted to use its version meant for degress so I tried converting the angles to radians inside the formula. I'm not sure if I did it correctly.

It seems that the difference is caused by the fact that I used α=49 in Wolfram and the original, not rounded value α=48.5904 in SMath.

By the way, can I set SMath to round α to integer using degrees ? Round function seems to work only for radians.

Wrote

Yes, that's the formula for area of circular segment. I wanted to use its version meant for degress so I tried converting the angles to radians inside the formula. I'm not sure if I did it correctly.

It seems that the difference is caused by the fact that I used α=49 in Wolfram and the original, not rounded value α=48.5904 in SMath.

By the way, can I set SMath to round α to integer using degrees ? Round function seems to work only for radians.

Convert the radian to degree angle by dividing it to pi/180, round it, multiply by pi/180.
I have used degree symbol but pi/180 could be used to.

This is when rounding is set to away from zero.
Otherwise I suggest to use round(3) function.
If α=48.5°, round(2) function will give 48°.
Because round(2) is set half to even, not to upper number.
round(3) function shall result with 49°.

By the way, I think this should be coded as reversed.
By default round(2) should round to upper.
If someone wants to round half to even, then round(3) can be used for it.

Regards

In general to round to a multiple of a number you have to divide the value before the rounding by the number and multiply again by it after the rounding.

round(Θ/'°,0)*'°

Wrote

Yes, that's the formula for area of circular segment.

Check vs the attached document [Tema, Perry].

Inst_Segment Partial Random [PUBLISH].sm (38 KiB) downloaded 31 time(s).

Using your numbers and equations (and also simplifying the first part of the second equation because (pi*180)/(pi*360) reduces to 1/2), I got the same results using SMath Studio (0.99.7610.506), Mathcad Prime 5.0, and my SwissMicros DM42 calculator. The DM42 calculates using 34 digits, so it is far more precise than any other calculator on the market.

For Theta, SM and MCP produced 97.18075578145820. The DM42 produced 97.18075578145828132303899562614856, so both SM and MCP truncated at the last non-zero digit.

For A2, SM and MCP produced 140.4156012643280. The DM42 produced 140.4156012643279962251654177332504

However, I suggest not rounding Theta to 97° in the second part of the second equation. I used your 97°, even though it appeared to be incorrect.

34 digits of what ? the floating point register ?
What is unknown is the technical accuracy of DM42 asin.
asin(0.5*30/20) is decimal asin(0.75) is undefined two decimals.
Whatever, Smath has nothing to do in there. It does not calculate asin.
It displays the Win builtin asin 21 floating points
conventionalized display 15 decimals.

Jean....

The DM42 uses quad-precision floating point.

From https://www.swissmicros.com/product/dm42: "The DM42 runs Free42, based on a decimal floating-point maths library and IEEE 754-2008 quadruple precision decimal floating-point, encoding numbers in 16 bytes and giving 34 decimal places of precision with exponents ranging from -6143 to +6144." and "Floating point standard, IEEE 754-2008, 128-bit floating point precision implementation with 128-bit transcendental function support"

Free 42 is a calculator simulation of the Hewlett-Packard HP-42S written by Thomas Okken. The HP-42S was my daily driver for 29 years before I purchased the DM42. Free42 for the PC has both floating point and binary coded decimal versions. The BCD version exists for exact compatibility with the physical HP-42S. The floating point version uses quad-precision floating point and that is what made its way into the DM42. See https://thomasokken.com/free42/ for more information.

And, yes the asin calcs to 0.75 exactly, but the conversion to degrees makes it a transcendental number. Regardless, the issue isn't with SMath here, as you say.

Wrote

And, yes the asin calcs to 0.75 exactly, but the conversion to degrees makes it a transcendental number.
Regardless, the issue isn't with SMath here, as you say.

Thanks for the update, my last HP 41 SX
Mathcad 11 ... asin(3/4) float 250 ... 250 decimals
Mathcad 11 ... asin(0.75) float 250 ... 21 decimals
AFAIK, 250 decimals from continued fraction.
Otherwise known/published ChebyShev 25 D.
Take care ... Jean

Jean...

Mathcad Prime 5.0 produces the same 250 digits using either asin (3/4), float 250 or asin (0.75), float 250.

This is not something I have ever needed, so I hadn't checked this behavior before. I would check MC15, but for some reason it's not working on my computer at the moment.

Fred