Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Dave M wrote:
> >That was probably me. (Which means it was probsbly a daft proposal,
> >and everyone rightly ignored it ;-)
> >The basic idea was that all numeric SV types must provide methods
> >that extract their vlaue as an integer or float of a size (abitrarily large)
> >specified by the caller, the format of which is a Perl standard.
> >For example, one might say:
>
> While nifty, I don't know that perl's going to support numerics with that
> much control over them. (That one's up to Larry) Most likely any
> non-CPU-native numeric support will get tossed into the generic
> bigint/bigfloat/bigcomplex bin and be done with it. (Complex and imaginary
> numbers are part of the C99 standard, FWIW--I just installed a new version
> of Dec C that has preliminary support for it too. Looks nifty...)
>
> How to handle math on objects that aren't on the mainline (int/bigint or
> float/bigfloat) path is a rather dicey thing, and a part of me is really
> tempted to just punt. That's something that'll have to wait for Larry,
> though, since it revolves around what the defined behavior there is.
>
> All the math is easy if the scalars are of known types. Addition and
> multiplication are easy if only one of the scalars involved is of known
> type. Math with both of unknown type, or subtraction and division with the
> right-hand operand of unknown type, is rather more difficult. :(
I'm not clear with your scheme how addition works if one of the scalars
(the adder) is of unknown type. ie
given sv1 of type NUM, sv2 of type UNKNOWN; $sv1 + $sv2 would invoke:
sv1->add[UNKNOWN](sv2),
which somewhere will cause a function in the vtable for NUMs to be called, eg
NUM_add_UNKNOWN(sv1,sv2) { .... }
Now, how does does this function perform its calculation?
My proposal does (I think...) handle, at least to a certain extent,
most of the 'difficult' cases you listed above.
(Sorry for flogging a dead horse!)
Dave M.
