Welcome Guest! To enable all features please Login. New Registrations are disabled.

Error

 2 Pages12>
 Previous Topic Next Topic
 omorr #1 Posted : 21 August 2019 18:58:40(UTC) Rank: AdministrationGroups: Registered, Advanced MemberJoined: 23/06/2009(UTC)Posts: 1,740Was thanked: 318 time(s) in 268 post(s) This was mentioned on another thread regarding small numbers. Adding two small numbers will cause an error with a rather confusing message (result is above max. positive allowed number???). There should not be an error but either zero or 1.5e-115 as a result. It is even mentioned in this post that the last working version was 0.99.6824. I believe that some binary arithmetic fails here.Regards,RadovanEdited by user 21 August 2019 19:02:45(UTC)  | Reason: Not specified When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
 Wanna join the discussion?! Login to your SMath Studio Forum forum account. New Registrations are disabled.
 overlord #2 Posted : 21 August 2019 19:55:05(UTC) Rank: Advanced MemberGroups: Registered Joined: 23/07/2013(UTC)Posts: 1,133Was thanked: 515 time(s) in 344 post(s) Originally Posted by: omorr This was mentioned on another thread regarding small numbers. Adding two small numbers will cause an error with a rather confusing message (result is above max. positive allowed number???). There should not be an error but either zero or 1.5e-115 as a result. It is even mentioned in this post that the last working version was 0.99.6824. I believe that some binary arithmetic fails here.Regards,RadovanYou are right Radovan, this should be a bug. I have checked the addition on old versions.0.99.7016 (and older versions) can calculate the mentioned additon, 0.99.7100 and after doesn't.Let me clarify something, exp(709.783) is still not calculated on 0.99.6824 too.But somehow the Project Fission.sm calculations can be done with 0.99.6824.As I said on other thread, there are some serious issues over here.Regards
 omorr #3 Posted : 21 August 2019 20:36:11(UTC) Rank: AdministrationGroups: Registered, Advanced MemberJoined: 23/06/2009(UTC)Posts: 1,740Was thanked: 318 time(s) in 268 post(s) Originally Posted by: overlord ...I have checked the addition on old versions.0.99.7016 (and older versions) can calculate the mentioned additon, 0.99.7100 and after doesn't.Let me clarify something, exp(709.783) is still not calculated on 0.99.6824 too.But somehow the Project Fission.sm calculations can be done with 0.99.6824.As I said on other thread, there are some serious issues over here.RegardsI agree and thank you for checking.Regards,Radovan When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
 Jean Giraud #4 Posted : 21 August 2019 22:18:07(UTC) Rank: GuestGroups: Registered Joined: 04/07/2015(UTC)Posts: 6,866Was thanked: 981 time(s) in 809 post(s) Originally Posted by: omorr There should not be an error but either zero or 1.5e-115 as a result. It is even mentioned in this post that the last working version was 0.99.6824. I believe that some binary arithmetic fails here.For sure 7109 is freaked, not yet doctored.
 Jean Giraud #5 Posted : 21 August 2019 22:44:36(UTC) Rank: GuestGroups: Registered Joined: 04/07/2015(UTC)Posts: 6,866Was thanked: 981 time(s) in 809 post(s) Originally Posted by: Jean Giraud For sure 7109 is freaked, not yet doctored.As it looks, 7109 has been deeply victimized.Something like the American credit card Capital One [109 000 000 victims]Quebec taxation ministry [30 000 victims]Another Quebec bank [9 000 000 victims] 1 user thanked Jean Giraud for this useful post. on 22/08/2019(UTC)
 omorr #6 Posted : 22 August 2019 09:57:05(UTC) Rank: AdministrationGroups: Registered, Advanced MemberJoined: 23/06/2009(UTC)Posts: 1,740Was thanked: 318 time(s) in 268 post(s) This error message is also confusing (Numeric optimization of the region).Why some array and what index is mentioned here?Regards,Radovan When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
 overlord #7 Posted : 22 August 2019 11:09:11(UTC) Rank: Advanced MemberGroups: Registered Joined: 23/07/2013(UTC)Posts: 1,133Was thanked: 515 time(s) in 344 post(s) Originally Posted by: omorr This error message is also confusing (Numeric optimization of the region).Why some array and what index is mentioned here?Regards,RadovanThe error message is wrong here. Actually the number is bigger than maximum value of IEEE 754 double-precision standard (binary64) capability.This is why we are getting an error. (the error should be overflow, not array or index)http://en.wikipedia.org/wiki/Do...on_floating-point_formatWhich is;2^1023*(2-2^(-52))=1.79769313486232*10^308If Smath can be recoded with IEEE 754 Octuple-precision (binary256) maximum value could be;2^262143*(2−2^(−236))=1.61132571748576047361957211845200501064402387454966951747637125049607182699*10^78913RegardsEdited by user 22 August 2019 11:10:50(UTC)  | Reason: Not specified 3 users thanked overlord for this useful post. on 22/08/2019(UTC),  on 22/08/2019(UTC),  on 22/08/2019(UTC)
 overlord #8 Posted : 22 August 2019 11:19:18(UTC) Rank: Advanced MemberGroups: Registered Joined: 23/07/2013(UTC)Posts: 1,133Was thanked: 515 time(s) in 344 post(s) What I couldn't understand why Smath is giving the error below?Maximum value of IEEE754 binary64 can be calculated and shown on its own.But why do I get an error if maximum (or minimum) value is assigned to a variable?Regards 1 user thanked overlord for this useful post. on 22/08/2019(UTC)
 omorr #9 Posted : 22 August 2019 11:47:12(UTC) Rank: AdministrationGroups: Registered, Advanced MemberJoined: 23/06/2009(UTC)Posts: 1,740Was thanked: 318 time(s) in 268 post(s) As we mentionded here many times, SMath always had some serious problems with its core symbolic/numeric engine. Therefore different Optimizations introduced to overcome these problems etc. The problems still remained or reappeared here and there. See this mentioned simple example with different Optimizations. optim.sm (7kb) downloaded 15 time(s).Regards,Radovan When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" 2 users thanked omorr for this useful post. on 22/08/2019(UTC),  on 22/08/2019(UTC)
 Jean Giraud #10 Posted : 22 August 2019 19:16:50(UTC) Rank: GuestGroups: Registered Joined: 04/07/2015(UTC)Posts: 6,866Was thanked: 981 time(s) in 809 post(s) 1.5*10^309 is above 32 bit floating ^307SS 6179 replies otherwise "Result above max allowed positive number""Index above the bounds of the array" is seemingly Windows message.The function is the power function Y^X built-in at machine code level.As it looks: they call the machine code suite "array" associated withan "index" executing that suite ???Radovan, your work hard !Cheers ... Jean
 Jean Giraud #11 Posted : 22 August 2019 23:39:38(UTC) Rank: GuestGroups: Registered Joined: 04/07/2015(UTC)Posts: 6,866Was thanked: 981 time(s) in 809 post(s) Originally Posted by: overlord What I couldn't understand why Smath is giving the error below?Maximum value of IEEE754 binary64 can be calculated and shown on its own.But why do I get an error if maximum (or minimum) value is assigned to a variable?Answer is in some ways here, attached.Functions don't exist in computing machinery. They are machine code from Windows,from the Padé rational fraction [Hart et al.] 4 arithmetic operations[+,-,*,/].Their rating is 21 digits floating point -3 uncertain floating digits.Only 15 are conserved [Excel, Mathcad, Smath ...] taking into account errorpropagation from projects and by agreed convention.As it looks/demonstrated attached, Smath replaces digits above 15 by '0'.That may not be correct in some ways ?All that stuff 64 floating point is purely useless for PC on the accountof the explained above. It has surely interest for parallel computingcapable of displaying > 15 digits. No interest for Engineering project.Attached MCD is from XP Pro. 64 bits floating point. It points the > 307.Most interesting but NOT that many adepts.On the other hand, it bother my Thiele as they have to be expanded via maple. Some coefficients are so long that they can't be evaluated.I'm thus forced to run in MCD for evaluation.
 omorr #12 Posted : 25 August 2019 10:01:12(UTC) Rank: AdministrationGroups: Registered, Advanced MemberJoined: 23/06/2009(UTC)Posts: 1,740Was thanked: 318 time(s) in 268 post(s) Just to get back to the more problematic thing here. The edge of the big numbers is not so problematic as the edge of the numbers close to zero (IMHO).The main problem here is with the rather small numbers close to zero. I think that lots of calculations will fail if we deal with the numbers which have practically zero values because of the errors SMath will popup and stop calculations. I think this behavior can not be acceptable.Unfortunately, no answers yet about this problemRegards,RadovanEdited by user 25 August 2019 11:42:33(UTC)  | Reason: Not specified When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" 1 user thanked omorr for this useful post. on 25/08/2019(UTC)
 uni #13 Posted : 25 August 2019 16:32:34(UTC) Rank: Advanced MemberGroups: Registered, Advanced MemberJoined: 10/11/2010(UTC)Posts: 1,496Was thanked: 1275 time(s) in 746 post(s) There is no difference in the presentation of large and small numbers. To represent a large number, you need one long integer ( a/1 ). To represent a small number, you need long integer ( 1/a ). The problem is long integers, i.e. large numbers. It's all about this: С ⊂ Q ⊂ Z, there C - complex numbers, Q - rational numbers, Z - integers. So, if you have any number as symbolic expression this number is complex number represented with real and image parts as rational numbers represented as big integers. I don't know how it works in SMath Studio, but in Tiny.Science all numbers based on long integers. And a small number is a big number x in equation 1/x. Russia ☭ forever Viacheslav N. Mezentsev 2 users thanked uni for this useful post. on 25/08/2019(UTC),  on 26/08/2019(UTC)
 Jean Giraud #14 Posted : 25 August 2019 16:59:14(UTC) Rank: GuestGroups: Registered Joined: 04/07/2015(UTC)Posts: 6,866Was thanked: 981 time(s) in 809 post(s) Originally Posted by: omorr Just to get back to the more problematic thing here. The edge of the big numbers is not so problematic as the edge of the numbers close to zero (IMHO).The main problem here is with the rather small numbers close to zero. I think that lots of calculations will fail if we deal with the numbers which have practically zero values because of the errors SMath will popup and stop calculations. I think this behavior can not be acceptable.Unfortunately, no answers yet about this problemI have recollection [1990] zero was defined value ≤ 10e-12=0 Today is not so and anything from anything that calculates.Mathcad 11 [2003] XP Pro ... 1.7976931348623157*10^-15 = 1.7976931348623157*10^-151.7976931348623157*10^-16 = 0.000000000000000Smath result below may mean something but not to me ≤ e-15e-15 is only few layers of hydrogen atom at top of 1 km tower,i.e: not measurable.Cheers ... Jean 1 user thanked Jean Giraud for this useful post. on 25/08/2019(UTC)
 omorr #15 Posted : 25 August 2019 20:38:22(UTC) Rank: AdministrationGroups: Registered, Advanced MemberJoined: 23/06/2009(UTC)Posts: 1,740Was thanked: 318 time(s) in 268 post(s) Some more weird things regarding the presentation of numbers and optimization in SMathI agree with uni that both internal presentations of small and big numbers are equally important but SMath is obviously doing something wrong. Regards,Radovan When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
 Jean Giraud #16 Posted : 25 August 2019 21:39:26(UTC) Rank: GuestGroups: Registered Joined: 04/07/2015(UTC)Posts: 6,866Was thanked: 981 time(s) in 809 post(s) Originally Posted by: omorr I agree with uni that both internal presentations of small and big numbers are equally important but SMath is obviously doing something wrong.Floating point arithmetic floats in uncertainty.That's why all functions rated 21 decimals are truncated to 15 display.Cody Junior has a long explanation on that with different machines.The book in question is ~ 1990 or before.1.976262583364990/1.7976931348623157=1.09933255294784
 omorr #17 Posted : 26 August 2019 10:39:50(UTC) Rank: AdministrationGroups: Registered, Advanced MemberJoined: 23/06/2009(UTC)Posts: 1,740Was thanked: 318 time(s) in 268 post(s) Unfortunately, my question still remained unanswered. Is this going to stay this way or is there any chance of changing this somehow in SMath?Regards,Radovan When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
 Davide Carpi #18 Posted : 26 August 2019 11:56:00(UTC) Rank: Advanced MemberGroups: Registered, Advanced MemberJoined: 13/01/2012(UTC)Posts: 2,662Location: ItalyWas thanked: 1348 time(s) in 884 post(s) Originally Posted by: omorr Unfortunately, my question still remained unanswered. Is this going to stay this way or is there any chance of changing this somehow in SMath?I think we might try to capture the exception and return a "full 0" for such cases. To be inspected since different optimizations works in different ways (nice catches Radovan). If you like my plugins consider to support SMath Studio buying a plan; to offer me a coffee: paypal.me/dcprojects 1 user thanked Davide Carpi for this useful post. on 26/08/2019(UTC)
 omorr #19 Posted : 26 August 2019 12:16:41(UTC) Rank: AdministrationGroups: Registered, Advanced MemberJoined: 23/06/2009(UTC)Posts: 1,740Was thanked: 318 time(s) in 268 post(s) Originally Posted by: Davide Carpi Originally Posted by: omorr Unfortunately, my question still remained unanswered. Is this going to stay this way or is there any chance of changing this somehow in SMath?I think we might try to capture the exception and return a "full 0" for such cases. To be inspected since different optimizations works in different ways (nice catches Radovan).Thank you Davide for your answer and the confirmation that there is actually a problem I suppose.Regards,Radovan When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
 Jean Giraud #20 Posted : 26 August 2019 15:23:17(UTC) Rank: GuestGroups: Registered Joined: 04/07/2015(UTC)Posts: 6,866Was thanked: 981 time(s) in 809 post(s) Originally Posted by: Davide Carpi I think we might try to capture the exception and return a "full 0" for such cases. To be inspected since different optimizations works in different ways (nice catches Radovan).Thanks Davide for attending our distress !The problem appeared in the Fission project SS 7019 few weeks ago.Project turned red in the Originator document, but fine SS 6179.Mathematica 4.0 had NaN Mathcad 11.2a implemented NaN at design time of DAEP [2003]Jean Maths Overflow [Max above limit].sm (48kb) downloaded 20 time(s). Project Fission.sm (188kb) downloaded 19 time(s).
 Users browsing this topic
 Similar Topics solve small numbers (Questions) by elis02 02/11/2023 03:42:25(UTC) Evaluating Small numbers (Questions) by Aj 07/07/2013 19:10:16(UTC)
 2 Pages12>
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.