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

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

.5 against 0.5f

Started byfir <profesor.fir@gmail.com>
First post2026-10-27 11:53 +0100
Last post2026-10-27 13:08 -0700
Articles 20 on this page of 127 — 18 participants

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 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 23:19 +0100
          Re: .5 against 0.5f Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-30 00:50 +0000
            Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 05:01 +0100
              Re: .5 against 0.5f "chine.bleu" <chine.bleu@yahoo.com> - 2026-10-30 02:39 -0700
                Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-30 11:06 +0100
            Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 21:17 -0700
      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 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 23:06 +0100
                    Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 13:39 -0700
                      Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 16:56 -0700
                        Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 04:38 +0100
                          Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-30 09:11 +0100
            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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 15:47 -0700
                                      Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-30 01:17 +0000
                                    Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 16:46 -0700
                                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 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 16:06 -0700
                                      Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-30 00:21 +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 22:55 +0100
                                    Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 16:29 -0700
                                      Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 03:57 +0100
                                        Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 20:53 -0700
                                          Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 05:06 +0100
                                      Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-30 09:33 +0100
                                      Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-30 10:58 +0000
                                  Re: .5 against 0.5f Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-29 23:46 +0000
                                    Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 18:37 -0700
                                    Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 04:22 +0100
                                Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 17:58 +0100
                                Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 15:42 -0700
                                  Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-30 01:27 +0000
                                    Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-30 02:08 +0000
                                      Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 19:37 -0700
            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 Michael S <already5chosen@yahoo.com> - 2026-10-30 11:58 +0200
                  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 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

#403638

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2026-10-27 12:29 -0700
Message-ID<86y0bjlz6g.fsf@linuxsc.com>
In reply to#403632
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

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2026-10-27 13:11 -0700
Message-ID<11br0i5$1r6p7$3@dont-email.me>
In reply to#403638
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

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2026-10-27 13:25 -0700
Message-ID<11br1b3$1rtel$1@dont-email.me>
In reply to#403647
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

FromMichael S <already5chosen@yahoo.com>
Date2026-10-27 21:43 +0200
Message-ID<20261027214342.000022c4@yahoo.com>
In reply to#403632
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

FromMichael S <already5chosen@yahoo.com>
Date2026-10-27 22:05 +0200
Message-ID<20261027220506.0000321d@yahoo.com>
In reply to#403640
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

FromMichael S <already5chosen@yahoo.com>
Date2026-10-27 22:51 +0200
Message-ID<20261027225141.000076e0@yahoo.com>
In reply to#403643
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

FromKaz Kylheku <046-301-5902@kylheku.com>
Date2026-10-27 20:05 +0000
Message-ID<20261027125914.162@kylheku.com>
In reply to#403632
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

Frombartc <bc@freeuk.com>
Date2026-10-27 21:03 +0000
Message-ID<11br3ih$1sscp$1@dont-email.me>
In reply to#403644
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

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2026-10-27 15:41 -0700
Message-ID<11br9at$1uh9q$1@kst.eternal-september.org>
In reply to#403644
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

Fromscott@slp53.sl.home (Scott Lurndal)
Date2026-10-28 16:23 +0000
Message-ID<FjpES.74628$_pxc.26774@fx17.iad>
In reply to#403665
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

Fromsteve g <Sgonedes1977@gmail.com>
Date2026-10-28 02:25 -0400
Message-ID<87fqxqnxyw.fsf@gmail.com>
In reply to#403632
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

Frommakendo <makendo@makendo.invalid>
Date2026-10-29 18:04 +0800
Message-ID<11bv5o7$37qph$1@dont-email.me>
In reply to#403632
> 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

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2026-10-29 05:01 -0700
Message-ID<11bvcii$3a06t$3@kst.eternal-september.org>
In reply to#403778
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

FromDavid Brown <david.brown@hesbynett.no>
Date2026-10-29 13:55 +0100
Message-ID<11bvfor$3bl7q$1@dont-email.me>
In reply to#403783
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

Frombartc <bc@freeuk.com>
Date2026-10-29 14:32 +0000
Message-ID<11bvldc$3e02t$1@dont-email.me>
In reply to#403784
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]

#403801

FromJanis Papanagnou <janis_papanagnou+ng@hotmail.com>
Date2026-10-29 23:19 +0100
Message-ID<11c0gq4$2t865$3@dont-email.me>
In reply to#403783
On 2026-10-29 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.

We also have to consider conversions of currencies between states
in international trade, or, at times, switch of a currency unit;
e.g. 1 Euro = 1,95583 DEM (note the officially defined number of
decimals).

Janis

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

#403811

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-10-30 00:50 +0000
Message-ID<11c0plh$3s02c$1@dont-email.me>
In reply to#403778
On Thu, 29 Oct 2026 18:04:52 +0800, makendo wrote:

> 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.

1 yen = 100 sen = 1000 rin

    “The sen and the rin were eventually taken out of circulation at
    the end of 1953”
        -- <https://en.wikipedia.org/wiki/Japanese_yen>

How would you do calculations involving compound interest payments
without floating-point arithmetic? And why would you want to?

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

#403821

FromJanis Papanagnou <janis_papanagnou+ng@hotmail.com>
Date2026-10-30 05:01 +0100
Message-ID<11c14qg$2t866$7@dont-email.me>
In reply to#403811
On 2026-10-30 01:50, Lawrence D’Oliveiro wrote:
> [...]
> 
> How would you do calculations involving compound interest payments
> without floating-point arithmetic? And why would you want to?

Because what gets in and what comes out is just exact fixed point?
And you need more an exact transformation to and from the internal
values? And exact representation with BCD more than binary floating
point? (Mind the 0.10 issue!) - I think there was a reason why with
COBOL, the COmmon Business Oriented Language, there was - at least
historically - fixed-point arithmetic used for the financial sector?
(But please CMIIW.)

Would there be a problem with fixed-point arithmetic (that internally
uses a few more than just two decimals for rounding etc.) but that is
using basically a fixed-point representation?

And we saw in some post this hilarious sample of an (Amazon?) bill.
(Not that this couldn't have been fixed even/also with FP-arithmetic.)

Janis

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

#403829

From"chine.bleu" <chine.bleu@yahoo.com>
Date2026-10-30 02:39 -0700
Message-ID<11c1ok8$469v$1@dont-email.me>
In reply to#403821
Janis Papanagnou wrote:
> Would there be a problem with fixed-point arithmetic (that internally
> uses a few more than just two decimals for rounding etc.) but that is
> using basically a fixed-point representation?
You could make a library for rational numbers (two integers) arithmetic 
where the denominator is a power of ten. If the CPU has decimal 
arithmetic, implement it in assembly.

-- 
Siri Seal of Disavowal #777-000. Disavowed. Denied.  @
NO KINGS    For I desire mercy not sacrifice.       /|\
The Church of the Holey Apple .signature 5.5        / \
of Discordian Mysteries. This post insults Islam. Mohamed

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

#403832

FromDavid Brown <david.brown@hesbynett.no>
Date2026-10-30 11:06 +0100
Message-ID<11c1q7s$4tso$1@dont-email.me>
In reply to#403829
On 30/10/2026 10:39, chine.bleu wrote:
> Janis Papanagnou wrote:
>> Would there be a problem with fixed-point arithmetic (that internally
>> uses a few more than just two decimals for rounding etc.) but that is
>> using basically a fixed-point representation?
> You could make a library for rational numbers (two integers) arithmetic 
> where the denominator is a power of ten. If the CPU has decimal 
> arithmetic, implement it in assembly.
> 

It does not make much sense to talk about a library for rational 
numbers, then restrict it to denominators with powers of ten.  When you 
need exactly reproducible decimals, one option is to use a fixed number 
of places and then used scaled integers (a.k.a. fixed-point arithmetic) 
- basically hold your values in "long long int" types with a constant 
scale factor of 1'000'000, or similar.

If you want to be able to handle different scale factors easily, then 
decimal floating point formats are appropriate.  These are standardised 
in ISO/IEC 60559, and supported in C as _Decimal32, _Decimal64 and 
_Decimal128.  The types are optional in C, but supported at least by gcc 
on "big" target systems.  If the target hardware has appropriate 
instructions for them, the compiler should use that - that is vastly 
better than using assembly.

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

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

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

csiph-web