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 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 23:19 +0100
      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 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 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 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 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 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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#403724

On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:

> (should i also write 0.0f insetad of 0 BTW?)

A lot of context removed.  No.  IMO, if you have
a numerical constant that can be written as an
integer and that integer is less than 2^P
where P is the precision of the floating point
type of interest (here, 2^P means 2 raised to
the Pth power), then simply write the numerical
constant as an integer.  It's easier to read.

float foo(float a) {
  float x = 25 * a;
  return (x);
}

A compiler ought to convert 25 in the above to
25.f as 25 is exactly representable (at least in
IEEE-754 binary32 format) in float.  

-- 
steve

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

#403730

Steven G. Kargl pisze:
> On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
> 
>> (should i also write 0.0f insetad of 0 BTW?)
> 
> A lot of context removed.  No.  IMO, if you have
> a numerical constant that can be written as an
> integer and that integer is less than 2^P
> where P is the precision of the floating point
> type of interest (here, 2^P means 2 raised to
> the Pth power), then simply write the numerical
> constant as an integer.  It's easier to read.
> 
> float foo(float a) {
>    float x = 25 * a;
>    return (x);
> }
> 
> A compiler ought to convert 25 in the above to
> 25.f as 25 is exactly representable (at least in
> IEEE-754 binary32 format) in float.
> 
there is something like integer*float multiplication , or not?
if so 25*a and 25.*a or 25.0f*a could make a difference

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

#403734

fir pisze:
> Steven G. Kargl pisze:
>> On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
>>
>>> (should i also write 0.0f insetad of 0 BTW?)
>>
>> A lot of context removed.  No.  IMO, if you have
>> a numerical constant that can be written as an
>> integer and that integer is less than 2^P
>> where P is the precision of the floating point
>> type of interest (here, 2^P means 2 raised to
>> the Pth power), then simply write the numerical
>> constant as an integer.  It's easier to read.
>>
>> float foo(float a) {
>>    float x = 25 * a;
>>    return (x);
>> }
>>
>> A compiler ought to convert 25 in the above to
>> 25.f as 25 is exactly representable (at least in
>> IEEE-754 binary32 format) in float.
>>
> there is something like integer*float multiplication , or not?
> if so 25*a and 25.*a or 25.0f*a could make a difference

and i would say it is good to be able to express what one wants

and write 25*a, 25.0d *a, 25.0f *a  //if there would be version for double

but for me its really weird that compiler cant 25.*a resolve as floats 
if optimisation is on and put those conversions

same as 25 imo shouldn be treated as int if in runtime faster it would 
be if that would be short long or char

imo constant is constant so 25.1 imo even should not represent nor float 
nor double but probably the 'ideal' value

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

#403738

On Wed, 28 Oct 2026 19:15:45 +0100, fir wrote:

> Steven G. Kargl pisze:
>> On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
>> 
>>> (should i also write 0.0f insetad of 0 BTW?)
>> 
>> A lot of context removed.  No.  IMO, if you have
>> a numerical constant that can be written as an
>> integer and that integer is less than 2^P
>> where P is the precision of the floating point
>> type of interest (here, 2^P means 2 raised to
>> the Pth power), then simply write the numerical
>> constant as an integer.  It's easier to read.
>> 
>> float foo(float a) {
>>    float x = 25 * a;
>>    return (x);
>> }
>> 
>> A compiler ought to convert 25 in the above to
>> 25.f as 25 is exactly representable (at least in
>> IEEE-754 binary32 format) in float.
>> 
> there is something like integer*float multiplication , or not?
> if so 25*a and 25.*a or 25.0f*a could make a difference

For 25, 25., and 25.0f, the compiler ought to produce the
same assembly.  Why?  Because the integer 25 is exactly
representable in both float (IEEE-754 binary32) and double
(IEEE-754 binary64), and the float 25.0f is exactly
representable in double.  A compiler can take advantage of
this to produce an optimal assembly listing.  At least with
clang, one sees this.

float
foo(int n, float x)
{
//  float a = x * 25;
//  float a = x * 25.f;
   float a = x * 25.;
   return (a);
}

Selecting each declaration in order yields

% cc -o z.s -S -O3 j8.c && md5 -r z.s
0879b3f8c5924476e64657d4b17a9405 z.s
% cc -o z.s -S -O3 j8.c && md5 -r z.s
0879b3f8c5924476e64657d4b17a9405 z.s
% cc -o z.s -S -O3 j8.c && md5 -r z.s
0879b3f8c5924476e64657d4b17a9405 z.s

Now, take x/10, x*0.1, and x*0.1f.

float
foo(int n, float x)
{
//  float a = x * 0.1;
//  float a = x * 0.1f;
   float a = x / 10;
   return (a);
}

The integer 10 is exactly representable, but a compiler will
likely produce a division, and that's what we see with clang

.LCPI0_0:
        .long   0x41200000                      # float 10
...
        .cfi_def_cfa_register %rbp
        divss   .LCPI0_0(%rip), %xmm0
        popq    %rbp
        .cfi_def_cfa %rsp, 8
        retq

The real number 0.1 is not exactly representable in either 
float or double.  The compiler will chose the best available
floating point number nearest to 0.1 and 0.1f (and this 
depends on the rounding mode).  With 0.1f and clang, you get 

.LCPI0_0:
        .long   0x3dcccccd                      # float 0.100000001
...
        .cfi_def_cfa_register %rbp
        mulss   .LCPI0_0(%rip), %xmm0
        popq    %rbp
        .cfi_def_cfa %rsp, 8
        retq

Finally, with 0.1, clang produces

.LCPI0_0:
        .quad   0x3fb999999999999a              # double 0.10000000000000001
...

        .cfi_def_cfa_register %rbp
        cvtss2sd        %xmm0, %xmm0
        mulsd   .LCPI0_0(%rip), %xmm0
        cvtsd2ss        %xmm0, %xmm0
        popq    %rbp
        .cfi_def_cfa %rsp, 8
        retq

Notice, the conversions in this case.  If numerical accuracy
is unimportant but speed is, then using 0.1f seems to be the
best choice.  If numerical accuracy is important, one probably
use double from the get-go.

If you are going to work with floating point arithmetic,
then you should read Goldberg's paper.  In fact, you
will likely want to read it multiple times.

-- 
steve

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

#403741

"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
> On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
>> (should i also write 0.0f insetad of 0 BTW?)
>
> A lot of context removed.  No.  IMO, if you have
> a numerical constant that can be written as an
> integer and that integer is less than 2^P
> where P is the precision of the floating point
> type of interest (here, 2^P means 2 raised to
> the Pth power), then simply write the numerical
> constant as an integer.  It's easier to read.
>
> float foo(float a) {
>   float x = 25 * a;
>   return (x);
> }
>
> A compiler ought to convert 25 in the above to
> 25.f as 25 is exactly representable (at least in
> IEEE-754 binary32 format) in float.  

I disagree.  Yes, the int constant 25 is implicitly converted to float
as part of the "usual arithmetic conversions".  But I find
    float x = 25.0 * a;
or even
    float x = 25.0f * a;
clearer than
    float x = 25 * a;

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

#403756

On Wed, 28 Oct 2026 13:31:06 -0700, Keith Thompson wrote:

> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>> On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
>>> (should i also write 0.0f insetad of 0 BTW?)
>>
>> A lot of context removed.  No.  IMO, if you have
>> a numerical constant that can be written as an
>> integer and that integer is less than 2^P
>> where P is the precision of the floating point
>> type of interest (here, 2^P means 2 raised to
>> the Pth power), then simply write the numerical
>> constant as an integer.  It's easier to read.
>>
>> float foo(float a) {
>>   float x = 25 * a;
>>   return (x);
>> }
>>
>> A compiler ought to convert 25 in the above to
>> 25.f as 25 is exactly representable (at least in
>> IEEE-754 binary32 format) in float.  
> 
> I disagree.  Yes, the int constant 25 is implicitly converted to float
> as part of the "usual arithmetic conversions".  But I find
>     float x = 25.0 * a;
> or even
>     float x = 25.0f * a;
> clearer than
>     float x = 25 * a;

ROTL.  You find '25 * a' too difficult to realize
that it is twenty-five times a.  The 2 or 3 extra
digits (i.e., '.', '0', and 'f') are nothing but
fluff.

-- 
steve 

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

#403760

On 2026-10-28 23:44, Steven G. Kargl wrote:
> On Wed, 28 Oct 2026 13:31:06 -0700, Keith Thompson wrote:
>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>> [...]
>>>
>>> float foo(float a) {
>>>    float x = 25 * a;
>>>    return (x);
>>> }
>>>
>>> A compiler ought to convert 25 in the above to
>>> 25.f as 25 is exactly representable (at least in
>>> IEEE-754 binary32 format) in float.
>>
>> I disagree.  Yes, the int constant 25 is implicitly converted to float
>> as part of the "usual arithmetic conversions".  But I find
>>      float x = 25.0 * a;
>> or even
>>      float x = 25.0f * a;
>> clearer than
>>      float x = 25 * a;
> 
> ROTL.  You find '25 * a' too difficult to realize
> that it is twenty-five times a.  The 2 or 3 extra
> digits (i.e., '.', '0', and 'f') are nothing but
> fluff.

I basically agree with Keith here.

It's not about "realizing" the _mathematical_ meaning of "25 * a",
or about having a clearer/terser (less "fluffy") expression.

I'm sure the compiler would be able to create the correct internal
representation based on the program context; in that respect the
"25" should suffice, and not even impose any additional conversion
operation. IMO. (There might be some hindrance based on C's design
that I'm not aware of, though.)

 From a programmers' perspective it always appeared useful to see
the type of the involved components in expressions. That's way I
write in every language "25.0" if I want to express a Real value.
(In some language it can even be functionally important, or even
be mandated.)

Where I disagree is that the 'f' would be meaningful as "concept"
(even if in "C" there's two "sorts" of floats, and two literals
for the same abstract numeric domain of real numbers). (But see
my disclaimer above about possible home-brewed hindrances in "C".)

Janis

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

#403761

"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
> On Wed, 28 Oct 2026 13:31:06 -0700, Keith Thompson wrote:
>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>> On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
>>>> (should i also write 0.0f insetad of 0 BTW?)
>>>
>>> A lot of context removed.  No.  IMO, if you have
>>> a numerical constant that can be written as an
>>> integer and that integer is less than 2^P
>>> where P is the precision of the floating point
>>> type of interest (here, 2^P means 2 raised to
>>> the Pth power), then simply write the numerical
>>> constant as an integer.  It's easier to read.
>>>
>>> float foo(float a) {
>>>   float x = 25 * a;
>>>   return (x);
>>> }
>>>
>>> A compiler ought to convert 25 in the above to
>>> 25.f as 25 is exactly representable (at least in
>>> IEEE-754 binary32 format) in float.  
>> 
>> I disagree.  Yes, the int constant 25 is implicitly converted to float
>> as part of the "usual arithmetic conversions".  But I find
>>     float x = 25.0 * a;
>> or even
>>     float x = 25.0f * a;
>> clearer than
>>     float x = 25 * a;
>
> ROTL.  You find '25 * a' too difficult to realize
> that it is twenty-five times a.  The 2 or 3 extra
> digits (i.e., '.', '0', and 'f') are nothing but
> fluff.

I didn't say that I find `25 * a` difficult to understand.  I said
that I find `25.0 * a` clearer.  Even if it's only very slightly
easier to understand, that's well worth the cost of typing two
extra characters.

In this particular case, the type "float" appears on the same line as
the constant.  In other cases, you might have an isolated assignment
like `x = 25.0 * a;`.  In such a case, I find the floating-point
constant helpful as a reminder that this is a floating-point
operation, not an integer operation.

(Also, you misspelled "ROFL", and you don't need parentheses on the
return statement, particularly if you dislike fluff.)

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

#403763

On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:

> 
> (Also, you misspelled "ROFL", and you don't need parentheses on the
> return statement, particularly if you dislike fluff.)

Yeah, I was laugh too hard while typing ;-)

Parentheses is a habit from BSD kernel source file style guide.

% man 9 style
...

     Values in return statements should be enclosed in parentheses.


I also have debugging macros RETURNI() that require parens.

-- 
steve

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

#403764

"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:

> On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
>
>> (Also, you misspelled "ROFL", and you don't need parentheses on the
>> return statement, particularly if you dislike fluff.)
>
> Yeah, I was laugh too hard while typing ;-)
>
> Parentheses is a habit from BSD kernel source file style guide.

Now is a good time to start unlearning that habit.

> % man 9 style
> ...
>
>      Values in return statements should be enclosed in parentheses.
>
>
> I also have debugging macros RETURNI() that require parens.

That strengthens the motivation not to use parentheses with
return statements, to emphasize that they are different from
the macros.  Otherwise someone might wonder if there had been
a

  #define return(x)  return ...something involving x...

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

#403765

On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:

> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
> 
>> On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
>>
>>> (Also, you misspelled "ROFL", and you don't need parentheses on the
>>> return statement, particularly if you dislike fluff.)
>>
>> Yeah, I was laugh too hard while typing ;-)
>>
>> Parentheses is a habit from BSD kernel source file style guide.
> 
> Now is a good time to start unlearning that habit.

Why?  What harm do the parentheses cause?

Unlearning is not likely to happen.  I've been a long-time
contributor to FreeBSD, and have no plans to stop.  Feel
free to check the git history on FreeBSD libm sources.
My finger prints are all over the code.  So, yeah, I know
a enough about floating point arithmetic and C standard
requirements to be dangerous. 

>> % man 9 style
>> ...
>>
>>      Values in return statements should be enclosed in parentheses.
>>
>>
>> I also have debugging macros RETURNI() that require parens.
> 
> That strengthens the motivation not to use parentheses with
> return statements, to emphasize that they are different from
> the macros.

Do you ignore the style requirements of all the projects 
that you may have worked on, and simply use whatever 
your personal preferences are?

-- 
steve

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

#403774

On 29/10/2026 02:50, Steven G. Kargl wrote:
> On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
> 
>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>
>>> On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
>>>
>>>> (Also, you misspelled "ROFL", and you don't need parentheses on the
>>>> return statement, particularly if you dislike fluff.)
>>>
>>> Yeah, I was laugh too hard while typing ;-)
>>>
>>> Parentheses is a habit from BSD kernel source file style guide.
>>
>> Now is a good time to start unlearning that habit.
> 
> Why?  What harm do the parentheses cause?

I can't see that parentheses here cause any actual harm - but they are 
certainly unnecessary fluff, and do no good.

Every extra level of parentheses adds to the cognitive effort required 
to understand and interpret an expression.  It takes longer to read, and 
has a higher chance of misinterpretation.  If the parenthesis are 
necessary - "(a + b) * c" - then this is clearly a cost worth paying. 
Sometimes parentheses are not necessary, but /reduce/ the cognitive 
effort, such as "(a > 2) && (a < 5)".  Again, the parentheses are then a 
good thing (albeit subjectively).

But in "return (x);", they add nothing but cognitive effort.  The C 
programmer's brain has to consider and reject the possibility that this 
is a function call or a macro invocation.  The effort is small, but 
nonetheless wasted.

Let me put it another way.  What benefit do you think there is from 
these parentheses?  Why does the FreeBSD style guide recommend them?  I 
can see benefits in consistency of style once that usage has been 
established, but why have them in the first place?

> 
> Unlearning is not likely to happen.  I've been a long-time
> contributor to FreeBSD, and have no plans to stop.  Feel
> free to check the git history on FreeBSD libm sources.
> My finger prints are all over the code.  So, yeah, I know
> a enough about floating point arithmetic and C standard
> requirements to be dangerous.
> 
>>> % man 9 style
>>> ...
>>>
>>>       Values in return statements should be enclosed in parentheses.
>>>
>>>
>>> I also have debugging macros RETURNI() that require parens.
>>
>> That strengthens the motivation not to use parentheses with
>> return statements, to emphasize that they are different from
>> the macros.
> 
> Do you ignore the style requirements of all the projects
> that you may have worked on, and simply use whatever
> your personal preferences are?
> 

When working on code with particular style requirements, it makes sense 
to follow those style requirements - even if you disagree with the 
requirements.  When working on other code, you are then freed from 
following rules that are unnecessary or counter-productive.

If I were contributing code to FreeBSD and it /requires/ parentheses in 
return statements for the code to be accepted, I'd put parentheses in 
return statements.  If it merely /recommends/ them, I would not do so - 
but would change my mind if other FreeBSD contributors made a fuss about 
it.  In no other code would I use them, and in code reviews I would ask 
for them to be removed.

But I would not bother about them in throw-away Usenet code, except if 
the post was complaining about other unnecessary "fluff" :-)

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

#403787

In article <11bv4jd$37ch9$1@dont-email.me>,
David Brown  <david.brown@hesbynett.no> wrote:
>> [snip]
>> Why?  What harm do the parentheses cause?
>
>I can't see that parentheses here cause any actual harm - but they are
>certainly unnecessary fluff, and do no good.

I agree; in my own code, I do not generally use parentheses
around the expression I give in a `return` statement.  But often
our code is not our own, in the sense that we're constrained by
working on a much larger project and there are externally
imposed constraints that we must honor.  I don't have to like
them but, but I do have to abide by them.

>Every extra level of parentheses adds to the cognitive effort required
>to understand and interpret an expression.  It takes longer to read, and
>has a higher chance of misinterpretation.  If the parenthesis are
>necessary - "(a + b) * c" - then this is clearly a cost worth paying.
>Sometimes parentheses are not necessary, but /reduce/ the cognitive
>effort, such as "(a > 2) && (a < 5)".  Again, the parentheses are then a
>good thing (albeit subjectively).
>
>But in "return (x);", they add nothing but cognitive effort.  The C
>programmer's brain has to consider and reject the possibility that this
>is a function call or a macro invocation.  The effort is small, but
>nonetheless wasted.
>
>Let me put it another way.  What benefit do you think there is from
>these parentheses?  Why does the FreeBSD style guide recommend them?  I
>can see benefits in consistency of style once that usage has been
>established, but why have them in the first place?

I mostly agree with you.  But when working on a large project,
that spans many decades, with many different contributers,
having uniformity is good.  You mention cogitive load, but I
submit that it is strictly worse in that regard to have to deal
with multiple stylistic differences based on individual
preference.

My example is the Google monorepo.  When I left Google, it
contained about 2BLOC of code.  All of which more or less
conformed to Google's mandatory style "guides" (which were only
"guides" insofar as allowing people to get explicit exemptions
for very specific reasons from a small group of extremely senior
engineers: like, Sanjay Ghemawat and Jeff Dean type of senior).

Personally, I despised the style rules for almost all languages
Google used; I thought the code was ugly.  *But*, after a few
weeks working in the codebase, they became all but invisible; I
had to consciously think about them to remember my aesthetic
objections.  Furthermore, I claim that rigid adherence to _a_
set of rules, no matter how ugly I thought they were, was a big
factor in allowing Google to scale to tends of thousands of
engineers working concurrently in a multi-billion line codebase.

Put another way, it is more important to have _a_ style that is
used uniformly, while it is relatively less important what rules
that style imposes.

>>>> [snip]
>>>> % man 9 style
>>>> ...
>>>>
>>>>       Values in return statements should be enclosed in parentheses.
>>>>
>>>>
>>>> I also have debugging macros RETURNI() that require parens.
>>>
>>> That strengthens the motivation not to use parentheses with
>>> return statements, to emphasize that they are different from
>>> the macros.

A metanote, not to David, but of course, reference to the
`style(9)` man page _strengthens_ the argument for
parenthesizing return'ed expressions when working with FreeBSD
code.  In fairness, it wasn't clear that that was the original
context.

>> Do you ignore the style requirements of all the projects
>> that you may have worked on, and simply use whatever
>> your personal preferences are?
>
>When working on code with particular style requirements, it makes sense
>to follow those style requirements - even if you disagree with the
>requirements.  When working on other code, you are then freed from
>following rules that are unnecessary or counter-productive.
>
>If I were contributing code to FreeBSD and it /requires/ parentheses in
>return statements for the code to be accepted, I'd put parentheses in
>return statements.  If it merely /recommends/ them, I would not do so -
>but would change my mind if other FreeBSD contributors made a fuss about
>it.  In no other code would I use them, and in code reviews I would ask
>for them to be removed.
>
>But I would not bother about them in throw-away Usenet code, except if
>the post was complaining about other unnecessary "fluff" :-)

I do not find the amount of heat this has generated particularly
useful.  The parentheses may be superfluous, but they're not
wrong, and if OP prefers to include them, it does no harm; in
this case, there's a very good reason: OP works with FreeBSD
code often, which mandates them; maintaining two separate styles
to appease the USENET crowd is probably more cognitive effort
than mentally blocking them out for a `return`.

	- Dan C.

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

#403789

On Thu, 29 Oct 2026 10:45:16 +0100, David Brown wrote:
> 
> Let me put it another way.  What benefit do you think there is from 
> these parentheses?  Why does the FreeBSD style guide recommend them?  I 
> can see benefits in consistency of style once that usage has been 
> established, but why have them in the first place?
> 

As we all know, FreeBSD is derived from software developed by
the CSRG at UC Berkeley during the 70's.  FreeBSD adopted the
Kernel Normal Format (KNF) from CSRG.  You will need to contact
a former member of CSRG such as Bostik, McKusick, Joy, Leffler,
etc. and them why KNF requires ().

Perhaps, the C compiler from 40 or so years ago required
parentheses in a return statement.  Or, just maybe, members of
CSRG read K&R and noticed the authors of the book consistently
use paretheses in their examples.  Ah yes, let's look at
the documentation:

% man 9 style

HISTORY
     This manual page was originally based on the src/admin/style/style file
     from the 4.4BSD-Lite2 release, with frequent updates to reflect the
     current practice and desire of the FreeBSD project.
     src/admin/style/style is a codification by the CSRG of the programming
     style of Ken Thompson and Dennis Ritchie in Version 6 AT&T UNIX.

So, it seems to be a preference of Ritchie.

-- 
steve

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

#403804

"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:

> On Thu, 29 Oct 2026 10:45:16 +0100, David Brown wrote:
>
>> Let me put it another way.  What benefit do you think there is from
>> these parentheses?  Why does the FreeBSD style guide recommend them?
>> I can see benefits in consistency of style once that usage has been
>> established, but why have them in the first place?
>
> As we all know, FreeBSD is derived from software developed by
> the CSRG at UC Berkeley during the 70's.  FreeBSD adopted the
> Kernel Normal Format (KNF) from CSRG.  You will need to contact
> a former member of CSRG such as Bostik, McKusick, Joy, Leffler,
> etc.  and them why KNF requires ().
>
> Perhaps, the C compiler from 40 or so years ago required
> parentheses in a return statement.  Or, just maybe, members of
> CSRG read K&R and noticed the authors of the book consistently
> use paretheses in their examples.  Ah yes, let's look at
> the documentation:
>
> % man 9 style
>
> HISTORY
>     This manual page was originally based on the src/admin/style/style
>     file from the 4.4BSD-Lite2 release, with frequent updates to
>     reflect the current practice and desire of the FreeBSD project.
>     src/admin/style/style is a codification by the CSRG of the
>     programming style of Ken Thompson and Dennis Ritchie in Version6
>     AT&T UNIX.
>
> So, it seems to be a preference of Ritchie.

It may have been simply long-standing habit rather than preference.
In the early days of C parentheses around return expressions were
required, not optional.  I've been programming in C long enough to
have been influenced by that requirement (and later learned to undo
it).

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

#403788

On 2026-10-28 21:50, Steven G. Kargl wrote:
> On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
> 
>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>
>>> On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
>>>
>>>> (Also, you misspelled "ROFL", and you don't need parentheses on the
>>>> return statement, particularly if you dislike fluff.)
>>>
>>> Yeah, I was laugh too hard while typing ;-)
>>>
>>> Parentheses is a habit from BSD kernel source file style guide.
>>
>> Now is a good time to start unlearning that habit.
> 
> Why?  What harm do the parentheses cause?

They can lead to people thinking that return is a function, even if they
nominally know better. What would you think of

	return (a=b).retval;

You might never write such code, and might never read it either, but you
should have no trouble parsing it. Do you?

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

#403792

On Thu, 29 Oct 2026 11:56:38 -0400, James Kuyper wrote:

> On 2026-10-28 21:50, Steven G. Kargl wrote:
>> On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
>> 
>>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>>
>>>> On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
>>>>
>>>>> (Also, you misspelled "ROFL", and you don't need parentheses on the
>>>>> return statement, particularly if you dislike fluff.)
>>>>
>>>> Yeah, I was laugh too hard while typing ;-)
>>>>
>>>> Parentheses is a habit from BSD kernel source file style guide.
>>>
>>> Now is a good time to start unlearning that habit.
>> 
>> Why?  What harm do the parentheses cause?
> 
> They can lead to people thinking that return is a function, even if they
> nominally know better. What would you think of
> 
> 	return (a=b).retval;
> 
> You might never write such code, and might never read it either, but you
> should have no trouble parsing it. Do you?

Never written nor seen such a line of code.  Of course, a random
line of code taken out of context may have many interpretations
or no interpretation at all.  I likely know less than 25% of
what C can do as I am primarily interested in only C23 7.12 and
Annex F and G.

I do find it interesting that in a newgroup purportedly concerned
with discussions about the C programming language, I seem to have
been the only person in this thread to show a complete self-contained
piece of code so fir can see the consequences of not understanding
floating point arithmetic.

-- 
steve

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

#403805

"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
> On Thu, 29 Oct 2026 11:56:38 -0400, James Kuyper wrote:
>> On 2026-10-28 21:50, Steven G. Kargl wrote:
[...]
>>> Why?  What harm do the parentheses cause?
>> 
>> They can lead to people thinking that return is a function, even if they
>> nominally know better. What would you think of
>> 
>> 	return (a=b).retval;
>> 
>> You might never write such code, and might never read it either, but you
>> should have no trouble parsing it. Do you?
>
> Never written nor seen such a line of code.  Of course, a random
> line of code taken out of context may have many interpretations
> or no interpretation at all.  I likely know less than 25% of
> what C can do as I am primarily interested in only C23 7.12 and
> Annex F and G.

(7.12 is <math.h>; Annexes F and G are ISO/IEC 60559 arithmetic.)

The question isn't whether you've ever seen such code (which I'm
guessing James made up as an example).  The question is whether
you can easily understand it.  Someone who had a mental model that
return requires parentheses would likely have trouble with it.  (And
in fact very early versions of C did require parentheses on return
statements with an expression.)

> I do find it interesting that in a newgroup purportedly concerned
> with discussions about the C programming language, I seem to have
> been the only person in this thread to show a complete self-contained
> piece of code so fir can see the consequences of not understanding
> floating point arithmetic.

You may be one of the few people who's willing to engage with fir.
I didn't reply to him because I don't read his posts.

Are you the same person as steve g <Sgonedes1977@gmail.com>?

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

#403795

In article <11bvqbn$3g0tj$1@dont-email.me>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>On 2026-10-28 21:50, Steven G. Kargl wrote:
>> On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
>>
>>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
>>>
>>>> On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
>>>>
>>>>> (Also, you misspelled "ROFL", and you don't need parentheses on the
>>>>> return statement, particularly if you dislike fluff.)
>>>>
>>>> Yeah, I was laugh too hard while typing ;-)
>>>>
>>>> Parentheses is a habit from BSD kernel source file style guide.
>>>
>>> Now is a good time to start unlearning that habit.
>>
>> Why?  What harm do the parentheses cause?
>
>They can lead to people thinking that return is a function, even if they
>nominally know better.

What?  This is an incredibly weak argument.

If someone thought that `return` was a function, then why
wouldn't they think that `if` or `while` were also functions?
Or `sizeof`, and so on?

>What would you think of
>
>	return (a=b).retval;
>
>You might never write such code, and might never read it either, but you
>should have no trouble parsing it. Do you?

I would think that code is bad, and unnecessarily obscure, but
perhaps someone _would_ write this code.

	struct v {
		int retval;
	};

	struct v a;

	int
	something(void)
	{
		struct v b;
		b.retval = 1;
		return (a=b).retval;
	}

Of course, it would make no difference if the `return` statement
were written as,

	return ((a=b).retval);

But again, the whole premise (that a programmer familiar with C
would ever think that `return` is a function) is silly.

	- Dan C.

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

#403799

On 2026-10-29 20:49, Dan Cross wrote:
> [...]
> 
> But again, the whole premise (that a programmer familiar with C
> would ever think that `return` is a function) is silly.

Yes, that's hard to believe.

I've heard the argument somehow reversed, alike "You don't need
the parenthesis since 'return' is a statement (and no function)."
IOW, it was not about mistaking 'return' for a function, more to
make its _character as statement_ clear (and by that, en passant,
invalidate K&R's paragon which had been widely followed back then).

Janis

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

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

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

csiph-web