Solving overflows!

[GoogleCodeExporter]

There are certain inconsistencies concerning numerical overflows. Just 
binary/hexa -> decimal conversions are protected against overflows (error is 
thrown when numbers overflow).

But it could be good to guard overflows for all operations: basically just try 
to evaluate "19 << 222". Apparently, negative result is incorrect.

Solution: there are ways to detect overflows. I do it by 
http://pastebin.com/MTuyje6s, i added additional exception type, this is 
generally enough + it is easy to do special checks eg. for factorial where you 
expect numbers <1;+INF). What do you think about it?

Original issue reported on code.google.com by Rotter.M...@gmail.com on 31 Jan 2013 at 6:43

[GoogleCodeExporter]

Original comment by Rotter.M...@gmail.com on 4 Feb 2013 at 1:30

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by Rotter.M...@gmail.com on 4 Feb 2013 at 1:37

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Overflows will be fighted on per-operator/function basis.

Started with safe factorial postfix operator.

Original comment by Rotter.M...@gmail.com on 4 Feb 2013 at 7:29

• Changed state: Started

[GoogleCodeExporter]

Thinking about something similar to this:

http://stackoverflow.com/questions/199333/best-way-to-detect-integer-overflow-in
-c-c

Original comment by Rotter.M...@gmail.com on 5 Feb 2013 at 7:43

• Added labels: Type-Defect, Priority-Medium
• Removed labels: Type-Enhancement, Priority-Low

[GoogleCodeExporter]

added initial overflow detection for "<<".

Original comment by Rotter.M...@gmail.com on 5 Feb 2013 at 6:29

[GoogleCodeExporter]

somewhat related: I changed the code to allow passing of ecDOMAIN_ERROR and 
ecOVERFLOW without converting it to ecEVAL.

Original comment by ib...@gmx.info on 5 Feb 2013 at 10:55

[GoogleCodeExporter]

There is no real problem with overflows in general. IEEE-754 will properly 
translate overflows to nan respectively +/-inf. For instance: 10^1234 will 
yield +inf which is exactly what i would expect. Similar results for 
1/(insanely small value). The only issue i found so far is that muparserx does 
not interpret insanely high values like "1e1234" properly. This should be fixed 
though but apart from this ther is no problem with relying on the mechanism 
provided by IEEE-754.

Original comment by ib...@gmx.info on 23 Feb 2013 at 10:26

[GoogleCodeExporter]

The only remaining issue (incorrect parsing of "1e1234" or "1e-1234") are 
resolved now.

Original comment by ib...@gmx.info on 8 Jul 2013 at 9:37

• Changed state: Fixed