On Fri, Mar 28, 2008 at 3:47 PM, <[EMAIL PROTECTED]> wrote:
> I think nearest makes more sense. People will be really surprised when
> /1 turns into 0.
They shouldn't be, if they're asking for an integer specifically.
That's what happens now in Perl 5...
If you have a rational
The choice of floor vs ceiling is essentially arbitrary, as long as
its consistent; using truncation or rounding is mathematically
unsound. Most implementations use floor, though.
So in general I would expect these to hold:
x div y = floor(x/y)
x mod y = x - y * floor(x/y)
Most importantly, thi
TSa wrote:
> just re-reading S03 I saw that it defines the Rat to Int
> conversion as truncation. Why not floor semantics like in %?
> Actually I would recommend floor semantics whenever an integer
> is coerced. With the sole exception of Num propably using
> rounding.
If the difference matters t
I think nearest makes more sense. People will be really surprised when
/1 turns into 0.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-- Original message --
From: TSa <[EMAIL PROTECTED]>
> HaloO,
>
> just re-reading S03 I
At 09:46 -0400 3/27/08, Mark J. Reed wrote:
>Is it just me, or is all this talk about precedence and functions vs operators
>vs methods creating a niggling sensation in anyone else's head? It feels like
>we're in the vicinity of another one of them Big Simplifying Idea things.
>Unfortunately, I
HaloO,
just re-reading S03 I saw that it defines the Rat to Int
conversion as truncation. Why not floor semantics like in %?
Actually I would recommend floor semantics whenever an integer
is coerced. With the sole exception of Num propably using
rounding.
Regards, TSa.
--
The Angel of Geometry
Author: larry
Date: Fri Mar 28 10:42:39 2008
New Revision: 14528
Modified:
doc/trunk/design/syn/S04.pod
Log:
typo from cognominal++
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(o
HaloO,
Larry Wall wrote:
As it stands the .() forms are a great way to stack ops after
a term. Together with knowing about the ops on the symbolic unary
level you can easily read expressions from the terms outwards.
I'm not actually parsing expressions. Or as you point out below
with respect t
