Re: Int/Rat max precision (was Re: r28882 - docs/Perl6/Spec)
HaloO, On Friday, 23. October 2009 02:27:00 Darren Duncan wrote: Thinking further, my interpretation of what you said above is that the Rational role is now basically saying that a number is represented in terms of numerator/denominator and that certain operators are supported, but now it is sounding like the details of whether the operators will produce Rational results or Num results is now determinable on a per-class basis, so we may end up working with types like Rat32, Rat64, BigRat (just this one being unlimited precision), etc after all. I believe that the thing people that don't care about the precision should use in sigs and variable declarations is the Rat role. That is I think that Rat should be the role that is currently named Rational. More specific instantiations of that role are then written in my proposed type signature invocant slot syntax as Rat[Rat64:]. Note that this is no problem because e.g. 'my Rat $x = 3/4' doesn't require Rat to be an instantiable class. Actually the class that implements Rat is chosen by the compiler to be e.g. Rat64. Then there need to be installation time defaults, command line switches and lexical pragmas to influence this choice. The second thing that needs to be hookable to different classes is the handling of overflow and underflow of e.g. Rat64 to either upgrade to BigRat or wrap the offending value back into Rat64 or switch over to Num. Then there is the problem of mixed precision cases etc. Presumably then with the Integer role we'll also have types like Int32, Int64, BigInt that do the role and also convert to a Num when their bounds are exceeded? Does that sound about right? Yes. I think there should be an Int role and classes implementing it. The Int role must be a subrole of Rat. E.g. it adds the bit manipulation operators which are difficult to define for rationals if not outright meaningless. This subroling is needed for calling Rat routines with an Int, of course. From a Huffman POV the roles for generic integers and rationals must be short, so the Numeric and Rational roles in S32 are going in the wrong direction. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Int/Rat max precision (was Re: r28882 - docs/Perl6/Spec)
I agree with TSa's comments in general. Make Int and Rat the roles, and people who don't care about precision-affected semantics can invoke those. Let the longer names be for the implementing classes, invoked directly by people who do care about precision-affected semantics. -- Darren Duncan TSa (Thomas Sandlaß) wrote: On Friday, 23. October 2009 02:27:00 Darren Duncan wrote: Thinking further, my interpretation of what you said above is that the Rational role is now basically saying that a number is represented in terms of numerator/denominator and that certain operators are supported, but now it is sounding like the details of whether the operators will produce Rational results or Num results is now determinable on a per-class basis, so we may end up working with types like Rat32, Rat64, BigRat (just this one being unlimited precision), etc after all. I believe that the thing people that don't care about the precision should use in sigs and variable declarations is the Rat role. That is I think that Rat should be the role that is currently named Rational. More specific instantiations of that role are then written in my proposed type signature invocant slot syntax as Rat[Rat64:]. Note that this is no problem because e.g. 'my Rat $x = 3/4' doesn't require Rat to be an instantiable class. Actually the class that implements Rat is chosen by the compiler to be e.g. Rat64. Then there need to be installation time defaults, command line switches and lexical pragmas to influence this choice. The second thing that needs to be hookable to different classes is the handling of overflow and underflow of e.g. Rat64 to either upgrade to BigRat or wrap the offending value back into Rat64 or switch over to Num. Then there is the problem of mixed precision cases etc. Presumably then with the Integer role we'll also have types like Int32, Int64, BigInt that do the role and also convert to a Num when their bounds are exceeded? Does that sound about right? Yes. I think there should be an Int role and classes implementing it. The Int role must be a subrole of Rat. E.g. it adds the bit manipulation operators which are difficult to define for rationals if not outright meaningless. This subroling is needed for calling Rat routines with an Int, of course. From a Huffman POV the roles for generic integers and rationals must be short, so the Numeric and Rational roles in S32 are going in the wrong direction.
Int/Rat max precision (was Re: r28882 - docs/Perl6/Spec)
pugs-comm...@feather.perl6.nl wrote: Author: lwall Date: 2009-10-22 18:21:29 +0200 (Thu, 22 Oct 2009) New Revision: 28882 Modified: docs/Perl6/Spec/S02-bits.pod Log: [S02] tweak Rat to max out at rat64 by default Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2009-10-22 15:55:21 UTC (rev 28881) +++ docs/Perl6/Spec/S02-bits.pod2009-10-22 16:21:29 UTC (rev 28882) @@ -672,6 +672,15 @@ Numeric values in untyped variables use CInt and CNum semantics rather than Cint and Cnum. +However, for pragmatic reasons, CRat values are guaranteed to be +exact only up to a certain point. By default, this is the precision +that would be represented by a Crat64 type, that is, with a numerator +and denominator consisting of Cint64 values. CRats that would require +more than 64 bits of storage in either numerator or denominator are +automatically converted to CNums. (If rationals are defined by a +role, it may be possible to instantiate a CRat type with a different +maximum precision.) + =item * Perl 6 should by default make standard IEEE floating point concepts What is the simplest way then to ensure all your Rat math is unlimited precision by default, same as your Int math? I would expect those 2 types to be consistent with each other in that way. Or are Int values now also guaranteed to be exact only up to int64, and then automatically change to Num? Now I can understand why you might make that change to Rat's default behaviour, expecially if users are getting a Rat by default simply for writing their numbers in a certain format like 3/4 or 1.3 and they may have actually wanted inexact semantics. Thinking further, my interpretation of what you said above is that the Rational role is now basically saying that a number is represented in terms of numerator/denominator and that certain operators are supported, but now it is sounding like the details of whether the operators will produce Rational results or Num results is now determinable on a per-class basis, so we may end up working with types like Rat32, Rat64, BigRat (just this one being unlimited precision), etc after all. Is that where you're going with this? Presumably then with the Integer role we'll also have types like Int32, Int64, BigInt that do the role and also convert to a Num when their bounds are exceeded? Does that sound about right? If it is, then I propose the following: 1. Have some classes like the above, eg Rat32+BigRat+Int32+BigInt etc pre-defined portably in the language spec, and make it so that plain Int and Rat are simply declared as installation-specific aliases for one of those more specific-named types. These alias definitions are defined in the setting or something and would be defined to match the largest values that either can be efficiently handled on the particular platform or are likely to be needed by the users with exact precision. 2. And then, people who want to be guaranteed that specific numeric semantics are portable across all Perl 6 implementations, with a possible hit in performance, would explicitly use say Rat64 or BigRat etc in their code, and those for whom the precise semantics don't need to be portable, can just use plain Rat, and know they'll get the best that the implementation thinks it can deliver with good efficiency. 3. As a middle-ground, still do #1 but also let users redefine what Int and Rat alias on a per-program basis, so they can still choose the 64 or Big etc option explicitly for portable behavior, but they only have to write the plain Rat etc in all their code. What do you think about that? Note that names can change, but I think being able to do what I stated would go further to let more users have what they want than under-serving a large number in favor of another large number. -- Darren Duncan
