From: Bruno H. <br...@cl...> - 2010-08-03 00:27:51
|
Sam, > > On platforms where FAST_FLOAT and FAST_DOUBLE are defined (that is, most > > platforms nowadays, except ARM), this will be the case. > > why aren't FAST_FLOAT and FAST_DOUBLE defined on ALL pltforms? FAST_FLOAT and FAST_DOUBLE cannot be defined on platforms which have a floating-point format other than the IEEE 754 one, or where some of the operations are not IEEE 854 compliant (esp. regarding the rounding). (Note: on Alpha processors, the exceptions are not IEEE 854 compliant, but fortunately this has had no effect on clisp so far.) Also, there's the ARM problem with the endianness of the words in a 'double'. Also, there are sometimes cases where one does not want to trust the FPU (think of the Pentium FDIV bug...). > there is a problem with using dfloat_N_equal in elt_compare. > usually I can get away with > > if (!(ffloat_N_equal(elt2.eksplicit,fixnum(elt1)))) goto no; > > but for 32-bit arrays I cannot use fixnum. Good point. You're right, we also need two functions ffloat_uint32_equal and dfloat_uint32_equal. I'm adding these functions to realelem.d (untested - it's late for me today). > I still think that it is wrong to roundtrip through lisp when I am > comparing C integers with C floats, so the correct expression is > > if (elt2.machine_float != elt1) goto no; This expression will not work. CPUs have no instructions for comparing a single-float with an uint32. The compiler will either turn this expression into ((uint32)elt2.machine_float != elt1) or into (elt2.machine_float != (float)elt1) In the first case, it produces the wrong result when elt2 is >= 2^32 and elt1 is 2^32-1 or 2^31-1. In the second case, it produces wrong results when elt2 = 2^30 and elt1 = 2^30 + 1. For 'double' instead of 'float', though, the second expression would work. You will get an expression nearly as efficient as this by using dfloat_uint32_equal, on platforms where FAST_DOUBLE is defined. It's one of clisp's basic principles that it can also be used on platforms where the FPU is somewhat deficient. Bruno |