Note: it would be good to break multiple questions into separate threads
with different subjects for those of us who use threaded mail readers,
so I will answer each of these with a different subject.
Larry
HaloO,
Luke Palmer wrote:
When do we do integer/rational math and when do we do floating point math?
Since we have now flooring semantics on modulus and division I wonder
how the coercion of nums to ints takes place. Does it also use floor?
E.g. is @array[-0.3] accessing the last element or is
On Mon, Jan 22, 2007 at 05:56:46PM -0800, Larry Wall wrote:
> The default / operator is not going to do integer division. This is
> not negotiable; normal people expect 1/2 to mean one half, so / is
> going to coerce to some type that can support fractions. We'll use
I agree. And I hope I count
TSa writes:
> Smylers wrote:
>
> > I'd much prefer for introductory Perl books not to have to explain
> > what "Euclidean" means.
>
> Yeah, it will not dive into the exact reasons why the floor
> definition was chosen, either.
Sure, if we _only_ have floor (or indeed if we _only_ have one of th
HaloO,
Smylers wrote:
Do you think most Perl programmers appreciate the difference, or are
likely to need both sorts frequently?
I guess not.
I'd much prefer for introductory
Perl books not to have to explain what "Euclidean" means.
Yeah, it will not dive into the exact reasons why the f
HaloO,
Larry Wall wrote:
Well, mostly, unless we consider that Num(1.0) might have to wait
till run time to know what conversion to Num actually means, if Num
is sufficiently delegational But I think the compiler can probably
require a tighter definition of basic types for optimization purp
TSa writes:
> Larry Wall wrote:
>
> > The default / operator is not going to do integer division. [..] And
> > % should stick to standard floor semantics, I expect.
>
> Since the latin1 charset contains the division character ÷ we could
> use that to mean floor based integer division and % the f
HaloO,
Larry Wall wrote:
The default / operator is not going to do integer division. [..]
And % should stick to standard floor semantics, I expect.
Since the latin1 charset contains the division character ÷ we
could use that to mean floor based integer division and % the
floor based modulus. T
HaloO,
Larry Wall wrote:
For various practical reasons I don't think we can treat Int as a
subset of Num, especially if Num is representing any of several
approximating types that may or may not have the "headroom" for
arbitrary integer math, or that lose low bits in the processing of
gaining hi
On 1/23/07, Paul Seamons <[EMAIL PROTECTED]> wrote:
> While I'm in general agreement with everything you've said it makes me a
> tad nervous to hinge so much on the difference of one character. Can
you
> imagine trying to track down the bug where
>
> if ($alpha === $beta) { ... }
>
> reall
> While I'm in general agreement with everything you've said it makes me a
> tad nervous to hinge so much on the difference of one character. Can you
> imagine trying to track down the bug where
>
> if ($alpha === $beta) { ... }
>
> really should have been
>
> if ($alpha == $beta) { ... }
I accidently sent this just to Darren ...
-Scott
-- Forwarded message --
From: Jonathan Scott Duff <[EMAIL PROTECTED]>
Date: Jan 22, 2007 6:23 PM
Subject: Re: Numeric Semantics
To: Darren Duncan <[EMAIL PROTECTED]>
On 1/22/07, Darren Duncan <[EMAIL PROTECTE
On 1/22/07, Doug McNutt <[EMAIL PROTECTED]> wrote:
At 00:32 + 1/23/07, Smylers wrote:
> % perl -wle 'print 99 / 2'
> 49.5
I would expect the line to return 49 because you surely meant integer
division. Perl 5 just doesn't have a user-available type integer.
That doesn't mean that I sur
On Mon, Jan 22, 2007 at 08:47:22PM -0800, Darren Duncan wrote:
: At 5:56 PM -0800 1/22/07, Larry Wall wrote:
: >Whether a Num that happens to be an integer prints out with .0 is a
: >separate issue. My bias is that a Num pretend to be an integer when
: >it can. I think most folks (including mathe
HaloO
Darren Duncan wrote:
Up front, I will say that, all this stuff about 1 vs 1.0 won't matter at
all if the Int type is an actual subset of the Num type (but whose
implementation is system-recognized and optimized), meaning that Int and
Num are not disjoint, as "most folks" usually expect t
Larry Wall writes:
> The default / operator is not going to do integer division.
Yay!
> This is not negotiable;
Double-yay!
> Whether a Num that happens to be an integer prints out with .0 is a
> separate issue. My bias is that a Num pretend to be an integer when
> it can.
Triple-yay!
Smyle
At 5:56 PM -0800 1/22/07, Larry Wall wrote:
Whether a Num that happens to be an integer prints out with .0 is a
separate issue. My bias is that a Num pretend to be an integer when
it can. I think most folks (including mathematicians) think that
the integer 1 and the distance from 0 to 1 on the
The default / operator is not going to do integer division. This is
not negotiable; normal people expect 1/2 to mean one half, so / is
going to coerce to some type that can support fractions. We'll use
"div" and "mod" for the polymorphic variants defaulting to floor
semantics, and things like edi
Doug McNutt wrote:
At 00:32 + 1/23/07, Smylers wrote:
% perl -wle 'print 99 / 2'
49.5
I would expect the line to return 49 because you surely meant integer
> division. Perl 5 just doesn't have a user-available type integer.
I'd find that somewhat unhelpful. Especially on a one-liner, l
At 12:32 AM + 1/23/07, Smylers wrote:
Darren Duncan writes:
For round-trip consistency, a generic non-formatted num-to-char-string
operation should include a .0 as appropriate if it is converting from
a Num, whereas when converting from an Int it would not.
So this (in Perl 5):
% pe
At 00:32 + 1/23/07, Smylers wrote:
> % perl -wle 'print 99 / 2'
> 49.5
I would expect the line to return 49 because you surely meant integer division.
Perl 5 just doesn't have a user-available type integer.
% perl -wle 'print 99.0 / 2.0' OR
% perl -wle 'print 99.0 / 2'
would return 49.5
Darren Duncan writes:
> For round-trip consistency, a generic non-formatted num-to-char-string
> operation should include a .0 as appropriate if it is converting from
> a Num, whereas when converting from an Int it would not.
So this (in Perl 5):
% perl -wle 'print 100 / 2'
50
you would wan
At 10:03 AM -0800 1/17/07, Jonathan Lang wrote:
TSa wrote:
Luke Palmer wrote:
That is, is 1 different from 1.0?
I opt for 1 being Int and 1.0 being Num. But for the
latter a test .does(Int) might succeed on the footing
that the fractional part is zero, that is 1.0%1 == 0.
I'm very leery of
TSa wrote:
Luke Palmer wrote:
> That is, is 1 different from 1.0?
I opt for 1 being Int and 1.0 being Num. But for the
latter a test .does(Int) might succeed on the footing
that the fractional part is zero, that is 1.0%1 == 0.
I'm very leery of the idea that "A.does(B)" ever returns true when
HaloO,
Luke Palmer wrote:
That is, is 1 different from 1.0?
I opt for 1 being Int and 1.0 being Num. But for the
latter a test .does(Int) might succeed on the footing
that the fractional part is zero, that is 1.0%1 == 0.
Note that 1/3*3 does not necessarily equal 1.0 for
floating point math. I
HaloO,
Jonathan Lang wrote:
Agreed. My only doubt at this point is which definition should be the
default. Do we go with "mathematically elegant" (E) or "industry
standard" (F, I think)?
I think industry (language) standard is undefined behavior ;)
I'm kind of waiting for an answer what fea
TSa wrote:
My list was sorted in decreasing order of importance with the
F-definition beating the E-definition in popularity. So all I want is
use Math::DivMod:euclid;
to get the E-definition and a
use Math::DivMod;
to get them all. The F-definition being the default when no import is
HaloO,
Smylers wrote:
That depends on exactly what you mean by "we" and "need".
Well, with "we" I meant the Perl 6 language list and "need"
is driven by the observation that we can't agree on a single
definition, so picking your personal favorite should be
possible.
By all means have them a
TSa writes:
> Looks like we need a host of division function pairs:
>
> fdiv fmodflooring division
> ediv emodeuclidean division
> rdiv rmodrounding division
> tdiv tmodtruncating division
> cdiv cmodceiling division
That depends on exactly what you mean by "we" and
HaloO,
I wrote:
I cannot give an algorithm how to calculate the remainder.
Even less do I know how to generalize it to full Complex.
Since one wants the absolute value of the remainder less
than the absolute value of the divisor the float result
is *rounded* in the real and imaginary component
HaloO,
Mark J. Reed wrote:
I believe mod should be defined in the conventional way: x mod y = x -
floor(x/y) * y, which does yield 0.8 for 3.2 mod 2.4. However, for
3.2 mod - 2.4 it yields -1.6. To get 0.8 you would have to round
toward zero instead of taking the floor, and that complicates an
HaloO,
Jonathan Lang wrote:
That said, I'm still trying to wrap my head around how the Euclidiean
definition would work for complex numbers. What would be the quotient
and remainder for, e.g., 8i / 3; 8 / 3i; (3 + 4i) / 3; 8 / (4 + 3i);
or (12 + 5i) / (3 + 4i)?
I assume you are intending the
Mark J. Reed <[EMAIL PROTECTED]> wrote:
I believe mod should be defined in the conventional way: x mod y = x -
floor(x/y) * y, which does yield 0.8 for 3.2 mod 2.4. However, for
3.2 mod - 2.4 it yields -1.6. To get 0.8 you would have to round
toward zero instead of taking the floor, and that co
I believe mod should be defined in the conventional way: x mod y = x -
floor(x/y) * y, which does yield 0.8 for 3.2 mod 2.4. However, for
3.2 mod - 2.4 it yields -1.6. To get 0.8 you would have to round
toward zero instead of taking the floor, and that complicates any
computation that crosses ze
At 17:35 +0100 1/9/07, TSa wrote:
>May I use this to remind the list that I proposed to define the modulus in the
>most algebraically pleasing way, i.e. in the Euclidean definition.
>(See http://www.cs.uu.nl/~daan/download/papers/divmodnote-letter.pdf)
>E.g. this modulus is also defined for Comple
HaloO,
Darren Duncan wrote:
Following from this, I propose that we have distinct-looking operators
(not just multis) that users can explicitly choose when they want to do
integer division/modulus or non-integer division/modulus.
For example, we could have:
div - integer division
mod - in
At 9:57 PM -0700 1/4/07, Doug McNutt wrote:
At 18:23 -0800 1/4/07, Dave Whipp wrote:
Darren Duncan wrote:
For example, the extra space of putting them aside will let us
expand them to make them more thorough, such as dealing well with
exact vs inexact, fixed vs infinite length, fuzzy or inter
At 18:23 -0800 1/4/07, Dave Whipp wrote:
>Darren Duncan wrote:
>
>>For example, the extra space of putting them aside will let us expand them to
>>make them more thorough, such as dealing well with exact vs inexact, fixed vs
>>infinite length, fuzzy or interval based vs not, caring about sigfigs
Darren Duncan wrote:
For example, the extra space of putting them aside will let us expand
them to make them more thorough, such as dealing well with exact vs
inexact, fixed vs infinite length, fuzzy or interval based vs not,
caring about sigfigs or not, real vs complex vs quaternon, etc.
I
I'm going to offer a bit of clarification to my earlier comment,
since some of it was misinterpreted.
First, what I'm proposing is not intended to affect the
machine-native types at all; the proposal is strictly concerning the
boxed types.
Second, I was not suggesting that all non-integer nu
On Thu, Jan 04, 2007 at 04:32:11AM -0700, Luke Palmer wrote:
: >Eg, are non-integer numbers used anywhere to implement any of: the
: >meta-model, grammars and parsing, control flow, generic collection
: >types, input and output, whatever? AFAIK, those are mainly
: >implemented with booleans, integ
On 1/4/07, Darren Duncan <[EMAIL PROTECTED]> wrote:
It occurs to me that, while they still need privileged support in
Perl 6 the language, non-integer numbers aren't actually all that
important as far as implementing the language core goes.
Well, that's true to an extent. It's also true that w
I just had a thought, which may or may not help this discussion along.
It occurs to me that, while they still need privileged support in
Perl 6 the language, non-integer numbers aren't actually all that
important as far as implementing the language core goes.
That is, I consider non-integers
On Tue, Jan 02, 2007 at 11:22:22AM -0700, Doug McNutt wrote:
: See FORTRAN conventions to continue.
Well, I don't think FORTRAN implicit conventions will fly anymore,
but basically I think I agree with you that different contexts will
want to warp what they mean by "numeric". Leaving aside the wh
At 09:24 -0800 1/2/07, Larry Wall wrote:
>But I'm also still wondering whether a simpler approach is to declare
>that Num is a role that can encapsulate objects of class Int, Num,
>Rat, or Dec as necessary. There also a lot to be said for simple...
Simple. . . YES! but I'm in no position to help
On Tue, Jan 02, 2007 at 09:24:20AM -0800, Larry Wall wrote:
: But I'm also still wondering whether a simpler approach is to declare
: that Num is a role that can encapsulate objects of class Int, Num,
: Rat, or Dec as necessary. There also a lot to be said for simple...
Well, that's wrong several
On Sun, Dec 31, 2006 at 03:02:08AM -0800, Darren Duncan wrote:
: At 9:34 AM + 12/29/06, Luke Palmer wrote:
: >When do we do integer/rational math and when do we do floating point math?
: >
: >That is, is 1 different from 1.0? Should 10**500 be infinity or a 1
: >with 500 zeroes after it? Shou
On 12/31/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
For example, we could have:
div - integer division
mod - integer modulus
/ - number division
% - number modulus
Or alternately:
idiv - integer division
imod - integer modulus
ndiv - number division
nmod - number
"Luke Palmer" schreef:
> When do we do integer/rational math and when do we do floating point
> math?
>
> That is, is 1 different from 1.0? Should 10**500 be infinity or a 1
> with 500 zeroes after it? Should 10**10**6 run out of memory? Should
> "say (1/3)**500" print a bunch of digits to the
Darren Duncan wrote:
Following from this, I propose that we have distinct-looking
operators (not just multis) that users can explicitly choose when
they want to do integer division/modulus or non-integer
division/modulus.
I don't know if the following constitutes a problem or not; but the
one o
At 9:34 AM + 12/29/06, Luke Palmer wrote:
When do we do integer/rational math and when do we do floating point math?
That is, is 1 different from 1.0? Should 10**500 be infinity or a 1
with 500 zeroes after it? Should 10**10**6 run out of memory? Should
"say (1/3)**500" print a bunch of d
When do we do integer/rational math and when do we do floating point math?
That is, is 1 different from 1.0? Should 10**500 be infinity or a 1
with 500 zeroes after it? Should 10**10**6 run out of memory? Should
"say (1/3)**500" print a bunch of digits to the screen or print 0?
These are just
On Thu, 26 Aug 2004 11:10:59 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:56 AM -0400 8/26/04, John Siracusa wrote:
> >Why make a stop in 32-bit land at all in that case? If the system supports
> >64-bit ints, why not use them for everything right up until you promote to
> >BigNum? Is
At 10:56 AM -0400 8/26/04, John Siracusa wrote:
On Wed, 25 Aug 2004 07:48:03 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
John Siracusa <[EMAIL PROTECTED]> wrote:
> On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> The big question is whether being clever and pr
On Wed, 25 Aug 2004 07:48:03 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> John Siracusa <[EMAIL PROTECTED]> wrote:
> > On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> The big question is whether being clever and producing the tightest
> >> type is worth the t
BigNum is an arbitrary precision decimal number (Think BCD -- Binary Coded
Decimal ala the Unix utility BC)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 25, 2004 9:12 AM
To: [EMAIL PROTECTED]
Subject: RE: Numeric semantics for base pmcs
On
At 8:11 AM -0500 8/25/04, [EMAIL PROTECTED] wrote:
On Wed, 25 Aug 2004 08:40:32 -0400, "Gay, Jerry" <[EMAIL PROTECTED]> said:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> BigNums grow on demand. It depends on value and precision.
>
can BigNum then start at sizeof(int)? overflow would auto-grow
On Wed, 25 Aug 2004 08:40:32 -0400, "Gay, Jerry" <[EMAIL PROTECTED]> said:
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> > BigNums grow on demand. It depends on value and precision.
> >
>
> can BigNum then start at sizeof(int)? overflow would auto-grow the BigNum
> to
> the appropriate size, and
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> BigNums grow on demand. It depends on value and precision.
>
can BigNum then start at sizeof(int)? overflow would auto-grow the BigNum to
the appropriate size, and most integer math operations will keep space usage
as low as possible.
in fact, then i
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> At 8:45 PM +0200 8/24/04, Leopold Toetsch wrote:
>>>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
Nope -- we don't have bigints. :)
>>>
>>>Pardon, sir?
>
>> We've got the big number code, but I don't see muc
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:45 PM +0200 8/24/04, Leopold Toetsch wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>> Nope -- we don't have bigints. :)
>>
>>Pardon, sir?
> We've got the big number code, but I don't see much reason to
> distinguish between integers and non-inte
John Siracusa <[EMAIL PROTECTED]> wrote:
> On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> The big question is whether being clever and producing the tightest
>> type is worth the time to figure out what that type is, as well as
>> the potentially uncertain output typ
Felix Gallo <[EMAIL PROTECTED]> wrote:
> Dan, any feeling about RISC vs. CISC? Because to me, this seems
> like a good place to punt, and provide two, maybe three mults:
Not the best idea. The same argument would hold for all operations that
could overflow. With such a strategy will end with MMD
At Tue, 24 Aug 2004 15:19:52 -0400,
Dan Sugalski wrote:
>
> At 11:47 AM -0700 8/24/04, Sean O'Rourke wrote:
> >At Tue, 24 Aug 2004 13:33:45 -0400,
> >Dan Sugalski wrote:
> >> 7) Strings are treated as floats for math operations
> >
> >I think we can do better than this by first converting a strin
Nick writes:
> 2 * 3 give a bignum. That feels evil.
> Except that the way that $a = 2 * 3 will work is that the assignment of
> the bignum temporary to $a will cause $a to drop it back to an int
> (for most languages' choice of target PMC) ?
Dan, any feeling about RISC vs. CISC? Because to me, t
On Tue, Aug 24, 2004 at 03:08:21PM -0400, Dan Sugalski wrote:
> At 8:56 PM +0200 8/24/04, Leopold Toetsch wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> 5) Multiplication of two ints produces a bignum or an int, depending
> >> on the result
> >
> >Why that difference?
>
> At this point I'
At 11:47 AM -0700 8/24/04, Sean O'Rourke wrote:
At Tue, 24 Aug 2004 13:33:45 -0400,
Dan Sugalski wrote:
6) Division of two ints produces a bignum
Where "bignum" means both "bigger than 32-bit integer" and "rational
number"? So
Yes.
4 / 2 ==> Bignum("2/1")
which doesn't get automatically downg
At 8:56 PM +0200 8/24/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Okay, so:
4) Addition and subtraction of ints produces an int
???
Yeah, that was wrong. Later fixed. :)
5) Multiplication of two ints produces a bignum or an int, depending
on the result
Why that differen
At 8:45 PM +0200 8/24/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 1:42 PM -0400 8/24/04, Butler, Gerald wrote:
Shouldn't 4 also have potential to produce BigInt?
Nope -- we don't have bigints. :)
Pardon, sir?
We've got the big number code, but I don't see much reason to
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, so:
> 4) Addition and subtraction of ints produces an int
???
> 5) Multiplication of two ints produces a bignum or an int, depending
> on the result
Why that difference?
Int Int gives Bigint or Int (whatever fits)
for in (abs, neg, add, sub
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:42 PM -0400 8/24/04, Butler, Gerald wrote:
>>Shouldn't 4 also have potential to produce BigInt?
> Nope -- we don't have bigints. :)
Pardon, sir?
leo
At Tue, 24 Aug 2004 13:33:45 -0400,
Dan Sugalski wrote:
> 6) Division of two ints produces a bignum
Where "bignum" means both "bigger than 32-bit integer" and "rational
number"? So
4 / 2 ==> Bignum("2/1")
which doesn't get automatically downgraded to a normal int. Ok.
> 7) Strings are tre
On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The big question is whether being clever and producing the tightest
> type is worth the time to figure out what that type is, as well as
> the potentially uncertain output type.
Tangentially related: will promotion be su
At 1:39 PM -0400 8/24/04, Simon Glover wrote:
On Tue, 24 Aug 2004, Dan Sugalski wrote:>
6) Division of two ints produces a bignum
Surely it should only produce a bignum as a last resort. For instance,
shouldn't:
4 / 3
produce a float?
A float or a bignum, both are reasonable. There's that who
At 2:08 PM -0400 8/24/04, Matt Fowles wrote:
> >From: Dan Sugalski [mailto:[EMAIL PROTECTED]
> >10) The destination PMC is responsible for final conversion of the
>inbound value
>
I know there has been a lot of grumbling in the past about the need to
create PMCs to be the LHS of operations. I
Oops. I meant BigNum.
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 24, 2004 1:47 PM
To: Butler, Gerald; '[EMAIL PROTECTED]'
Subject: RE: Numeric semantics for base pmcs
At 1:42 PM -0400 8/24/04, Butler, Gerald wrote:
>Shouldn&
Shouldn't 4 also have potential to produce BigInt?
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 24, 2004 1:34 PM
To: [EMAIL PROTECTED]
Subject: Numeric semantics for base pmcs
Okay, so:
1) We round to zero when going from float to
Dan~
> >-Original Message-
> >From: Dan Sugalski [mailto:[EMAIL PROTECTED]
> >Sent: Tuesday, August 24, 2004 1:34 PM
> >To: [EMAIL PROTECTED]
> >Subject: Numeric semantics for base pmcs
> >
> >10) The destination PMC is responsible for final conv
At 1:42 PM -0400 8/24/04, Butler, Gerald wrote:
Shouldn't 4 also have potential to produce BigInt?
Nope -- we don't have bigints. :)
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 24, 2004 1:34 PM
To: [EMAIL PROTECTED]
Subject: Numeric sem
On Tue, 24 Aug 2004, Dan Sugalski wrote:>
>
> 6) Division of two ints produces a bignum
Surely it should only produce a bignum as a last resort. For instance,
shouldn't:
4 / 3
produce a float?
Also, what about a case like:
4 / 2
Does that produce an int, a float or a bignum?
> 9) An
Okay, so:
1) We round to zero when going from float to int
2) Overflows, underflows, and division by zero throws an exception
3) All-float operations produce floats
4) Addition and subtraction of ints produces an int
5) Multiplication of two ints produces a bignum or an int, depending
on the resul
81 matches
Mail list logo
