At 06:05 PM 12/12/00 +0000, David Mitchell wrote:
>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.
I don't, and it's what we need to do if we want to preserve perl's general
"It's all magic, and it works" scheme. Any operation that involves two of
perl's base types should work without losing any unnecessary data. Which
means that if you have an int and a bignum, the result should be a bignum,
no matter what order they appear in.
> > [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....
Yup, that's pretty much it. The common combinations have special-purpose
code to handle them, while everything else has generic fall-back code.
This isn't unreasonable. There aren't that many different types of
integers, strings, or numbers, so having the interpreter know how to handle
them directly's fine. (While there may be many different variants of each
type, (for example, you might ave three or four different types of floating
point types, they all should be convertable to a bignum or float) they all
should be able to act like the 'master' type easily enough) The rest of the
data types are going to be varied enough that falling back to a generic
routine's fine.
>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.
>????
Nope. int->sub[num](sv1, sv2) would have a function body that would look
something like:
return(Num->new((NV)sv1->int - get_num(sv2)));
Basically the integer subtraction routine knows that when passed a numeric
arf that it needs to return a number rather than an integer. The function
will probably be a little more complex than that, but that's the gist of it.
>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)
Well, if the math would over or underflow the current representation, and
there's one that could handle it, then I think that perl should
automagicaly promote the result to that nrew type unless specifically
prohibited from doing so. Which means that if you're doing integer math
that blows out the platform native int, then perl should return you a
bigint (or a floating point value masquerading as an integer). Loss of data
should be avoided if at all feasable.
How far we go with this depends on the speed hit, though.
>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.
Gack. No, not unless we're forced to. This sort of thing should be
invisible. (This isn't C, after all...)
>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?
The answer to 1 is no, so the answer to this is yes.
>I supect the answers are yes and no.
Luckily the answers are no and yes. :) Which sort of follows, if you take
the path of least annoyance. Doing it the other way would be more annoying,
so we shouldn't.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
