Result correctness

[GoogleCodeExporter]

What steps will reproduce the problem?
1. enter sin(pi)
2. wait
3. wait

What is the expected output? What do you see instead?


Well, numerically correct result is 0, but engine returns "very small number" 
which is caused by "incorrect" double precision number representation. Do you 
have any ideas on how to solve this? I would suggest either implementing "more 
accurrate" float-number data type or there could some kind of number "rounding".

Original issue reported on code.google.com by Rotter.M...@gmail.com on 24 Jan 2013 at 9:35

[GoogleCodeExporter]

I understand the ugliness of the result but as long as its within the bounds of 
the expected floating point accuracy there is not much i can do. Normally you 
should be able to change the floating point data type to long double but i 
havn't tried it in a while so it will likely not work without minor 
modifications. 

The only thing i can do is ensure the next release will compile with long 
double as its datatype. I'm not sure about "truncating" the result due to 
performance reasons but won't rule out implementing it either as i already do 
it for bogus imaginary parts of the result in some places of the code.

Original comment by ib...@gmx.info on 27 Jan 2013 at 2:27

[GoogleCodeExporter]

What about trying to make muparserx usable with gmp? It would amazing because i 
believe that numerical correctness is the last thing missing in muparserx, i 
did not findy any other major problems.

http://gmplib.org/

Original comment by Rotter.M...@gmail.com on 27 Jan 2013 at 8:32

[GoogleCodeExporter]

I'm about to close this issue as it is more of a feature request than a bug. As 
long as the result is within the bounds of the floating point accuracy i don't 
consider it a parser issue. googling for the problem shows even matlab having 
(had?) this issue. I would argue against needlessly "snapping" the result to 
zero as it is basically hiding the fact that i can't define pi with sufficient 
accuracy and i can't compute with absolute accuracy either.

Your suggestion of using gmplib is interesting but there are some obstacles: 
1.) gmplib is licences under the LGPL. Interfacing it would require changing 
the muparserx licence to LGPL. This is something i object to.
2.) I'm not entirely sure whether gmplib, respectively its C++ wrapper could 
work with std::complex and whether it has the necessary functions to support 
most of the muparserx functionality.
3.) I don't want any additional dependencies in muparser. The archive should 
compile without the need to install any additional library.

In general i think this is actually a good idea but i don't see this happening 
in the near future due to the issues mentioned above and a lack of time on my 
side. The good thing is that muparserx is open source and if anyone wants to 
take the initiative with a fork i would be willing to assist.

Original comment by ib...@gmx.info on 29 Jan 2013 at 10:32

[GoogleCodeExporter]

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

• Changed state: Done
• Added labels: Type-Enhancement
• Removed labels: Type-Defect