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

Edited by user 21 August 2019 19:02:45(UTC)  | Reason: Not specified

I agree and thank you for checking.

Regards,
Radovan

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]

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

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 16 time(s).

Regards,
Radovan

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.

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.

Some more weird things regarding the presentation of numbers and optimization in SMath



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

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

Thank you Davide for your answer and the confirmation that there is actually a problem I suppose.

Regards,
Radovan