Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #403612 > unrolled thread

.5 against 0.5f

Back to article view | Back to comp.lang.c

Contents

  .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-27 11:53 +0100
    Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-27 17:45 +0000
      Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-27 18:50 +0100
        Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-27 19:01 +0000
          Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-27 20:15 +0100
            Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-27 19:54 +0000
              Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:10 -0700
                Re: .5 against 0.5f steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:20 -0400
              Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-27 21:35 +0100
              Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 18:00 -0400
                Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-27 22:15 +0000
                Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 06:54 -0700
            Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-27 21:57 +0100
              Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 14:18 -0700
            Re: .5 against 0.5f steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:19 -0400
              Re: .5 against 0.5f Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-28 21:54 +0000
                Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:58 -0700
        Re: .5 against 0.5f steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:11 -0400
          Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 23:21 -0700
      Re: .5 against 0.5f scott@slp53.sl.home (Scott Lurndal) - 2026-10-27 18:40 +0000
        Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-27 12:29 -0700
          Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:11 -0700
            Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:25 -0700
        Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-27 21:43 +0200
          Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-27 22:05 +0200
            Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-27 22:51 +0200
        Re: .5 against 0.5f Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-27 20:05 +0000
          Re: .5 against 0.5f bartc <bc@freeuk.com> - 2026-10-27 21:03 +0000
          Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 15:41 -0700
            Re: .5 against 0.5f scott@slp53.sl.home (Scott Lurndal) - 2026-10-28 16:23 +0000
        Re: .5 against 0.5f steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:25 -0400
        Re: .5 against 0.5f makendo <makendo@makendo.invalid> - 2026-10-29 18:04 +0800
          Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 05:01 -0700
            Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 13:55 +0100
              Re: .5 against 0.5f bartc <bc@freeuk.com> - 2026-10-29 14:32 +0000
      Re: .5 against 0.5f Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-27 19:58 +0000
      Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 17:43 -0400
        Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 18:06 -0400
          Re: .5 against 0.5f Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-28 00:49 +0000
            Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 18:23 -0700
              Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 16:38 +0100
                Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 13:27 -0700
                  Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 00:08 +0100
                    Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:56 -0700
                      Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 18:55 +0100
                    Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 09:30 +0100
                      Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 04:54 -0700
                      Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 19:57 +0100
                        Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 20:56 +0100
                    Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 13:39 -0700
            Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 21:41 -0400
              Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 08:45 +0100
            Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 01:50 +0000
              Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 07:32 +0100
                Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 07:51 +0100
                  Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 07:55 +0100
                    Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 16:27 +0000
                      Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 17:44 +0100
                  Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 16:22 +0000
                    Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 19:15 +0100
                      Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 19:47 +0100
                      Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 19:10 +0000
                    Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 13:31 -0700
                      Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 22:44 +0000
                        Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 00:27 +0100
                        Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:39 -0700
                          Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 00:22 +0000
                            Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 17:59 -0700
                              Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 01:50 +0000
                                Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 10:45 +0100
                                  Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-29 14:56 +0000
                                  Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 16:34 +0000
                                Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-29 11:56 -0400
                                  Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 17:57 +0000
                                  Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-29 19:49 +0000
                                Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 17:58 +0100
            Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 08:39 +0100
              Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-28 22:25 +0200
                Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 10:48 +0100
                  Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 04:59 -0700
              Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 14:26 -0700
                Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-29 00:12 +0200
                  Re: .5 against 0.5f bartc <bc@freeuk.com> - 2026-10-28 22:33 +0000
                    Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 11:01 +0100
                  Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:05 -0700
                  Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 10:59 +0100
              Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:34 -0700
                Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 11:06 +0100
            Re: .5 against 0.5f tTh <tth@none.invalid> - 2026-10-28 15:08 +0100
              Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 07:49 -0700
            Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:36 -0700
        Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 15:53 -0700
          Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 21:55 -0400
            Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 19:02 -0700
          Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 08:56 +0100
        Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 08:01 -0700
    Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:08 -0700

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#403638

scott@slp53.sl.home (Scott Lurndal) writes:

> I ordered a couple of blu-rays from amazon last week, and the
> confirmation email had the following for the total price:
>
>    Total
>    75.71000000000001 USD
>
> Appears they may be using FP instead of integer fixed point arithmetic
> for pricing.

Send them an email saying you were overcharged and want a refund
of 0.000000000001 cents.  ;)

[toc] | [prev] | [next] | [standalone]

#403647

On 10/27/2026 12:29 PM, Tim Rentsch wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
> 
>> I ordered a couple of blu-rays from amazon last week, and the
>> confirmation email had the following for the total price:
>>
>>     Total
>>     75.71000000000001 USD
>>
>> Appears they may be using FP instead of integer fixed point arithmetic
>> for pricing.
> 
> Send them an email saying you were overcharged and want a refund
> of 0.000000000001 cents.  ;)

ROFL!

[toc] | [prev] | [next] | [standalone]

#403650

On 10/27/2026 1:11 PM, Chris M. Thomasson wrote:
> On 10/27/2026 12:29 PM, Tim Rentsch wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> I ordered a couple of blu-rays from amazon last week, and the
>>> confirmation email had the following for the total price:
>>>
>>>     Total
>>>     75.71000000000001 USD
>>>
>>> Appears they may be using FP instead of integer fixed point arithmetic
>>> for pricing.
>>
>> Send them an email saying you were overcharged and want a refund
>> of 0.000000000001 cents.  ;)
> 
> ROFL!

Must have just watched superman 3? ;^)

[toc] | [prev] | [next] | [standalone]

#403640

On Tue, 27 Oct 2026 18:40:52 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
> >On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
> >  
> >> if ai generates me some functions it puts everywhere this f at the
> >> and yet it add zeros so instead of .1 i got 0.1f
> >> 
> >> and i obviously dont like it
> >> 
> >> i write hvever some codes when i need speed so the question is may
> >> it give some difference?
> >> 
> >> i mean .1 maybe can be treated as doube constants so mabe occupies
> >> some more memory (?) or uses some casting in coplutations (?)
> >> 
> >> 
> >> i doubt it probably it makes difference but im strictly not sure  
> >
> >The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes 
> >code easier to read.  The difference between 0.1 and 0.1f with
> >their binary representations is a another matter.
> >
> >#include <stdio.h>
> >
> >int
> >main(void)
> >{
> >   double d;
> >   d = 0.1f;
> >   printf("%.13a\n", d);
> >   d = 0.1;
> >   printf("%.13a\n", d);
> >   return (0);
> >}
> >
> >% cc -o z t.c && ./z
> >0x1.99999a0000000p-4
> >0x1.999999999999ap-4
> >
> >The real number is 0.1 is not exactly representable in a binary
> >floating point format.  See
> >
> >https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html  
> 
> I ordered a couple of blu-rays from amazon last week, and the
> confirmation email had the following for the total price:
> 
>    Total
>    75.71000000000001 USD
> 
> Appears they may be using FP instead of integer fixed point arithmetic
> for pricing.

At least, unlike favorite AI of fir, Amazon was not using
single-precision.

[toc] | [prev] | [next] | [standalone]

#403643

On Tue, 27 Oct 2026 21:43:42 +0200
Michael S <already5chosen@yahoo.com> wrote:

> On Tue, 27 Oct 2026 18:40:52 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
> 
> > "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:  
> > >On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
> > >    
> > >> if ai generates me some functions it puts everywhere this f at
> > >> the and yet it add zeros so instead of .1 i got 0.1f
> > >> 
> > >> and i obviously dont like it
> > >> 
> > >> i write hvever some codes when i need speed so the question is
> > >> may it give some difference?
> > >> 
> > >> i mean .1 maybe can be treated as doube constants so mabe
> > >> occupies some more memory (?) or uses some casting in
> > >> coplutations (?)
> > >> 
> > >> 
> > >> i doubt it probably it makes difference but im strictly not sure
> > >>    
> > >
> > >The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes 
> > >code easier to read.  The difference between 0.1 and 0.1f with
> > >their binary representations is a another matter.
> > >
> > >#include <stdio.h>
> > >
> > >int
> > >main(void)
> > >{
> > >   double d;
> > >   d = 0.1f;
> > >   printf("%.13a\n", d);
> > >   d = 0.1;
> > >   printf("%.13a\n", d);
> > >   return (0);
> > >}
> > >
> > >% cc -o z t.c && ./z
> > >0x1.99999a0000000p-4
> > >0x1.999999999999ap-4
> > >
> > >The real number is 0.1 is not exactly representable in a binary
> > >floating point format.  See
> > >
> > >https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html    
> > 
> > I ordered a couple of blu-rays from amazon last week, and the
> > confirmation email had the following for the total price:
> > 
> >    Total
> >    75.71000000000001 USD
> > 
> > Appears they may be using FP instead of integer fixed point
> > arithmetic for pricing.  
> 
> At least, unlike favorite AI of fir, Amazon was not using
> single-precision.
> 
> 
> 

BTW, 75.71000000000001 looks like 67 * 1.13 in IEEE binary64, but
rounded up rather than to nearest.

[toc] | [prev] | [next] | [standalone]

#403654

On Tue, 27 Oct 2026 22:05:06 +0200
Michael S <already5chosen@yahoo.com> wrote:

> On Tue, 27 Oct 2026 21:43:42 +0200
> Michael S <already5chosen@yahoo.com> wrote:
> 
> > On Tue, 27 Oct 2026 18:40:52 GMT
> > scott@slp53.sl.home (Scott Lurndal) wrote:
> >   
> > > "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu>
> > > writes:    
> > > >On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
> > > >      
> > > >> if ai generates me some functions it puts everywhere this f at
> > > >> the and yet it add zeros so instead of .1 i got 0.1f
> > > >> 
> > > >> and i obviously dont like it
> > > >> 
> > > >> i write hvever some codes when i need speed so the question is
> > > >> may it give some difference?
> > > >> 
> > > >> i mean .1 maybe can be treated as doube constants so mabe
> > > >> occupies some more memory (?) or uses some casting in
> > > >> coplutations (?)
> > > >> 
> > > >> 
> > > >> i doubt it probably it makes difference but im strictly not
> > > >> sure 
> > > >
> > > >The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes 
> > > >code easier to read.  The difference between 0.1 and 0.1f with
> > > >their binary representations is a another matter.
> > > >
> > > >#include <stdio.h>
> > > >
> > > >int
> > > >main(void)
> > > >{
> > > >   double d;
> > > >   d = 0.1f;
> > > >   printf("%.13a\n", d);
> > > >   d = 0.1;
> > > >   printf("%.13a\n", d);
> > > >   return (0);
> > > >}
> > > >
> > > >% cc -o z t.c && ./z
> > > >0x1.99999a0000000p-4
> > > >0x1.999999999999ap-4
> > > >
> > > >The real number is 0.1 is not exactly representable in a binary
> > > >floating point format.  See
> > > >
> > > >https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
> > > >    
> > > 
> > > I ordered a couple of blu-rays from amazon last week, and the
> > > confirmation email had the following for the total price:
> > > 
> > >    Total
> > >    75.71000000000001 USD
> > > 
> > > Appears they may be using FP instead of integer fixed point
> > > arithmetic for pricing.    
> > 
> > At least, unlike favorite AI of fir, Amazon was not using
> > single-precision.
> > 
> > 
> >   
> 
> BTW, 75.71000000000001 looks like 67 * 1.13 in IEEE binary64, but
> rounded up rather than to nearest.
> 

Or 67 + 67 * 0.13 rounded to nearest.

[toc] | [prev] | [next] | [standalone]

#403644

On 2026-10-27, Scott Lurndal <scott@slp53.sl.home> wrote:
> I ordered a couple of blu-rays from amazon last week, and the
> confirmation email had the following for the total price:
>
>    Total
>    75.71000000000001 USD
>
> Appears they may be using FP instead of integer fixed point arithmetic
> for pricing.

That reminds of a joke I have in the TXR Lisp fortune module,
intended for displaying a random quip at REPL startup.

Oh, look, I got it after just a couple of tries:

This is the TXR Lisp interactive listener of TXR 302.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
1> (quip)
"Coding around Unicode grapheme clusters is a character-building exercise."
2> (quip)
"defmicro: error: expansion is larger than original form: switch to defmacro."
3> (prinl (quip))
"This could be the year of the TXR desktop; I can feel it!"
"This could be the year of the TXR desktop; I can feel it!"
4> (put-line (quip))
TXR kind of supports IEEE 754.00000000000003 floating-point.
t

:)

FP is fine for pricing: look at how ridiculously close to 75.71
the above approximation is. You just have to make sure never to
let enough error accumulate so that an intermediate value
is suddenly closer to the wrong penny value than the right one.
(Actually you don't even want to get anywhere near that level
of error.)

If all your system does is take a value from a ledger, do a few simple
calcluations on it, then round it to the best approximation of the nearest
penny before recording back into the ledger, you are fine.  You then just have
to be careful about converting the values to digits.


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#403656

On 27/10/2026 20:05, Kaz Kylheku wrote:
> On 2026-10-27, Scott Lurndal <scott@slp53.sl.home> wrote:
>> I ordered a couple of blu-rays from amazon last week, and the
>> confirmation email had the following for the total price:
>>
>>     Total
>>     75.71000000000001 USD
>>
>> Appears they may be using FP instead of integer fixed point arithmetic
>> for pricing.
> 
> That reminds of a joke I have in the TXR Lisp fortune module,
> intended for displaying a random quip at REPL startup.
> 
> Oh, look, I got it after just a couple of tries:
> 
> This is the TXR Lisp interactive listener of TXR 302.
> Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
> 1> (quip)
> "Coding around Unicode grapheme clusters is a character-building exercise."
> 2> (quip)
> "defmicro: error: expansion is larger than original form: switch to defmacro."
> 3> (prinl (quip))
> "This could be the year of the TXR desktop; I can feel it!"
> "This could be the year of the TXR desktop; I can feel it!"
> 4> (put-line (quip))
> TXR kind of supports IEEE 754.00000000000003 floating-point.
> t
> 
> :)
> 
> FP is fine for pricing: look at how ridiculously close to 75.71
> the above approximation is. You just have to make sure never to
> let enough error accumulate so that an intermediate value
> is suddenly closer to the wrong penny value than the right one.
> (Actually you don't even want to get anywhere near that level
> of error.)

I've used floats for pricing, I think even 32-bit ones. It should work 
fine within certain levels of magnitude - you want a few spare bits of 
precision beyond individual cents.

(To clarify, 32 bits may have been used to store prices in a stock file 
for example, so typical magnitudes would have been small, but 
calculations and totals would have used 64 bits.)

But apart from doing the rounding right as you suggest, the display 
should be only showing 2 decimals when displaying dollars, not 14. That 
example is very sloppy.

[toc] | [prev] | [next] | [standalone]

#403665

Kaz Kylheku <046-301-5902@kylheku.com> writes:
> On 2026-10-27, Scott Lurndal <scott@slp53.sl.home> wrote:
>> I ordered a couple of blu-rays from amazon last week, and the
>> confirmation email had the following for the total price:
>>
>>    Total
>>    75.71000000000001 USD

[...]

> FP is fine for pricing: look at how ridiculously close to 75.71
> the above approximation is. You just have to make sure never to
> let enough error accumulate so that an intermediate value
> is suddenly closer to the wrong penny value than the right one.

And how do you do that?

> (Actually you don't even want to get anywhere near that level
> of error.)

An arbitrarily small error can result in an ambiguity.  If you
calculate a result that should, mathematically, be very close to
75.715, it could round either to 75.71 or to 75.72.

I presume there are financial regulations that specify exactly how
these calculations are to be performed.  I have no idea what those
regulations say, but anyone writing financial code had better know
about the requirements and implement them correctly.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#403725

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Kaz Kylheku <046-301-5902@kylheku.com> writes:
>> On 2026-10-27, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> I ordered a couple of blu-rays from amazon last week, and the
>>> confirmation email had the following for the total price:
>>>
>>>    Total
>>>    75.71000000000001 USD
>
>[...]
>
>> FP is fine for pricing: look at how ridiculously close to 75.71
>> the above approximation is. You just have to make sure never to
>> let enough error accumulate so that an intermediate value
>> is suddenly closer to the wrong penny value than the right one.
>
>And how do you do that?
>
>> (Actually you don't even want to get anywhere near that level
>> of error.)
>
>An arbitrarily small error can result in an ambiguity.  If you
>calculate a result that should, mathematically, be very close to
>75.715, it could round either to 75.71 or to 75.72.
>
>I presume there are financial regulations that specify exactly how
>these calculations are to be performed.  I have no idea what those
>regulations say, but anyone writing financial code had better know
>about the requirements and implement them correctly.

There are.  And they explicitly forbid using binary floating
point representations.

Typically they use scaled fixed point 64-bit integers in modern code.

[toc] | [prev] | [next] | [standalone]

#403688

scott@slp53.sl.home (Scott Lurndal) writes:

> I ordered a couple of blu-rays from amazon last week, and the
> confirmation email had the following for the total price:
>
>    Total
>    75.71000000000001 USD
>
> Appears they may be using FP instead of integer fixed point arithmetic
> for pricing.

Try asking them for (ceiling 75.71000000000001)

[toc] | [prev] | [next] | [standalone]

#403778

> I ordered a couple of blu-rays from amazon last week, and the
> confirmation email had the following for the total price:
> 
>     Total
>     75.71000000000001 USD
> 
> Appears they may be using FP instead of integer fixed point arithmetic
> for pricing.

And this is why you should use the lowest value denominator when
storing monetary values -- store USD values in cents, CNY values
in fen, EUR values in cents, etc...

I envy in particular the Japanese on this -- they don't have monetary
units smaller than 1 yen, and as such misuse of floats in monetary
calculations are far less likely in Japan.

[toc] | [prev] | [next] | [standalone]

#403783

makendo <makendo@makendo.invalid> writes:
>> I ordered a couple of blu-rays from amazon last week, and the
>> confirmation email had the following for the total price:
>>     Total
>>     75.71000000000001 USD
>> Appears they may be using FP instead of integer fixed point
>> arithmetic
>> for pricing.
>
> And this is why you should use the lowest value denominator when
> storing monetary values -- store USD values in cents, CNY values
> in fen, EUR values in cents, etc...
[...]

That's not good enough.  Discounts, sales taxes, and compound
interest can easily result in amounts that are not multiples of
one cent, which must then be rounded or truncated to the nearest
cent following whatever financial rules are in effect.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#403784

On 29/10/2026 13:01, Keith Thompson wrote:
> makendo <makendo@makendo.invalid> writes:
>>> I ordered a couple of blu-rays from amazon last week, and the
>>> confirmation email had the following for the total price:
>>>      Total
>>>      75.71000000000001 USD
>>> Appears they may be using FP instead of integer fixed point
>>> arithmetic
>>> for pricing.
>>
>> And this is why you should use the lowest value denominator when
>> storing monetary values -- store USD values in cents, CNY values
>> in fen, EUR values in cents, etc...
> [...]
> 
> That's not good enough.  Discounts, sales taxes, and compound
> interest can easily result in amounts that are not multiples of
> one cent, which must then be rounded or truncated to the nearest
> cent following whatever financial rules are in effect.
> 

What is "good enough" depends on the context.  For a lot of situations, 
floating point, or rounding to the nearest dollar (or thousand dollars, 
or pounds, or whatever) can be fine.  You can happily use values in 
cents for your shop prices.

But for accurate financial records used in accounting, tax records, 
banking, etc., you are correct that it is not that simple.  Countries 
and groups of countries all have their standards that you need to 
conform to.  Typically the way to get correct values is to keep 
everything as large integer types of scaled currency denominations - 
like a thousandth of a cent.

[toc] | [prev] | [next] | [standalone]

#403785

On 29/10/2026 12:55, David Brown wrote:
> On 29/10/2026 13:01, Keith Thompson wrote:
>> makendo <makendo@makendo.invalid> writes:
>>>> I ordered a couple of blu-rays from amazon last week, and the
>>>> confirmation email had the following for the total price:
>>>>      Total
>>>>      75.71000000000001 USD
>>>> Appears they may be using FP instead of integer fixed point
>>>> arithmetic
>>>> for pricing.
>>>
>>> And this is why you should use the lowest value denominator when
>>> storing monetary values -- store USD values in cents, CNY values
>>> in fen, EUR values in cents, etc...
>> [...]
>>
>> That's not good enough.  Discounts, sales taxes, and compound
>> interest can easily result in amounts that are not multiples of
>> one cent, which must then be rounded or truncated to the nearest
>> cent following whatever financial rules are in effect.
>>
> 
> What is "good enough" depends on the context.  For a lot of situations, 
> floating point, or rounding to the nearest dollar (or thousand dollars, 
> or pounds, or whatever) can be fine.  You can happily use values in 
> cents for your shop prices.

For /storing/ values in some database, then float binary will be fine, 
evening using dollars and decimals cents such as $1.99.

But there are a couple of provisos:

* There is limited precision of some 22 or 23 bits, which caps the
   magnitude that can be represented

* It must be stipulated that the fractional part always represents
   between 0 and 99 hundredths of a dollar, even if the actual value
   cannot be exact (so 0.75 can be stored exactly, but not 0.74). There
   will never be a value halfway between two consecutive cents.

With those in place, then any stored value can be converted to an exact 
number of cents (for example, (int)(x*100+0.5) for positive x), or to 
some other exact representation.

Working directly with such float values is tricky.

Oh, there is one more proviso: if printing such a value, you must only 
show 2 decimal places, not 14! So you don't get stupid output like 
0.74000000953674316 USD.

[toc] | [prev] | [next] | [standalone]

#403642

On 2026-10-27, Steven G. Kargl <sgk@REMOVEtroutmask.apl.washington.edu> wrote:
> % cc -o z t.c && ./z
> 0x1.99999a0000000p-4
> 0x1.999999999999ap-4
>
> The real number is 0.1 is not exactly representable in a binary
> floating point format.

The real number 0.1 has a worse approximation in float than double,
(if those are not the same size).

However, every representation in float is supposed to be available
in double: float to double conversion is lossless.

If you write double d = 0.1f you are essentially saying you want d to
take on that approximation of 0.1 that is available in float,
rather than a possibly better one available in double.

The abstract semantics is that 0.1f is a constant of type float.
The actual semantics may be that the compiler notices that the
float is used as an initialize for a double, and so just convert
to a double constant of the same value.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#403660

On 2026-10-27 13:45, Steven G. Kargl wrote:
> On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
> 
>> if ai generates me some functions it puts everywhere this f at the and
>> yet it add zeros so instead of .1 i got 0.1f
>>
>> and i obviously dont like it
>>
>> i write hvever some codes when i need speed so the question is may it
>> give some difference?
>>
>> i mean .1 maybe can be treated as doube constants so mabe occupies some
>> more memory (?) or uses some casting in coplutations (?)
>>
>>
>> i doubt it probably it makes difference but im strictly not sure
> 
> The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes 
> code easier to read.  The difference between 0.1 and 0.1f with
> their binary representations is a another matter.
The number 0.1 cannot be represented exactly in binary.

The C constant "0.1" implicitly has a double value. It has "either the
nearest representable value" to exactly 0.1, "or the larger or smaller
representable value immediately adjacent to the nearest representable
value, chosen in an implementation-defined
manner." (6.5.4.3p4). Since it's double precision constant,
"representable" means "representable as a double precision number".

0.1f, on the other hand, is explicitly a float value. It follows the
same rules, but with "representable" meaning "can be represented as a
float".

0.1 and 0.1f will therefore not be the same. If you convert 0.1f to
double precision, it will convert the floating point value actually
stored to double precision, not the real value it represents. "if the
value being converted can be represented exactly in the new type, it is
unchanged." (6.2.4p4) Any float value is normally representable exactly
as a double, simply by setting all of the bits that are not stored in
float format to 0 in double format. Those bits will therefore not have
the same value they would have in "0.1".

If you convert 0.1 to float, y, "... the value being converted is in the
range of values that can be represented but cannot be represented
exactly," so "the result is either the nearest higher or nearest lower
representable value, chosen in an implementation-defined manner."
(6.3.2.5p2).
Note that "nearest" is, in this case, being determined relative to the
floating point value represented by "0.1", not the mathematical value of
1/10. Also, the "implementation-defined manner" need not be the same as
the one used for determining the value of floating point constants.

So, 0.1 and 0.1f have different values, and might be even more different
after either one is converted to the other's type for comparison. The
difference is only in the last representable bits, which won't matter
for most practical purposes, but will matter if you're comparing for
exact equality.

You should use 0.1 when the value will be stored in a double or would
otherwise immediately get converted to double when used (which is often
the case). You should use 0.1f to initialize a float variable or to pass
an argument to a function whose prototype specifies that the
corresponding parameter has the type float.

[toc] | [prev] | [next] | [standalone]

#403662

On 2026-10-27 17:43, James Kuyper wrote:
...> So, 0.1 and 0.1f have different values, and might be even more
different
> after either one is converted to the other's type for comparison. The
> difference is only in the last representable bits, which won't matter
> for most practical purposes, but will matter if you're comparing for
> exact equality.

That was a mistake. The difference involves the last representable bits
of the float value, and all of the smaller bits in the double format. As
a practical matter, if float arithmetic is adequate for your
application, it won't make much difference. However, if you need double
precision, you shouldn't be using the "f" suffix.

[toc] | [prev] | [next] | [standalone]

#403671

On Tue, 27 Oct 2026 18:06:25 -0400, James Kuyper wrote:

> However, if you need double precision, you shouldn't be using the
> "f" suffix.

Is there any situation where you *should* use the “f” suffix?

I am thinking: no.

[toc] | [prev] | [next] | [standalone]

#403672

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Tue, 27 Oct 2026 18:06:25 -0400, James Kuyper wrote:
>> However, if you need double precision, you shouldn't be using the
>> "f" suffix.
>
> Is there any situation where you *should* use the “f” suffix?
>
> I am thinking: no.

If you're working with values of type float, the "f" suffix is more
explicit.

Logically, something like

    float f = 0.1;

implies a conversion from double to float, which could be non-trivial.
In practice, the conversion is likely to be done at compile time.
The result is *probably* the same as `float f = 0.1f;`, but I don't
think that's guaranteed.

I can't think of a case were writing 0.1f rather than 0.1 would
cause any real (ahem) problems, but there are plenty of cases where
someone might consider it stylistically better.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web