On Wed, Dec 20, 2000 at 11:07:39PM +0000, Nick Ing-Simmons wrote:
> The snag is that there are common pairs
> e.g. concat(utf8,ascii) / concat(ascii,utf8)
> or
> plus(NV,IV) / plus(IV,NV)
>
> where it is possible to get "smart" when one arg is a "special case" of
> the other.
> And similarly numbers must be convertable to "complex long double" or
> what ever is the top if the built-in tree ? (NV I guess - complex is
> over-kill.)
NV is double doesn't guarantee that.
NV as long double does seem to as it preserves 64 bits. But I perl won't
let me Configure for long double on FreeBSD, so that demonstrates that it's
not available everywhere.
[this bit came later:]
> We have not solved (or I have not spotted) what you do
> when you get IV * NV. Something has to "know" to "upgrade" IV -> NV
> and call NV's '*' - which does not scale well.
Even doing the "right thing" choosing between double and a 64 bit unsigned
int so that 0x3333333333333333 * 3.0 is 0x9999999999999999 doesn't let you
evaluate 0x4444444444444444 * 1.5 and get 0x6666666666666666
(intermediate calculation requires something larger than either a double
or unsigned 64 bit integer, even though the result will fit in the
64 bit integer)
> It is the how do we do the generic case that worries me.
Maybe this is a digression, but it does suggest that there may not
be 1 top to the tree (at least for builtin numbers). Which may also hold
for strings.
> We old'ns need people that don't know "it can't be done" to tell us
> how to do it - but we reserve the right to say "we tried that it didn't
> work" too.
^ because
Nicholas Clark
