1. remainder() is not right
The remainder of x by y, which remainder() is supposed to return, is the number
with the smallest magnitude and the sign of y such that, if we call it z, x-z is
a multiple of y.
But remainder() has a quirkier response. For instance:
?remainder(-27,3600) -- -27, instead of 3573
?remainder(-3627,3600) -- ditto
?remainder(-3627,-3600) -- -27 is correct here
?remainder(27,-3600) -- 27, instead of -3573
Changing remainder()'s behaviour will break any code that works around this
behaviour. So perhaps should we add another function with the appropriate return
values; perhaps signed_remainder()?
Notionally, it might work like this:
global function signed_remainder(object a,object b)
integer atom_a,atom_b
atom c
if find(b,{{},0.0} then
return {} -- not a valid 2nd argument
-- crash("Invalid 2nd argument to remainder()")
end if
atom_a=atom(a)
atom_b=atom(b)
if atom_a!=atom_b then
if atom_a then -- atom,sequence
for i=1 to length(b) do
b[i]=signed_remainder(a,b[i])
end for
return b
else -- sequence,atom
for i=1 to length(a) do
a[i]=signed_remainder(a[i],b)
end for
return a
end if
elsif atom_a=0 then -- two sequences
if length(a)!=length(b) then
return {} -- let caller handle the mismatch
-- crash("Sequence lengths don't match")
else
for i=1 to length(a) do
a[i]=signed_remainder(a[i],b[i])
end for
return a
end if
else -- two atoms
c=remainder(a,b) -- smallest magnitude and sign of a
if a<0!=b<0 then
return c+b
else
return c
end if
end function
It will be probably better implemented as a builtin if there is a corresponding
C stdlib function with the desired behaviour. If only to take advantage of the
sequence extension mechanism binary_op() in be_runtime.c provides.
CChris
2. Re: remainder() is not right
> On 4 May 2008 at 6:16, CChris wrote (maybe snipped):
> The remainder of x by y, which remainder() is supposed to return, is
> the number with the smallest magnitude and the sign of y such that, if
> we call it z, x-z is a multiple of y.
>
> But remainder() has a quirkier response. For instance:
> ?remainder(-27,3600) -- -27, instead of 3573
> ?remainder(-3627,3600) -- ditto
> ?remainder(-3627,-3600) -- -27 is correct here
> ?remainder(27,-3600) -- 27, instead of -3573
>
Chris, IMHO actual results are coherent to function's description
found in Refman, or am I missing something? Isn't it supposed to
return the remainder of division of the first element by the second?
Best,
Euler
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
_| -----------------------------
_| Reply preferably to the list,
_| or to the address above. Thx!
3. Re: remainder() is not right
I get the same result as euphoria with the following C code compiled with bcc55
#include <stdio.h>
int main(int argc, char** argv){
printf("%d\n",-27 % 3600);
printf("%d\n",-3627 % 3600);
printf("%d\n",-3627 % -3600);
printf("%d\n",27 % -3600);
}
Jacques Deschênes
CChris wrote:
>
>
> The remainder of x by y, which remainder() is supposed to return, is the
> number
> with the smallest magnitude and the sign of y such that, if we call it z, x-z
> is a multiple of y.
>
> But remainder() has a quirkier response. For instance:
> ?remainder(-27,3600) -- -27, instead of 3573
> ?remainder(-3627,3600) -- ditto
> ?remainder(-3627,-3600) -- -27 is correct here
> ?remainder(27,-3600) -- 27, instead of -3573
>
> Changing remainder()'s behaviour will break any code that works around this
> behaviour. So perhaps should we add another function with the appropriate
> return
> values; perhaps signed_remainder()?
>
> Notionally, it might work like this:
> }}}
<eucode>
> global function signed_remainder(object a,object b)
> integer atom_a,atom_b
> atom c
>
> if find(b,{{},0.0} then
> return {} -- not a valid 2nd argument
> -- crash("Invalid 2nd argument to remainder()")
> end if
> atom_a=atom(a)
> atom_b=atom(b)
> if atom_a!=atom_b then
> if atom_a then -- atom,sequence
> for i=1 to length(b) do
> b[i]=signed_remainder(a,b[i])
> end for
> return b
> else -- sequence,atom
> for i=1 to length(a) do
> a[i]=signed_remainder(a[i],b)
> end for
> return a
> end if
> elsif atom_a=0 then -- two sequences
> if length(a)!=length(b) then
> return {} -- let caller handle the mismatch
> -- crash("Sequence lengths don't match")
> else
> for i=1 to length(a) do
> a[i]=signed_remainder(a[i],b[i])
> end for
> return a
> end if
> else -- two atoms
> c=remainder(a,b) -- smallest magnitude and sign of a
> if a<0!=b<0 then
> return c+b
> else
> return c
> end if
> end function
> </eucode>
{{{
>
> It will be probably better implemented as a builtin if there is a
> corresponding
> C stdlib function with the desired behaviour. If only to take advantage of the
> sequence extension mechanism binary_op() in be_runtime.c provides.
>
> CChris
4. Re: remainder() is not right
In fact remainder(x,y) means q*y+r=x
so
remainder(-27,3600)= (-27) is ok as 0*3600+(-27)=(-27)
remainder(-3627,3600)=(-27) is ok as -1*3600+(-27)=(-3627)
remainder(-3627,-3600) = -27 is ok as 1*(-3600)+(-27)=(-3627)
remainder(27,-3600) = 27 is ok as 0*3600+ 27 = 27
Jacques Deschênes
CChris wrote:
>
>
> The remainder of x by y, which remainder() is supposed to return, is the
> number
> with the smallest magnitude and the sign of y such that, if we call it z, x-z
> is a multiple of y.
>
> But remainder() has a quirkier response. For instance:
> ?remainder(-27,3600) -- -27, instead of 3573
> ?remainder(-3627,3600) -- ditto
> ?remainder(-3627,-3600) -- -27 is correct here
> ?remainder(27,-3600) -- 27, instead of -3573
>
> Changing remainder()'s behaviour will break any code that works around this
> behaviour. So perhaps should we add another function with the appropriate
> return
> values; perhaps signed_remainder()?
>
> Notionally, it might work like this:
> }}}
<eucode>
> global function signed_remainder(object a,object b)
> integer atom_a,atom_b
> atom c
>
> if find(b,{{},0.0} then
> return {} -- not a valid 2nd argument
> -- crash("Invalid 2nd argument to remainder()")
> end if
> atom_a=atom(a)
> atom_b=atom(b)
> if atom_a!=atom_b then
> if atom_a then -- atom,sequence
> for i=1 to length(b) do
> b[i]=signed_remainder(a,b[i])
> end for
> return b
> else -- sequence,atom
> for i=1 to length(a) do
> a[i]=signed_remainder(a[i],b)
> end for
> return a
> end if
> elsif atom_a=0 then -- two sequences
> if length(a)!=length(b) then
> return {} -- let caller handle the mismatch
> -- crash("Sequence lengths don't match")
> else
> for i=1 to length(a) do
> a[i]=signed_remainder(a[i],b[i])
> end for
> return a
> end if
> else -- two atoms
> c=remainder(a,b) -- smallest magnitude and sign of a
> if a<0!=b<0 then
> return c+b
> else
> return c
> end if
> end function
> </eucode>
{{{
>
> It will be probably better implemented as a builtin if there is a
> corresponding
> C stdlib function with the desired behaviour. If only to take advantage of the
> sequence extension mechanism binary_op() in be_runtime.c provides.
>
> CChris
5. Re: remainder() is not right
Nobody seems to have ponted out yet that the documenation for remainder
says that the result is the same sign as the first argument, not the second,
as CChris seems to have assumed.
Arthur Crump, UK
---------------------------------------------------------------------
CChris wrote:
>
>
> The remainder of x by y, which remainder() is supposed to return, is the
> number
> with the smallest magnitude and the sign of y such that, if we call it z, x-z
> is a multiple of y.
>
> But remainder() has a quirkier response. For instance:
> ?remainder(-27,3600) -- -27, instead of 3573
> ?remainder(-3627,3600) -- ditto
> ?remainder(-3627,-3600) -- -27 is correct here
> ?remainder(27,-3600) -- 27, instead of -3573
>
> Changing remainder()'s behaviour will break any code that works around this
> behaviour. So perhaps should we add another function with the appropriate
> return
> values; perhaps signed_remainder()?
>
... Code omitted ...
> CChris
6. Re: remainder() is not right
- Posted by CChris <christian.cuvier at agricul?ure.gouv.f?>
May 04, 2008
-
Last edited May 05, 2008
Euler German wrote:
>
> > On 4 May 2008 at 6:16, CChris wrote (maybe snipped):
>
> > The remainder of x by y, which remainder() is supposed to return, is
> > the number with the smallest magnitude and the sign of y such that, if
> > we call it z, x-z is a multiple of y.
> >
> > But remainder() has a quirkier response. For instance:
> > ?remainder(-27,3600) -- -27, instead of 3573
> > ?remainder(-3627,3600) -- ditto
> > ?remainder(-3627,-3600) -- -27 is correct here
> > ?remainder(27,-3600) -- 27, instead of -3573
> >
>
> Chris, IMHO actual results are coherent to function's description
> found in Refman, or am I missing something? Isn't it supposed to
> return the remainder of division of the first element by the second?
>
> Best,
> Euler
>
> --
> _
> _| euler f german
> _| sete lagoas, mg, brazil
> _| efgerman{AT}gmail{DOT}com
> _| -----------------------------
> _| Reply preferably to the list,
> _| or to the address above. Thx!
>
>
It returns *a* emainder. When a and b are positive, this is the expected value.
When signs are otherwise, then a discrepancy appears with what, in arithmetic, is
called "remainder".
CChris
7. Re: remainder() is not right
- Posted by CChris <christian.cuvier at agr?culture.go?v.fr>
May 04, 2008
-
Last edited May 05, 2008
jacques deschênes wrote:
>
> In fact remainder(x,y) means q*y+r=x
> so
> remainder(-27,3600)= (-27) is ok as 0*3600+(-27)=(-27)
> remainder(-3627,3600)=(-27) is ok as -1*3600+(-27)=(-3627)
> remainder(-3627,-3600) = -27 is ok as 1*(-3600)+(-27)=(-3627)
> remainder(27,-3600) = 27 is ok as 0*3600+ 27 = 27
>
> Jacques Deschênes
>
True. And signed_remainder() also respects this identity. But see, there are at
least two ways of defining it, the mathematic way and the C way.
CChris
> CChris wrote:
> >
> >
> > The remainder of x by y, which remainder() is supposed to return, is the
> > number
> > with the smallest magnitude and the sign of y such that, if we call it z,
> > x-z
> > is a multiple of y.
> >
> > But remainder() has a quirkier response. For instance:
> > ?remainder(-27,3600) -- -27, instead of 3573
> > ?remainder(-3627,3600) -- ditto
> > ?remainder(-3627,-3600) -- -27 is correct here
> > ?remainder(27,-3600) -- 27, instead of -3573
> >
> > Changing remainder()'s behaviour will break any code that works around this
> > behaviour. So perhaps should we add another function with the appropriate
> > return
> > values; perhaps signed_remainder()?
> >
> > Notionally, it might work like this:
> > }}}
<eucode>
> > global function signed_remainder(object a,object b)
> > integer atom_a,atom_b
> > atom c
> >
> > if find(b,{{},0.0} then
> > return {} -- not a valid 2nd argument
> > -- crash("Invalid 2nd argument to remainder()")
> > end if
> > atom_a=atom(a)
> > atom_b=atom(b)
> > if atom_a!=atom_b then
> > if atom_a then -- atom,sequence
> > for i=1 to length(b) do
> > b[i]=signed_remainder(a,b[i])
> > end for
> > return b
> > else -- sequence,atom
> > for i=1 to length(a) do
> > a[i]=signed_remainder(a[i],b)
> > end for
> > return a
> > end if
> > elsif atom_a=0 then -- two sequences
> > if length(a)!=length(b) then
> > return {} -- let caller handle the mismatch
> > -- crash("Sequence lengths don't match")
> > else
> > for i=1 to length(a) do
> > a[i]=signed_remainder(a[i],b[i])
> > end for
> > return a
> > end if
> > else -- two atoms
> > c=remainder(a,b) -- smallest magnitude and sign of a
> > if a<0!=b<0 then
> > return c+b
> > else
> > return c
> > end if
> > end function
> > </eucode>
{{{
> >
> > It will be probably better implemented as a builtin if there is a
> > corresponding
> > C stdlib function with the desired behaviour. If only to take advantage of
> > the
> > sequence extension mechanism binary_op() in be_runtime.c provides.
> >
> > CChris
8. Re: remainder() is not right
> On 4 May 2008 at 9:48, Arthur Crump wrote (maybe snipped):
> Nobody seems to have ponted out yet that the documenation for
> remainder says that the result is the same sign as the first argument,
> not the second, as CChris seems to have assumed.
>
In my opinion he is proposing a modulo function, say mod(x, y). It
could be defined as:
mod(x, y) = x - y * floor(x / y)
...and it will produce those results he claim remainder(x, y) should
give. I just think they are different functions. Maybe mod(x, y)
could be part of math.e
Best,
Euler
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
_| -----------------------------
_| Reply preferably to the list,
_| or to the address above. Thx!
9. Re: remainder() is not right
> On 4 May 2008 at 16:40, CChris wrote (maybe snipped):
> It returns *a* emainder. When a and b are positive, this is the
> expected value. When signs are otherwise, then a discrepancy appears
> with what, in arithmetic, is called "remainder".
>
Please, I'm not discussing mathematical discrepancies. I only stated
that remainder(), as described in reference manual, works as said,
thus returning the "left over" of a division, so it can't be told
wrong. I'm NOT saying there's no need for a "signed_remainder()",
though I have no use for it. YMMV.
Some quick explanation at:
- http://en.wikipedia.org/wiki/Remainder
- http://en.wikipedia.org/wiki/Modulo_operation
IMO you're describing a modulo function (or operator) so, if we had
something like:
m = mod(x, y) this would be in Euphoria as:
m = x - y * floor(x / y)
...and produces those same results you claim.
Best,
Euler
PS: This message was sent earlier but didn't find a safe way to the
list. Maybe munged headers and body. Sorry if you're getting this
twice.
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
_| -----------------------------
_| Reply preferably to the list,
_| or to the address above. Thx!
10. Re: remainder() is not right
Euler German wrote:
>
> > On 4 May 2008 at 16:40, CChris wrote (maybe snipped):
>
> > It returns *a* emainder. When a and b are positive, this is the
> > expected value. When signs are otherwise, then a discrepancy appears
> > with what, in arithmetic, is called "remainder".
> >
>
> Please, I'm not discussing mathematical discrepancies. I only stated
> that remainder(), as described in reference manual, works as said,
> thus returning the "left over" of a division, so it can't be told
> wrong. I'm NOT saying there's no need for a "signed_remainder()",
> though I have no use for it. YMMV.
>
> Some quick explanation at:
> - <a
> href="http://en.wikipedia.org/wiki/Remainder">http://en.wikipedia.org/wiki/Remainder</a>
> - <a
> href="http://en.wikipedia.org/wiki/Modulo_operation">http://en.wikipedia.org/wiki/Modulo_operation</a>
>
> IMO you're describing a modulo function (or operator) so, if we had
> something like:
>
> m = mod(x, y) this would be in Euphoria as:
>
> }}}
<eucode>
> m = x - y * floor(x / y)
> </eucode>
{{{
>
> ...and produces those same results you claim.
>
> Best,
> Euler
>
> PS: This message was sent earlier but didn't find a safe way to the
> list. Maybe munged headers and body. Sorry if you're getting this
> twice.
>
> --
> _
> _| euler f german
> _| sete lagoas, mg, brazil
> _| efgerman{AT}gmail{DOT}com
> _| -----------------------------
> _| Reply preferably to the list,
> _| or to the address above. Thx!
>
>
Ok for mod() or modulo(), and the formula would be right. Since that's what I
mostly need, I have learned not to use remainder() but when both operands are
above 0 (with extension to sequences).
CChris
11. Re: remainder() is not right
If we define the quotient to be floor(a / b), then it is true that remaider()
is not right.
In fact, floor((-27) / 3600) is -1, not 0.
Anyway, I noticed this problem long ago, and implemented a Residue
function in my General Functions package.
Maybe it should be called mod() instead.
Regards.
12. Re: remainder() is not right
More on the subject.
In C, there are two ways to get an integer quotient:
q = floor(a /(double)b);
and
q = (int)(a / (double)b);
For negative "a", they give different results.
Regards.
13. Re: remainder() is not right
I've added mod() to the standard library
global function mod(atom x, atom y)
return x - y * floor(x / y)
end function
The test cases all pass:
test_equal("mod() #1", 3573, mod(-27, 3600))
test_equal("mod() #2", 3573, mod(-3627, 3600))
test_equal("mod() #3", -27, mod(-3627, -3600))
test_equal("mod() #4", -3573, mod(27, -3600))
test_equal("mod() #5", 0, mod(10, 2))
Should I add any other tests to test for any strange parameters?
--
Jeremy Cowgar
http://jeremy.cowgar.com
14. Re: remainder() is not right
Jeremy Cowgar wrote:
>
> I've added mod() to the standard library
>
> }}}
<eucode>
> global function mod(atom x, atom y)
> return x - y * floor(x / y)
> end function
> </eucode>
{{{
>
> The test cases all pass:
>
> }}}
<eucode>
> test_equal("mod() #1", 3573, mod(-27, 3600))
> test_equal("mod() #2", 3573, mod(-3627, 3600))
> test_equal("mod() #3", -27, mod(-3627, -3600))
> test_equal("mod() #4", -3573, mod(27, -3600))
> test_equal("mod() #5", 0, mod(10, 2))
> </eucode>
{{{
>
> Should I add any other tests to test for any strange parameters?
>
Hm, I went to document the new mod() function and went to:
http://en.wikipedia.org/wiki/Modulo_operation
To get some more descriptive information and noticed that Euphoria is listed
there in the language table as supporting modulo operator and that it's function
name is remainder()
So, what's up with that? Is it not correct? I see that it's listed as:
Dividend while others are Divisor. Ada, for instance, has rem() which is
Dividend and mod() which is Divisor.
--
Jeremy Cowgar
http://jeremy.cowgar.com
15. Re: remainder() is not right
> On 5 May 2008 at 5:42, Jeremy Cowgar wrote (maybe snipped):
> I've added mod() to the standard library
>
> }}}
<eucode>
> global function mod(atom x, atom y)
> return x - y * floor(x / y)
> end function
> </eucode>
{{{
>
> The test cases all pass:
>
> }}}
<eucode>
> test_equal("mod() #1", 3573, mod(-27, 3600))
> test_equal("mod() #2", 3573, mod(-3627, 3600))
> test_equal("mod() #3", -27, mod(-3627, -3600))
> test_equal("mod() #4", -3573, mod(27, -3600))
> test_equal("mod() #5", 0, mod(10, 2))
> </eucode>
{{{
>
> Should I add any other tests to test for any strange parameters?
>
At http://en.wikipedia.org/wiki/Modulo_operation#Performance_issues
it's mentioned a correlation between mod() of powers of 2 could be
done as a bitwise AND, but this is too specific. Again, this is more
a matter how it would "look" in C. Prior to 1990 C "%" operator was
ambiguous but they make their mind since ISO 1999 C (I think).
Best,
Euler
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
_| -----------------------------
_| Reply preferably to the list,
_| or to the address above. Thx!
16. Re: remainder() is not right
Jeremy Cowgar wrote:
>
> Jeremy Cowgar wrote:
> >
> > I've added mod() to the standard library
> >
> > }}}
<eucode>
> > global function mod(atom x, atom y)
> > return x - y * floor(x / y)
> > end function
> > </eucode>
{{{
> >
> > The test cases all pass:
> >
> > }}}
<eucode>
> > test_equal("mod() #1", 3573, mod(-27, 3600))
> > test_equal("mod() #2", 3573, mod(-3627, 3600))
> > test_equal("mod() #3", -27, mod(-3627, -3600))
> > test_equal("mod() #4", -3573, mod(27, -3600))
> > test_equal("mod() #5", 0, mod(10, 2))
> > </eucode>
{{{
> >
> > Should I add any other tests to test for any strange parameters?
> >
>
> Hm, I went to document the new mod() function and went to:
>
> <a
> href="http://en.wikipedia.org/wiki/Modulo_operation">http://en.wikipedia.org/wiki/Modulo_operation</a>
>
> To get some more descriptive information and noticed that Euphoria is listed
> there in the language table as supporting modulo operator and that it's
> function
> name is remainder()
>
> So, what's up with that? Is it not correct? I see that it's listed as:
>
> Dividend while others are Divisor. Ada, for instance, has rem() which is
> Dividend
> and mod() which is Divisor.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
The quote appears to apply to Eu v4.0, with rem() renamed as remainder().
I assume "Divisor" means: the result has the sign of the divisor when not null.
CChris
17. Re: remainder() is not right
CChris wrote:
>
> > Dividend while others are Divisor. Ada, for instance, has rem() which is
> > Dividend
> > and mod() which is Divisor.
>
> The quote appears to apply to Eu v4.0, with rem() renamed as remainder().
> I assume "Divisor" means: the result has the sign of the divisor when not
> null.
>
Chris,
It's Ada that has rem() and mod(), another programming language. I was just
referencing it as it seems to support both remainder() (euphoria name) and mod().
--
Jeremy Cowgar
http://jeremy.cowgar.com
18. Re: remainder() is not right
> On 5 May 2008 at 6:30, Jeremy Cowgar wrote (maybe snipped):
> Hm, I went to document the new mod() function and went to:
>
> http://en.wikipedia.org/wiki/Modulo_operation
>
> To get some more descriptive information and noticed that Euphoria is
> listed there in the language table as supporting modulo operator and
> that it's function name is remainder()
>
> So, what's up with that? Is it not correct? I see that it's listed as:
>
> Dividend while others are Divisor. Ada, for instance, has rem() which
> is Dividend and mod() which is Divisor.
>
If I got the idea right, this has to do with de *ability* to convert
Euphoria code into C. The modulo operator in C doesn't behave exactly
the same way depending of the compiler and hardware. Seems they
"fixed" it after ISO 1999. In a 100% Euphoria world remainder()
should suffice, but after translated into C would it produce the same
result?
Best,
Euler
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
_| -----------------------------
_| Reply preferably to the list,
_| or to the address above. Thx!
19. Re: remainder() is not right
Euler German wrote:
>
> If I got the idea right, this has to do with de *ability* to convert
> Euphoria code into C. The modulo operator in C doesn't behave exactly
> the same way depending of the compiler and hardware. Seems they
> "fixed" it after ISO 1999. In a 100% Euphoria world remainder()
> should suffice, but after translated into C would it produce the same
> result?
This wouldn't be an issue. If it's all euphoria, then, obviously, it would
work the same. If it's implemented in the backend as part of the runtime,
it would still use that same code, rather than simply calling a C runtime
library function.
Matt
20. Re: remainder() is not right
> On 5 May 2008 at 8:41, Matt Lewis wrote (maybe snipped):
> Euler German wrote:
> >
> > If I got the idea right, this has to do with de *ability* to convert
> > Euphoria code into C. The modulo operator in C doesn't behave
> > exactly the same way depending of the compiler and hardware. Seems
> > they "fixed" it after ISO 1999. In a 100% Euphoria world remainder()
> > should suffice, but after translated into C would it produce the
> > same result?
>
> This wouldn't be an issue. If it's all euphoria, then, obviously, it
> would work the same. If it's implemented in the backend as part of
> the runtime, it would still use that same code, rather than simply
> calling a C runtime library function.
>
> Matt
>
Maybe I didn't express myself clearly. What I mean is that an
Euphoria program translated into C and compiled by a C compiler could
produce different results depending on the C compiler and/or the
hardware used. I was thinking on what Ricardo Forno said about it:
<rf>
More on the subject.
In C, there are two ways to get an integer quotient:
q = floor(a /(double)b);
and
q = (int)(a / (double)b);
For negative "a", they give different results.
</rf>
Hope it make sense now. :)
Best,
Euler
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
21. Re: remainder() is not right
Euler German wrote:
>
> Maybe I didn't express myself clearly. What I mean is that an
> Euphoria program translated into C and compiled by a C compiler could
> produce different results depending on the C compiler and/or the
> hardware used. I was thinking on what Ricardo Forno said about it:
>
> <rf>
> More on the subject.
> In C, there are two ways to get an integer quotient:
> q = floor(a /(double)b);
> and
> q = (int)(a / (double)b);
>
> For negative "a", they give different results.
> </rf>
I suppose this is theoretically true, but is anyone aware of differing
implementations of remainder or mod or whatever we're talking about?
There are only a handful of compilers that will currently build euphoria,
so we've already got that situation if the C libraries differ.
Matt
