1. bug in remainder ?
- Posted by Daniel Johnson <dpj22 at CAM.AC.UK>
Feb 03, 2000
-
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 ?
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 ?
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
-
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
-
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 ?
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 ?
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 ?
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
-
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 ?
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 ?
----- 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
