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