bug-gmp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Unclear documentation (or my confusion?)


From: Alexander Perlis
Subject: Unclear documentation (or my confusion?)
Date: Thu, 12 Jul 2001 11:32:05 -0700 (PDT)

Hi. I'm attempting to implement a "fixed-precision" class on top of
GMP. My ints are always 64-bits (2 limbs) and my intints are always
128-bits (4 limbs). I'm trying to use the low-level mpn_ interface.
I'm using GMP 3.1.1.

When I add two ints, I always tell mpn_add_n that there are 2 limbs,
even if, say, one of the ints is small and really takes up only 1
limb. This seems to work fine.

When I multiply to ints to get an intint, I always say my two source
operands have 2 limbs, even when they are small enough so that the
most-significant limbs are zero. Again, this seems to work fine.

But when I divide an intint by an int using mpn_tdiv_qr, I'm running
into difficulty: again I'm always passing "2 limbs" as the size of
the number by which I am dividing, and this appears to be the
problem. A brief examination of the mpn_tdiv_qr source indicates that
it assumes the top limb is nonzero. (But I might be wrong: I haven't
studied the source carefully.)

In summary, it is my impression that some mpn_ functions allow
parameters whose most-significant limbs are zero, whereas other mpn_
functions require certain parameters to have limb-counts as small as
possible, i.e., require the most-significant limb to be non-zero. If
my impression is correct, then the point of this email is that either
this is a bug, or if it is by design, then the documentation does not
indicate this fact. (Neither p.39 nor p.41 of the TeX-DVI
documentation (3.1, 3Aug2000) discusses limb-counts needing to be
minimal.)

Thank you kindly.
Alexander Perlis


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]