[CLN-list] More bugs.
Isidro Cachadiña Gutiérrez
icacha at unex.es
Mon Dec 13 10:35:03 CET 2004
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 at 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 *
***************************************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.cebix.net/pipermail/cln-list/attachments/20041213/9017eb39/attachment.pgp
More information about the CLN-list
mailing list