Bad handling of overflow

[Former user]

Originally reported on Google Code with ID 53

What steps will reproduce the problem?
1. Enter the expression exp(exp(exp(exp(2
2. Enter the brackets.

What is the expected output? What do you see instead?
I don't know:). Instead, it freezes. After a long time it works again, but 
freezes for several minutes on evaluating the expression. It then gives 
the correct answer.

What version of the product are you using? On what operating system?
0.7 Windows XP Professional SP2

Please provide any additional information below.
There must be a problem in the way it calculates exponentials.

Reported by lucaslevin on 2007-06-24 10:32:52

[Former user]

``` Thank very much you for your report. I've tried this in trunk and still happens. It only happens with exp as far as I could verify. Marking issue as accepted. ```

Reported by `helder.pereira.correia` on 2007-06-24 12:54:46 - Status changed: `Accepted` - Labels added: Milestone-0.8

[Former user]

``` IMHO it's not necessarily a bug, just a really huge number. Trying the expression in bc gives me

e(e(e(e(2)))) Runtime warning (func=e, adr=86): scale too large, set to 2147483647 Fatal error: Out of memory for malloc.

And I already have 2GB of memory in my machine.

According to bc, even "exp(exp(exp(2)))" results a number with several hundred digits. SC gives "0e702" here. Not exactly sure what that is supposed to mean, though. 1e702 I could understand :)

```

Reported by `ogre.crewman` on 2007-06-25 15:23:24

[Former user]

``` ogre.crewman is right, but still there must be a way to prevent this. I mean, the evaluator should detect such situations and return the message "unable to evaluate expression" or something similar. Any idea? ```

Reported by `helder.pereira.correia` on 2007-06-25 16:43:20 - Status changed: `New`

[Former user]

``` The floatnum engine, which I'm currently working on, does not have these problems. Overflow is checked in advance, and numbers are strictly limited in their size.

Wolf Lammen ```

Reported by `[e-mail]` on 2007-06-25 19:33:06

[Former user]

``` and, by the way, I think, it is none of the business of the evaluator to check for overflow. This unit does the syntactical analysis of input, it never computes anything, so it cannot determine overflow/underflow at all. This has to be reported by the layer beneath, that is the engine encoded in hmath/hnumber.

Wolf Lammen ```

Reported by `[e-mail]` on 2007-06-25 19:48:12

[Former user]

``` My mistake, I didn't mean the evaluator component but the mathematical engine instead. I'm looking forward to your new engine, it's looking very promising :) Meanwhile, I think we should do something on the current engine to prevent the program from freezing for minutes (or even many seconds) due to an overflow. ```

Reported by `helder.pereira.correia` on 2007-06-25 20:03:22

[Former user]

``` Let's ignore this for now, since it will become obsolete with the new upcoming engine. We'll mark it as Fixed when it's really not an issue anymore. It will stay as accepted and targetted for milestone 0.9 for now. Also changing the title, since it's not only related to EXP. ```

Reported by `helder.pereira.correia` on 2007-07-04 21:29:48 - Status changed: `Accepted` - Labels added: Milestone-0.9 - Labels removed: Milestone-0.8

[Former user]

``` fixed in trunk ```

Reported by `wolf.lammen` on 2007-08-08 21:14:03 - Status changed: `Fixed`

[Former user]

Reported by `wolf.lammen` on 2007-08-08 21:15:35 - Status changed: `Accepted`

[Former user]

``` Mark as Fixed ```

Reported by `ariya.hidayat` on 2007-08-09 10:56:40 - Status changed: `Fixed`

[Former user]

Reported by `helder.pereira.correia` on 2007-08-09 11:30:30