floating point underflow - a possible explanation
Hi again, when thinking of my problem, I found the following (it's a bit talking to myself, but perhaps you can find it useful). + The problem with the underflow happens (at least in my case) because the declaration in fnCalc3() Real y2 = Real(string("-6.6061s14"));y Real wrapper class. makes a cl_SF out of y2. The other variable is cl_LF. It seems this causes the underflow. + Actually I thought, this problem can not occur - that's why I use the wrapper class, as I always use the double initialisation- But I found this: valarray<Real> c; c.resize(3); Real dd=c[0]; valarray will call default constructor which is Real():cl_F() and therefore produce a c[0] with type cl_SF. Ok, didnot think of that. My problem. Anyway with the following I get a lot of conversions then dd=Real(1.0/3.0); <<= cl_LF dd=Real(1.0/3.0)+c[0]; <<= back cl_SF again dd=c[0]+Real(1.0/3.0); <<= still cl_SF So once I have cl_SF in my system, it can be anywhere. So now I changed default constructor to Real():cl_F(cl_float(cl_I(0),float_format(_PRECISION_CLN_NEWMAT))) {}; and everthing seems ok now. To be absolutely sure I can change also Real(const cl_F &f):cl_F(cl_float(f,float_format(_PRECISION_CLN))) {} in my wrapper. (The string initialization is intentional.) Michael Watch this!! 1.49557e-52 Am Montag 29 Oktober 2007 schrieb Michael Schuster:
Hi Richy & Cln-List,
Am Samstag 27 Oktober 2007 schrieb Richard B. Kreckel:
In order for anyone to be able to help you it is essential that you write a reduced test case where the problem appears and can be investigated.
Attachted I made a little demo programm which shows the problem. My output is : fnCalc1:1.49557e-52 fnCalc2:1.49557e-52 fnCalc2 + 0 :1.49557e-52 fnCalc3:0 Watch this!! 0 Watch this!! 1.49557e-52
The line >>Watch this!! 0<< should be >>Watch this!! 1.49557e-52<< at least in my mathematical opion.
Ok, I donot know if my construct with the class Real is a possibile good design. I wanted to have an easy possibility to switch from built-in-double type to a class type with higher precision.
Another problem is why I come (in my original programm) to a Real value-type of cl_SF while I only use the Real base class with cl_float() function as in the demo. But this is for next mailings here.
My system: $gcc --version gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux) Copyright (C) 2005 Free Software Foundation, Inc. Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es gibt KEINE Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE ZWECKE.
$rpm -q cln cln-1.1.9-5
Thanks for any hint.
Michael
Michael Schuster wrote:
So once I have cl_SF in my system, it can be anywhere. So now I changed default constructor to Real():cl_F(cl_float(cl_I(0),float_format(_PRECISION_CLN_NEWMAT))) {}; and everthing seems ok now.
What you have observed is intentional: There is no point keeping extra precision once it's been poisoned with an operand that has fewer digits. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (2)
-
Michael Schuster
-
Richard B. Kreckel