El Viernes, 10 de Diciembre de 2004 22:48, Richard B. Kreckel escribió:
Hi otra vez,
On Fri, 10 Dec 2004, Isidro [iso-8859-15] Cachadiña Gutiérrez wrote:
#include <iostream> #include <cln/lfloat.h> #include <cln/lfloat_io.h>
using namespace cln; int main(int argc, char **argv) {
default_float_format=float_format(100); cl_LF a,b,c; b="1e-60"; a="1.0"; c=a+b; std::cerr << "c=" << c << std::endl; c=c-a; std::cerr << "c=" << c << std::endl; }
And the outputs are 1.0L and 0.0L ¿What happen with the default_float_format?. If I write a="1.00000000000000000000000 ..." (100 zeros here) I obtain the same result, then b is lost somewhere.
More, when b about < 1e-20 then it is lost. Maybe an error in the conversion?
From the documentation:
4.1.3 Constructing floating-point numbers -----------------------------------------
`cl_F' objects with low precision are most easily constructed from C `float' and `double'. See *Note Conversions::.
........
Hello Richard and Bruno: I'm sorry to tell you that you don't understand that I wanted to say, because it is related to the use of the global variable default_float_format, and not with the floating point representation but I will explain it. Lets begin. First, with your documentation the function float_format_t float_format( uintL n) "Returns the smallest float format wich guarantees at least n _decimal_ digits in the mantissa (after the decimal point)" (see _undelined_ the word decimal digits) That is, being q the number of binary digits of the mantisa can be established the relation 2^-q = 10^-n then q = n log 10/log 2 and with n = 100 then q = 332 bits approximately. Then, following the documentation the line default_float_format=float_format(100); should guarantize at least 332 bits in the mantissa, aproximately ¿right?. When I define b="1e-60"; a="1.0"; Can I expect that these numbers will be represented with 332 mantissa bits, or not?. If not, there is a bug cause the global variable has not effect. Or it is a feature?, I'll discuss it 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.
`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.
To construct a `cl_F' with high precision, you can use the conversion from `const char *', but you have to specify the desired precision within the string. (See *Note Internal and printed representation::.) Example: cl_F e = "0.271828182845904523536028747135266249775724709369996e+1_40"; will set `e' to the given value, with a precision of 40 decimal digits.
Then is you don't consider the above behaviour as bugs, then I have a wish. The "programatic way" to define a number with the desired precission is good when you know how many decimal digits you need, but, for example I have a case in which I don't know how many digits I will need and I have to do with trial and error procedure. Then, the default_float_format must behave in this way: a = 5.0; then 5.0 have to be converted to a 330 bits (if I choose 100 decimal digits) and in all algebraical operations like b=a*2.72/c*7.28. all numbers have to be converted to the default_float_format that I have specified.
The programmatic way to construct a `cl_F' with high precision is through the `cl_float' conversion function, see *Note Conversion to floating-point numbers::. For example, to compute `e' to 40 decimal places, first construct 1.0 to 40 decimal places and then apply the exponential function: float_format_t precision = float_format(40); cl_F e = exp(cl_float(1,precision));
Then programatic way that you have proposed is not good for long proyects cause you have to define a variable number of digits and then apply to all the conversions and things like b=a*2.72/c*7.28 become as the ugly b = a*cl_float(2.72,precission)/c*cl_float(7.28,precision); But, .....let us read my first e-mail...
#include <iostream> #include <cln/real.h> #include <cln/real_io.h>
using namespace cln;
int main(int argc, char **argv) { default_float_format=float_format(100); cl_R a,b; b=cl_float(1e-1,default_float_format); a=cl_float(1,default_float_format); a=a+b; std::cerr << "a=" << a << std::endl; }
The output is:
a=1.1000000000000000055511151231257827021181583404541015625L0 > ^ ¿Why are here these noisy digits?. They are so close ..
Upss. It doesn't work. ¿a bug?. The difference it is that I used default_float_format instead precission 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.
It appears like you are still totally confused about the relation between decimal and binary representation. Please do have a close look at the paper by David Goldberg that Bruno Haible has recommended in an earlier thread!
If with all things that I wrote above you still think that I am confused with the relation between decimal and binary representation then I have a big problem, cause I think that two first mails were so clear about the problem.
What do you think a close approximation of 1/10 decimal in binary float is, provided you have 300 binary digits? Hint: the mantissa doesn't end in all zeros. Rather in 11001100110011001100....
Since CLN neither does BCD nor is psychic, all decimal numbers must be approximated for a binary representation. Now, since your input was not an (exact) rational number, but rather some float with limited precision, CLN did approximate as much as was reasonable. But not more.
Hasta la proxima -richy.
A ver si esta vez nos enteramos del problema. -- *************************************************************************** * 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 * ***************************************************************************