Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Numeric Semantics

9 views
Skip to first unread message

Luke Palmer

unread,
Dec 29, 2006, 4:34:08 AM12/29/06
to perl6language
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 examples. Exponentials are the easiest to think about
limit cases with, but the whole general issue needs precise semantics.

Luke

Darren Duncan

unread,
Dec 31, 2006, 6:02:08 AM12/31/06
to perl6language

Related to that question, I'd like to draw the list's attention to a
#perl6 discussion that several of us had today:

http://colabti.de/irclogger/irclogger_log/perl6?date=2006-12-31

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 - integer modulus
/ - number division
% - number modulus

Or alternately:

idiv - integer division
imod - integer modulus
ndiv - number division
nmod - number modulus

And in that case, "/" and "%" would be aliases for an alphanumeric
pair that can be changed using a lexical pragma; they would default
to ndiv/nmod.

In that case, the explicit "/" and "%" use would be subject to change
behaviour depending on the influence of a pragma, while explicit
idiv/imod/ndiv/nmod use would stay the same no matter what pragma is
in effect.

Note that the i/n variants would cast all their arguments as Int/Num
before performing the operation as appropriate; they do *not* simply
do non-integer work and then cast the result.

Change spelling to taste (eg, they could be spelled
Int::Div/Int::Mod/Num::Div/Num::Mod instead), but I hope you get the
point of what I was saying.

-- Darren Duncan

Jonathan Lang

unread,
Dec 31, 2006, 6:26:39 AM12/31/06
to p6l
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 other instance that I know of where there were type-specific
versions of a common operator was the string equality vs. numeric
equality. Note that in that case, we ended up with a third "generic
equality" operator, for cases where auto-coercing the terms beforehand
would kill vital information (such as whether the two terms were, in
fact, of different types...).

With that in mind, should we be thinking of operator triplets here as
well? Namely, integer division (coerce to Int, then divide), rational
division (coerce to Num, then divide), and generic division (no
coercion; use MMD to resolve)?

--
Jonathan "Dataweaver" Lang

Dr.Ruud

unread,
Dec 31, 2006, 7:18:33 AM12/31/06
to perl6-l...@perl.org
"Luke Palmer" schreef:

A Numeric could have multiple faces: Integer, Rational, Float, etc. Some
faces can have a Complex variant.

A bitstring could flag which faces are actual (usable, non-dirty).

Each face needs its own storage, for instance 1/2 could be stored as
Integer "0" (or "1", or alternating between them), Rational "1 / 2" (or
"2 ** -1"), Float "1B-1", etc.

Some conversions are without surprises, like from Integer to Float
(because loss of precision is normal when going from Integer to Float,
so even a difference of more than 1 is to be expected).
From Float to (Big)Integer can result in an unexpected difference of 1.
Or even in Inf.

(just rambling)

--
Affijn, Ruud

"Gewoon is een tijger."

Luke Palmer

unread,
Dec 31, 2006, 9:00:18 AM12/31/06
to Darren Duncan, perl6language
On 12/31/06, Darren Duncan <dar...@darrenduncan.net> 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 modulus

Perhaps. That's the easy problem. What do we do about rationals (I
don't think exploding into rdiv, rmod would be a good idea, but I
could be mistaken).

Luke

Larry Wall

unread,
Jan 2, 2007, 12:24:20 PM1/2/07
to perl6language

Something's been bugging me about this for days, and I think I finally
have a feeling about what it is. It's a reinventing-the-wheel kind
of feeling: most of these operators already *have* names, if you
count long names that include the return type.

infix:</>:($x, $y --> Int)
infix:</>:(Int $x, Int $y --> Int)
infix:</>:($x, $y --> Num)
infix:</>:(Num $x, Num $y --> Num)
infix:</>:($x, $y --> Rat)
infix:</>:(Rat $x, Rat $y --> Rat)

assuming suitable implementation of general forms. But see below.

: Note that the i/n variants would cast all their arguments as Int/Num

: before performing the operation as appropriate; they do *not* simply
: do non-integer work and then cast the result.

We don't have a way to name those two options for implementation:

multi infix:</> ($x, $y --> Int) { Int($x) / Int($y) }
multi infix:</> ($x, $y --> Int) { Int($x / $y) }

So perhaps we need a way to name those two differently. And maybe there's
a third:

multi infix:</> ($x, $y --> Int) { Int(CALLER::infix:</>($x,$y)) }

or maybe one uses a macro to get those semantics, since that latter
is an infinite recursion if CALLER::infix:</> already happens to pick
the Int returning variant. Oops...

: Change spelling to taste (eg, they could be spelled

: Int::Div/Int::Mod/Num::Div/Num::Mod instead), but I hope you get the
: point of what I was saying.

Assuming everything can be named with some kind of long name, the question
is whether our current aliasing facilities are sufficient for remapping
generic / and % operators, and creating convenience operators like idiv.
I would guess so. The main question then is whether Standard Perl should
provide such convenience operators, or pragmatic support for them.

The other issue is how this relates to return-type multiple dispatch,
and whether we support type inferencing, or require a pragma to say
that / assumes Rat for its return type. Or another wacky approach
would be to defer the choice until we know the actual use context
and then do the division. Run-time type inferencing, as it were...

I don't think that approach would necessarily imply full laziness--one
could presumably evaluate the arguments up to the point of making the
choice of which variant to call. Of course, if those arguments are
waiting with bated breath to find out *their* type context, then we
really are looking at type inferencing at run time, which transitively
implies a great deal of implied laziness (and associated potential
grief if done poorly). There's much to be said for a pragma that
forces the issue: "Just gimme my Rats, darn it!"

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...

Larry

Larry Wall

unread,
Jan 2, 2007, 1:22:21 PM1/2/07
to perl6language
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 ways. It would be more like Num is a Scalar
that is constrained to a Numeric role. But Scalars are mutable, and
that plays havoc with the value semantics. How can you tell if two
different numeric types are really holding the same value? There's no
one-to-one correspondence between approximate types and exact types.
You can pretend that a floater is a single value, but a given floater
really represents a range of rational and irrational values. You'd
really like Num to at least pretend it has value semantics though... :/

Larry

Doug McNutt

unread,
Jan 2, 2007, 1:22:22 PM1/2/07
to perl6language
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. Computer science has left me way behind. But.... I do a lot of computing and I do like perl 5. In fact, I use it on Mac OS neXt in preference to C or FORTRAN.

I fully understand floats, integers, complex, vectors, and big numbers and I believe that's typical of folks who really use computers for computing. It would be nice if perl 6 would allow me, the user, to specify in advance just which numeric type I want. Incompatible usage would be an error that would be politely objected to by the compiler.

How about a convention that integers begin with I, J, K, L, M, and N while others are floats? Perhaps those letters by themselves would imply that they are indexing quantities which should be assigned to hardware registers.

Yeah, that's just to show how old I am. But why not an optional typdef-like facility in perl which would tell the compiler what I want? It could even be an O-O style instantiation. Separate sigl's, perhaps but some unicode specials - questionable. User-defined sigl's in a pragma? DIM statements?

$Lynn / $Jill

would be an integer divide using whatever arithmetic logic unit the machine in use provides.

$Ross / $Todd

would be done with the floating point processor.

$Ross / $Lynn

would convert $Lynn to a float and return a float. See FORTRAN conventions to continue.

--
--> The greenhouse effect due to water vapor has never been fully modeled and weather forecasting remains irreducibly complex. It is clear that global warming is the act of an Intelligent Designer. <--

Larry Wall

unread,
Jan 2, 2007, 2:32:51 PM1/2/07
to perl6language
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 whole mess
of coercion before/after, OO and MD will mostly drive the decision of
which operators to use for existing objects, so the warpage in a given
context would be to select how you want new numeric objects created
(possibly extended to select otherwise tied multis on the basis of
their return type, but this can be viewed as an extension of creation
semantics (unless it also picks coercion)).

Anyway, there's already implicit in Perl 6 that a short name like
Num is really an alias to a longer name like Num-6.0.3-STD. We could
go slightly farther and say that by default Num is an alias to Flt,
and Flt is the alias to the "largest convenient" floating point
representation on this architecture. However, a given lexical scope
could alias Num to anything else it likes, and while that would not
influence the dispatch of any existing objects that came in from
elsewhere, it would influence the operator used to create any new
"Num" objects in the current context. So you could alias Num to Rat
or Fix or Dec or whatever if you like in a given lexical scope.

What this tells me, though, is that we need to be more explicit about
the meaning of type names that are mentioned within role definitions.
When a given role says "this method returns Num" it probably wants
to be generic; that is, it wants to mean the Num defined at the time
the role is composed, not the Num defined where the role is defined.
Whether that policy should be in effect for all type names by default
is a good question. (This is much like the virtualization of type
names within methods that we already mandate, actually.) If so,
then we need to decide the proper notation for "no I really do mean
the Num type in scope where the role is defined". Or the default can
go the other way, and then we'd need some way of saying that we do want
Num to be implicitly parametric without having to pass it every time
to the role composer.

Well, that's mostly just a bunch of thinking out loud. Others should
feel free to do likewise. But at some point it would be nice if the
optimizer can figure out what the user actually expects to happen,
which leads me to think that Num should eventually be mappable to a
less-abstract type at compile time, as long as it matches the desired
constraints of the user. I have this almost-tongue-in-cheek vision
of a numeric type selector that works like modern font selection,
where you say you want

use Num :where<-15-3-*-*-fast-*-*->;

and it gives you a numeric type with the appropriate constraints,
and you don't care whether it's actually implemented as decimal strings,
scaled integers or scaled floating point, as long as you get 15 digits
altogether, 3 exact digits after the decimal point, and it's fast. :)

Larry

Darren Duncan

unread,
Jan 4, 2007, 5:38:09 AM1/4/07
to perl6language
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 only a little more central than say,
date and time types, as far as how necessary they are for
bootstrapping Perl 6, which is to say, I don't think they are
necessary at all.

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, integers, strings, and collection types.

So, if non-integer numbers are officially language extensions, such
as date and time types are, though they may be privileged by having
their operators automatically imported for ease of use, and by how
they are implemented, then that could make a lot of design work
easier.

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. This
would also allow easier substitutions of such math libraries by
specializations for science or statistics or whatever, as the need
may be, since we don't really want to bundle *everything* with the
language.

Really, dealing with non-integer numbers properly deserves,
conceptually or actually, a separate component or several just for
them, as per unix philosophy of dedicated pieces doing what they do
well.

I hope this proposal makes sense.

-- Darren Duncan

Luke Palmer

unread,
Jan 4, 2007, 6:32:11 AM1/4/07
to Darren Duncan, perl6language
On 1/4/07, Darren Duncan <dar...@darrenduncan.net> 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 don't need
anything but function abstraction, function application, and source
filter capability to implement the language core. But that's kind of
skirting the issue.

> 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, integers, strings, and collection types.

They are necessary for I/O: mainly (and I think only) in the sleep() function.

> So, if non-integer numbers are officially language extensions, such
> as date and time types are, though they may be privileged by having
> their operators automatically imported for ease of use, and by how
> they are implemented, then that could make a lot of design work
> easier.

Well, that could make a lot of design work easier *for us*. Somebody
still has to design it There's a lot to be said for pushing design
issues off to CPAN. But I don't think this is the right time.

All numerics modules would have to know how to work with each other
(lest you would not be able to use a module whose numerics disagreed
with yours, if any non-integral numerics were in the interface).
That's not going to happen (and it becomes quadratically harder to add
new numerics modules). You could have a canonical form that the
numerics interface would have to know how to convert to, but that
isn't stripping all non-integral numerics from the language: it's
stripping all but one. But, supposing that we chose, eg. Rat for
that[1]...

Parrot has a native floating point type, requiring that the numerics
module implementor would have to modify the code generator and
optimizer, a royal pain in the ass (assuming we can come up with a
modular way to do such a thing in the first place...).

Finally, it's just weird. Perl is great at being "easy to get going
with", the TIMTOWTDI thing. Having to import a module in order to
divide two numbers, before you know what a module is, is too confusing
to beginners. Most perl tutorials start with "start every script with
#!/usr/bin/perl" (and many times) "#!/usr/bin/perl -w use strict;".
We're turning strict and warnings on by default because we thought
that having to start every script with a particular string was poor
huffman coding. Do you really want to add "use Numerics::Float" to
that list of "always use these" strings?

> Really, dealing with non-integer numbers properly deserves,
> conceptually or actually, a separate component or several just for
> them, as per unix philosophy of dedicated pieces doing what they do
> well.

This I agree with. Numerics are important enough to design an
architecture for. But I don't think that it would be a good decision
to punt them to CPAN, because they need to be pervasive in the
language: it's pretty important to get the numerics "module" right,
but it's much more important that everybody agrees on which one to
use.

Luke

[1] There are problems with choosing a canonical form, because the
only numeric form that can accurately represent all others is the
"algebraic form" (not to be confused with algebraic numbers) where you
just delay all operations that lose any accuracy whatsoever.

Larry Wall

unread,
Jan 4, 2007, 2:03:44 PM1/4/07
to perl6language
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, integers, strings, and collection types.
:
: They are necessary for I/O: mainly (and I think only) in the sleep()
: function.

Yes, though I'd generalize sleep() to pretty much any time API,
since time is (to the first approximation) continuous. The time()
function will return a floater, for instance. It should be considered
wrongish to supply any timing API that only lets you specify integer
seconds plus integer fractions of a second. Such APIs are not
interoperable, and floaters are getting fast enough that timing
calculations should not be a bottleneck.

: >So, if non-integer numbers are officially language extensions, such


: >as date and time types are, though they may be privileged by having
: >their operators automatically imported for ease of use, and by how
: >they are implemented, then that could make a lot of design work
: >easier.
:
: Well, that could make a lot of design work easier *for us*. Somebody
: still has to design it There's a lot to be said for pushing design
: issues off to CPAN. But I don't think this is the right time.

Agreed. Perl 6 is about picking good defaults along with the extensibility.

: All numerics modules would have to know how to work with each other


: (lest you would not be able to use a module whose numerics disagreed
: with yours, if any non-integral numerics were in the interface).
: That's not going to happen (and it becomes quadratically harder to add
: new numerics modules). You could have a canonical form that the
: numerics interface would have to know how to convert to, but that
: isn't stripping all non-integral numerics from the language: it's
: stripping all but one. But, supposing that we chose, eg. Rat for
: that[1]...

There are intermediate solutions that don't require a full crossbar
solution. We could have a pecking order of interchange formats such
that the "best" one is negotiated by any two numerics packages. If two
packages both can do algebraic form, they use that. Otherwise if
both can do Rats, they use that. Otherwise they use the biggest Flt
they can both manage. We probably require all numerics to support
Flt64 or some such. Perhaps the pecking order can be user-defined
to sneak Dec or Fix in there somewhere, or to rate Flt better than Rat
for speed reasons.

Of course, any two numerics packages can negotiate to make a direct
conversion and bypass the canonical pecking order entirely. But if
Num is generic numerics then it could presumably be aliasable within
a lexical scope to any type that supports the pecking order. The
default would presumably be Flt.

Larry

Darren Duncan

unread,
Jan 4, 2007, 5:22:49 PM1/4/07
to perl6language
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 numeric support be
punted to CPAN.

Third, I was not suggesting that users would have to say things like
"use Num::Float" in order to do basic things.

Treating the support as an "extension" still allows it to be
distributed with Perl itself, and imported by default.

My suggestion is fundamentally about how we might conceptualize the
matter of where non-integer numerics fit in the language.

By conceptualizing them as being more on the fringes rather than the
inner circle, it allows us to make the associated feature set
"bigger" without feeling like we're bloating the core, which includes
possibly splitting and extending Num (and Complex) up into several
more distinct types with their own specified semantics, eg rational
vs float.

In short, it frees us more to not try and shoehorn a complicated
matter into a small space to "avoid bloat", but give it its own space.

I hope that helps.

-- Darren Duncan

Dave Whipp

unread,
Jan 4, 2007, 9:23:11 PM1/4/07
to perl6-l...@perl.org
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 agree with the general idea that this is non core (from an
implementatin perspective); but one thing struck me here (slightly off
topic, but not too far): a quaternion cannot be a Num because anyone
using a "Num" will assume that multiplication is commutative (for
quaternions, $a*$b != $b*$a).

It would be good if the type system could catch this type of thing; e.g.
as a trait on the infix:<*> operator that would prevent the composition
of the Num role from the Quaternion role because of this operator
behavioral mismatch. The fundamental types should offer very strong
guarantees of their behavior: implementations can differ in their
precision and accuracy; but not much more.

Doug McNutt

unread,
Jan 4, 2007, 11:57:24 PM1/4/07
to perl6-l...@perl.org
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 or not, real vs complex vs quaternon, etc.
>
>I agree with the general idea that this is non core (from an implementatin perspective); but one thing struck me here (slightly off topic, but not too far): a quaternion cannot be a Num because anyone using a "Num" will assume that multiplication is commutative (for quaternions, $a*$b != $b*$a).

Complex is truly a kind of number even though it has two dimensions, sort of. Completeness in the sense that every number has a square root is an argument for including them in the core.

Quaternions are much more like vectors - real ones - where we have been before. Those array operators which I first thought were going to be real vector operators like cross and dot product are confusing enough. I think of a quarternion as a unit vector with an extra component for length. Aren't there two kinds of multiplication for them?

Vectors, matrices, tensors, and symmetry groups should not be core but the procedures for overloading operators so that they can be implemented as add-ins should be ready to use and easy for a simple-minded mathematician to implement.

--
--> If it's not on fire it's a software problem. <--

Darren Duncan

unread,
Jan 5, 2007, 2:28:02 AM1/5/07
to perl6-l...@perl.org
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 interval
>>>based vs not, caring about sigfigs or not, real vs complex vs
>>>quaternon, etc.
>>
> >I agree with the general idea that this is non core (from an
>implementatin perspective); but one thing struck me here (slightly
>off topic, but not too far): a quaternion cannot be a Num because
>anyone using a "Num" will assume that multiplication is commutative
>(for quaternions, $a*$b != $b*$a).
>
>Quaternions are much more like vectors - real ones - where we have
>been before.
>
>Vectors, matrices, tensors, and symmetry groups should not be core
>but the procedures for overloading operators so that they can be
>implemented as add-ins should be ready to use and easy for a
>simple-minded mathematician to implement.

FYI, my mentioning of quaternions was a throwaway example, based on
the assumption from context that they were to complex what complex
was to real; please ignore that detail in my post. -- Darren Duncan

TSa

unread,
Jan 9, 2007, 11:35:16 AM1/9/07
to perl6language
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 - integer modulus
> / - number division
> % - number modulus

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)

That is we define % and mod as the saw-tooth function that
has jumps at every integer multiple of the absolute value of
the modulus:
^ y
|_m
/ /| / / / /
/ / | / / / / x % m
/ / |/ / / /
-*---*---*---*---*---*--> x
-2m -m 0 m 2m 3m

E.g. 3.2 % 2.4 == 3.2 % -2.4 == 0.8

This definition is most useful when it comes to defining the modulus
for classes that fit the underlying axioms of an (euclidean) integral
domain. E.g. this modulus is also defined for Complex numbers.


Regards, TSa.
--

Doug McNutt

unread,
Jan 9, 2007, 2:08:01 PM1/9/07
to perl6language
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 numbers.

That is well worth reading from this physicist's point of view. 2001 is well before I found you guise.

Integer part of a complex number tells which integral-radius annulus it's in. An interesting and likely useful concept.

Mark J. Reed

unread,
Jan 9, 2007, 2:23:25 PM1/9/07
to Doug McNutt, perl6language
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 zero.

Jonathan Lang

unread,
Jan 9, 2007, 11:51:55 PM1/9/07
to p6l

Personally, I like the fact that the Euclidian definition yields a
positive remainder for all real numbers.

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)?

--
Jonathan "Dataweaver" Lang

TSa

unread,
Jan 11, 2007, 6:31:20 AM1/11/07
to p6l
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 Gaussian Integers Int[i], i.e. complex
numbers with Int coefficients. There you have to solve the equations

a = q * b + r

with q and r from Int[i] and N(r) < N(b) where N(x + yi) = x**2 + y**2.
This yields for your numbers e.g.

a = 8i, b = 3 => q = 2i, r = 2i

But what comes as a surprise to me is that these q and r are not unique!
q = 3i and r = -i works as well. So there is an additional constraint on
r that enforces a unique pair. E.g. x >= 0 and y >= 0 for r = x + yi.
Here are my results for the rest of your examples:

a = 8, b = 3i => q = -2i, r = 2
q = -3i, r = -1

a = 3 + 4i, b = 3 => q = 1 + i, r = i

a = 8, b = 4 + 3i => q = 1 - i, r = 1 + i

a = 12 + 5i, b = 3 + 4i => q = 2 - i, r = 2
q = 3 - i, r = -4i
q = 2 - 2i, r = -2 + 3i

I cannot give an algorithm how to calculate the remainder.
Even less do I know how to generalize it to full Complex.

Regards, TSa.
--

TSa

unread,
Jan 15, 2007, 9:52:28 AM1/15/07
to perl6language
HaloO,

So, you are opting for the F-definition. Could you give examples
where the E-definition makes problems when crossing zero?


Looks like we need a host of division function pairs:

fdiv fmod flooring division
ediv emod euclidean division
rdiv rmod rounding division
tdiv tmod truncating division
cdiv cmod ceiling division

Note that the div functions have signature :(Num, Num --> Int)
and the mod functions have signature :(Num ::T --> T). When called
with Ints the mod funtions also return an Int. There should be a
pair of operators div and % that is aliased to one of the above
according to a pragma. The F-definition seems to be the default
by popular demand.

The / operator always returns a Num or perhaps has signature
:(Num --> Num ^ Int) such that 8 / 2 == 4 gives an Int result.
Even 1.6 / 0.4 == 4 might return an Int. But this means that / has
to run a divisibility test and rounding errors might spoil this.
E.g. (4/3) / (1/3) == 4.0000000003 is just almost an Int.

The R-definition has the funny effect of returning a negative
remainder even for positiv dividend and divisor. E.g. 8 rdiv 3 == 3
and 8 rmod 3 == -1. But this definition is used in the complex
case of the Gaussian Integers. E.g.

(12 + 5i) div (3 + 4i) == round(2.24 - 1.32i) == 2 - i

and

(12 + 5i) % (3 + 4i) == 2


BTW, we should define that the family of rounding functions
floor, ceil, round and trunc all take a positiv modulus as their
optional second argument that defines the jump width and height.
The default is of course 1. E.g floor(1.3, 0.25) == 1.25 and
floor(-2.7, 1.3) == -3.9. We could actually make these two optional
positional parameters for width and height separately with the
height the same as the width if not given and width defaulting to 1,
as before.


Regards, TSa.
--

TSa

unread,
Jan 15, 2007, 12:06:27 PM1/15/07
to p6l
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 components separately.
That is the rmod definition as outlined in my other mail in
this thread. The fact that a remainder is negative for positive
dividend and divisor is moot for complex numbers with their
continuous "sign" in the range 0..2*pi in the polar representation.

Regards, TSa.
--

Smylers

unread,
Jan 15, 2007, 4:01:29 PM1/15/07
to perl6-l...@perl.org
TSa writes:

> Looks like we need a host of division function pairs:
>
> fdiv fmod flooring division
> ediv emod euclidean division
> rdiv rmod rounding division
> tdiv tmod truncating division
> cdiv cmod ceiling division

That depends on exactly what you mean by "we" and "need".

I think it would be terrible to that many div and mod functions as a
core part of the Perl language. Most people would rarely use any of
them, and merely having them there at all slightly raises the barrier of
entry to Perl, making the documentation just a little bit fatter.

By all means have them available as modules. Presumably people who need
this stuff in Perl 5 have already created Cpan modules providing them,
and the same will happen in Perl 6.

Smylers

TSa

unread,
Jan 16, 2007, 9:57:36 AM1/16/07
to perl6-l...@perl.org
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 available as modules.

That is perfectly fine. We should have / return a Num, div return
an Int and % as the Num modulus. This somewhat leaves mod undefined.
How could we fill-in that gap with a useful case? Perhaps we sneak in
euclidean remainder? But that would not fit the F-definition div. So
we might have the pairs fdiv and % and div and mod in core and the rest
in a module. Hmm, or we drop % or use it for something else. The
simplest solution is to have mod as alias for %. Note that F-definition
and E-definition agree for a divisor greater than zero.

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 beeing the default when no import is
done. A sane definition of div and % is important. A spec that leaves
it up to the implementation to pick whatever is convenient is bad in
my eyes.


Regards, TSa.
--

Jonathan Lang

unread,
Jan 16, 2007, 10:45:06 AM1/16/07
to p6l
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
> done.

You're unlikely to ever need more than one definition at a time; so
put each in its own module and import as needed. This will produce
both simpler code (you won't need to remember which of nearly a
half-dozen variant spellings of div or mod to use each time in order
to get the appropriate definition) and more readable code (e.g., if
you see "use Math::Modulus::Truncate" in a given lexical scope, you
know that div and mod will be using the truncating definition there).

In the rare instance that you need more than one definition at a time,
import the ones you need and qualify your div and mod calls by the
module names: e.g. 'Math::Modulus::Euclid::div' and
'Math::Modulus::Floor::div'. The Huffman coding seems appropriate;
and if the length is excessive, it's because the module names' lengths
should be shorter (say, 'Math::ModE' instead of
'Math::Modulus::Euclid').

> A sane definition of div and % is important. A spec that leaves
> it up to the implementation to pick whatever is convenient is bad in
> my eyes.

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)?

--
Jonathan "Dataweaver" Lang

TSa

unread,
Jan 16, 2007, 11:30:33 AM1/16/07
to p6l
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 Mark has with
calculations crossing zero that are more difficult with
the Euclidean definition. Any idea?

Regards, TSa.
--

TSa

unread,
Jan 17, 2007, 12:48:18 PM1/17/07
to perl6language
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. It's more like 0.999... which raises
the question how the construction of an Int from a Num works?
Do we truncate, floor or round? Would (1/3*3).does(Int) be
true?


> Should 10**500 be infinity or a 1 with 500 zeroes after it?

IEEE 754 distinguishes Overflow from Inf. Both are outside the
order of the valid numbers. Should we have these exceptional values
comparable? E.g. code like

# some calculation involving $x
if $x == Overflow {...}

seems reasonable. And I think that Inf == Inf and things
like $x < Inf should be valid syntax. I think Overflow < Inf
makes sense as well.


> Should 10**10**6 run out of memory? Should
> "say (1/3)**500" print a bunch of digits to the screen or print 0?

Are we silently underflowing to zero? Or should it return an
Underflow? In particular I would expect Underflow to carry a
sign and Underflow.abs > 0.

Also Num needs to support signed zero e.g. for handling 1/(1/$x)
for $x == +/-Inf to end up with the correct sign of Inf. But of
course +0 == -0.


A somewhat tangential idea of mine are types like int31 that makes
signed 32 bit arithmetic modulo the Mersenne prime 2**31 - 1. That
would guarantee two things. First $x * $y > 0 whenever $x > 0 &&
$y > 0, that is there are no divisors of zero. Second -2**31 is
available to encode "infinity" or NaN. In int61 arithmetic with
modulus 2**61 - 1 in a 64 bit value we have the two spare bit
combinations 01 and 10 after the sign to encode special numbers.

Regards, TSa.
--

Jonathan Lang

unread,
Jan 17, 2007, 1:03:19 PM1/17/07
to p6l
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
role A does not compose role B; and my understanding has been that Int
does Num, not the other way around.

--
Jonathan "Dataweaver" Lang

luc_J_...@mac.com

unread,
Jan 21, 2007, 4:50:39 PM1/21/07
to

TSa wrote:

> IEEE 754 distinguishes Overflow from Inf. Both are outside the
> order of the valid numbers. Should we have these exceptional values
> comparable? E.g. code like
>
> # some calculation involving $x
> if $x == Overflow {...}
>
> seems reasonable. And I think that Inf == Inf and things
> like $x < Inf should be valid syntax. I think Overflow < Inf
> makes sense as well.

I think you are mistaken. By IEEE 754, Inf is one possible value of a
floating point number whereas overflow is a flag which is set when the
result of a computation cannot be represented within the range of the
current floating point format. There are quite a few other "special"
values, +0, -0, NaN, subnormals and quite a few other such flags,
invalid, divide by zero, overflow, underflow, inexact. The idea is that
the programmer can retrospectively look at those flags. It is actually
also permitted to set traps which would raise an exception if one of
those flags is set, but this is in no way compulsory since IEEE 754
guarantees that any floating-point operation will return a meaningful
result, even if it has to be one of the special values.

Thus I am afraid that your proposed Overflow < Inf is an heresy by IEEE
754.

A good annotated reference is of course Kahan's explication of the
standard: http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF

> Also Num needs to support signed zero e.g. for handling 1/(1/$x)
> for $x == +/-Inf to end up with the correct sign of Inf. But of
> course +0 == -0.

That is an excellent remark indeed.

Luc Bourhis
Univ. Of Durham

Darren Duncan

unread,
Jan 22, 2007, 6:34:55 PM1/22/07
to p6l

I think that 1 should be an Int and 1.0 should be a Num. That makes
things very predictable for users, as well as easy to parse ... the
visible radix point indicates that you are usually measuring to
fractions of an integer, even if you aren't in that exact case. Also
importantly, it makes it easy for users to choose what they want.

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.

Furthermore, my preference is for Int and Num to be completely
disjoint types, meaning that "1 === 1.0" will return False. However,
every Int value can be mapped to a Num value, and so "1 == 1.0" will
return True as expected, because == casts both sides as Num.

As for which .does which, I would use the relationship between Str
and Int|Num as an example. AFAIK, Int|Num .does Str, but not the
reverse. Similarly, Int should .does Num, but not the reverse. This
is all assuming that the purpose of .does is to indicate when values
of one type can be substituted for values of another type.

Similarly, if there is no .does relationship between Int|Num and Str,
due to what .does is actually for, then there shouldn't be one
between Int and Num.

-- Darren Duncan

Smylers

unread,
Jan 22, 2007, 7:32:32 PM1/22/07
to perl6-l...@perl.org
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 in Perl 6 to print 50.0 instead?

Obviously it would be possible to get 50 by explicitly converting the
result to an integer:

% perl6 -e 'say (100 / 2).int'

But of course always using C<int> means you lose any fractional parts
from divisions that don't yield integers:

% perl -wle 'print 99 / 2'
49.5

How would you get the current Perl 5 behaviour of displaying fractional
parts if they exist and not if they don't?

Smylers

Doug McNutt

unread,
Jan 22, 2007, 8:19:28 PM1/22/07
to perl6-l...@perl.org
At 00:32 +0000 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 because a coercion was required and float is the default for such things.

But that may be the mathematician in me. Computers often do things I don't expect.

my $numer = 99 as INT; (You know what I mean. Perhaps a DIM statement?)
my $denom = 2 as INT;
print $numer / $denom;
???

--
--> If you are presented a number as a percentage, and you do not clearly understand the numerator and the denominator involved, you are surely being lied to. <--

Darren Duncan

unread,
Jan 22, 2007, 8:35:29 PM1/22/07
to perl6-l...@perl.org
At 12:32 AM +0000 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):
>
> % perl -wle 'print 100 / 2'
> 50
>
>you would want in Perl 6 to print 50.0 instead?

If you said "print 100 / 2" in Perl 6, I would expect you to get "50"
out because you did a division of 2 Int. Whereas, if you said "print
100.0 / 2.0", then I would expect a "50.0" output, as you did a
division of 2 Num.

-- Darren Duncan

Dave Whipp

unread,
Jan 22, 2007, 8:57:59 PM1/22/07
to perl6-l...@perl.org
Doug McNutt wrote:
> At 00:32 +0000 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, literals
should be Num-bers, because that's what's usually intended. Either that,
or infix:</>(Int,Int-->Num) -- except when MMD on return type finds a
more constrained form.

Larry Wall

unread,
Jan 22, 2007, 8:56:46 PM1/22/07
to perl6-l...@perl.org
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 and emod can in turn be importable
aliases to whichever kind of divmod you like, potentially even
overriding the definition of "div" and "mod" in the current lexical
scope through the magic of lexically scoped multiple dispatch.

And % should stick to standard floor semantics, I expect.

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 real number line
happen to be the same number most of the time. And Perl is not about
forcing a type-theoretical viewpoint on the user...

Larry

Darren Duncan

unread,
Jan 22, 2007, 11:47:22 PM1/22/07
to perl6-l...@perl.org
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 real number line
>happen to be the same number most of the time. And Perl is not about
>forcing a type-theoretical viewpoint on the user...

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 be the
case, such that, eg, 1 === 1.0 returns true.

Of course if we did that, then dealing with Int will have a number of
the same implementation issues as with dealing with "subset"-declared
types in general.

I don't know yet whether it was decided one way or the other.

Whereas, if Int is not an actual subset of Num, and so their values
are disjoint, then ...

FYI, my comment about a stringified Num having a .0 for
round-tripping was meant to concern Perl code generation in
particular, such as what .perl() does, but it was brought up in a
more generic way, to stringification in general, for an attempt at
some consistency.

Whether or not that is an issue depends really on whether we consider
the literal 1.0 in Perl code to be an Int or a Num. If, when we
parse Perl, we decide that 1.0 is a Num rather than an Int such as 1
would be, then a .perl() invoked on a Num of value 1.0 should return
1.0 also, so that executing that code once again produces the Num we
started with rather than an Int.

On the other hand, if .perl() produces some long-hand like "Int(1)"
or "Num(1)", then it won't matter whether it is "Num(1)" or
"Num(1.0)" etc.

-- Darren Duncan

Smylers

unread,
Jan 23, 2007, 2:55:38 AM1/23/07
to perl6-l...@perl.org
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

TSa

unread,
Jan 23, 2007, 6:38:21 AM1/23/07
to perl6-l...@perl.org
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 be the case,
> such that, eg, 1 === 1.0 returns true.

I agree to that except for the last statement. I think that 1 === 1.0
should be False because the involved types are different. This e.g.
also applies to 1.0 === Complex(1.0,0.0) which should be False. In
both cases we should have numeric equality, i.e. 1 == 1.0 and
1.0 == Complex(1.0,0.0) are True. And of course we have the subtyping
chain Int <: Num <: Complex.

The Gaussian integers are a subtype of Complex and a supertype of
Int but not of Num. So in the end we have the type lattice

Complex
/ \
Num Gaussian
\ /
Int

It's interesting how this Gaussian type might be fitted in after the
other three. The link from Int to Gaussian needs a supertyping
construct. Something like 'role Gaussian does Complex superdoes Int'.
So consider this as an addendum to the supertyping thread.


Regards, TSa.
--

Larry Wall

unread,
Jan 23, 2007, 12:45:50 PM1/23/07
to perl6-l...@perl.org
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 mathematicians) think that
: >the integer 1 and the distance from 0 to 1 on the real number line
: >happen to be the same number most of the time. And Perl is not about
: >forcing a type-theoretical viewpoint on the user...
:
: 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 be the
: case, such that, eg, 1 === 1.0 returns true.
:
: Of course if we did that, then dealing with Int will have a number of
: the same implementation issues as with dealing with "subset"-declared
: types in general.
:
: I don't know yet whether it was decided one way or the other.

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 high bits. It would be possible to make Int a subset of Rat
(assuming Rat is implemented as Int/Int), but I don't think Rats are
very practical either for most applications. It is unlikely that the
universe uses Rats to calculate QM interactions.

: Whereas, if Int is not an actual subset of Num, and so their values
: are disjoint, then ...

Then 1.0 == 1 !=== 1.0. I'm fine with that.

: FYI, my comment about a stringified Num having a .0 for

: round-tripping was meant to concern Perl code generation in
: particular, such as what .perl() does, but it was brought up in a
: more generic way, to stringification in general, for an attempt at
: some consistency.

It seems like an unnecessary consistency to me. The .perl method
is intended to provide a human-readable, round-trippable form of
serialization, and as a form of serialization it is required to
capture all the information so that the original data structure
can be recreated exactly. This policy is something the type should
have little say in. At most it should have a say in *which* way to
canonicalize all the data.

The purpose of stringification, on the other hand, is whatever the type
wants it to be, and it is specifically allowed to lose information,
as long as the remaining string is suggestive to a human reader how
to reconstruct the information in question (or that the information is
none of their business). A document object could decide to stringify
to a URI, for instance. An imported Perl 5 code reference could
decide to stringify to CODE(0xdeadbeef). :)

: Whether or not that is an issue depends really on whether we consider

: the literal 1.0 in Perl code to be an Int or a Num. If, when we
: parse Perl, we decide that 1.0 is a Num rather than an Int such as 1
: would be, then a .perl() invoked on a Num of value 1.0 should return
: 1.0 also, so that executing that code once again produces the Num we
: started with rather than an Int.

I think the intent of 1.0 in Perl code is clearly more Numish than
Intish, so I'm with you there. So I'm fine with Num(1).perl coming
out simply as "1.0" without further type annotation. But ~1.0 is
allowed to say "1" if that's how Num likes to stringify.

: On the other hand, if .perl() produces some long-hand like "Int(1)"

: or "Num(1)", then it won't matter whether it is "Num(1)" or
: "Num(1.0)" etc.

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 purposes,
at least by default.

Larry

Jonathan Scott Duff

unread,
Jan 23, 2007, 9:50:48 AM1/23/07
to Doug McNutt, perl6-l...@perl.org
On 1/22/07, Doug McNutt <doug...@macnauchtan.com> wrote:
>
> At 00:32 +0000 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 meant integer division. Being used to how
Perl 5 (and many other languages) do things, I would expect floating point
division (though if it's not floating point beneath the covers that's fine
with me as long as I can still get 49.5 out).

% perl -wle 'print 99.0 / 2.0' OR
> % perl -wle 'print 99.0 / 2'
>
> would return 49.5 because a coercion was required and float is the default
> for such things.
>
> But that may be the mathematician in me.


I don't see why the mathematician in you doesn't expect "regular"
mathematical behavior from Perl. Perhaps it's that you've been using
computers too long and have become used to the limitations of digital media.

-Scott
--
Jonathan Scott Duff
perl...@gmail.com

Jonathan Scott Duff

unread,
Jan 23, 2007, 9:40:50 AM1/23/07
to perl6-l...@perl.org
I accidently sent this just to Darren ...

-Scott

---------- Forwarded message ----------
From: Jonathan Scott Duff <perl...@gmail.com>
Date: Jan 22, 2007 6:23 PM
Subject: Re: Numeric Semantics
To: Darren Duncan <dar...@darrenduncan.net>

On 1/22/07, Darren Duncan <dar...@darrenduncan.net> wrote:.

> I think that 1 should be an Int and 1.0 should be a Num. That makes
> things very predictable for users, as well as easy to parse ... the
> visible radix point indicates that you are usually measuring to
> fractions of an integer, even if you aren't in that exact case. Also
> importantly, it makes it easy for users to choose what they want.
>

> 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.
>

> Furthermore, my preference is for Int and Num to be completely
> disjoint types, meaning that "1 === 1.0" will return False. However,
> every Int value can be mapped to a Num value, and so "1 == 1.0" will
> return True as expected, because == casts both sides as Num.


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) { ... }

Anyway, it's not like this problem wasn't already there, it's just that your
email made it stand out to me.

Paul Seamons

unread,
Jan 23, 2007, 2:43:21 PM1/23/07
to perl6-l...@perl.org
> 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) { ... }
>
> Anyway, it's not like this problem wasn't already there, it's just that
> your email made it stand out to me.

I'm not adding support to either side of the issue. I just wanted to point
out that with Perl 5 and other current languages I occasionally have to
search for that bug right now. Except it is spelled a little different with

if ($alpha = $beta) { ... }

When I really meant:

if ($alpha == $beta) { ... }

It is rare though. I think the == vs === will be rare also.

Paul

Jonathan Scott Duff

unread,
Jan 23, 2007, 6:02:59 PM1/23/07
to Paul Seamons, perl6-l...@perl.org


Perhaps.

To me, finding the = vs. == bug is a bit easier due to the large conceptual
difference between the operators. (or maybe I'm just used to looking for it
after 20+ years of coding in languages that have = and ==) But for == vs.
===, they are both comparators and that tends to muddy the waters a bit when
it comes to your brain helping you find the bug. (at least it does for me)

TSa

unread,
Jan 24, 2007, 6:47:56 AM1/24/07
to perl6-l...@perl.org
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 high bits.

But we can have Int a subtype of Num? That would be very
practical for dispatch which uses the partial order of the
types. In particular mixed mode dispatches like 3.14 + 2
should be dispatchable to &infix:<+>:(Num,Num-->Num). And
of course there can be specializations for pure Int
&infix:<+>:(Int,Int-->Int). And for optimization purposes
there will be targets like &infix:<+>:(int32,int32-->int32^int64).
In other words there will be subtype relations between the
lowercase types like int32 <: num64. BTW, do we have something
like num80, num96 and num128 to support e.g. int64 <: num80?

If we do arbitrary integer math we might as well need to
do arbitrary floating math. The combinations need to be
picked such that the Int types are fully embedded in the
floats. E.g. 32 bit ints are embedded into 64 bit floats.
So whenever the Int implementation switches to a bigger
representation the corresponding Num has to make a step
as well.

In the abstract we could represent Nums as an integer
plus a remainder in the range 0..^1. Integers would then
be a proper subset with the constraint that the remainder
is zero. For full rational number support the remainder
must be capabable of repetitions such that 0.333... represents
1/3 with full accuracy and results like 0.999... are normalized
to 1.0. For irrational numbers the remainder might have a
closure that produces more digits if requested.

Regards, TSa.
--

TSa

unread,
Jan 24, 2007, 7:20:51 AM1/24/07
to perl6-l...@perl.org
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. Then we could make the div and mod pair
mean the Euclidean definition. Everything else could be loadable
from a module. Deal?

Regards, TSa.
--

Smylers

unread,
Jan 24, 2007, 7:39:51 AM1/24/07
to perl6-l...@perl.org
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 based
> modulus. Then we could make the div and mod pair mean the Euclidean
> definition.

Do you think most Perl programmers appreciate the difference, or are
likely to need both sorts frequently? I'd much prefer for introductory
Perl books not to have to explain what "Euclidean" means.

> Everything else could be loadable from a module.

I still reckon a single type of division is sufficient in core, with
everything else in modules.

Smylers

TSa

unread,
Jan 24, 2007, 7:42:37 AM1/24/07
to perl6-l...@perl.org
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 purposes,
> at least by default.

Does that mean that 1 actually defaults to int32 and 1.0
to num64? How is ** handled? Does 2**2 === 4 or does that
mean 4.0 === 4 and hence False? In other words is there a
&infix:<**>:(Int,UInt-->Int) and will 2**2 dispatch to it?

Talking of UInt, how is potential sign handled in ===?

my UInt $x = 3;
my Int $y = 3;

if $x === $y { say "true?" }

Regards, TSa.
--

TSa

unread,
Jan 24, 2007, 8:06:53 AM1/24/07
to perl6-l...@perl.org
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 floor
definition was chosen, either.


> I still reckon a single type of division is sufficient in core, with
> everything else in modules.

Sorry I was taken away by the beauty of the two pairs
÷, % and div, mod. But I figure that people might want
div as ASCII version of ÷ and perhaps like mod better
than %.


Regards, TSa.
--

Smylers

unread,
Jan 24, 2007, 8:57:44 AM1/24/07
to perl6-l...@perl.org
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). But as soon as we have two different sorts of div, it's
necessary to explain the difference between them.

Smylers

Nicholas Clark

unread,
Jan 24, 2007, 5:53:26 PM1/24/07
to perl6-l...@perl.org
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 as "normal", but even with my knowledge of C,
and its typing and presence, it still took me two weeks to track down the
bug in

double mu = 2/3;

which produced very wrong results. (The rheology was supposed to be perfectly
elastic, so we knew something was wrong, but tracking it down to that line...)

If I write 2/3 I'm thinking maths, not type theory, and "two thirds" is what
I expect.

Nicholas Clark

TSa

unread,
Jan 30, 2007, 12:02:59 PM1/30/07
to perl6language
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 it truncating
to zero and indexing from the front?


Another integer issue is how the ++ and -- operators behave. Do they
coerce to int before the operation or do they keep nums as nums?
E.g.

my $x = 3.25;
$x++; # 4.25 or 4?
$x = -2.25;
$x--; # -3.25 or -4 or -3?


How are coercions handled when calling functions?

sub identity ( Int $i ) { return $i }

my Num $x = 3.25;

say indentity($x); # prints 3 or type error? Or even 3.25?

I'm opting for type error on the footing that Int <: Num and
you can't allow a supertype where a subtype is expected.


BTW, are character positions integers or can we have fractional
characters on a higher unicode level that is a sequence of lower
level chars?


Regards, TSa.
--

Larry Wall

unread,
Jan 30, 2007, 12:14:43 PM1/30/07
to perl6language
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

Larry Wall

unread,
Jan 30, 2007, 12:23:33 PM1/30/07
to perl6language
On Tue, Jan 30, 2007 at 06:02:59PM +0100, TSa wrote:
: 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 it truncating
: to zero and indexing from the front?

Perl 5 truncates, I believe. One could argue that floor is better behaved,
but the 0/-1 transition in subscripts is totally cork-brained anyway, so
I don't think it really matters if our numbers behave when wrapping around
the end of an array.

Interestingly, negative fractions, if truncated, would give us a way to
talk about the element off the end of the array, presuming that the endness
of the subscript is determined from the sign before it is truncated:

push @array, 42;
@array[-0.1] = 42; # same thing
@array[-0.0] = 42; # same thing?

Since -0.0 is a possible Num representation, that last one probably works.
But @array[-0] probably doesn't, since Int probably doesn't represent -0,
and the constant folder would remove the sign before the subscript can
see it.

But it probably doesn't matter. If one really wants "infinite" modular
arrays, then you probably just say @array[$x % @array] or some such,
which gives you the floor semantics.

Larry

Larry Wall

unread,
Jan 30, 2007, 12:41:53 PM1/30/07
to perl6language
On Tue, Jan 30, 2007 at 06:02:59PM +0100, TSa wrote:
: BTW, are character positions integers or can we have fractional

: characters on a higher unicode level that is a sequence of lower
: level chars?

Unfortunately this is a units problem where the units are not of
fixed length. StrPos is already defined in S02 to be an opaque type
that you should not think of as being in any particular units except
perhaps "chars at the current Unicode level". Subtracting two StrPos
objects gives you a StrLen at the current Unicode level. These might
all be represented underneath as byte or codepoint offsets, but the
user should not rely on it.

Larry

Jonathan Lang

unread,
Jan 30, 2007, 5:19:01 PM1/30/07
to perl6language
Larry Wall wrote:

> TSa wrote:
> : 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 it truncating
> : to zero and indexing from the front?
>
> Perl 5 truncates, I believe. One could argue that floor is better behaved,
> but the 0/-1 transition in subscripts is totally cork-brained anyway, so
> I don't think it really matters if our numbers behave when wrapping around
> the end of an array.

Perhaps. Then again, it isn't the remainder that would define which
element you're looking at in this case; it would be the integer
portion. And if I understand flooring semantics properly, -0.3 div 1
== -1. Also, -0.3 mod 1 == 0.7; right? Or is that the difference
between mod and %: the former returns the remainder as an integer
(e.g., '0'), while % return the remainder as a Num (e.g., '0.7')?
With truncating semantics, -0.3 div 1 == 0, and -0.3 % 1 == -0.3.

I think that TSa has a point here: converting from Num to Int should
always be equivalent to saying 'Num div 1'. Which means that if you
ever override div to provide different semantics by default (e.g.,
Euclidean), you would also change the semantics of the Num-to-Int
coercion.

> Interestingly, negative fractions, if truncated, would give us a way to
> talk about the element off the end of the array, presuming that the endness
> of the subscript is determined from the sign before it is truncated:
>
> push @array, 42;
> @array[-0.1] = 42; # same thing
> @array[-0.0] = 42; # same thing?

Eh. A neat little bell-and-whistle, but more confusing than it is useful.

> But it probably doesn't matter. If one really wants "infinite" modular
> arrays, then you probably just say @array[$x % @array] or some such,
> which gives you the floor semantics.

True enough. I'd suggest doing this implicitly (with 'mod' instead of
'%'), ensuring that virtually every index maps to an existing element;
but then you'd lose the ability to append to an array by assigning to
'@array[@array]' (not that I'd do this; but I can see why some might
prefer this idiom to being pushy).

It's the sort of thing that I could see using a trait for: 'my @array
but oroborus' would invoke an implicit modulus on the index, while
standard arrays would not. Likewise, those who don't want the
backward-indexing semantics could remove them by saying something like
'my @array but ray', causing negative indices to throw errors instead.
Ideally, applying both would cause negative indices to choke, but
would wrap too-large positive indices back to the beginning of the
array.

--
Jonathan "Dataweaver" Lang

Nicholas Clark

unread,
Jan 30, 2007, 6:16:05 PM1/30/07
to perl6language
On Tue, Jan 30, 2007 at 09:23:33AM -0800, Larry Wall wrote:

> Since -0.0 is a possible Num representation, that last one probably works.
> But @array[-0] probably doesn't, since Int probably doesn't represent -0,

Well, it might just be using 1's complement :-)

Nicholas Clark

Larry Wall

unread,
Jan 30, 2007, 6:30:09 PM1/30/07
to perl6language
On Tue, Jan 30, 2007 at 02:19:01PM -0800, Jonathan Lang wrote:
: It's the sort of thing that I could see using a trait for: 'my @array

: but oroborus' would invoke an implicit modulus on the index, while
: standard arrays would not. Likewise, those who don't want the
: backward-indexing semantics could remove them by saying something like
: 'my @array but ray', causing negative indices to throw errors instead.
: Ideally, applying both would cause negative indices to choke, but
: would wrap too-large positive indices back to the beginning of the
: array.

Um, negative indices on shaped arrays were outlawed several hours ago...

Larry

Jonathan Lang

unread,
Jan 30, 2007, 6:36:08 PM1/30/07
to perl6language
Larry Wall wrote:
> Um, negative indices on shaped arrays were outlawed several hours ago...

Yeah; I hadn't gotten around to that when I posted this. Sorry about that.

--
Jonathan "Dataweaver" Lang

0 new messages