Large(ish) integers not supported

[GoogleCodeExporter]

What steps will reproduce the problem?
1. The following code throws:
mup::ParserX parser(mup::pckALL_NON_COMPLEX);
mup::Value value1{0};
mup::Variable variable1{&value1};
parser.DefineVar("v1", variable1);
parser.SetExpr("2147483648");
try {
    cout << parser.Eval().GetInteger() << endl;
} ...

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

The value is only 2^31, shouldn't values up to 2^64-1 be supported for unsigned 
(long long) integers? Is it possible to specify the type of the variable at 
compile-time (and get a parsing error if it is not used as such in the 
expression)?

Currently I'm planning to use std::enable_if<std::is_integral<... and 
enable_if<is_floating_point<... to use either parser.Eval().GetInteger() or 
parser.Eval().GetFloatingpoint() to return the correct value from the parser. 
It would be nice if all types if integers and floating points were supported...

What version of the product are you using? On what operating system?

3.0.1

Original issue reported on code.google.com by ilja.j.h...@nasa.gov on 14 Jul 2014 at 2:49

[GoogleCodeExporter]

Tests indicate that 2^31 is interpreted as a floating point value. You can use 
it in computations but you can not retrieve it with GetInteger(). This is a 
general problem since muparserx does not differentiate between double and 
integer values internally. I havn't made up my mind what to do here since it 
affects only the GetInteger function. I may end up removing GetInteger 
altogether. Maybe i merge GetInteger and GetFloat into a GetValue function.

Original comment by ib...@gmx.info on 14 Jul 2014 at 8:48

• Changed state: Accepted

[GoogleCodeExporter]

So internally muparserx always uses doubles? If there is no way to change that 
I vote for removing GetInteger. Are integers in expressions always converted to 
doubles for computations or are expressions computed with infinite precision? 
If the internal representation is always double that'd result in loss of 
precision when using large enough integers with non-zero least significant 
digits (larger than DBL_MANT_DIG or DBL_DIG?).

Original comment by ilja.j.h...@nasa.gov on 15 Jul 2014 at 2:42

[GoogleCodeExporter]

Internally muparserx is using std::complex<double> as its base type. Integers 
are always mapped to double. You will see loss of precision in integer values 
whenever the number of digits in your integer exceeds the number of digits 
returned by std::nuneric_limits<double>::digits10. You should be fine for up to 
48 bit integer values. 

Original comment by ib...@gmx.info on 15 Jul 2014 at 4:31

[GoogleCodeExporter]

I would also like to see support for large integers int64_t. I was about to try
recompiling muparserx and redefine the int typedef to int64_t, but the comments 
above
make me think this is not going work.

Original comment by Victor.W...@gmail.com on 24 Jan 2015 at 3:28

[GoogleCodeExporter]

Changed the typedef of int to in64_t. This exposed the need for a lot of 
explicit
casting to (int_type) in several library files and a lot in the unit tests.

Had to switch from clang to gcc to avoid a problem with use of undefined 
__float128.
Everything compiled file. The example mostly succeeds except for a couple of 
matrix tests.

Attached is the changed source code and the output from the example showing the 
unit test results.

Original comment by Victor.W...@gmail.com on 26 Jan 2015 at 3:46

Attachments:

• int64_muparserx.tar.bz2
• example.out

[GoogleCodeExporter]

I doubt the unit tests are sufficient now since we need to test integer values 
at the std::limit<int_type>::max() and min()

Original comment by Victor.W...@gmail.com on 26 Jan 2015 at 3:49

[GoogleCodeExporter]

I am eager to see support for large integers

Original comment by Jeffrey....@gmail.com on 26 Feb 2015 at 2:50