Re: [Rd] bug in modulus operator %% (PR#7852)
On Thu, 12 May 2005, Kjetil Brinchmann Halvorsen wrote: Prof Brian Ripley wrote: I've now found a Windows system that does this. This is also Windows XP, fully patched, and with the same rw2010. So it may be chip-specific: the one that works is a P4 and the one that does not is a latest Pentium M. I am not sure that the guarantee on the help page has been supported for a while. I've altered the code so it is more likely to be. BTW, options(digits=20) 1 %% 0.001 [1] 0.0009792 shows why the original is not a bug in R. Why is that not a bug in R? On my machine (windows XP, rw2010 from CRAN) I Because 0 <= y %% x < y, so that adding any multiple of 0.001 takes it out of range. get: test <- function(x, y) (x %% y) + y * ( x %/% y ) # should be x test(1, 0.001) [1] 1.001 test(1, 0.1) [1] 1.1 test(1, 1) [1] 1 test(1, 0.01) [1] 1.01 and this differences (well, not the third one) cannot be said to be rounding error. I think they can. The problem is that x %/% y is affected by rounding error in the representation of 0.01, as in 1 %/% 0.01 [1] 99 on my machine. That is due to rounding error. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in modulus operator %% (PR#7852)
Prof Brian Ripley wrote: I've now found a Windows system that does this. This is also Windows XP, fully patched, and with the same rw2010. So it may be chip-specific: the one that works is a P4 and the one that does not is a latest Pentium M. I am not sure that the guarantee on the help page has been supported for a while. I've altered the code so it is more likely to be. BTW, options(digits=20) 1 %% 0.001 [1] 0.0009792 shows why the original is not a bug in R. Why is that not a bug in R? On my machine (windows XP, rw2010 from CRAN) I get: test <- function(x, y) (x %% y) + y * ( x %/% y ) # should be x > test(1, 0.001) [1] 1.001 > test(1, 0.1) [1] 1.1 > test(1, 1) [1] 1 > test(1, 0.01) [1] 1.01 and this differences (well, not the third one) cannot be said to be rounding error. Kjetil On Thu, 12 May 2005 [EMAIL PROTECTED] wrote: On Wed, 11 May 2005 [EMAIL PROTECTED] wrote: Yes, you are correct. I had only checked one of my platforms. Linux works as you suggest. But for me on Windows, x <- 1 y <- 0.2 x %/% y [1] 5 ## I get a 4 in Linux I get 5 on Windows, but (x %% y) + y * (x %/% y) [1] 1 so is there a problem particular to your Windows runtime? version _ =20 platform i386-pc-mingw32 arch i386 =20 os mingw32 =20 system i386, mingw32 =20 status =20 major2 =20 minor1.0 =20 year 2005 =20 month04=20 day 18=20 language R =20 -Original Message- From: Peter Dalgaard [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 4:14 PM To: McGehee, Robert Cc: [EMAIL PROTECTED]; Peter Dalgaard; [EMAIL PROTECTED]; [EMAIL PROTECTED]; r-devel@stat.math.ethz.ch Subject: Re: [Rd] bug in modulus operator %% (PR#7852) "McGehee, Robert" <[EMAIL PROTECTED]> writes: Yes, but from ?"%%": "It is guaranteed that 'x =3D=3D (x %% y) + y * (x %/% y)' (up to = rounding error) ..." =20 (R 2.1.0) x <- 1 y <- 0.2 x %% y [1] 0.2 (x %% y) + y * (x %/% y) [1] 1.2 =20 Certainly 1 does not equal 1.2 as the documentation would suggest, and these seem like large enough numbers to not be effected by rounding errors or lack of precision. Now that looks a bit odd, but it isn't universal: x <- 1 y <- 0.2 x %% y [1] 0.2 x %/% y [1] 4 (x %% y) + y * (x %/% y) [1] 1 So what platform was that happening on? -- Kjetil Halvorsen. Peace is the most effective weapon of mass construction. -- Mahdi Elmandjra -- No virus found in this outgoing message. Checked by AVG Anti-Virus. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] bug in modulus operator %% (PR#7852)
Could very easily be chipset, but I'm actually running a Pentium 4 myself. Pentium 4 1.9GHz, on a Windows XP Professional Version 2002 Service Professional, Service Pack 1. Also of interest, > 1 %% 0.2 [1] 0.2 > 1 %% 0.25 [1] 0 -Original Message- From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: Thursday, May 12, 2005 3:39 AM To: r-devel@stat.math.ethz.ch Subject: RE: [Rd] bug in modulus operator %% (PR#7852) I've now found a Windows system that does this. This is also Windows XP, fully patched, and with the same rw2010. So it may be chip-specific: the one that works is a P4 and the one that does not is a latest Pentium M. I am not sure that the guarantee on the help page has been supported for a while. I've altered the code so it is more likely to be. BTW, > options(digits=20) > 1 %% 0.001 [1] 0.0009792 shows why the original is not a bug in R. On Thu, 12 May 2005 [EMAIL PROTECTED] wrote: > On Wed, 11 May 2005 [EMAIL PROTECTED] wrote: > >> Yes, you are correct. I had only checked one of my platforms. Linux >> works as you suggest. But for me on Windows, >> >>> x <- 1 >>> y <- 0.2 >>> x %/% y >> [1] 5 ## I get a 4 in Linux > > I get 5 on Windows, but > >> (x %% y) + y * (x %/% y) > [1] 1 > > so is there a problem particular to your Windows runtime? > > >> >> version >> _ =20 >> platform i386-pc-mingw32 >> arch i386 =20 >> os mingw32 =20 >> system i386, mingw32 =20 >> status =20 >> major2 =20 >> minor1.0 =20 >> year 2005 =20 >> month04=20 >> day 18=20 >> language R =20 >> >> >> -Original Message- >> From: Peter Dalgaard [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, May 11, 2005 4:14 PM >> To: McGehee, Robert >> Cc: [EMAIL PROTECTED]; Peter Dalgaard; [EMAIL PROTECTED]; >> [EMAIL PROTECTED]; r-devel@stat.math.ethz.ch >> Subject: Re: [Rd] bug in modulus operator %% (PR#7852) >> >> >> "McGehee, Robert" <[EMAIL PROTECTED]> writes: >> >>> Yes, but from ?"%%": >>> "It is guaranteed that 'x =3D=3D (x %% y) + y * (x %/% y)' (up to = >> rounding >>> error) ..." >>> =20 >>> (R 2.1.0) >>>> x <- 1 >>>> y <- 0.2 >>>> x %% y >>> [1] 0.2 >>>> (x %% y) + y * (x %/% y) >>> [1] 1.2 >>> =20 >>> Certainly 1 does not equal 1.2 as the documentation would suggest, and >>> these seem like large enough numbers to not be effected by rounding >>> errors or lack of precision. >> >> Now that looks a bit odd, but it isn't universal: >> >>> x <- 1 >>> y <- 0.2 >>> x %% y >> [1] 0.2 >>> x %/% y >> [1] 4 >>> (x %% y) + y * (x %/% y) >> [1] 1 >> >> So what platform was that happening on? -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] bug in modulus operator %% (PR#7852)
I've now found a Windows system that does this. This is also Windows XP, fully patched, and with the same rw2010. So it may be chip-specific: the one that works is a P4 and the one that does not is a latest Pentium M. I am not sure that the guarantee on the help page has been supported for a while. I've altered the code so it is more likely to be. BTW, options(digits=20) 1 %% 0.001 [1] 0.0009792 shows why the original is not a bug in R. On Thu, 12 May 2005 [EMAIL PROTECTED] wrote: On Wed, 11 May 2005 [EMAIL PROTECTED] wrote: Yes, you are correct. I had only checked one of my platforms. Linux works as you suggest. But for me on Windows, x <- 1 y <- 0.2 x %/% y [1] 5 ## I get a 4 in Linux I get 5 on Windows, but (x %% y) + y * (x %/% y) [1] 1 so is there a problem particular to your Windows runtime? version _ =20 platform i386-pc-mingw32 arch i386 =20 os mingw32 =20 system i386, mingw32 =20 status =20 major2 =20 minor1.0 =20 year 2005 =20 month04=20 day 18=20 language R =20 -Original Message- From: Peter Dalgaard [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 4:14 PM To: McGehee, Robert Cc: [EMAIL PROTECTED]; Peter Dalgaard; [EMAIL PROTECTED]; [EMAIL PROTECTED]; r-devel@stat.math.ethz.ch Subject: Re: [Rd] bug in modulus operator %% (PR#7852) "McGehee, Robert" <[EMAIL PROTECTED]> writes: Yes, but from ?"%%": "It is guaranteed that 'x =3D=3D (x %% y) + y * (x %/% y)' (up to = rounding error) ..." =20 (R 2.1.0) x <- 1 y <- 0.2 x %% y [1] 0.2 (x %% y) + y * (x %/% y) [1] 1.2 =20 Certainly 1 does not equal 1.2 as the documentation would suggest, and these seem like large enough numbers to not be effected by rounding errors or lack of precision. Now that looks a bit odd, but it isn't universal: x <- 1 y <- 0.2 x %% y [1] 0.2 x %/% y [1] 4 (x %% y) + y * (x %/% y) [1] 1 So what platform was that happening on? -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] bug in modulus operator %% (PR#7852)
On Wed, 11 May 2005 [EMAIL PROTECTED] wrote: > Yes, you are correct. I had only checked one of my platforms. Linux > works as you suggest. But for me on Windows, > >> x <- 1 >> y <- 0.2 >> x %/% y > [1] 5 ## I get a 4 in Linux I get 5 on Windows, but > (x %% y) + y * (x %/% y) [1] 1 so is there a problem particular to your Windows runtime? > > version > _ =20 > platform i386-pc-mingw32 > arch i386 =20 > os mingw32 =20 > system i386, mingw32 =20 > status =20 > major2 =20 > minor1.0 =20 > year 2005 =20 > month04=20 > day 18=20 > language R =20 > > > -Original Message- > From: Peter Dalgaard [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 11, 2005 4:14 PM > To: McGehee, Robert > Cc: [EMAIL PROTECTED]; Peter Dalgaard; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; r-devel@stat.math.ethz.ch > Subject: Re: [Rd] bug in modulus operator %% (PR#7852) > > > "McGehee, Robert" <[EMAIL PROTECTED]> writes: > >> Yes, but from ?"%%": >> "It is guaranteed that 'x =3D=3D (x %% y) + y * (x %/% y)' (up to = > rounding >> error) ..." >> =20 >> (R 2.1.0) >>> x <- 1 >>> y <- 0.2 >>> x %% y >> [1] 0.2 >>> (x %% y) + y * (x %/% y) >> [1] 1.2 >> =20 >> Certainly 1 does not equal 1.2 as the documentation would suggest, and >> these seem like large enough numbers to not be effected by rounding >> errors or lack of precision. > > Now that looks a bit odd, but it isn't universal: > >> x <- 1 >> y <- 0.2 >> x %% y > [1] 0.2 >> x %/% y > [1] 4 >> (x %% y) + y * (x %/% y) > [1] 1 > > So what platform was that happening on? > > --=20 > O__ Peter Dalgaard Blegdamsvej 3 =20 > c/ /'_ --- Dept. of Biostatistics 2200 Cph. N =20 > (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 > ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 > > __ > R-devel@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in modulus operator %% (PR#7852)
[EMAIL PROTECTED] wrote: Yes, you are correct. I had only checked one of my platforms. Linux works as you suggest. But for me on Windows,=20 Certainly looks like a bug on Windows to me. I'm going offline for a day very soon now, but I'll try to remember to look into it. Duncan Murdoch x <- 1 y <- 0.2 x %/% y [1] 5 ## I get a 4 in Linux version _ =20 platform i386-pc-mingw32 arch i386 =20 os mingw32 =20 system i386, mingw32 =20 status =20 major2 =20 minor1.0 =20 year 2005 =20 month04=20 day 18=20 language R =20 -Original Message- From: Peter Dalgaard [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 4:14 PM To: McGehee, Robert Cc: [EMAIL PROTECTED]; Peter Dalgaard; [EMAIL PROTECTED]; [EMAIL PROTECTED]; r-devel@stat.math.ethz.ch Subject: Re: [Rd] bug in modulus operator %% (PR#7852) "McGehee, Robert" <[EMAIL PROTECTED]> writes: Yes, but from ?"%%": "It is guaranteed that 'x =3D=3D (x %% y) + y * (x %/% y)' (up to = rounding error) ..." =20 (R 2.1.0) x <- 1 y <- 0.2 x %% y [1] 0.2 (x %% y) + y * (x %/% y) [1] 1.2 =20 Certainly 1 does not equal 1.2 as the documentation would suggest, and these seem like large enough numbers to not be effected by rounding errors or lack of precision. Now that looks a bit odd, but it isn't universal: x <- 1 y <- 0.2 x %% y [1] 0.2 x %/% y [1] 4 (x %% y) + y * (x %/% y) [1] 1 So what platform was that happening on? --=20 O__ Peter Dalgaard Blegdamsvej 3 =20 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N =20 (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] bug in modulus operator %% (PR#7852)
Yes, you are correct. I had only checked one of my platforms. Linux works as you suggest. But for me on Windows,=20 > x <- 1 > y <- 0.2 > x %/% y [1] 5 ## I get a 4 in Linux version _ =20 platform i386-pc-mingw32 arch i386 =20 os mingw32 =20 system i386, mingw32 =20 status =20 major2 =20 minor1.0 =20 year 2005 =20 month04=20 day 18=20 language R =20 -Original Message- From: Peter Dalgaard [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 4:14 PM To: McGehee, Robert Cc: [EMAIL PROTECTED]; Peter Dalgaard; [EMAIL PROTECTED]; [EMAIL PROTECTED]; r-devel@stat.math.ethz.ch Subject: Re: [Rd] bug in modulus operator %% (PR#7852) "McGehee, Robert" <[EMAIL PROTECTED]> writes: > Yes, but from ?"%%": > "It is guaranteed that 'x =3D=3D (x %% y) + y * (x %/% y)' (up to = rounding > error) ..." >=20 > (R 2.1.0) > > x <- 1 > > y <- 0.2 > > x %% y > [1] 0.2 > > (x %% y) + y * (x %/% y) > [1] 1.2 >=20 > Certainly 1 does not equal 1.2 as the documentation would suggest, and > these seem like large enough numbers to not be effected by rounding > errors or lack of precision. Now that looks a bit odd, but it isn't universal: > x <- 1 > y <- 0.2 > x %% y [1] 0.2 > x %/% y [1] 4 > (x %% y) + y * (x %/% y) [1] 1 So what platform was that happening on? --=20 O__ Peter Dalgaard Blegdamsvej 3 =20 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N =20 (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in modulus operator %% (PR#7852)
"McGehee, Robert" <[EMAIL PROTECTED]> writes: > Yes, but from ?"%%": > "It is guaranteed that 'x == (x %% y) + y * (x %/% y)' (up to rounding > error) ..." > > (R 2.1.0) > > x <- 1 > > y <- 0.2 > > x %% y > [1] 0.2 > > (x %% y) + y * (x %/% y) > [1] 1.2 > > Certainly 1 does not equal 1.2 as the documentation would suggest, and > these seem like large enough numbers to not be effected by rounding > errors or lack of precision. Now that looks a bit odd, but it isn't universal: > x <- 1 > y <- 0.2 > x %% y [1] 0.2 > x %/% y [1] 4 > (x %% y) + y * (x %/% y) [1] 1 So what platform was that happening on? -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in modulus operator %% (PR#7852)
"McGehee, Robert" <[EMAIL PROTECTED]> writes: > Yes, but from ?"%%": > "It is guaranteed that 'x == (x %% y) + y * (x %/% y)' (up to rounding > error) ..." > > (R 2.1.0) > > x <- 1 > > y <- 0.2 > > x %% y > [1] 0.2 > > (x %% y) + y * (x %/% y) > [1] 1.2 > > Certainly 1 does not equal 1.2 as the documentation would suggest, and > these seem like large enough numbers to not be effected by rounding > errors or lack of precision. Now that looks a bit odd, but it isn't universal: > x <- 1 > y <- 0.2 > x %% y [1] 0.2 > x %/% y [1] 4 > (x %% y) + y * (x %/% y) [1] 1 So what platform was that happening on? -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] bug in modulus operator %% (PR#7852)
Yes, but from ?"%%": "It is guaranteed that 'x =3D=3D (x %% y) + y * (x %/% y)' (up to = rounding error) ..." (R 2.1.0) > x <- 1 > y <- 0.2 > x %% y [1] 0.2 > (x %% y) + y * (x %/% y) [1] 1.2 Certainly 1 does not equal 1.2 as the documentation would suggest, and these seem like large enough numbers to not be effected by rounding errors or lack of precision. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 3:25 PM To: Peter Dalgaard Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; r-devel@stat.math.ethz.ch Subject: Re: [Rd] bug in modulus operator %% (PR#7852) On 11-May-05 Peter Dalgaard wrote: > [EMAIL PROTECTED] writes: >=20 >> The following can't be right, >> first rw2010: >>=20 >> > 1 %% 0.001 >> [1] 0.001 >>=20 >> Then rw2001: >>=20 >> > 1 %% 0.001 >> [1] -2.081668e-17 >> > >>=20 >> and the last seems about right. =20 >=20 > A negative remainder? I don't think so. Presumably the result comes > from >=20 > o %% now warns if its accuracy is likely to be affected by lack > of precision (as in 1e18 %% 11, the unrealistic expectation of > PR#7409), and tries harder to return a value in range when it > is. >=20 > So, not a bug. Agreed! One should always be aware of such fuzzy edges in any case where the mathematical result depends on mathematically exact representation, as here. In such cases what I often do is on the lines of ((1000*x)%%(1000*y))/1000 Using R-2.1.0beta, first of all I get the same as Kjetil: 1 %% 0.001 ## [1] 0.001 Secondly I get (1000*1)%%(1000*0.001) ## [1] 0 Although this trick does not guarantee the exact result, it makes it more likely; and also, any little inexactness will now show up more clearly since in the form ((BIG*x) %% (BIG*y))/BIG the possible discrepancy before division by BIG is at most y in magnitude. While the properties of this trick are not entirely transparent, one can for instance compare the result of using it with the result of not using it, and then come to a decision as to which to use. A further example on the same lines is 1 %% (0.1) # [1] 1e-05 (Similar to Kjetil's first example), while ((1000*1) %% (1000*0.1))/1000 ## [1] -2.081668e-17 Any comments would be interesting! Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 11-May-05 Time: 20:13:22 -- XFMail -- __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] bug in modulus operator %% (PR#7852)
Yes, but from ?"%%": "It is guaranteed that 'x == (x %% y) + y * (x %/% y)' (up to rounding error) ..." (R 2.1.0) > x <- 1 > y <- 0.2 > x %% y [1] 0.2 > (x %% y) + y * (x %/% y) [1] 1.2 Certainly 1 does not equal 1.2 as the documentation would suggest, and these seem like large enough numbers to not be effected by rounding errors or lack of precision. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 3:25 PM To: Peter Dalgaard Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; r-devel@stat.math.ethz.ch Subject: Re: [Rd] bug in modulus operator %% (PR#7852) On 11-May-05 Peter Dalgaard wrote: > [EMAIL PROTECTED] writes: > >> The following can't be right, >> first rw2010: >> >> > 1 %% 0.001 >> [1] 0.001 >> >> Then rw2001: >> >> > 1 %% 0.001 >> [1] -2.081668e-17 >> > >> >> and the last seems about right. > > A negative remainder? I don't think so. Presumably the result comes > from > > o %% now warns if its accuracy is likely to be affected by lack > of precision (as in 1e18 %% 11, the unrealistic expectation of > PR#7409), and tries harder to return a value in range when it > is. > > So, not a bug. Agreed! One should always be aware of such fuzzy edges in any case where the mathematical result depends on mathematically exact representation, as here. In such cases what I often do is on the lines of ((1000*x)%%(1000*y))/1000 Using R-2.1.0beta, first of all I get the same as Kjetil: 1 %% 0.001 ## [1] 0.001 Secondly I get (1000*1)%%(1000*0.001) ## [1] 0 Although this trick does not guarantee the exact result, it makes it more likely; and also, any little inexactness will now show up more clearly since in the form ((BIG*x) %% (BIG*y))/BIG the possible discrepancy before division by BIG is at most y in magnitude. While the properties of this trick are not entirely transparent, one can for instance compare the result of using it with the result of not using it, and then come to a decision as to which to use. A further example on the same lines is 1 %% (0.1) # [1] 1e-05 (Similar to Kjetil's first example), while ((1000*1) %% (1000*0.1))/1000 ## [1] -2.081668e-17 Any comments would be interesting! Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 11-May-05 Time: 20:13:22 -- XFMail -- __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in modulus operator %% (PR#7852)
On 11-May-05 Peter Dalgaard wrote: > [EMAIL PROTECTED] writes: > >> The following can't be right, >> first rw2010: >> >> > 1 %% 0.001 >> [1] 0.001 >> >> Then rw2001: >> >> > 1 %% 0.001 >> [1] -2.081668e-17 >> > >> >> and the last seems about right. > > A negative remainder? I don't think so. Presumably the result comes > from > > o %% now warns if its accuracy is likely to be affected by lack > of precision (as in 1e18 %% 11, the unrealistic expectation of > PR#7409), and tries harder to return a value in range when it > is. > > So, not a bug. Agreed! One should always be aware of such fuzzy edges in any case where the mathematical result depends on mathematically exact representation, as here. In such cases what I often do is on the lines of ((1000*x)%%(1000*y))/1000 Using R-2.1.0beta, first of all I get the same as Kjetil: 1 %% 0.001 ## [1] 0.001 Secondly I get (1000*1)%%(1000*0.001) ## [1] 0 Although this trick does not guarantee the exact result, it makes it more likely; and also, any little inexactness will now show up more clearly since in the form ((BIG*x) %% (BIG*y))/BIG the possible discrepancy before division by BIG is at most y in magnitude. While the properties of this trick are not entirely transparent, one can for instance compare the result of using it with the result of not using it, and then come to a decision as to which to use. A further example on the same lines is 1 %% (0.1) # [1] 1e-05 (Similar to Kjetil's first example), while ((1000*1) %% (1000*0.1))/1000 ## [1] -2.081668e-17 Any comments would be interesting! Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 11-May-05 Time: 20:13:22 -- XFMail -- __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in modulus operator %% (PR#7852)
[EMAIL PROTECTED] writes: > The following can't be right, > first rw2010: > > > 1 %% 0.001 > [1] 0.001 > > Then rw2001: > > > 1 %% 0.001 > [1] -2.081668e-17 > > > > and the last seems about right. A negative remainder? I don't think so. Presumably the result comes from o %% now warns if its accuracy is likely to be affected by lack of precision (as in 1e18 %% 11, the unrealistic expectation of PR#7409), and tries harder to return a value in range when it is. So, not a bug. -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in modulus operator %% (PR#7852)
The following can't be right, first rw2010: > 1 %% 0.001 [1] 0.001 Then rw2001: > 1 %% 0.001 [1] -2.081668e-17 > and the last seems about right. -- Kjetil Halvorsen. Peace is the most effective weapon of mass construction. -- Mahdi Elmandjra -- No virus found in this outgoing message. Checked by AVG Anti-Virus. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel