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
-~----------~----~----~----~------~----~------~--~---
