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