Mon 09 Oct 2017 09:00:20 PM UTC, comment #10:
I posted this upstream https://github.com/sympy/sympy/issues/13425
As I said below, I don't really think there is a bug here. Its more like: there is something you should not be doing (putting floats into vpa and expected more than 15 digits accuracy) but in some very specific cases (integer powers of two), we can nonetheless recover accuracy.
A better fix might be to have vpa look for decimal points in strings and raise a warning (like the rat warning in sym).
|
Sun 08 Oct 2017 10:45:15 PM UTC, comment #9:
I'll do it and post the link back here...
|
Sun 08 Oct 2017 08:07:09 PM UTC, comment #8:
I had looked briefly at the list of open issues on SymPy but I wasn't able to find one similar to this that is open or that had been reported. Colin, do you want to raise this with SymPy? If not I can do it.
|
Sun 08 Oct 2017 05:07:22 PM UTC, comment #7:
Mike: No, I haven't. I don't really feel I'm suited for that, due to my very limited Python/SymPy knowledge
|
Sun 08 Oct 2017 04:09:49 PM UTC, comment #6:
Luis - have you discussed this with SymPy yet?
|
Mon 14 Aug 2017 11:10:20 PM UTC, comment #5:
This one is not wrong:
There python has done a floating point computation which we then ask to magically convert to 30 digits accuracy. That aint gonna happen: the computation was already done in lower precision.
The case with the string is less obvious:
This depends on exactly what SymPy promises for string input to N. I'm not sure what is promised (docs don't say you're supposed to pass strings to N at all) but what is done currently in practice is pass the input to `sympify` which will evaluate that expression (that is compute a double precision floating point).
Interestingly, one can do this:
I'm not sure that would be a good change for SymPy or not: but as Mike as said, that's a discussion for upstream.
|
Mon 14 Aug 2017 03:56:14 PM UTC, comment #4:
Yeah, sorry, I thought there was a difference between Octave's and Sympy's results, but actually they are the same (and wrong)
|
Mon 14 Aug 2017 03:43:25 PM UTC, comment #3:
So this looks like something you may want to get improved in SymPy? Please link to a SymPy issue tracker if so, or we can mark this as won't fix.
|
Mon 14 Aug 2017 01:09:43 PM UTC, comment #2:
Sympy version with strings also gives wrong results (sorry for so many messages). So Octave does the same as Sympy.
gives
|
Mon 14 Aug 2017 01:00:27 PM UTC, comment #1:
Sorry, I forgot the relevant Sympy case. It works the same as Octave:
gives
|
Mon 14 Aug 2017 09:59:26 AM UTC, original submission:
Running these statements in Octave
produces the following results, the fourth of which is not correct:
This is strange, specially considering that .5 is represented exactly as a float (see third statement).
For reference, SymPy produces the correct result:
gives
|