On Sun, Jun 07, 2026 at 08:46:08AM +0800, Qian Yun wrote:
> On 6/3/26 6:38 PM, Waldek Hebisch wrote:
> > On Wed, Jun 03, 2026 at 05:34:55PM +0800, Qian Yun wrote:
> >> It is happening in numsolve.spad, function "findGenZeros"
> >> that precision is increased by 100.
> >>
> >> I think in the attached patch, by reordering the transform
> >> to be after resetting precision, this problem is solved.
> >
> > I am not sure if there is a problem. Namely, to compute result
> > at requested accuracy we need to increase intermediate precision.
> > Since final rounding may add to total error computing "exact
> > 20 digits" (or similar) is rather complex process. So, instead,
> > normal policy in FriCAS is to keep results at whatever precision
> > they were computed.
> But the increased precision is temporary, and not all bits are
> accurate. Also "complexSolve" comes with a parameter "eps",
> which dictates the accuracy requirement from user.
Consider first some basics. Using n-bit integer mantissa we
have at most 1/2 of error due to rounding. Mantissa itself
is at least 2^(n - 1), which leads to 2^(-n) of releative error.
This error is due to representation, so in a sense unavidable.
Our basic arithmetic operations provide results with such an
accuracy.
Now, in general I would prefer to deliver result with relative
error at most 2^(-n). This is not always reasonable, but I would
like to have such accuracy when it is relatively easy to attain.
Since such an error can be produced by rounding alone, we either
would need to do some heroic work to deliver very accurate
result which even after rounding has required accuracy or
we do not round and return more bits. The second is much
easier.
To put it a bit differently, unless we internaly compute with
much higher accuracy some of printed digits will be inaccurate.
I find it more reasonable to print more digits and have
guaranteed error bound than to print less digits and less
accurate results. However, if user prefers the second, then
'outputGeneral' still allows printing with prescribed number
of digits. Changing computational routines to always round
does not give choice: once accuracy is lost it can not be
easily restored.
Maybe a little theoretical example. Consider say 10 bit
accuracy and exact reasult which in binary is 1000000000.1001.
"Correct" rounding would give 1000000001. Computation may give
something like 1000000000.01110. After rounding it becomes
1000000000. So the relative error is bigger than desired
bound. OTOH if we keep few extra bits the result is within
bound.
--
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 view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/aiXhSDbkd15Xanhk%40fricas.org.
