hm. i suppose i could do that. you have to be careful about division,
though. i'm not sure about 68k series, but the x86 series does 64 bit
division, but considers it an overflow if either the quotient or remainder
exceeds 32bits (or maybe i'm even more dated than i realize - i'm going by
the 386 reference, and maybe the Pentium has a way around this, i don't
know). of course the compiler can provide a longlong library that gets
linked into your code to work around this, so as along as the compiler
actually deals with this, you're ok. i don't remember anything definitely
stating that it will work, so i'm not real eager to spend time on what may
turn out to be a wild goose chase.
ignoring the chipset, before you can divide you must multiply each
fixed-point number by your fixed point precision an *extra* time, or you
will lose precision in your final result. with those caveats, it may work.
i probably won't get around to investigating any time soon.
----- Original Message -----
From: pete moss <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, September 12, 1999 3:09 PM
Subject: Re: What's the best Currency Format?
> Chris Antos wrote:
> >
> > v2 of my app HandyShopper uses Long to represent cents.
> >
> > however, i discovered very quickly that fixed-point math is limited.
think
> > about longhand multiplication (since this is what you're emulating).
> >
> > let's take 400.00 and 1200.00 for instance. we convert them to 40000
and
> > 120000 as Longs, and now we multiply them. whups, overflow. the result
is
> > 4,800,000,000 which is larger than 32 bits (much less 31 to allow
negative
> > numbers). so the problem is that although you can divide by 100
afterwards
> > (to get us back to only 2 "decimal" places) and the final result would
> > actually fit, it has already overflowed before you have an opportunity
to
> > shift the decimal place correctly.
> >
>
>
> have you tried using long long types?
>
> :P
>
