oldk1331 wrote:
>
> > For moderate arguments final adjustment to
> > satisfy requirements of ISQRT may add nontrivial cost.
>
> That's not entirely true: with following patch
> and testcase
> [approxSqrt(x) for x in (1..2*10^5)];
>
> it's 0.86s v.s. 0.80s.
Taking this at face value this is about 8% of overhead
for essentially gaining 1 bit of accuracy. In other
places increasing accuracy by 1 bit have _much_ lower
cost.
> Well, for small arguments we can even hard code answers.
>
> So I propose to
> 1. change the documentation to \spad{-1 < x - sqrt(n) <= 0}
> 2. apply following check
> 3. use ISQRT for INT/NNI/PI
Pragmaticaly just using ISQRT looks OK. Hovever, on estetic
level current definition looks much better. Namely once we
commit to tighter definition there is unavoidable overhead.
OTOH in most uses we can tolerate much higher error than
now and in few other places we could increse accuracy by
1 bit. To put it differently: current definition strikes
alomst perfect balance, gives good accuracy for intended
uses and avoids extra overheads.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
