I fixed the tests, and now the abortion that is mpf all works , until the next error in it.
Jason On Friday 07 August 2009 23:46:37 jason wrote: > The corrected mpf _eq now breaks the c++ t-prec tests.... > > t-prec.cc:66: GNU MP assertion failed: __gmpf_eq(_a, _c, > very_large_prec) > Aborted > > This is an error in the testing function , it was expecting something > broken... > I remember some issue with this and mpf precision from last year? , > I'll have to look it up > > Jason > > On Aug 3, 2:55 pm, Jason Moxham <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
