Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.misc |
| References | <ljqg3o$8dh$2@dont-email.me> <Y8ocv.64639$8%2.40203@fx06.am4> <537246b1$0$59749$c3e8da3$e074e489@news.astraweb.com> <JJtcv.95786$Sp6.12404@fx15.am4> <lkvgvv$19v$1@dont-email.me> |
| Subject | Re: BASIC is 50 |
| Message-ID | <jUIcv.37987$ub6.35971@fx32.am4> (permalink) |
| Organization | virginmedia.com |
| Date | 2014-05-14 12:58 +0100 |
"Bruce Evans" <bde@besplex.bde.org> wrote in message
news:lkvgvv$19v$1@dont-email.me...
> In article <JJtcv.95786$Sp6.12404@fx15.am4>, BartC <bc@freeuk.com> wrote:
>>"Rich" <rich@example.com> wrote in message
>>news:537246b1$0$59749$c3e8da3$e074e489@news.astraweb.com...
>>> BartC <bc@freeuk.com> wrote:
>>
>>>> Given enough precision, I believe that binary floating point can
>>>> emulate what can be done in decimal arithmetic.
>>>
>>> Actually, no.
>
> Actually, yes.
>
>>> 0.1 in decimal is an infinite repeating sequence in binary floating
>>> point. So it is impossible to have enough precision to exactly
>>> represent 0.1 (decimal) in binary floating point.
>
> 10.0 (0.1 dollars in cents) is equally exact all reasonable
> implementations
> of floating point.
So what? You don't use the primitive '=' (or '==' in C) between floating
point values when you know the results are not absolutely precise.
>>The following is an example of how it can be done (see main()). Actually,
>>you can replace the definition of 'myfloat' with just 'float' instead of
>>'double', and it will still work (but up to a smaller magnitude). This
>>code
>>emulates some decimal arithmetic with two decimal places. (Note that the
>>normal 0.1+0.2==0.3 can give True with some compilers.)
>
> Giving True is probably a compiler bug.
Not really. Probably just a coincidence. For example, if any constant 0.1 to
0.9 in the code is constructed as a multiple of 0.1, then it could well be
the case that 0.1+0.2 has exactly the same representation as 0.3.
>>/* Floating emulation of fixed point decimal arithmetic */
>
> Too complicated. Just do everything in whole cents (or whatever the
> minimal unit in the currency is).
The emulation could have used whole units, sure, with input or output scaled
by the right number of decimal places. But it was tidier in this simple demo
to have the stored floating point value be the same as the emulated decimal
without scaling. Also you can use floating point constants within the code
as 0.1 without a scale function needed.
> In C, require C99 or later, with
> IEEE754 support (otherwise you cannot even depend on 1.0 + 1.0 being
> 2.0).
That sounds like a bad implementation, but shouldn't effect the results of
programs like this.
>>myfloat round_dec(myfloat x){
>>if (x>0.0)
>> return floor((x+rounding)*factor)/factor;
>>else
>> if (x>-rounding) return 0.0;
>> return ceil((x-rounding)*factor)/factor;
>>}
>
> This only works when the error in the FP calculations is slightly less
> than 0.5 cents.
That's the trick. If you are emulating some hardware or software that always
has intermediate results with two decimal places (as in my example), then
you do the same. For simple addition or subtraction, you might have to do
large numbers of successive operations, each without rounding, before the
cumulative error approaches 0.005.
With intermediate rounding at each step, the error will rarely be that
large.
> One URL pointed to in this thread gives an example
> where adding 0.5 to round up half-way cases doesn't work as expected,
> because some expression like 0.49999... + 0.5 gives 1.0 after rounding.
Yes there are issues with rounding where a result is exactly between two
possible values. I mention that in another post.
> Interest rate calculations are one source of half-way cases. The
> interest rate is presumably specified as a decimal fraction, say
> 5%/year. Suppose the principal is $1.10. The interest in infinite
> precision is 5.5 cents. This must be rounded according to
> financial rules. I don't know what they are, but presumably they
> favour bankers, so it is down to 5 cents. Suppose you calculated
> the principal dollars an have a tiny error, so it is $1.10000...1.
> Then the interest calculation gives 5.50000...5 cents. This is
> above the half-way point, so hopefully it is not rounded in the
> banker's favour and is rounded up to 6 cents. However, that would
> be illegal since the error is in the calculation.
Floating point gives you the opportunity to round to either 5.0 or 6.0
cents, it doesn't really matter, and remember the approximate 0.5 cents and
add it to next year's interest. Nobody loses out in the long run. Decimal
fixed point can end up discarding some fractions of a cent completely.
Unless you use decimal floating point, then you have the same rounding
problems.
But to solve the above problem, requires a bit more thought. For example, if
interest rates are quoted to a resolution of 0.1% (ie. 0.001), and principal
amounts to $0.01, then any such calculation can only give results to 5
decimal places (but I'm not a mathematician so cannot say for certain).
In other words, any result must be to the nearest $0.00001. Provided there
is enough floating point precision in reserve, it can make use of this fact
to apply the right kind of rounding.
In your example, in one instance I got a result of $0.05500000000000000700,
rounded to 0.05500 (to 1/1000 of a cent). Now I can apply a rounding
function more confidently: any value less than 0.054995 can be rounded down
to 0.05000, and above 0.055005 to 0.06000, assuming rounding rules are to
the nearest cent. But I now have a window within which the interest rate
calculation is expected to be, and that gives me leaway for any FP
inaccuracies.
--
Bartc
Back to comp.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
BASIC is 50 Gordon Henderson <gordon+usenet@drogon.net> - 2014-04-30 09:34 +0000
Re: BASIC is 50 Ant <ant@zimage.comANT> - 2014-04-30 03:42 -0700
Re: BASIC is 50 Bob Eager <news0002@eager.cx> - 2014-04-30 10:46 +0000
Re: BASIC is 50 Gordon Henderson <gordon+usenet@drogon.net> - 2014-04-30 12:03 +0000
Re: BASIC is 50 Rich <rich@example.com> - 2014-04-30 11:12 +0000
Re: BASIC is 50 scott@alfter.diespammersdie.us (Scott Alfter) - 2014-04-30 15:56 +0000
Re: BASIC is 50 Rich <rich@example.com> - 2014-04-30 20:41 +0000
Re: BASIC is 50 Will Honea <whonea@whonea.net> - 2014-04-30 18:38 -0600
Re: BASIC is 50 Rich <rich@example.com> - 2014-05-01 02:38 +0000
Re: BASIC is 50 Will Honea <whonea@whonea.net> - 2014-04-30 22:50 -0600
Re: BASIC is 50 Rich <rich@example.com> - 2014-04-30 20:48 +0000
Re: BASIC is 50 Richard Kettlewell <rjk@greenend.org.uk> - 2014-05-02 09:27 +0100
Re: BASIC is 50 Tim Streater <timstreater@greenbee.net> - 2014-05-02 09:50 +0100
Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-07 10:48 +0100
Re: BASIC is 50 Tim Streater <timstreater@greenbee.net> - 2014-05-07 10:57 +0100
Re: BASIC is 50 Huge <Huge@nowhere.much.invalid> - 2014-05-07 11:20 +0000
Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-07 13:14 +0100
Re: BASIC is 50 Marko Rauhamaa <marko@pacujo.net> - 2014-05-07 16:05 +0300
Re: BASIC is 50 Paul Sture <nospam@sture.ch> - 2014-05-08 18:06 +0200
Re: BASIC is 50 Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 20:17 +0300
Re: BASIC is 50 "James Harris" <james.harris.1@gmail.com> - 2014-05-07 16:08 +0100
Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-07 18:38 +0100
Re: BASIC is 50 "James Harris" <james.harris.1@gmail.com> - 2014-05-07 19:09 +0100
Re: BASIC is 50 Huge <Huge@nowhere.much.invalid> - 2014-05-07 19:08 +0000
Re: BASIC is 50 greymausg@mail.com - 2014-05-08 10:15 +0000
Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-08 11:38 +0100
Re: BASIC is 50 Paul Sture <nospam@sture.ch> - 2014-05-08 17:55 +0200
Re: BASIC is 50 Paul Sture <nospam@sture.ch> - 2014-05-08 17:44 +0200
Re: BASIC is 50 Rich <rich@example.com> - 2014-05-12 12:39 +0000
Re: BASIC is 50 Marko Rauhamaa <marko@pacujo.net> - 2014-05-12 16:06 +0300
Re: BASIC is 50 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-12 22:48 +0100
Re: BASIC is 50 Rich <rich@example.com> - 2014-05-13 12:03 +0000
Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-13 13:23 +0100
Re: BASIC is 50 Rich <rich@example.com> - 2014-05-13 16:22 +0000
Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-13 19:42 +0100
Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-13 19:49 +0100
Re: BASIC is 50 Rich <rich@example.com> - 2014-05-14 01:09 +0000
Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-14 09:51 +0100
Re: BASIC is 50 bde@besplex.bde.org (Bruce Evans) - 2014-05-14 10:36 +0000
Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-14 12:58 +0100
Re: BASIC is 50 bde@besplex.bde.org (Bruce Evans) - 2014-05-14 16:13 +0000
Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-14 19:24 +0100
Re: BASIC is 50 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-13 15:50 +0100
Re: BASIC is 50 Johny B Good <johnny-b-good@invalid.ntlworld.com> - 2014-05-01 02:50 +0100
Re: BASIC is 50 David Hume <David.Hume@example.com> - 2014-05-01 09:06 +0100
Re: BASIC is 50 Gordon Henderson <gordon+usenet@drogon.net> - 2014-05-01 09:56 +0000
Re: BASIC is 50 Rich <rich@example.com> - 2014-05-01 10:25 +0000
Re: BASIC is 50 Marko Rauhamaa <marko@pacujo.net> - 2014-05-01 16:43 +0300
Re: BASIC is 50 Gordon Henderson <gordon+usenet@drogon.net> - 2014-05-01 18:03 +0000
Re: BASIC is 50 Bob Eager <news0002@eager.cx> - 2014-05-01 21:35 +0000
Re: BASIC is 50 Rob <monst.oorzudo@ntlworld.com> - 2014-05-01 22:41 +0100
Re: BASIC is 50 David Hume <David.Hume@example.com> - 2014-05-02 09:26 +0100
Re: BASIC is 50 Hils <hils@saynotospam.net> - 2014-05-02 10:46 +0100
Re: BASIC is 50 Johny B Good <johnny-b-good@invalid.ntlworld.com> - 2014-05-02 23:11 +0100
Re: BASIC is 50 Anssi Saari <as@sci.fi> - 2014-04-30 17:51 +0300
Re: BASIC is 50 Peter Percival <peterxpercival@hotmail.com> - 2014-05-14 17:40 +0100
csiph-web