variable precision arithmetic (vpa) errant results in windows 10, octave-4.0.1

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

variable precision arithmetic (vpa) errant results in windows 10, octave-4.0.1

reik red

The following problem with vpa (variable precision arithmetic) occurs only in octave-4.0.1 win10 32b version and not in the linux 64b version. As you can see, the number "1/3" is inaccurately represented when digits is greater than 16 (which happens to be roughly the native precision of a double, and perhaps that is not a coincidence).

I wanted to try this also in octave-4.0.2, but I had trouble installing the symbolic package (contains vpa function) .

Any thoughts on what is going on here?

----------------------------------------------------------------------------------------------------------------

%this is in  win10 64b with octave 4.0.1 32b for windows (not cygwin version, not 64b version)

>> pkg load symbolic

>> x=vpa(1/3,21)
OctSymPy v2.4.0: this is free software without warranty, see source.
Initializing communication with SymPy using a popen2() pipe.
Using winwrapy.bat workaround for bug #43036 (Octave <= 4.0.2, on Windows)
Some output from the Python subprocess (pid 968) might appear next.

OctSymPy: Communication established.  SymPy v1.0.
Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AM
D64)]
x = (sym) 0.333333333333333314830
>> x=vpa(1/3,19)
x = (sym) 0.3333333333333333148
>> x=vpa(1/3,30)
x = (sym) 0.333333333333333314829616256247
>> x=vpa(1/3,20)
x = (sym) 0.33333333333333331483
>> x=vpa(1/3,10)
x = (sym) 0.3333333333
>> x=vpa(1/3,15)
x = (sym) 0.333333333333333
>> x=vpa(1/3,16)
x = (sym) 0.3333333333333333
>> x=vpa(1/3,17)
x = (sym) 0.33333333333333331

>> version
ans = 4.0.1
>> uname
ans =
  scalar structure containing the fields:
    sysname = MINGW32_NT-6.2
    nodename = *
    release = Windows 6.2
    version =
    machine = i686

This is the python version I use

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------------------------------------------------------------------------------------------------------------


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: variable precision arithmetic (vpa) errant results in windows 10, octave-4.0.1

Doug Stewart-4


On Wed, Jun 22, 2016 at 12:30 AM, reik red <[hidden email]> wrote:

The following problem with vpa (variable precision arithmetic) occurs only in octave-4.0.1 win10 32b version and not in the linux 64b version. As you can see, the number "1/3" is inaccurately represented when digits is greater than 16 (which happens to be roughly the native precision of a double, and perhaps that is not a coincidence).

I wanted to try this also in octave-4.0.2, but I had trouble installing the symbolic package (contains vpa function) .

Any thoughts on what is going on here?

----------------------------------------------------------------------------------------------------------------

%this is in  win10 64b with octave 4.0.1 32b for windows (not cygwin version, not 64b version)

>> pkg load symbolic

>> x=vpa(1/3,21)
OctSymPy v2.4.0: this is free software without warranty, see source.
Initializing communication with SymPy using a popen2() pipe.
Using winwrapy.bat workaround for bug #43036 (Octave <= 4.0.2, on Windows)
Some output from the Python subprocess (pid 968) might appear next.

OctSymPy: Communication established.  SymPy v1.0.
Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AM
D64)]
x = (sym) 0.333333333333333314830
>> x=vpa(1/3,19)
x = (sym) 0.3333333333333333148
>> x=vpa(1/3,30)
x = (sym) 0.333333333333333314829616256247
>> x=vpa(1/3,20)
x = (sym) 0.33333333333333331483
>> x=vpa(1/3,10)
x = (sym) 0.3333333333
>> x=vpa(1/3,15)
x = (sym) 0.333333333333333
>> x=vpa(1/3,16)
x = (sym) 0.3333333333333333
>> x=vpa(1/3,17)
x = (sym) 0.33333333333333331

>> version
ans = 4.0.1
>> uname
ans =
  scalar structure containing the fields:
    sysname = MINGW32_NT-6.2
    nodename = *
    release = Windows 6.2
    version =
    machine = i686

This is the python version I use

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------------------------------------------------------------------------------------------------------------


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave


try
>> x=vpa('1/3',27)

what is happening with your tries was  the octave interpreter was doing the 1/3 before
 it sent it to vpa

--
DASCertificate for 206392


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: variable precision arithmetic (vpa) errant results in windows 10, octave-4.0.1

Colin Macdonald-2
In reply to this post by reik red
On 21/06/16 21:30, reik red wrote:
> As you can see, the number "1/3" is inaccurately represented when digits

I haven't read all that but have you read "help vpa"?

There are ok:

vpa("1/3", 64)
vpa(sym(1)/3, 64)
vpa(1, 64)

Whereas vpa(1/3, 64) first creates the a double precision floating point
number near 1/3 and then converts it to have 64 digits, which must be lossy.

Colin

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: variable precision arithmetic (vpa) errant results in windows 10, octave-4.0.1

Colin Macdonald-2
On 22/06/16 08:31, Colin Macdonald wrote:
> On 21/06/16 21:30, reik red wrote:
>> As you can see, the number "1/3" is inaccurately represented when digits
>
> I haven't read all that but have you read "help vpa"?

That sounds ruder than I intended (maillist before coffee, sorry).

Let me follow up with a question: "vpa" could explicitly warn when you
give it a double (which is not a smallish integer).  This is how "sym"
behaves.  Do you think that would be a good thing?

I originally figured that might be annoying for someone who understands
and wants "vpa(1/3)"... but maybe those people can simply disable the error.

Thoughts?

thanks,
Colin

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: variable precision arithmetic (vpa) errant results in windows 10, octave-4.0.1

Oliver Heimlich
Am 22. Juni 2016 17:44:21 MESZ, schrieb Colin Macdonald <[hidden email]>:

>On 22/06/16 08:31, Colin Macdonald wrote:
>> On 21/06/16 21:30, reik red wrote:
>>> As you can see, the number "1/3" is inaccurately represented when
>digits
>>
>> I haven't read all that but have you read "help vpa"?
>
>That sounds ruder than I intended (maillist before coffee, sorry).
>
>Let me follow up with a question: "vpa" could explicitly warn when you
>give it a double (which is not a smallish integer).  This is how "sym"
>behaves.  Do you think that would be a good thing?
>
>I originally figured that might be annoying for someone who understands
>
>and wants "vpa(1/3)"... but maybe those people can simply disable the
>error.
>
>Thoughts?
>
>thanks,
>Colin
>
>_______________________________________________
>Help-octave mailing list
>[hidden email]
>https://lists.gnu.org/mailman/listinfo/help-octave

A warning could help new users.

There is the exactly same issue in the interval package. If you want to implement this feature in the construtors (maybe with a regexp to identify fractions and decimal numbers) we should use the same warning id.

Oliver

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: variable precision arithmetic (vpa) errant results in windows 10, octave-4.0.1

Jordi Gutiérrez Hermoso-2
In reply to this post by Colin Macdonald-2
On Wed, 2016-06-22 at 08:31 -0700, Colin Macdonald wrote:

> Whereas vpa(1/3, 64) first creates the a double precision floating
> point number near 1/3 and then converts it to have 64 digits, which
> must be lossy.

"Lossy" is a funny word to use here, as vpa("1/3", 64) is also lossy,
but you are prescribing how much you want to lose. :-)

- Jordi G. H.



_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: variable precision arithmetic (vpa) errant results in windows 10, octave-4.0.1

Colin Macdonald-2
On 22/06/16 11:04, Jordi Gutiérrez Hermoso wrote:
> "Lossy" is a funny word to use here, as vpa("1/3", 64) is also lossy,
> but you are prescribing how much you want to lose. :-)

:)  What do you think about adding a warning?  (one that does not use
the term "lossy" perhaps).

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: variable precision arithmetic (vpa) errant results in windows 10, octave-4.0.1

reik red
In reply to this post by Oliver Heimlich
Thanks, Colin. Indeed I made a blunder. I included quotes when I tested on linux but no quotes when I tested in windows. A warning sounds like a good idea, perhaps something like

"vpa: unquoted expressions made only of numerical constants (numbers) will be evaluated as double floats before being passed into vpa (is that what you wanted?)"

But I am at the same time a bit surprised by how sym() works, and wondering whether vpa() should behave the same way or not. It looks to me like sym gives a warning but then actually gets the accurate answer anyway, as follows:

x = vpa (sym (1 / 3), 20)
warning: Using rat() heuristics for double-precision input (is this what you wanted?)
warning: called from
    sym at line 225 column 7
    vpatest at line 11 column 3
x = (sym) 0.33333333333333333333
3 * x
ans = (sym) 1.0000000000000000000

That is surprising to me. It appears that the argument to sym() is not evaluated by the octave parser, but rather by the sym() function itself, whether the argument is a (quoted) string or not! Clearly I lack knowledge of how the internals of octave function calls work, but this surprised me! Let me pose the following question: If vpa() behaved the same way as sym(), would leaving out the quotes be safe for all cases of constant numerical expressions? Is that a desirable behavior?

I'm not intentionally trying to stir up any trouble here, just wondering what the thinking and mechanism behind the observed behavior is. Perhaps also I have misunderstood something ;).



_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: variable precision arithmetic (vpa) errant results in windows 10, octave-4.0.1

Colin Macdonald-2
On 22/06/16 11:26, Reik Reid wrote:
> But I am at the same time a bit surprised by how sym() works

sym(1/3) cannot get inside the double either: 1/3 happens in Octave
before we (sym) ever see it.

you need "sym(1)/3".

Colin

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: variable precision arithmetic (vpa) errant results in windows 10, octave-4.0.1

Colin Macdonald-2
In reply to this post by reik red
On 22/06/16 11:26, Reik Reid wrote:
> If vpa() behaved the same way as sym(), would leaving out the quotes be
> safe for all cases of constant numerical expressions? Is that a
> desirable behavior?

There is a relatively small set of values were its safe to leave off the
quotes, for both sym and vpa.  That set is "small" integers, inf, nan,
and pi.  The latter just for convenience (might have been a bad idea).


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: variable precision arithmetic (vpa) errant results in windows 10, octave-4.0.1

reik red
Thank you for your insights and for writing vpa() and sym() and probably a ton of other stuff hat I have not seen yet.


On 06/22/16 14:34, Colin Macdonald wrote:
> On 22/06/16 11:26, Reik Reid wrote:
>> If vpa() behaved the same way as sym(), would leaving out the quotes be
>> safe for all cases of constant numerical expressions? Is that a
>> desirable behavior?
>
> There is a relatively small set of values were its safe to leave off the quotes, for both sym and vpa.  That set is
> "small" integers, inf, nan, and pi.  The latter just for convenience (might have been a bad idea).
>


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave