Re: Numeric Semantics
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.
--
Re: Numeric Semantics
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
Re: Numeric Semantics
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. --
Re: Numeric Semantics
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. --
Re: Numeric Semantics
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
Re: Numeric Semantics
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.
--
Re: Numeric Semantics
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. --
Re: Numeric Semantics
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
Re: Numeric Semantics
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
Re: Numeric Semantics
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. --
Re: Numeric Semantics
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
Re: Numeric Semantics
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 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 [EMAIL PROTECTED]
Fwd: Numeric Semantics
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 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.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Fwd: Numeric Semantics
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
Re: Fwd: Numeric Semantics
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 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.
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)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Numeric Semantics
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 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. 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
Re: Numeric Semantics
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 Cint 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
Re: Numeric Semantics
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 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. --
Re: Numeric Semantics
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): % 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
Re: Numeric Semantics
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, 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.
Re: Numeric Semantics
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
Re: Numeric Semantics
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
Re: Numeric Semantics
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
Re: Numeric Semantics
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.
--
Re: Numeric Semantics
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
Re: Numeric Semantics
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. --
Re: Numeric Semantics
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
Re: Numeric Semantics
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. --
Re: Numeric Semantics
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 any computation that crosses zero. 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 fmodflooring division ediv emodeuclidean division rdiv rmodrounding division tdiv tmodtruncating division cdiv cmodceiling 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.03 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. --
Re: Numeric Semantics
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. --
Re: Numeric Semantics
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. 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
Re: Numeric Semantics
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. --
Re: Numeric Semantics
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. --
Re: Numeric Semantics
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. -- -- If it's not on fire it's a software problem. --
Re: Numeric Semantics
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.
Re: Numeric Semantics
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 complicates any computation that crosses zero. 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
Non-integers as language extensions (was Re: Numeric Semantics)
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
Re: Non-integers as language extensions (was Re: Numeric Semantics)
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 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.
Re: Non-integers as language extensions (was Re: Numeric Semantics)
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
Re: Non-integers as language extensions (was Re: Numeric Semantics)
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
Re: Non-integers as language extensions (was Re: Numeric Semantics)
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.
Re: Non-integers as language extensions (was Re: Numeric Semantics)
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. --
Re: Non-integers as language extensions (was Re: Numeric Semantics)
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
Re: Numeric Semantics
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 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.
:
: 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.
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
Re: Numeric Semantics
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
Re: Numeric Semantics
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. --
Re: Numeric Semantics
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
Re: Numeric Semantics
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 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. 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
Numeric Semantics
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
Re: Numeric Semantics
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 print 0? These are just examples. Exponentials are the easiest to think about limit cases with, but the whole general issue needs precise semantics. 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.
Re: Numeric Semantics
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 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
Numeric Semantics
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
Re: Numeric semantics for base pmcs
On Wed, 25 Aug 2004 07:48:03 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote: John Siracusa [EMAIL PROTECTED] wrote: On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: The big question is whether being clever and producing the tightest type is worth the time to figure out what that type is, as well as the potentially uncertain output type. Tangentially related: will promotion be suitably delayed on systems with support for 64-bit ints? More generally, what is the state-of/plan-for 64-bit support (whatever that may mean) in Parrot? I thought about that during BigInt hacking. It could be a nice optimization if we go: Int - Int64 - BigInt on 32-bit systems that have 64-bit integer support. OTOH it makes type promotion a bit more complicated and dependent on configuration settings. Why make a stop in 32-bit land at all in that case? If the system supports 64-bit ints, why not use them for everything right up until you promote to BigNum? Is it a memory bandwidth issue or something? Either way, it'll definitely be a boon to fast integer math if 64-bit ints are used to stave off promotion to BigNum when possible. This may be especially true for languages like Perl 6 which (AFAIK) doesn't have an int64 native type specifier. So either Perl 6's int type is 64-bit where possible, or is a 32-to-64-auto-promoting type. -John
Re: Numeric semantics for base pmcs
On Thu, 26 Aug 2004 11:10:59 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: At 10:56 AM -0400 8/26/04, John Siracusa wrote: Why make a stop in 32-bit land at all in that case? If the system supports 64-bit ints, why not use them for everything right up until you promote to BigNum? Is it a memory bandwidth issue or something? If you've built parrot to use 64 bit ints, it will. Hm, but does that also mean that it'll expect all ints to be 64 bit? I'm thinking of hybrid situations like Mac OS X on a G5, where the OS and all system libs are still 32-bit, but the CPU can handle 64-bit integers. We still have to generally address the whole 64 bit integer question. I've been avoiding it, but I'm not sure that's ultimately feasable. Obviously someone needs to buy you a G5 in order to adequately motivate you... ;) -John
Re: Numeric semantics for base pmcs
Felix Gallo [EMAIL PROTECTED] wrote: Dan, any feeling about RISC vs. CISC? Because to me, this seems like a good place to punt, and provide two, maybe three mults: Not the best idea. The same argument would hold for all operations that could overflow. With such a strategy will end with MMD tables that blow all processor caches. If you need a more customized behavior you can always override e.g. multiplication. If you need that really fast to, you can provide a custom PMC. Another concern besides speed might be sizeof(PMC) for each of the options...some of the genome/nasa guys could get kinda twitchy if bignum is 1k per, etc., etc. BigNums grow on demand. It depends on value and precision. F. leo
Re: Numeric semantics for base pmcs
John Siracusa [EMAIL PROTECTED] wrote: On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: The big question is whether being clever and producing the tightest type is worth the time to figure out what that type is, as well as the potentially uncertain output type. Tangentially related: will promotion be suitably delayed on systems with support for 64-bit ints? More generally, what is the state-of/plan-for 64-bit support (whatever that may mean) in Parrot? I thought about that during BigInt hacking. It could be a nice optimization if we go: Int - Int64 - BigInt on 32-bit systems that have 64-bit integer support. OTOH it makes type promotion a bit more complicated and dependent on configuration settings. -John leo
Re: Numeric semantics for base pmcs
Dan Sugalski [EMAIL PROTECTED] wrote: At 8:45 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Nope -- we don't have bigints. :) Pardon, sir? We've got the big number code, but I don't see much reason to distinguish between integers and non-integers at this level -- the only difference is exponent twiddling. Ah, ok. BigInt as a degenerated BigNum. I still prefer the notion that adding or multiplying to integers give a BigInt on overflow. While at num vs int: do we automatically downgrade to int again? 6.0/2.0 = 3.0 or 3 ? leo
Re: Numeric semantics for base pmcs
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: At 8:45 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Nope -- we don't have bigints. :) Pardon, sir? We've got the big number code, but I don't see much reason to distinguish between integers and non-integers at this level -- the only difference is exponent twiddling. Ah, ok. BigInt as a degenerated BigNum. I still prefer the notion that adding or multiplying to integers give a BigInt on overflow. While at num vs int: do we automatically downgrade to int again? 6.0/2.0 = 3.0 or 3 ? No. Once a real, always a real. I see no harm in collapsing appropriate rationals to ints mind...
RE: Numeric semantics for base pmcs
On Wed, 25 Aug 2004 08:40:32 -0400, Gay, Jerry [EMAIL PROTECTED] said: Leopold Toetsch [EMAIL PROTECTED] wrote: BigNums grow on demand. It depends on value and precision. can BigNum then start at sizeof(int)? overflow would auto-grow the BigNum to the appropriate size, and most integer math operations will keep space usage as low as possible. in fact, then int is just a degenerate case of BigNum, one that doesn't grow and throws an exception instead. or, maybe that's the case already, i should probably read the docs. ~jerry What is the most reasonable paradigm for scientific/high precision applications? It seems to me that this type of thing has been hashed out before, and it should be designed in a way that makes it attractive/sellable for scientists, engineers, etc. One handicap that Perl has (by reputation only) in the sciences is that it is not good for precision math. I know this is not true, and you all know this is not true, but the community(ies) at large do not know - they are stuck in the land of Fortran, and from my experience people are by-passing Perl for things like Python when they do venture out. Just out of curiosity, is BigNum like a double (16 bit) or is it just limited by the precision of the machine, i.e. 32 or 64 bit? Thanks, Brett Perl6 ToDo: http://www.parrotcode.org/todo
RE: Numeric semantics for base pmcs
BigNum is an arbitrary precision decimal number (Think BCD -- Binary Coded Decimal ala the Unix utility BC) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 25, 2004 9:12 AM To: [EMAIL PROTECTED] Subject: RE: Numeric semantics for base pmcs On Wed, 25 Aug 2004 08:40:32 -0400, Gay, Jerry [EMAIL PROTECTED] said: Leopold Toetsch [EMAIL PROTECTED] wrote: BigNums grow on demand. It depends on value and precision. can BigNum then start at sizeof(int)? overflow would auto-grow the BigNum to the appropriate size, and most integer math operations will keep space usage as low as possible. in fact, then int is just a degenerate case of BigNum, one that doesn't grow and throws an exception instead. or, maybe that's the case already, i should probably read the docs. ~jerry What is the most reasonable paradigm for scientific/high precision applications? It seems to me that this type of thing has been hashed out before, and it should be designed in a way that makes it attractive/sellable for scientists, engineers, etc. One handicap that Perl has (by reputation only) in the sciences is that it is not good for precision math. I know this is not true, and you all know this is not true, but the community(ies) at large do not know - they are stuck in the land of Fortran, and from my experience people are by-passing Perl for things like Python when they do venture out. Just out of curiosity, is BigNum like a double (16 bit) or is it just limited by the precision of the machine, i.e. 32 or 64 bit? Thanks, Brett Perl6 ToDo: http://www.parrotcode.org/todo The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
Re: Numeric semantics for base pmcs
On Tue, 24 Aug 2004, Dan Sugalski wrote: 6) Division of two ints produces a bignum Surely it should only produce a bignum as a last resort. For instance, shouldn't: 4 / 3 produce a float? Also, what about a case like: 4 / 2 Does that produce an int, a float or a bignum? 9) Any operation with a bignum produces a bignum Should there be some way to test whether a bignum can be downgraded into a float? Simon
RE: Numeric semantics for base pmcs
At 1:42 PM -0400 8/24/04, Butler, Gerald wrote: Shouldn't 4 also have potential to produce BigInt? Nope -- we don't have bigints. :) -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Numeric semantics for base pmcs Okay, so: 1) We round to zero when going from float to int 2) Overflows, underflows, and division by zero throws an exception 3) All-float operations produce floats 4) Addition and subtraction of ints produces an int 5) Multiplication of two ints produces a bignum or an int, depending on the result 6) Division of two ints produces a bignum 7) Strings are treated as floats for math operations 8) Any operation with a float and an int, string, or bool produces a float 9) Any operation with a bignum produces a bignum 10) The destination PMC is responsible for final conversion of the inbound value That seem reasonable? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
Dan~ -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Numeric semantics for base pmcs 10) The destination PMC is responsible for final conversion of the inbound value I know there has been a lot of grumbling in the past about the need to create PMCs to be the LHS of operations. I don't have a real suggestion here, but I just wanted to draw attention to this recurring theme, since now would be a good time to deal with it. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
RE: Numeric semantics for base pmcs
Shouldn't 4 also have potential to produce BigInt? -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Numeric semantics for base pmcs Okay, so: 1) We round to zero when going from float to int 2) Overflows, underflows, and division by zero throws an exception 3) All-float operations produce floats 4) Addition and subtraction of ints produces an int 5) Multiplication of two ints produces a bignum or an int, depending on the result 6) Division of two ints produces a bignum 7) Strings are treated as floats for math operations 8) Any operation with a float and an int, string, or bool produces a float 9) Any operation with a bignum produces a bignum 10) The destination PMC is responsible for final conversion of the inbound value That seem reasonable? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
RE: Numeric semantics for base pmcs
Oops. I meant BigNum. -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:47 PM To: Butler, Gerald; '[EMAIL PROTECTED]' Subject: RE: Numeric semantics for base pmcs At 1:42 PM -0400 8/24/04, Butler, Gerald wrote: Shouldn't 4 also have potential to produce BigInt? Nope -- we don't have bigints. :) -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Numeric semantics for base pmcs Okay, so: 1) We round to zero when going from float to int 2) Overflows, underflows, and division by zero throws an exception 3) All-float operations produce floats 4) Addition and subtraction of ints produces an int 5) Multiplication of two ints produces a bignum or an int, depending on the result 6) Division of two ints produces a bignum 7) Strings are treated as floats for math operations 8) Any operation with a float and an int, string, or bool produces a float 9) Any operation with a bignum produces a bignum 10) The destination PMC is responsible for final conversion of the inbound value That seem reasonable? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
Re: Numeric semantics for base pmcs
At 1:39 PM -0400 8/24/04, Simon Glover wrote: On Tue, 24 Aug 2004, Dan Sugalski wrote: 6) Division of two ints produces a bignum Surely it should only produce a bignum as a last resort. For instance, shouldn't: 4 / 3 produce a float? A float or a bignum, both are reasonable. There's that whole issue of speed, though. (And to some extent precision) Also, what about a case like: 4 / 2 Does that produce an int, a float or a bignum? Good question. 9) Any operation with a bignum produces a bignum Should there be some way to test whether a bignum can be downgraded into a float? Probably, yeah. At the moment I'm somewhat loathe to drop down to floats because of the loss of precision. The big question is whether being clever and producing the tightest type is worth the time to figure out what that type is, as well as the potentially uncertain output type. I don't have a choice I think is right, though I'm leaning towards an answer that's got a consistent output type, though I'm not sure what that type should be. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: The big question is whether being clever and producing the tightest type is worth the time to figure out what that type is, as well as the potentially uncertain output type. Tangentially related: will promotion be suitably delayed on systems with support for 64-bit ints? More generally, what is the state-of/plan-for 64-bit support (whatever that may mean) in Parrot? -John
Re: Numeric semantics for base pmcs
At Tue, 24 Aug 2004 13:33:45 -0400, Dan Sugalski wrote: 6) Division of two ints produces a bignum Where bignum means both bigger than 32-bit integer and rational number? So 4 / 2 == Bignum(2/1) which doesn't get automatically downgraded to a normal int. Ok. 7) Strings are treated as floats for math operations I think we can do better than this by first converting a string to the least reasonable numeric type (with int float bignum), then re-dispatching to the appropriate numeric x numeric operation. Always treating strings as floats means we lose both when 2+3 != 2+3 and when one of the strings is too large to be a floating-point number. Also, doing this redispatch means that the printed and internal representations of numbers will always behave the same way. /s
Re: Numeric semantics for base pmcs
Dan Sugalski [EMAIL PROTECTED] wrote: At 1:42 PM -0400 8/24/04, Butler, Gerald wrote: Shouldn't 4 also have potential to produce BigInt? Nope -- we don't have bigints. :) Pardon, sir? leo
Re: Numeric semantics for base pmcs
Dan Sugalski [EMAIL PROTECTED] wrote: Okay, so: 4) Addition and subtraction of ints produces an int ??? 5) Multiplication of two ints produces a bignum or an int, depending on the result Why that difference? Int op Int gives Bigint or Int (whatever fits) for op in (abs, neg, add, sub, mul) And don't forget corner cases. What about bitwise ops BTW, e.g. left shift. That seem reasonable? Else yes. leo
Re: Numeric semantics for base pmcs
At 8:45 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At 1:42 PM -0400 8/24/04, Butler, Gerald wrote: Shouldn't 4 also have potential to produce BigInt? Nope -- we don't have bigints. :) Pardon, sir? We've got the big number code, but I don't see much reason to distinguish between integers and non-integers at this level -- the only difference is exponent twiddling. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
At 8:56 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Okay, so: 4) Addition and subtraction of ints produces an int ??? Yeah, that was wrong. Later fixed. :) 5) Multiplication of two ints produces a bignum or an int, depending on the result Why that difference? At this point I'm tempted to not have the difference and unconditionally produce a bignum. Int op Int gives Bigint or Int (whatever fits) for op in (abs, neg, add, sub, mul) And don't forget corner cases. I think we've got the corner cases dealt with. I think... What about bitwise ops BTW, e.g. left shift. Gah! Haven't gotten there yet. We're still working on basic math... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
At 11:47 AM -0700 8/24/04, Sean O'Rourke wrote: At Tue, 24 Aug 2004 13:33:45 -0400, Dan Sugalski wrote: 6) Division of two ints produces a bignum Where bignum means both bigger than 32-bit integer and rational number? So Yes. 4 / 2 == Bignum(2/1) which doesn't get automatically downgraded to a normal int. Ok. 7) Strings are treated as floats for math operations I think we can do better than this by first converting a string to the least reasonable numeric type (with int float bignum), then re-dispatching to the appropriate numeric x numeric operation. Always treating strings as floats means we lose both when 2+3 != 2+3 and when one of the strings is too large to be a floating-point number. Also, doing this redispatch means that the printed and internal representations of numbers will always behave the same way. I'm still not sure about doing dynamic down-typing (or whatever it's called) to get the tighest possible type. I'm getting the distinct feeling that it's what most people want, though. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
On Tue, Aug 24, 2004 at 03:08:21PM -0400, Dan Sugalski wrote: At 8:56 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: 5) Multiplication of two ints produces a bignum or an int, depending on the result Why that difference? At this point I'm tempted to not have the difference and unconditionally produce a bignum. 2 * 3 give a bignum. That feels evil. Except that the way that $a = 2 * 3 will work is that the assignment of the bignum temporary to $a will cause $a to drop it back to an int (for most languages' choice of target PMC) ? Nicholas Clark
Re: Numeric semantics for base pmcs
Nick writes: 2 * 3 give a bignum. That feels evil. Except that the way that $a = 2 * 3 will work is that the assignment of the bignum temporary to $a will cause $a to drop it back to an int (for most languages' choice of target PMC) ? Dan, any feeling about RISC vs. CISC? Because to me, this seems like a good place to punt, and provide two, maybe three mults: multbig: returns bignum, relies on PMC smart autounboxing multint: returns int-or-die, no unboxing multsmallest: returns parrot-defined 'smallest type that fits', balancing speed vs. compiler/interpreter autoboxing/ autounboxing hinting Most people in Perl would be happy with multbig, because frankly they don't care that their math takes .1 ms rather than .0001 ms (or whatever). But the set of people that really would rather have superfast math could drop over to multint. And, a notional Perl6 optimizing compiler could use multsmallest when it detects the conditions are right. Another concern besides speed might be sizeof(PMC) for each of the options...some of the genome/nasa guys could get kinda twitchy if bignum is 1k per, etc., etc. F.
Re: Numeric semantics for base pmcs
At Tue, 24 Aug 2004 15:19:52 -0400, Dan Sugalski wrote: At 11:47 AM -0700 8/24/04, Sean O'Rourke wrote: At Tue, 24 Aug 2004 13:33:45 -0400, Dan Sugalski wrote: 7) Strings are treated as floats for math operations I think we can do better than this by first converting a string to the least reasonable numeric type (with int float bignum), then re-dispatching to the appropriate numeric x numeric operation. Always treating strings as floats means we lose both when 2+3 != 2+3 and when one of the strings is too large to be a floating-point number. Also, doing this redispatch means that the printed and internal representations of numbers will always behave the same way. I'm still not sure about doing dynamic down-typing (or whatever it's called) to get the tighest possible type. I'm getting the distinct feeling that it's what most people want, though. :) This doesn't have to involve dynamic down-typing, only a string-to-numeric converter that returns the most specific type. After that, operations between two numeric objects are welcome to do whatever they want. I actually agree with you that it's just not worth it to check for possible down-conversions. /s
