My point is, for this specific "complexSolve" function, say user requests 10 digits accuracy, FLOAT domain has 20 digits accuracy by default, the result of "complexSolve" is accurate up to 15 digits (a random guess), but it is a 50 digits float.
If digits()$Float is x, then user requests accuracy greater than x, we should signal an error. If the eps accuracy is smaller than x, then we can return results with x digits perfectly fine. - Qian On 6/8/26 5:23 AM, Waldek Hebisch wrote: > 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. > -- 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/1432f317-9f43-4401-9628-278bf181783f%40gmail.com.
