I will just match the "gmp definition" which is
two mpf's match in the top n bits iff 1) both are zero or both not zero 2) signs are the same 3) exponents are the same 4) count leading zeros of top limb are the same 5) top n bits are the same Note: 5 is always true for n=0 or 1 Jason On Monday 03 August 2009 04:30:59 Bill Hart wrote: > Anyhow, it is a stupid function. The only thing which makes sense is > to talk about the difference between the two numbers being less than > 2^-p (although it would be easier to say <= 2^-p), > > Bill. > > 2009/8/3 Bill Hart <[email protected]>: > > 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 -~----------~----~----~----~------~----~------~--~---
