On Thu, Dec 21, 2000 at 05:36:05PM +0000, Nick Ing-Simmons wrote:
> Nicholas Clark <[EMAIL PROTECTED]> writes:
> >>
> >> 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.)
> >
> >> 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.
>
> Which is why it worries me. If I invent a new number type (say),
> what vtable entries must it have to allow all the generic things
> to function? Given a choice between NV/UV/IV possibles on what basis do we
> choose one branch over the other?
I don't have an answer. The specific implementation for perl5 defaults to
attempt integers first because
1: it can tell if a value is precise and accurate as an integer
(floating point always has more range, but may lose precision)
so only if both operands are integers (including converting floating
point values such as 3.0 to integers) does it attempt integer maths
2: it can tell if the integer maths overflows. In which case it repeats
the whole operation with floating point.
but it has those two rules because it "knows"
1: how to tell if a floating point (or string) value loses nothing if
converted to an integer
2: that it can detect integer overflow
3: that integer arithmetic on integers that doesn't overflow is possibly
more accurate that floating point, certainly not less accurate
4: that floating point won't overflow for those times when integers will
(losing precision is better than losing everything; if you want
overflow "use integer;")
ie lots of stuff about *both* types.
So this is a set of special case rules, that probably don't generalise too
far. I can't tell you from it what extra methods a vtable would need to
implement other number types such as fractions or surds
(no-one's mentioned them yet as potential number types)
Nicholas Clark
