Comments inline. Some snippage.
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?
$a = int(3.4);
$b = $a + 3.56; #b = 6.56
With 'use integer' (or its equivalent) in effect, you can simply ignore the
fractional part. (You briefly imply that they're all the same, but I don't
quite understand why they're not.)
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.)
>
> =head2 Rounding
>
> The rounding part of the context defines the rounding algoritm to be
> used, the following are provided (examples assume a precision of 5):
>
> =over 4
>
> =item Round down
>
> Any unwanted digits are simply truncated from the coefficient.
Call it 'truncation' then. 'Round down' can be ambiguous with negative
numbers.
>
> [0, 1234567, 10] => [0, 12345, 12]
>
> =item Round half up
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).
>
> 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.)
>
> [0, 1234567, 10] => [0, 12346, 12]
> [0, 1234549, 10] => [0, 12345, 12]
> [0, 9999950, 10] => [0, 10000, 13]
>
> =item Round half even
>
> The first lost digit is examined, if it lies in the range 0-4, the
> coefficient is truncated directly, if in the range 6-9, the
> coefficient is rounded up. If the first lost digit is equal to 5, and
> the remaining lost digits in the coefficient are non-zero, the number
> is also rounded up. If the lost digits are equal to exactly half, the
> number is rounded up if the least significant retained digit is odd,
> and rounded down if it is even.
How bizarre. Odd, even. ;-)
>
> The following operations are provided by the library, they function
> exactly as those described in the Standard Decimal Arithmetic (SDA)
> (see references below) with some extension to cope with integer and
> fixed fractional part numbers. Only the deviations are outlined here.
And I'll be lazy and not read it yet, so my questions may be ignorant.
> =item Division
>
> 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.
>
> 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?
> arithmetic to limit the number of digits returned. It is safe to
> chose a precision at least as big the largest number of digits
> of either argument to the division function.
>
> =item Integer division, Remainder
>
> For both integer and fixed-fraction numbers, the result returned by
> the remainder function will be an integer or fixed-fraction number.
> The result of integer division will be an integer.
And again, ints.
>
> =item Rounding
>
> =item Plus / Minus
>
> =item Comparison
>
> 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."
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.)
Some comparisons do this to show relative magnitude of the comparison. I'm
not sure if Perl (or Parrot) will need the exact values or not.
>
> =item Rescale
>
> =item Power
>
> =back
>
> =head2 Conversion to and from strings
>
> A one to one conversion between the abstract representation above and
> a string is provided by the library, and acts as defined by the
> standard decimal arithmetic. Other conversation operations may also
> be implemented, and these may not provide one to one mapping.
s/conversation/conversion/
Will you control formatted (ie, printf) strings, or will someone else need
to?
>
> A pedantic error checking conversion is available within the library,
> but only works with native strings. Versions which work with parrot
> strings will also be provided, although in a seperate file to the rest
> of the library (they will share a common private header file).
>
> =head1 IMPLEMENTATION
>
> Functions are provided with implement the arithmetic, conversion,
> creation and destruction of big numbers by dealing with otherwise
> opaque big number objects.
>
> =head2 Big number representation
>
> A big number is represented by the following structure, this is
> capable of being allocated, tracked and destroyed by the parrot
> garbage collection system.
>
> 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.
> } 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?
Alex++
Cheers,
--
Bryan C. Warnock
[EMAIL PROTECTED]
