[CLN-list] More bugs.
Isidro Cachadiña Gutiérrez
icacha at unex.es
Tue Dec 14 09:20:04 CET 2004
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 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/20041214/d70707c1/attachment.pgp
More information about the CLN-list
mailing list