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/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
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
47 matches
Mail list logo
