Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 12, 2000 at 02:20:44PM +0000, David Mitchell wrote:
> > If we assume that ints and nums are perl builtins, and that some people
> > have implemented the following external types: byte (eg as implemented
> > as a specialised array type), bigreal, complex, bigcomplex, bigrat,
> > quaternian; then the following table shows how well my system copes:
> >
> > num - int gives accurate num
> > int - num gives accurate num
>
> what happens if the size of int is such that the maximum int is larger than
> the value at which num's can no longer maintain integer accuracy?
Then some precision is lost. This seems reasonably natural to me, in the sense that
nums have a wider range, and so when mixing the two, returning a num may
result in loss of precision but not an overflowm, which is the lesser of two
evils. A really smart implementation might choose whether to return a num or
an int depending on the sizes of its operands, but personally I think that's
asking for trouble.
> > With the sv1->sub[typeof(sv2)](sv2) scheme, even something as simple as
> > byte - bigreal is problematic, as this would cause byte->sub[GENERIC] to be
called,
> > which has very little chance of 'doing the right thing'.
>
> unless it uses your scheme at this point.
> [this might be the correct speed tradeoff - common types know how to
> interact with common types directly, and know how to call a slower but
> maximally accurate routine if they are beyond their competency]
So are you suggesting a hybrid, where for the standard type permutations
the right sub is immediately called, while the arg1->op[GENERIC] functions check
the 'size' of the operands, and if necesary, swap them and invoke some other
method from someone's vtable? I suppose that might work....
Also, some of the standard perumations would also need to do some re-invoking, eg
($int - $num) would invoke Int->sub[NUM](sv1,sv2,0), which itself would just fall
through to Num->sub[INT](sv2,sv1,1) - the 0/1 paramter indictating whether args
have been swapped.
????
> It's surprising how easy it is to slow things down with decision making code
> in your arithmetic ops. I'm trying to coax perl5 into doing better 64 bit
> integer arithmetic:
>
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-12/msg00499.html
Rather you than me!
I think the work you're doing with 64-bits shows up a problem in perl5
which hasn't really been addressed in perl6: In Perl 5 there is really only
one numeric type (NV). Okay, so there's an IV and a UV too, but these are
just variations with ill-defined semantics (eg on my 32-bit system, 2^31 + 2^31
gives a zero int, while pow (eg 2**3) just returns an NV, no questions
asked). And because the semantics are so ill-defined, they have mostly broken
for 64-bit architectures, hence your big patch.
Thus in perl5 with only one numeric type, there aren't any well-defined language
semantics for upgrading or downgrading between different numeric types, or specific
language features for declaring a variable of a specific type, or requesting
that an expression return a particular type.
The semantics that I have suggested so far (and I'm not by any stretch suggesting
that this is optimum), basically imply that expressions return a value of the
type of the 'biggest' of their operands. There is no automatic upgrading
(eg 2 large ints when added dont return a num), or downgrading (eg the difference
of 2 similar nums will never return an int), and "my integer $i = expr" doesnt
cause expr to be evaluated in a fancy integer context.
I think (though I may be wrong here - if so sorry!) that Dan's stuff similarly
ignores or sidesteps any implications of extra language semantics.
(ie Dan's semantics are: return a type equal to the LH operand, roughly speaking)
I think this this boils down to 2 important questions, and I'd be interested in
hearing people's opinions of them.
1. Does the Perl 6 language require some explicit syntax and/or semnatics to
handle multiple and user-defined numeric types?
Eg "my type $scalar", "$i + integer($r1+$r2)" and so on.
2. If the answer to (1) is yes, is it possible to decide what the numeric part of
the vtable API should be until the details of (1) has been agreed on?
I supect the answers are yes and no.
Dave.
