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
