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

Notification

Icon
Error

Login


2 Pages12>
Options
Go to last post Go to first unread
Offline omorr  
#1 Posted : 21 August 2019 18:58:40(UTC)
omorr


Rank: Administration

Groups: Registered, Advanced Member
Joined: 23/06/2009(UTC)
Posts: 1,740
Man
Serbia

Was 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???).

addsmall.png

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,
Radovan

Edited 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.

Online overlord  
#2 Posted : 21 August 2019 19:55:05(UTC)
overlord


Rank: Advanced Member

Groups: Registered
Joined: 23/07/2013(UTC)
Posts: 1,124
Turkey

Was thanked: 506 time(s) in 337 post(s)
Originally Posted by: omorr Go to Quoted Post
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???).

addsmall.png

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,
Radovan

You 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
Offline omorr  
#3 Posted : 21 August 2019 20:36:11(UTC)
omorr


Rank: Administration

Groups: Registered, Advanced Member
Joined: 23/06/2009(UTC)
Posts: 1,740
Man
Serbia

Was thanked: 318 time(s) in 268 post(s)
Originally Posted by: overlord Go to Quoted Post

...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

I agree and thank you for checking.

Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
Offline Jean Giraud  
#4 Posted : 21 August 2019 22:18:07(UTC)
Jean Giraud

Rank: Guest

Groups: Registered
Joined: 04/07/2015(UTC)
Posts: 6,868
Canada

Was thanked: 980 time(s) in 808 post(s)
Originally Posted by: omorr Go to Quoted Post
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.

Small.PNG

Offline Jean Giraud  
#5 Posted : 21 August 2019 22:44:36(UTC)
Jean Giraud

Rank: Guest

Groups: Registered
Joined: 04/07/2015(UTC)
Posts: 6,868
Canada

Was thanked: 980 time(s) in 808 post(s)
Originally Posted by: Jean Giraud Go to Quoted Post
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]

SmallSanity.PNG

thanks 1 user thanked Jean Giraud for this useful post.
on 22/08/2019(UTC)
Offline omorr  
#6 Posted : 22 August 2019 09:57:05(UTC)
omorr


Rank: Administration

Groups: Registered, Advanced Member
Joined: 23/06/2009(UTC)
Posts: 1,740
Man
Serbia

Was thanked: 318 time(s) in 268 post(s)
This error message is also confusing (Numeric optimization of the region).

greatnumber.png

Why some array and what index is mentioned here?

Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
Online overlord  
#7 Posted : 22 August 2019 11:09:11(UTC)
overlord


Rank: Advanced Member

Groups: Registered
Joined: 23/07/2013(UTC)
Posts: 1,124
Turkey

Was thanked: 506 time(s) in 337 post(s)
Originally Posted by: omorr Go to Quoted Post
This error message is also confusing (Numeric optimization of the region).

greatnumber.png

Why some array and what index is mentioned here?

Regards,
Radovan


The 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_format

Which is;

2^1023*(2-2^(-52))=1.79769313486232*10^308

If Smath can be recoded with IEEE 754 Octuple-precision (binary256) maximum value could be;

2^262143*(2−2^(−236))=1.61132571748576047361957211845200501064402387454966951747637125049607182699*10^78913

Regards

Edited by user 22 August 2019 11:10:50(UTC)  | Reason: Not specified

thanks 3 users thanked overlord for this useful post.
on 22/08/2019(UTC),  on 22/08/2019(UTC),  on 22/08/2019(UTC)
Online overlord  
#8 Posted : 22 August 2019 11:19:18(UTC)
overlord


Rank: Advanced Member

Groups: Registered
Joined: 23/07/2013(UTC)
Posts: 1,124
Turkey

Was thanked: 506 time(s) in 337 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?

IEEE754.png

Regards
thanks 1 user thanked overlord for this useful post.
on 22/08/2019(UTC)
Offline omorr  
#9 Posted : 22 August 2019 11:47:12(UTC)
omorr


Rank: Administration

Groups: Registered, Advanced Member
Joined: 23/06/2009(UTC)
Posts: 1,740
Man
Serbia

Was 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.PNG

optim.sm (7kb) downloaded 15 time(s).

Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
thanks 2 users thanked omorr for this useful post.
on 22/08/2019(UTC),  on 22/08/2019(UTC)
Offline Jean Giraud  
#10 Posted : 22 August 2019 19:16:50(UTC)
Jean Giraud

Rank: Guest

Groups: Registered
Joined: 04/07/2015(UTC)
Posts: 6,868
Canada

Was thanked: 980 time(s) in 808 post(s)
1.5*10^309 is above 32 bit floating ^307
SS 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 with
an "index" executing that suite ???
Radovan, your work hard !
Cheers ... Jean
Offline Jean Giraud  
#11 Posted : 22 August 2019 23:39:38(UTC)
Jean Giraud

Rank: Guest

Groups: Registered
Joined: 04/07/2015(UTC)
Posts: 6,868
Canada

Was thanked: 980 time(s) in 808 post(s)
Originally Posted by: overlord Go to Quoted Post
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 error
propagation 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 account
of the explained above. It has surely interest for parallel computing
capable 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.

Result_Smath.PNG

Result_MCD.bmp



Offline omorr  
#12 Posted : 25 August 2019 10:01:12(UTC)
omorr


Rank: Administration

Groups: Registered, Advanced Member
Joined: 23/06/2009(UTC)
Posts: 1,740
Man
Serbia

Was 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 problem

Regards,
Radovan

Edited 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!"
thanks 1 user thanked omorr for this useful post.
on 25/08/2019(UTC)
Offline uni  
#13 Posted : 25 August 2019 16:32:34(UTC)
uni


Rank: Advanced Member

Groups: Registered, Advanced Member
Joined: 10/11/2010(UTC)
Posts: 1,493
Man
Russian Federation

Was thanked: 1274 time(s) in 745 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
thanks 2 users thanked uni for this useful post.
on 25/08/2019(UTC),  on 26/08/2019(UTC)
Offline Jean Giraud  
#14 Posted : 25 August 2019 16:59:14(UTC)
Jean Giraud

Rank: Guest

Groups: Registered
Joined: 04/07/2015(UTC)
Posts: 6,868
Canada

Was thanked: 980 time(s) in 808 post(s)
Originally Posted by: omorr Go to Quoted Post
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 problem

I 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^-15
1.7976931348623157*10^-16 = 0.000000000000000

Smath result below may mean something but not to me ≤ e-15
e-15 is only few layers of hydrogen atom at top of 1 km tower,
i.e: not measurable.

Cheers ... Jean

Zero.PNG
thanks 1 user thanked Jean Giraud for this useful post.
on 25/08/2019(UTC)
Offline omorr  
#15 Posted : 25 August 2019 20:38:22(UTC)
omorr


Rank: Administration

Groups: Registered, Advanced Member
Joined: 23/06/2009(UTC)
Posts: 1,740
Man
Serbia

Was thanked: 318 time(s) in 268 post(s)
Some more weird things regarding the presentation of numbers and optimization in SMath

smallnumbers.PNG

I 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!"
Offline Jean Giraud  
#16 Posted : 25 August 2019 21:39:26(UTC)
Jean Giraud

Rank: Guest

Groups: Registered
Joined: 04/07/2015(UTC)
Posts: 6,868
Canada

Was thanked: 980 time(s) in 808 post(s)
Originally Posted by: omorr Go to Quoted Post
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

Small_Uncertain.PNG
Offline omorr  
#17 Posted : 26 August 2019 10:39:50(UTC)
omorr


Rank: Administration

Groups: Registered, Advanced Member
Joined: 23/06/2009(UTC)
Posts: 1,740
Man
Serbia

Was 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!"
Offline Davide Carpi  
#18 Posted : 26 August 2019 11:56:00(UTC)
Davide Carpi


Rank: Advanced Member

Groups: Registered, Advanced Member
Joined: 13/01/2012(UTC)
Posts: 2,639
Man
Italy
Location: Italy

Was thanked: 1323 time(s) in 873 post(s)
Originally Posted by: omorr Go to Quoted Post
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
thanks 1 user thanked Davide Carpi for this useful post.
on 26/08/2019(UTC)
Offline omorr  
#19 Posted : 26 August 2019 12:16:41(UTC)
omorr


Rank: Administration

Groups: Registered, Advanced Member
Joined: 23/06/2009(UTC)
Posts: 1,740
Man
Serbia

Was thanked: 318 time(s) in 268 post(s)
Originally Posted by: Davide Carpi Go to Quoted Post
Originally Posted by: omorr Go to Quoted Post
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!"
Offline Jean Giraud  
#20 Posted : 26 August 2019 15:23:17(UTC)
Jean Giraud

Rank: Guest

Groups: Registered
Joined: 04/07/2015(UTC)
Posts: 6,868
Canada

Was thanked: 980 time(s) in 808 post(s)
Originally Posted by: Davide Carpi Go to Quoted Post
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

SmallSanityWiki.PNG

Maths Overflow [Max above limit].sm (48kb) downloaded 20 time(s).
Project Fission.sm (188kb) downloaded 19 time(s).

Users browsing this topic
Guest
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.