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

11 messages
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 On Wed, Jun 22, 2016 at 12:30 AM, reik red 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-- DAS _______________________________________________ Help-octave mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-octave
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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-octaveA 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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 3x = (sym) 0.333333333333333333333 * xans = (sym) 1.0000000000000000000That 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
Open this post in threaded view
|

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

 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