Re: 5-byte numbers


And if this is not an option use double.

Thanks. I novicely overlooked that as a candidate, preferably without
having to install another compiler for "long long" (albeit I've access,
to all newer OS/2 ones, but not everywhere).

no rounding errors as long as your numbers are integral and fit into
the mantissa.

I don't know for 100% sure what the mantissa is. The numbers indeed are
unsigned integers (cumulative volume of traded shares). YMMV, but I'll
be fine with a readable 12 digits for the sum(200). I've read a manual,
and saw it can hold 15 digits (with a sizeof() 8 bytes).

But there's a problem. Perhaps as silly as overlooking a "double". I've
finished a Rexx'ish solution faster than I've found out how to output
a double with a result other than "0", as in (very briefly):

double d;
d=65536*65536*16;
printf("d=%lu\n",d/128);

Please note that, AFAIK, using ".2" decimals with the printf()-family
also introduces an additional rounding problem. Survivable, but it's
something to keep in mind then.

I could post the nearly finished Rexx'ish solution, including expected
rounding, but IMO that math is too simple to have any generic use: add
numbers one-by-one, and divide the result by 40 (to obtain a ratio of
5:200 as %.2f, in the end).

volume[i]=random(65536*1024);

Since your result is an approximate number anyway

In a way, yes. But the result is verifyable, as if my random()-function
also sends the result to a leading financial newspaper. It illustrates
that the outcome (=sum(200)) may exceed an ULONG, but not always. Last
week the smallest gap in the Top-10 was 0.03 (rounded), and it's hardly
more than a short-list. And some error in a result may be the biggest
surpise ever to be seen, if noticed at all.

Nevertheless I'll also give your other calculated solution a try. It's
both easy and interesting to compare its results with the current Rexx-
based results (C preprocessing, Rexx finishing). And I may even get a
double working, assuming 15 digits are readable with an "E" in there.



---
.

Relevant Pages

  • Re: BigNum -- Floating Point
    ... > mantissa and exponent. ... In that the current implementation already uses 32-bit "digits", ... (in one design I'm considering) ...
    (comp.programming)
  • Re: Complete RPL object type table
    ... Although HP allocated 20 bits for the DIGITS setting, ... The "LongFloat" library ... ddddddd....ddddddddd - mantissa digits ... - length of exponent and its sign + 5 ...
    (comp.sys.hp48)
  • Re: How to output FLOAT(18) in full form by E-format in VA PL/I?
    ... s=18 (all mantissa's digits). ... File input contains ... I don't worry about 4 digit mantissa in IEEE. ... why I can't use Edescriptor? ...
    (comp.lang.pl1)
  • Re: internal write rounds wrong
    ... such as hand recorded data. ... (There is also the double rounding problem that might ... will usually be enough digits that the bias is pretty small. ...
    (comp.lang.fortran)
  • Re: please check my homework
    ... a double precision float has 53 bits ... has only 16 significant digits. ... |>> range and the mantissa only has to do with the precision. ... | Numerical Computation isn't my strong point (just barely passed the ...
    (comp.programming)
Loading