On Tue, Dec 12, 2000 at 06:05:30PM +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've got integer overflow detection to work on p5 (for all the platforms I
can test on). But it has to make the assumption of 2s complement for useable
speed. It would be so much easier in assembler.
> > 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....
I was suggesting that operations should (could?) behave *as if* your
scheme were followed all the time. As far as anything outside the
operators was concerned the would be no detectable difference.
But actually the operators would take short cuts if they knew what both
sides were (and as Dan seems be thinking in terms of vtables, shortcuts
would appear to be vtable methods).
I suspect that this hybrid cheating approach may well be faster when most
operations use a few types of builtin numbers, but still preserves the
full flexibity and accuracy (well, minimal lossyness) of your scheme.
> 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.
> ????
Hadn't thought that far. Seems like a workable suggestion.
It's better than assuming that you can negate an operand.
> 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.
It's also because perl assumes that IV == (IV)(NV)IV for all IV.
Which is no longer true if you want 64 bit IVs when your NVs are 64 bits,
but have mantissa, sign and exponent to fit in that space.
> 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
They seem to be pretty close to optimal for accuracy even when new types
appear after core code is written.
> 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.
Quite possibly. But until we have the language semantics I guess working
out how to do perl5 language semantics better isn't a complete waste of
time. We've got a working perl5 to benchmark against.
(and I found it damn hard to make code that runs as fast as it, even for
the "obvious" do 32 bit IV maths as integers rather than 64 bit NVs)
Nicholas Clark
