On Sun, 24 Feb 2002, Bryan C. Warnock wrote:
> On Thursday 21 February 2002 22:08, Alex Gough wrote:
> >
> > It is therefore the current I<context> which determines which numeric
> > type is being considered during a particular operation, this makes it
> > easy to upgrade from one numeric form to another, and also allows for
> > considerable code-reuse within the library.
>
> Is there any reason, then, why we have separate Big Ints and Big Floats?
> Why not simply treat Big Ints as Big Floats with a precision of 0?
This is a choice to be made by the languages using the library. The
major difference is that a BigInt can grow to have as many digits in
its coefficient as the implementation can provide, while a BigFloat
will never have more than I<precision> digits.
> I would think the only differences are one of context, which shouldn't
> necessitate separate types. (Which isn't to say that you're wrong. But you
> may want to better explain it in the PDD.)
Indeed. This isn't a Perl6 BigInt pdd, this is a parrot big number
library pdd.
> Call it 'truncation' then. 'Round down' can be ambiguous with negative
> numbers.
Because it's called `round down', then explained as truncation for
people who've not read the standards.
> Similarly with 'up'. Not sure about you scholarly types on your side of the
> pond, but we survivors of the American edumacation system know this as
> 'rounding' or 'round out' (or 'traditional rounding' when discussing other
> techniques here).
Because there is also `round up', `round half down', `round floor' and
`round ceiling', which I will be including in the next release of the
pdd. While the names do not indicate exactly what they do, they are
standard and understood.
> > The first lost digit is examined, if this is in the range 0-4, the
> > coefficient is truncated directly, if in the range 5-9, one is added
> > to the final digit of the coefficient. If this leads to a coefficient
> > with more than I<precision> digits, the final trailing zero is
> > removed.
>
> I don't understand this. (The last sentence, that is. I understand
> rounding.)
With a precision of 5, a coefficient of 999995 is truncated to 99999,
then rounded up (due to the 5) to 100000, which has six digits, so the
final digit is removed and the number's exponent increased giving
10000.
> How bizarre. Odd, even. ;-)
Yes, but some people use it and some laws require it, providing it in
a library means it only needs to be implemented once.
> > Under integer conditions, division is halted once the first fractional
> > digit is calculated, with the result then being rounded to an integer
> > and returned. Under fixed-fraction conditions, one more digit than
> > needed is calculated, with the coefficient then being rounded and
> > returned.
>
> Again, I don't understand the difference between an integer and a
> fixed-fractional number with a fractional portion of 0.
There isn't one, I'm just being explicit.
> > If a floating point value is required, or if inexact division by a
> > very small number is attempted, it may be wise to follow big float
>
> 'follow'? 'allow', maybe?
The library allows people to do what they want, they're making the
choice, and how they use it follows this choice.
> > Comparision returns a big number which is equal to 1, 0 or -1. An
> > alternative form which returns an INTVAL is also provided.
>
> "Comparison returns 1, 0, or -1 (for 'a' being larger, equal to, or smaller
> than 'b') as either a big number, or an INTVAL."
This is given in the standard, only the additional version which does
not produce a new big number is noted here.
> Since comparison is normally done via subtraction, would it be better to
> simply return the difference? (Of course, if you wanted subtraction, you'd
> do subtraction.)
No, because that's not what the standard base arithmetic expects of a
comparison function.
> s/conversation/conversion/
>
> Will you control formatted (ie, printf) strings, or will someone else need
> to?
We need to sort out how locales are going to work before I'm going anywhere
near this issue.
> > typedef struct {
> > BN_NIB* buffer; /* string of nibbles */
> > UINTVAL nibs; /* nibs allocated, in sizeof(BN_NIB) */
> > UINTVAL flags; /* May store, say +Inf */
> > INTVAL digits; /* digits used */
> > int sign; /* sign of number, 0=> positive, zero, 1 =>
> > negative */ INTVAL expn; /* exponent of number */
>
> Which implies there *is* a limit, at least, of the exponent.
Yes, this is a computer. There are exceptional conditions which take
this into account.
> > } parrot_bignum_t;
>
> And no bigint. Hmmm, so all my previous comments are null. Perhaps the PDD
> earlier on should only make a distinction between fixed and non-fixed
> fractional numbers, with just a footnote than integers are fixed-fractional
> at 0.
>
> +- Inf. NaN. Will you support -0?
Getting there, those are in the extended specification :).
Alex
