Rank: Member Groups: Registered
Joined: 18/10/2020(UTC) Posts: 26

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 roundoff 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 (5kb) downloaded 8 time(s).




Rank: Advanced Member Groups: Registered, Advanced Member Joined: 13/01/2012(UTC) Posts: 2,344 Location: Italy Was thanked: 1180 time(s) in 776 post(s)

It isn't the area of a circular segment? I don't notice accuracy issues. 
If you like my plugins please consider a donation to SMath Studio; for personal contributions to me: paypal.me/dcprojects 



Rank: Member Groups: Registered
Joined: 18/10/2020(UTC) Posts: 26

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.




Rank: Advanced Member Groups: Registered
Joined: 23/07/2013(UTC) Posts: 252 Was thanked: 69 time(s) in 50 post(s)

Originally Posted by: EngMath 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 Edited by user 07 April 2021 23:57:12(UTC)
 Reason: Not specified




Rank: Advanced Member Groups: Registered, Advanced Member Joined: 13/01/2012(UTC) Posts: 2,344 Location: Italy Was thanked: 1180 time(s) in 776 post(s)

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)*'° Edited by user 10 April 2021 00:02:21(UTC)
 Reason: Marked as solved (not a bug) 
If you like my plugins please consider a donation to SMath Studio; for personal contributions to me: paypal.me/dcprojects 



Rank: Advanced Member Groups: Registered
Joined: 04/07/2015(UTC) Posts: 5,254 Was thanked: 825 time(s) in 656 post(s)





Rank: Newbie
Groups: Registered
Joined: 30/01/2019(UTC) Posts: 4 Location: California

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 nonzero 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. Edited by user 08 April 2021 03:16:07(UTC)
 Reason: Not specified




Rank: Advanced Member Groups: Registered
Joined: 04/07/2015(UTC) Posts: 5,254 Was thanked: 825 time(s) in 656 post(s)

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.




Rank: Newbie
Groups: Registered
Joined: 30/01/2019(UTC) Posts: 4 Location: California

Jean.... The DM42 uses quadprecision floating point. From https://www.swissmicros.com/product/dm42: "The DM42 runs Free42, based on a decimal floatingpoint maths library and IEEE 7542008 quadruple precision decimal floatingpoint, encoding numbers in 16 bytes and giving 34 decimal places of precision with exponents ranging from 6143 to +6144." and "Floating point standard, IEEE 7542008, 128bit floating point precision implementation with 128bit transcendental function support" Free 42 is a calculator simulation of the HewlettPackard HP42S written by Thomas Okken. The HP42S 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 HP42S. The floating point version uses quadprecision 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. Edited by user 08 April 2021 20:40:39(UTC)
 Reason: Not specified




Rank: Advanced Member Groups: Registered
Joined: 04/07/2015(UTC) Posts: 5,254 Was thanked: 825 time(s) in 656 post(s)

Originally Posted by: NotRetiredYet 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




Rank: Newbie
Groups: Registered
Joined: 30/01/2019(UTC) Posts: 4 Location: California

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




Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.