pugs-comm...@feather.perl6.nl wrote:
Author: lwall
Date: 2009-10-22 18:21:29 +0200 (Thu, 22 Oct 2009)
New Revision: 28882

[S02] tweak Rat to max out at rat64 by default

Modified: docs/Perl6/Spec/S02-bits.pod
--- docs/Perl6/Spec/S02-bits.pod        2009-10-22 15:55:21 UTC (rev 28881)
+++ docs/Perl6/Spec/S02-bits.pod        2009-10-22 16:21:29 UTC (rev 28882)
@@ -672,6 +672,15 @@
 Numeric values in untyped variables use C<Int> and C<Num> semantics
 rather than C<int> and C<num>.
+However, for pragmatic reasons, C<Rat> values are guaranteed to be
+exact only up to a certain point.  By default, this is the precision
+that would be represented by a C<rat64> type, that is, with a numerator
+and denominator consisting of C<int64> values.  C<Rat>s that would require
+more than 64 bits of storage in either numerator or denominator are
+automatically converted to C<Num>s.  (If rationals are defined by a
+role, it may be possible to instantiate a C<Rat> 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

Reply via email to