Anomaly when integer zero combined with extended float.
I ran across an anomaly in CLN that occurs when an integer zero value is combined with an extended precision floating point number. Consider the following cl_R a,b,r; Now assign a cl_I variable whose value is zero to a, and a high precision cl_LF value to b. Then perform any of the following operations. r = a * b; r = b * a; r = a / b; In every case, the precision degrades to the default value. However, if the integer value in a is anything other than zero, the result has the precision of b. Since this only occurs for multiply and divide, I suspect it may be due to some shortcut that is taken when one of the operands is zero. The same anomaly occurs if the variables are declared cl_N and operand b is a high precision floating point complex number. The simplest way to demonstrate this behavior is to use the clnum Python module. The following session is on a 64-bit platform with version 1.1.9 of CLN.
from clnum import mpf x=mpf(1,50) x mpf('1.0',55) 0*x # Results in default precision mpf('0.0',36) 1*x # Preserves the precision mpf('1.0',55)
Ray Buvel P.S. Is there another way to report anomalies other than posting to the list?
Hi! Ray Buvel wrote:
I ran across an anomaly in CLN that occurs when an integer zero value is combined with an extended precision floating point number. Consider the following
cl_R a,b,r;
Now assign a cl_I variable whose value is zero to a, and a high precision cl_LF value to b. Then perform any of the following operations.
r = a * b; r = b * a; r = a / b;
In every case, the precision degrades to the default value. However, if the integer value in a is anything other than zero, the result has the precision of b.
Since this only occurs for multiply and divide, I suspect it may be due to some shortcut that is taken when one of the operands is zero.
What really happens is that CLN detects that the result is an exact zero and represents it exactly as an integer, not as a floating point number. You may easily convince yourself about this by checking the return value of instanceof(r, cl_I_ring).
P.S. Is there another way to report anomalies other than posting to the list?
No. I think a list is just fine as long as the amount of anomalies stays low. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On 9/6/06, Richard B. Kreckel <kreckel@ginac.de> wrote: <snip>
What really happens is that CLN detects that the result is an exact zero and represents it exactly as an integer, not as a floating point number.
You may easily convince yourself about this by checking the return value of instanceof(r, cl_I_ring).
Thanks for pointing this out. I need to modify my code to handle this special case correctly. As long as the result will be used in further CLN calculations, this return value is useful. However, once I translate it to a Python type, it needs to be a floating point value with the precision of the other operand.
participants (2)
-
Ray Buvel
-
Richard B. Kreckel