Hello again. It seems that I am "improving" the list traffic, :-).
Can I expect that these numbers will be represented with 332 mantissa bits, or not?.
No. Use cl_float(x,y) for that. And remember that cl_float returns a cl_F, not a cl_LF.
Yes. Now all my floats are cl_F.
If not, there is a bug cause the global variable has not effect. Or it is a feature?, I'll discuss it later...
Feature. goto later;
If yes, there is a bug cause in the result the b is truncated about 1e-20 which is approximately 60 mantissa bits, and it is so close to the number of mantissa bit of the double type.
Just one hopefully clarifying remark: This is because you specifically asked CLN to construct a cl_LF, which is at least as large as double. You end up with two machine words, which is 64 Bit and that is quite close to 20 decimal digits.
Then. The main difference is that, by default, cl_F and cl_LF have different precission unless you specify it, right?. If it is true it was not clear for me in the documentation.
`cl_F' objects with low precision are most easily constructed from C `float' and `double'. See *Note Conversions::.
I think, because I have not read all the source code that there is a problem in the decimal to binary conversion that don't read the default_float_format variable before convert it to numbers), and then it has not effect.
later: Nobody expects you to read all the sources. But the documentation clearly states (4.11.1 Conversion to floating-point numbers):
`float_format_t default_float_format' Global variable: the default float format used when converting rational numbers to floats.
To convert a real number to a float, each of the types `cl_R', `cl_F', `cl_I', `cl_RA', `int', `unsigned int', `float', `double' defines the following operations:
`cl_F cl_float (const TYPE&x, float_format_t f)' Returns `x' as a float of format `f'.
`cl_F cl_float (const TYPE&x, const cl_F& y)' Returns `x' in the float format of `y'.
`cl_F cl_float (const TYPE&x)' Returns `x' as a float of format `default_float_format' if it is an exact number, or `x' itself if it is already a float.
I think that you are doing things with floating point numbers that are documented to work with rationals only.
Yes, maybe.
No. In a large project this would not be a good idea because any deterioration of precision due to lower precision in some of the input variables would go undetected.
Ok. This is the phylosophy of your library, but it is tedious for me (I don't know if for other people also) , to rewrite all sources and conversions of numbers as cl_float(x,y).
I do think it was a brilliant idea to require people to write down the complete cl_float(double,float_format_t) spell.
I also think that something in your approach is broken if you wish to control the imact of double precision floating point variables on 100 decimal digit precision floating point variables.
No.
b = a*cl_float(2.72,precission)/c*cl_float(7.28,precision);
Unless that statement is inside a loop anyway (in which case the constant factor ought to be hoisted out) I would write that such things rather as b = cl_float( 2.72*7.28, precision ) * a / c;
Yes, of course, It was only an example. I was two days working in my program in order to write all floats as cl_float(float,precision) on arithmetic expressions and checking for the correct precission. But I am writing better: b=cl_float(2.72/7.28,a)*a/c;
You are not implying that it makes a difference if you use your own variable of type float_format_t instead of the global default_float_format, are you? If you think you have found a bug, please send a test program as small as possible, tell us what it does for you, and what you expected it to do. Otherwise, we won't be able to help you.
and the conversion of 1e-1 was done with approximately the double precission cause the noisy digits 55111... are about the 19 decimal digit not about the desired 100.
Maybe you aren't confused. But your bug reports sure are confusing. :-)
Well. Is this a bug and is it well reported? .. ------------------------------------------------------------------------------------------ #include <iostream> #include <cln/float.h> #include <cln/float_io.h> using namespace cln; int main(int argc, char **argv) { // Wrong result? float_format_t prec; prec=float_format(100); cl_F a,b,c; b=cl_float(1.0e-10,prec); a=cl_float(1.0,prec); c=a+b; std::cerr << "Incorrect: " << std::endl; std::cerr << "c=" << c << std::endl; c=c-a; std::cerr << "c=" << c << std::endl; // Right result std::cerr << "Correct:" << std::endl; a="1.0_100"; b="1.0e-10_100"; c=a+b; std::cerr << "c=" << c << std::endl; c=c-a; std::cerr << "c=" << c << std::endl; } -------------------------------------------------------------------------------------- The output in my computer. =================================================== Incorrect: c=1.00000000010000000000000000364321973154977415791655470655996396089904010295867919921875L0 c=1.0000000000000000364321973154977415791655470655996396089904010295867919921875L-10 Correct: c=1.0000000001L0 c=9.999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999997972106604L-11 =================================================== A ver si esta vez... -- *************************************************************************** * Dr. Isidro Cachadiña Gutiérrez * * Departamento de Física * * Facultad de Ciencias * * Universidad de Extremadura * * 06071 Badajoz ( SPAIN ) * * email: icacha@unex.es * * Teléfono: +34 924 289 300 Ext. 6826 Fax: +34 924 289 651 * *************************************************************************** * Usuario Linux: 8569 * * Para clave pública GnuPG: http://onsager.unex.es/firma.pub.asc * ***************************************************************************