> > version of add() would be called, and an IV SB would result.
>
> "The IV version of add()"? Beware of combinatorial explosion:
> addII, addIU, addUI, addUU, addIN, addNI, addNN, addblahbah....
Ah, but you've forgotten the point of my orginal posting (back in
prehistory ;-)
where given 2 mixed args, the add() method associated with the
'biggest' arg (as determined by precison()) is called.
if sv1 is an IV and sv2 is an NV, then adding them causes
sv2->add(sv2,sv1,1) to be called, ie the NV version of add is run.
Within this method,
sv1->get_real(sv1) is called, which demands that the IV return an NV
representation of itself.
> > I presume that with bigint in force, even
> >
> > $x = 2
> > would make $x a bigint?
>
> Not necessarily. The tokenizer is able to tell the difference
> It currently does this by using UVs if a positive IV wouldn't
> be enough, and NVs if even a UV wouldn't be. 'use bigint' could
> be a hint saying "don't go NV unless absolutely unavoidable", such
> as "sin(2)". For division such as 2/3, NV could still be be default
> unless a "use bigrat" is in effect.
We start running into lots of problems here. First, the parser
would need to know a fair bit about particular user-defined types that have
been loaded in, on order to make clever interpretations of literals.
Second, my scheme currenly has no general way for expresssions to be
automatic upgraded when they fail to fit the current representation. So in
use bigint;
$x = 2_000_000_000; # $x is just an IV
$y = $x ** $x;
how does the IV version of exp() (which is the one that gets called, since
both args are IV), know not to try this itself, but instead pass the whole
job over to the bigint verson of exp()?
Personally I think automatic upgrades whould be avoided as far as possible,
except for built-in IV/UVs -> built-in NVs, to keep perl5 code happy.
