1. bug in remainder ?
- Posted by Daniel Johnson <dpj22 at CAM.AC.UK> Feb 03, 2000
- 421 views
- Last edited Feb 04, 2000
? remainder(1,.1) .1 ? remainder(1,.01) .01 ? remainder(10,1) 1 -- Daniel Johnson Engineer, smartypants and clown Jesus College, Cambridge all at a very reasonable price dpj22 at cam.ac.uk zeus.jesus.cam.ac.uk/~dpj22 talk dpj22 at jewish.jesus.cam.ac.uk
2. Re: bug in remainder ?
- Posted by Brian Broker <bkb at CNW.COM> Feb 03, 2000
- 424 views
On Thu, 3 Feb 2000 20:21:04 +0000, Daniel Johnson wrote: >? remainder(1,.1) >.1 >? remainder(1,.01) >.01 >? remainder(10,1) >1 I get: 0.1 0.01 0 What version/platform is giving you your results? -- Brian
3. Re: bug in remainder ?
- Posted by Brian Broker <bkb at CNW.COM> Feb 03, 2000
- 409 views
On Thu, 3 Feb 2000 16:09:48 -0500, Brian Broker <bkb at CNW.COM> wrote: >On Thu, 3 Feb 2000 20:21:04 +0000, Daniel Johnson wrote: > >>? remainder(1,.1) >>.1 >>? remainder(1,.01) >>.01 >>? remainder(10,1) >>1 > >I get: >0.1 >0.01 >0 Hmmm... now that I think about it, shouldn't they all be zero? What am I missing here? ? remainder( 3.5, 1.7 ) for example, correctly outputs 0.1 -- Brian
4. Re: bug in remainder ?
- Posted by Daniel Johnson <dpj22 at CAM.AC.UK> Feb 03, 2000
- 420 views
- Last edited Feb 04, 2000
# >? remainder(1,.1) # >.1 # >? remainder(1,.01) # >.01 # >? remainder(10,1) # >1 # # I get: # 0.1 # 0.01 # 0 # # What version/platform is giving you your results? 2.2 Final Debian Linux 2.0.36 -- Daniel Johnson Engineer, smartypants and clown Jesus College, Cambridge all at a very reasonable price dpj22 at cam.ac.uk zeus.jesus.cam.ac.uk/~dpj22 talk dpj22 at jewish.jesus.cam.ac.uk
5. Re: bug in remainder ?
- Posted by Daniel Johnson <dpj22 at CAM.AC.UK> Feb 03, 2000
- 417 views
- Last edited Feb 04, 2000
# On Thu, 3 Feb 2000 16:09:48 -0500, Brian Broker <bkb at CNW.COM> wrote: # # >On Thu, 3 Feb 2000 20:21:04 +0000, Daniel Johnson wrote: # > # >>? remainder(1,.1) # >>.1 # >>? remainder(1,.01) # >>.01 # >>? remainder(10,1) # >>1 # >I get: # >0.1 # >0.01 # >0 # Hmmm... now that I think about it, shouldn't they all be zero? What am I # missing here? Oooh. Back on the list and made a fool of myself already your results are the same as mine, I just had a parity error during the serial transfer from screen to brain back to screen. I am not completely sure exactly what a remainder is when you leave the comfy world of integers, but this behaviour does seem somewhat illogical. If I had written the remainder function (and it had no bugs in) they would all be 0. Rob can you set the record straight on this one ? -- Daniel Johnson Engineer, smartypants and clown Jesus College, Cambridge all at a very reasonable price dpj22 at cam.ac.uk zeus.jesus.cam.ac.uk/~dpj22 talk dpj22 at jewish.jesus.cam.ac.uk
6. Re: bug in remainder ?
- Posted by Irv Mullins <irv at ELLIJAY.COM> Feb 03, 2000
- 423 views
On Thu, 03 Feb 2000, you wrote: > # >? remainder(1,.1) > # >.1 > # >? remainder(1,.01) > # >.01 > # >? remainder(10,1) > # >1 > # > # I get: > # 0.1 > # 0.01 > # 0 > # > # What version/platform is giving you your results? > > 2.2 Final > Debian Linux 2.0.36 > On SuSE 6.1 I get: 0.1 0.01 0 Irv
7. Re: bug in remainder ?
- Posted by Everett Williams <rett at GVTC.COM> Feb 03, 2000
- 416 views
On Thu, 3 Feb 2000 16:19:45 -0500, Brian Broker <bkb at CNW.COM> wrote: >On Thu, 3 Feb 2000 16:09:48 -0500, Brian Broker <bkb at CNW.COM> wrote: > >>On Thu, 3 Feb 2000 20:21:04 +0000, Daniel Johnson wrote: >> >>>? remainder(1,.1) >>>.1 >>>? remainder(1,.01) >>>.01 >>>? remainder(10,1) >>>1 >> >>I get: >>0.1 >>0.01 >>0 > >Hmmm... now that I think about it, shouldn't they all be zero? What am I >missing here? > >? remainder( 3.5, 1.7 ) >for example, correctly outputs 0.1 > >-- Brian Here's the definition from the manual Syntax: x3 = remainder(x1, x2) Description: Compute the remainder after dividing x1 by x2. The result will have the same sign as x1, and the magnitude of the result will be less than the magnitude of x2. Comments: The arguments to this function may be atoms or sequences. The rules for operations on sequences apply. By this, any even multiple should provide an answer of zero, but if an enterprising interpreter were to convert .01 or any other decimal value less than 0 to a float before doing the the division, the answer would always come out slightly different than one would expect because of rounding errors. To get an accurate value, one must move the decimal on both the divisor and the dividend so that both are whole numbers and then scale the remainder. ? remainder(10,1)/10 0 ? remainder(100,1)/100 0 ? remainder(10,1) 0 Everett L.(Rett) Williams rett at gvtc.com
8. Re: bug in remainder ?
- Posted by Daniel Johnson <dpj22 at CAM.AC.UK> Feb 04, 2000
- 449 views
Thanks for that extract Rett, which explains all. However here we have a problem. If remainder does not work properly with floating point numbers it should only accept integers, or there should be a work around. I have to use C++ here so if I want to use a clunky language where I am constantly forced to think of such things I can use that. Euphoria is here to set us free from having to think like a machine, and in that sense this could be considered a bug, albeit a documented one. Can the eccentric millionaire figure out a workaround for this ? -- Daniel Johnson Engineer, smartypants and clown Jesus College, Cambridge all at a very reasonable price dpj22 at cam.ac.uk zeus.jesus.cam.ac.uk/~dpj22 talk dpj22 at jewish.jesus.cam.ac.uk
9. Re: bug in remainder ?
- Posted by Robert Craig <rds at ATTCANADA.NET> Feb 03, 2000
- 415 views
- Last edited Feb 04, 2000
Daniel Johnson writes: > ? remainder(1, .1) > 0.1 > ? remainder(1, .01) > 0.01 > ? remainder(10, 1) > 0 (as he corrected himself later) The last case is obviously correct. The remainder of 10 divided by 1 is 0. The first two look wrong, but that's because we humans can represent numbers like .1 exactly in our brains, whereas Intel 64-bit floating-point has no bit pattern that corresponds exactly to .1 (or .01), so it uses something that's "very close to .1". The machine must figure that 10 is 9 times "very close to .1", plus "very close to .1". So the remainder must be "very close to .1", which looks like 0.1 when you print it, but isn't exactly 0.1. In the floating point case I simply call a C library routine to compute the result, so blame it all on C and Intel. The moral is: don't expect perfect accuracy in floating-point calculations. if 1 = .1+.1+.1+.1+.1+.1+.1+.1+.1+.1 then puts(1, "perfect floating-point\n") else puts(1, "fuzzy floating-point\n") end if Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
10. Re: bug in remainder ?
- Posted by Everett Williams <rett at GVTC.COM> Feb 04, 2000
- 414 views
Daniel Johnson wrote: >Thanks for that extract Rett, which explains all. > >However here we have a problem. If remainder does not work properly with >floating point numbers it should only accept integers, or there should be a >work around. I have to use C++ here so if I want to use a clunky language >where I am constantly forced to think of such things I can use that. Euphoria >is here to set us free from having to think like a machine, and in that sense >this could be considered a bug, albeit a documented one. Can the eccentric >millionaire figure out a workaround for this ? > Not to defend a side-effect of my least favorite aspect of Eu, but the problem with floating point decimals not adding up to the sum of their parts is as old as computing. We had the problem in Fortran programs in 1966 on the CDC 6600 that I cut my teeth on. The only way to avoid it is to reformulate every piece of math using decimals to use integers and do divides...which were then and are now the slowest instructions on many computers. With modern integer ALU's processing almost all instructions in less than one cycle, the issue is no longer as critical. The transformation, however, is quite expensive in program logic. With a compiler that only has to do the transformation once for many runs of an object program, the issue is not germane. With an interpretive or compile and go system like Eu, it can put a real kink in performance. If computers were decimal systems, the problem would be trivial, but binary math just does not map one on one to base ten math. I am convinced that COBOL programs became the dominant accounting language base because of IBM's use of the packed decimal instruction set in their mainframes. This allowed people to do normal decimal math with little consideration for the binary nature of computer storage. The problem with Eu in this situation is expectations. Since we are not supposed to know the internal format of data, we tend to take a WYSIWYG attitude towards the data that we use. Unfortunately, it ain't so and this isn't the only situation where this occurs. It also exposes the thinness of the Eu documentation. Much is left to surmise or experiment. This particular item is easy to test and expose. Other items are less so. Everett L.(Rett) Williams rett at gvtc.com
11. Re: bug in remainder ?
- Posted by Kat <gertie at ZEBRA.NET> Feb 04, 2000
- 420 views
----- Original Message ----- From: Robert Craig <rds at ATTCANADA.NET> To: <EUPHORIA at LISTSERV.MUOHIO.EDU> Sent: Thursday, February 03, 2000 7:36 PM Subject: Re: bug in remainder ? > Daniel Johnson writes: > > ? remainder(1, .1) > > 0.1 > > ? remainder(1, .01) > > 0.01 > > ? remainder(10, 1) > > 0 (as he corrected himself later) > > The last case is obviously correct. > The remainder of 10 divided by 1 is 0. > > The first two look wrong, but that's because we > humans can represent numbers like .1 exactly in our brains, > whereas Intel 64-bit floating-point has no bit pattern that > corresponds exactly to .1 (or .01), so it uses something > that's "very close to .1". The machine must figure that > 10 is 9 times "very close to .1", plus "very close to .1". > So the remainder must be "very close to .1", which looks like > 0.1 when you print it, but isn't exactly 0.1. > > In the floating point case I simply call a C library routine to > compute the result, so blame it all on C and Intel. > > The moral is: don't expect perfect accuracy > in floating-point calculations. > > if 1 = .1+.1+.1+.1+.1+.1+.1+.1+.1+.1 then > puts(1, "perfect floating-point\n") > else > puts(1, "fuzzy floating-point\n") > end if If you really need this accuracy, string math is the *only* way to get it,, otherwise, no matter what you do, the number base translations from the puter's base2 to our base10 will mess it up in unpredictable ways. Kat