The exponents certainly should make a difference. 256 = 1.000*2^8 128 = 0.100*2^8
And I agree that the top 7 bits of 256 and 257 are equal. 256 = 1.00000000x2^8 257 = 1.00000001x2^8 But 255 and 256 are different according to the current definition. 255 = 0.11111111x2^8 256 = 1.00000000x2^8 But I disagree with GMP about the top zero bits. If they are not the same, which of those zero bits differ? I suppose one could say all of them. But then you'd have to always return false. Bill. 2009/8/3 Jason Moxham <[email protected]>: > > It's not that obvious because this is the definition > > -- Function: int mpf_eq (mpf_t OP1, mpf_t OP2, unsigned long int op3) > Return non-zero if the first OP3 bits of OP1 and OP2 are equal, > zero otherwise. I.e., test if OP1 and OP2 are approximately equal. > > Caution: Currently only whole limbs are compared, and only in an > exact fashion. In the future values like 1000 and 0111 may be > considered the same to 3 bits (on the basis that their difference > is that small). > > This definition is not clear either !!!! according to the above 256 and 128 > are equal to within 3 bits , but the function returns not equal (both old and > new gmp). For 0 bits the new gmp doesn't always return true , the > signs,exponents also have to be the same. > > eg currently and in the new gmp > > 256 and 257 are equal to 0,1,2,3,..7 bits and not equal to 8,9,... bits > 256 and 255 are not equal to 0,1,2,... bits > > > > On Monday 03 August 2009 02:50:41 Bill Hart wrote: >> I think we always return true. Everything is true of the empty set. >> >> Bill. >> >> 2009/8/2 Jason Moxham <[email protected]>: >> > I've fixed the current mpf_eq error , the only question that remains is >> > what to do in the case when nbits=0 >> > ie are the top 0 bits of two mpf's equal ? do we always return true ? >> > even when the two mpf are complete differnent signs/sizes etc >> > >> > Jason >> > >> > On Friday 17 July 2009 05:59:51 Bill Hart wrote: >> >> If we replaced it with MPFR we'd be stuck at the current version, as >> >> they are changing license. >> >> >> >> There are also lots of projects out there which currently use GMP and >> >> MPFR. It would be a minor problem to include MPFR in MPIR because of >> >> symbol clashes. I'm not really in favour of the idea. Besides that >> >> floating point arithmetic is not really my domain. The first time I >> >> ever knowingly used MPFR was when I ported that code to C for Kristin. >> >> >> >> Bill. >> >> >> >> 2009/7/17 Jason Moxham <[email protected]>: >> >> > I hear there is a another mpf error , we should fix this. It's looks >> >> > like it's been in the code since the year dot . Look at all the errors >> >> > in GMP/MPIR from the last two/three years , most are >> >> > compiler/configure or mpf errors. I would vote to get rid of the mpf >> >> > layer , but we have to keep it for backward compatibility ;( , How >> >> > about replacing it with mpfr and add a wrapper for the three and half >> >> > people who use the mpf layer. >> >> > >> >> > Jason >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
