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
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,
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
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.
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 floor
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
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 the
others).
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 to
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
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 surely
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 PROTECTED] wrote:.
I think
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) { ... }
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) { ... }
really should
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
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 want
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
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):
%
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,
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 ediv
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
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!
Smylers
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.
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
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
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 fear
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
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
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 need.
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
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 Complex
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
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
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 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 we
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,
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
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
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
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? Should
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
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 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
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
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
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 screen or
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
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
47 matches
Mail list logo
