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 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 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 14:07 +0100
              Re: .5 against 0.5f scott@slp53.sl.home (Scott Lurndal) - 2026-10-30 13:55 +0000
                Re: .5 against 0.5f "chine.bleu" <chine.bleu@yahoo.com> - 2026-10-30 07:45 -0700
            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 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 14:54 +0100
                              Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-30 15:25 +0100
                                Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-30 14:45 +0000
            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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

#403835

On 2026-10-30 10:39, chine.bleu wrote:
>
> You could make a library for rational numbers (two integers) arithmetic 
> where the denominator is a power of ten.

Using rational numbers is of course an option. Though I don't recall
to have seen common systems with support of rational arithmetic, and
also languages with a rational numbers type seem not be too common.
(Incidentally I've not long ago written such for a language that while
inherently supporting even 'complex' numbers there's no 'rational'.
Rationals are no biggie so could easily be provided through a library.)
But I also think the fixed point approach is still just simpler and
that's probably the reason for often having been used.

> If the CPU has decimal arithmetic, implement it in assembly.

Well, the pocket calculators often had that and did exactly that.

Janis

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

#403837

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>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.)

All the early electrodata/burroughs business computers (Datatron 220,
Burroughs B300, Burroughs B3500) used fixed point BCD representations
for business applications and the COBOL compiler.

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

Simply using %8.2f would have been sufficient, but modern programmers
don't like printf formatting, apparently.

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

#403840

scott@slp53.sl.home (Scott Lurndal) wrote:
> All the early electrodata/burroughs business computers (Datatron 220,
> Burroughs B300, Burroughs B3500) used fixed point BCD representations
> for business applications and the COBOL compiler.

STAR-100 supported 65535 digit decimal.

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

#403823

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
[...]
> How would you do calculations involving compound interest payments
> without floating-point arithmetic?

Because you'd want to follow the standards for financial calculations,
which are likely to require some kind of fixed-point.

>                                    And why would you want to?

To obtain the exact results required by the relevant financial
regulations, and to avoid accusations of malfeasance.

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

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

#403721

On 2026-10-28 02:23, Keith Thompson wrote:
> 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.

I think "logically" is a misleading word here.

The thought of something "implicit" going on here is a thought that
might stem from (knowing) the inherent mechanisms and quirks of the
C-language not necessarily what one would logically expect.

My expectation (for sensibly defined programming languages) would be
that literals for two different "real numbers" types are generic WRT
those types; they should be usable [in "C"] without loss (or kludges)
with 'float' and 'double'.

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

Janis

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

#403740

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-10-28 02:23, Keith Thompson wrote:
>> 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.
>
> I think "logically" is a misleading word here.

Perhaps "in the abstract machine" would have been clearer than
"logically".

In the abstract machine, 0.1 is of type double.  The initialization
causes that value to be converted from double to float.

> The thought of something "implicit" going on here is a thought that
> might stem from (knowing) the inherent mechanisms and quirks of the
> C-language not necessarily what one would logically expect.

My logical expectation is based on knowing C.

> My expectation (for sensibly defined programming languages) would be
> that literals for two different "real numbers" types are generic WRT
> those types; they should be usable [in "C"] without loss (or kludges)
> with 'float' and 'double'.

Sure, a compiler can generate code to store (float)0.1 in f without
doing a conversion, as long as the semantics are consistent.  But 0.1f
and 0.1 are of different types.  If they happen to behave the same way
in some context, it's a consequence of the C language rules.

Note in particular that this:
    double d = 0.1f;
has different semantics than
    double d = 0.1;
if double has more precision than float.    

[...]

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

#403759

On 2026-10-28 21:27, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
>> The thought of something "implicit" going on here is a thought that
>> might stem from (knowing) the inherent mechanisms and quirks of the
>> C-language not necessarily what one would logically expect.
> 
> My logical expectation is based on knowing C.

And knowing also a lot of the internals, and C-standards documents,
I'm sure. (My point was just that "normal" C-programmers might not
have that background and would "logically" assume different. - But
since you had clarified the word by using a more appropriate one in
this post I'm fine with that now. Thanks.)

> 
>> My expectation (for sensibly defined programming languages) would be
>> that literals for two different "real numbers" types are generic WRT
>> those types; they should be usable [in "C"] without loss (or kludges)
>> with 'float' and 'double'.
> 
> Sure, a compiler can generate code to store (float)0.1 in f without
> doing a conversion, as long as the semantics are consistent. 

Only that my view here is that you need a "conversion" in both cases,
since you primarily have to convert from a string representation of
the literal to the appropriate internal (binary) form. And given the
_program contexts_ you can do _the one_ appropriate conversion for
the types involved (i.e. Text->Float and Text->Double, respectively).

Note: my argumentation is based on questioning the existence of 'F'.
So I'd appreciate to hear of any enlightening application cases, ones
that would be impossible when 'F' in literals wouldn't be present.

(And, ideally, practically relevant usages. - We know that "C" is as
it is, and as it is there's some unavoidable consequences from that.)

> But 0.1f
> and 0.1 are of different types.  If they happen to behave the same way
> in some context, it's a consequence of the C language rules.

Yes, sure. Only that I think that context should suffice to interpret
"0.1" appropriately!

> 
> Note in particular that this:
>      double d = 0.1f;
> has different semantics than
>      double d = 0.1;
> if double has more precision than float.

Sure. But isn't that difference basically just a home-brewed C-issue?

I'd be curious why one would write the former in the first place.
Will a programmer or program designer gain something by assigning a
'float' constant literal to a 'double' variable?

I've never needed such, erm.., "hacks" ever in any of my C-code or
in other languages. So I'm honestly asking.

Janis

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

#403762

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-10-28 21:27, Keith Thompson wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> [...]
>>> The thought of something "implicit" going on here is a thought that
>>> might stem from (knowing) the inherent mechanisms and quirks of the
>>> C-language not necessarily what one would logically expect.
>> My logical expectation is based on knowing C.
>
> And knowing also a lot of the internals, and C-standards documents,
> I'm sure. (My point was just that "normal" C-programmers might not
> have that background and would "logically" assume different. - But
> since you had clarified the word by using a more appropriate one in
> this post I'm fine with that now. Thanks.)
>
>>> My expectation (for sensibly defined programming languages) would be
>>> that literals for two different "real numbers" types are generic WRT
>>> those types; they should be usable [in "C"] without loss (or kludges)
>>> with 'float' and 'double'.
>> Sure, a compiler can generate code to store (float)0.1 in f without
>> doing a conversion, as long as the semantics are consistent. 
>
> Only that my view here is that you need a "conversion" in both cases,
> since you primarily have to convert from a string representation of
> the literal to the appropriate internal (binary) form. And given the
> _program contexts_ you can do _the one_ appropriate conversion for
> the types involved (i.e. Text->Float and Text->Double, respectively).

I don't think of the process that takes a source code construct
like `0.1` and yields a value of 0.1 at run time as a "conversion".
It's just the meaning of the token.  "Text" is not a C type.  (The
constant might happen to be held in a C string at some point, but
only if the compiler is written in C.)

> Note: my argumentation is based on questioning the existence of 'F'.
> So I'd appreciate to hear of any enlightening application cases, ones
> that would be impossible when 'F' in literals wouldn't be present.

By 'F', you mean the 'f' or 'F' suffix on a floating constant, right?
(Your use of upper case threw me off for a moment.  No biggie.)

> (And, ideally, practically relevant usages. - We know that "C" is as
> it is, and as it is there's some unavoidable consequences from that.)

Yes, we know that from "C", which is the topic of this newsgroup.
I'm not sure what distinction you're making.  You seem to be
implying that C imposes some set of obscure rules on top of what
all programmers know.  0.0 is something that everyone recognizes,
while 0.0f is an obscure C feature.

I don't think of it that way.  C code is governed by the rules of C.

>> But 0.1f and 0.1 are of different types.  If they happen to behave
>> the same way in some context, it's a consequence of the C language
>> rules.
>
> Yes, sure. Only that I think that context should suffice to interpret
> "0.1" appropriately!

In many cases, yes, the final result is likely to be the same.
Even so, using 0.1 rather than 0.1f can result in less efficient
generated code if the compiler isn't sufficiently clever, or perhaps
even if it is.

And if I'm trying to use type float and avoid type double (as, for
example, David Brown has good reasons to do), writing `0.1f` is a
great way to avoid having to think about how clever the compiler
has to be to avoid unnecessary conversions.

>> Note in particular that this:
>>      double d = 0.1f;
>> has different semantics than
>>      double d = 0.1;
>> if double has more precision than float.
>
> Sure. But isn't that difference basically just a home-brewed C-issue?

"Home-brewed"?  It's a rule imposed by the C language.

> I'd be curious why one would write the former in the first place.
> Will a programmer or program designer gain something by assigning a
> 'float' constant literal to a 'double' variable?

Probably not.  The point is that there are real semantic differences
between 0.1f and 0.1.

On the other hand, if you want to print a float value using printf, it
will be converted to double.

    printf("%.55f\n%.55f\n", 0.1f, 0.1);

    0.1000000014901161193847656250000000000000000000000000000
    0.1000000000000000055511151231257827021181583404541015625

> I've never needed such, erm.., "hacks" ever in any of my C-code or
> in other languages. So I'm honestly asking.

It was an example, not meant to be a demonstration of useful code.
I could have mentioned that `sizeof 0.1f` is likely to be different
from `sizeof 0.1`, but that's even more unrealistic.

I think there's a common attitude that double is the "default" type
for floating-point constants.  That's a valid way to look at it, but
I suggest an equally valid way is to say that *there is no default*.

If I write 0.1f, I'm explicitly using type float.
If I write 0.1,  I'm explicitly using type double.
If I write 0.1L, I'm explicitly using type long double.

In one of the three cases, the suffix just happens to be empty.

(And again, I'm glossing over FLT_EVAL_METHOD.)

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

#403791

On 2026-10-29 00:56, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 2026-10-28 21:27, Keith Thompson wrote:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> [...]
>>>> The thought of something "implicit" going on here is a thought that
>>>> might stem from (knowing) the inherent mechanisms and quirks of the
>>>> C-language not necessarily what one would logically expect.
>>> My logical expectation is based on knowing C.
>>
>> And knowing also a lot of the internals, and C-standards documents,
>> I'm sure. (My point was just that "normal" C-programmers might not
>> have that background and would "logically" assume different. - But
>> since you had clarified the word by using a more appropriate one in
>> this post I'm fine with that now. Thanks.)
>>
>>>> My expectation (for sensibly defined programming languages) would be
>>>> that literals for two different "real numbers" types are generic WRT
>>>> those types; they should be usable [in "C"] without loss (or kludges)
>>>> with 'float' and 'double'.
>>> Sure, a compiler can generate code to store (float)0.1 in f without
>>> doing a conversion, as long as the semantics are consistent.
>>
>> Only that my view here is that you need a "conversion" in both cases,
>> since you primarily have to convert from a string representation of
>> the literal to the appropriate internal (binary) form. And given the
>> _program contexts_ you can do _the one_ appropriate conversion for
>> the types involved (i.e. Text->Float and Text->Double, respectively).
> 
> I don't think of the process that takes a source code construct
> like `0.1` and yields a value of 0.1 at run time as a "conversion".
> It's just the meaning of the token.  "Text" is not a C type. [...]

Sure. I was speaking about source code text, that gets transformed
to some binary representation by the compiler. I took the view from
a programmer's perspective of a language; to be clear, not mandating
(as some here do) that a programmer should read the C-standard to
learn and understand the language, but as more typical, a textbook.

> 
>> Note: my argumentation is based on questioning the existence of 'F'.
>> So I'd appreciate to hear of any enlightening application cases, ones
>> that would be impossible when 'F' in literals wouldn't be present.
> 
> By 'F', you mean the 'f' or 'F' suffix on a floating constant, right?
> (Your use of upper case threw me off for a moment.  No biggie.)

Yes. (Didn't intend to confuse people.) I'm regularly using (in "C")
capital letters for such qualifiers, so that they better stand out.
The 'L' for example (that I use more often; 'F' I've never used since
I also rarely do 'float' operations) is often (depending on the font)
harder to distinguish (from '1') if written in lower-case ('l').

> 
>> (And, ideally, practically relevant usages. - We know that "C" is as
>> it is, and as it is there's some unavoidable consequences from that.)
> 
> Yes, we know that from "C", which is the topic of this newsgroup.
> I'm not sure what distinction you're making. 

I wanted to avoid reflexes like "accept how it is or leave" comments.
(I obviously failed with making that intent clear.)

As I've explained above, I was looking at it from a programmer's
perspective, not from someone who has the C-standard as bible on his
nightstand. With experiences from many other languages the "F-topic",
its necessity, is not that clear if we look at "C" conceptionally.

> You seem to be
> implying that C imposes some set of obscure rules on top of what
> all programmers know.  0.0 is something that everyone recognizes,
> while 0.0f is an obscure C feature.

(I think 0 is a bad example, for some reasons in "C" and general.)

That "0.1" is (or may be, depending on the actual 'float' and 'double'
characteristics) effectively something different than "0.1F" is the
trivial part, unnecessary to explain. I had expanded below what was
bothering me.

> 
> I don't think of it that way.  C code is governed by the rules of C.
> 
>>> But 0.1f and 0.1 are of different types.  If they happen to behave
>>> the same way in some context, it's a consequence of the C language
>>> rules.
>>
>> Yes, sure. Only that I think that context should suffice to interpret
>> "0.1" appropriately!
> 
> In many cases, yes, the final result is likely to be the same.
> Even so, using 0.1 rather than 0.1f can result in less efficient
> generated code if the compiler isn't sufficiently clever, or perhaps
> even if it is.
> 
> And if I'm trying to use type float and avoid type double (as, for
> example, David Brown has good reasons to do), writing `0.1f` is a
> great way to avoid having to think about how clever the compiler
> has to be to avoid unnecessary conversions.

Actually I had been thinking about applications that David might
have - I recall he once said about him using 'float' to match some
controller hardware restrictions and stay efficient (or some such).

And while the initialization sample (below) did not make any sense
to me I was then thinking about expressions with mixed types where
it could make sense. But the consequences did also not make "much"
sense to me when thinking about it. Two basic cases appeared to me.
One was having expressions with mixed types (float and double);
in the micro-controller-case that would anyway have to be handled
in a sub-optimal way (performance-wise) when 'double's appear. And
in case of using just 'float' variables with non-F-tagged constants
my expectation would be that the compiler would/should take care of
the appropriate, sensible, efficient use of the constant. (Operating
in 'float' precision but interpreting "Real" literals as 'double'?!)
You say, "avoid having to think about how clever the compiler" is;
I understand that. But wouldn't it be more sensible to compose your
"Real" expressions in appropriate parts that reflect and guarantee
the precision explicitly? (As "C" is as it is it might be appealing
to use the 'F' instead, I admit. As said I was principally question
the necessity of 'F' in "C" from a design perspective.)

> 
>>> Note in particular that this:
>>>       double d = 0.1f;
>>> has different semantics than
>>>       double d = 0.1;
>>> if double has more precision than float.
>>
>> Sure. But isn't that difference basically just a home-brewed C-issue?
> 
> "Home-brewed"?  It's a rule imposed by the C language.

(I meant; is it a "home-brewed" consequence of the C-language design.)

> 
>> I'd be curious why one would write the former in the first place.
>> Will a programmer or program designer gain something by assigning a
>> 'float' constant literal to a 'double' variable?
> 
> Probably not.  The point is that there are real semantic differences
> between 0.1f and 0.1.

Sure.

Janis

> [...]

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

#403773

On 29/10/2026 00:08, Janis Papanagnou wrote:
> On 2026-10-28 21:27, Keith Thompson wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> [...]

>> But 0.1f
>> and 0.1 are of different types.  If they happen to behave the same way
>> in some context, it's a consequence of the C language rules.
> 
> Yes, sure. Only that I think that context should suffice to interpret
> "0.1" appropriately!
> 

Do you mean that you think it would have been better if the rules of C 
were different, so that the context always determined how "0.1" was to 
be interpreted?  That's not an unreasonable feature for a programming 
language - AFAIUI, that is how numeric literals work in Ada.  But it is 
not how things work in C, where the value and type of an expression is 
determined entirely by the expression itself, independently of the context.

I hate to try to speculate as to whether the C philosophy or the Ada 
philosophy here is more common - but I don't know of any languages other 
than Ada that make the type of literals dependent on their use or 
context.  There are of course many languages that might follow the Ada 
path, unbeknownst to me.  (You can have fun making class types in C++, 
and no doubt other languages, that emulate this behaviour, but it is not 
part of the language.)

So when you write "float x = 0.1;", the 0.1 is a value of type double. 
It is converted to float by the assignment operator.

>>
>> Note in particular that this:
>>      double d = 0.1f;
>> has different semantics than
>>      double d = 0.1;
>> if double has more precision than float.
> 
> Sure. But isn't that difference basically just a home-brewed C-issue?
> 
> I'd be curious why one would write the former in the first place.
> Will a programmer or program designer gain something by assigning a
> 'float' constant literal to a 'double' variable?

"double d1 = 0.1;" and "double d2 = 0.1f;" do not put the same value in 
"d1" and "d2".  Often the exact value does not matter much, and usually 
when it /does/ matter, the double-precision version is what you want. 
But sometimes people are interested in highly reproducible results from 
their floating point - and that means being precise about the types you 
want.

I agree that is would be very unusual to want to initialise a 
double-precision variable with a single-precision floating constant.  I 
can't think of a circumstance where I would have reason to do so 
directly.  I /can/ think of indirect situations:

	#define scale_factor 1.234f
	...
	#if USE_HIGH_PRECISION
		typedef double calculation_t;
	#else
		typedef float calculation_t;
	#endif
	...
	calculation_t sf = scale_factor;

It is more likely that I'd make "scale_factor" a const of type 
"calculation_t", initialised from "1.234".  But perhaps that macro 
constant came from third-party code.


For more general use of single-precision floating constants, the 
use-cases are clearer.

First, there is the obvious one that regardless of how the floating 
constant is used, it is clear to the reader that 0.1f is single 
precision.  In contexts where speed matters (such as for limited 
microcontrollers, or where you hope to use SIMD acceleration) you do not 
want to use double precision accidentally - being explicit is better.

Secondly, narrowing conversions are not allowed in constexpr 
initialisations - you cannot write "constexpr float f = 0.1;".  (In C++, 
this also applies to braced initialisation - and is a good reason to use 
such initialisation style.)  Static analysis tools may also complain 
about narrowing initialisations.

And of course we have already covered their use in expressions.

> 
> I've never needed such, erm.., "hacks" ever in any of my C-code or
> in other languages. So I'm honestly asking.
> 

Sure.  I haven't written "double d = 0.1f;" in my code either.

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

#403781

David Brown <david.brown@hesbynett.no> writes:
> On 29/10/2026 00:08, Janis Papanagnou wrote:
>> On 2026-10-28 21:27, Keith Thompson wrote:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> [...]
>
>>> But 0.1f
>>> and 0.1 are of different types.  If they happen to behave the same way
>>> in some context, it's a consequence of the C language rules.
>> Yes, sure. Only that I think that context should suffice to
>> interpret
>> "0.1" appropriately!
>
> Do you mean that you think it would have been better if the rules of C
> were different, so that the context always determined how "0.1" was to
> be interpreted?  That's not an unreasonable feature for a programming
> language - AFAIUI, that is how numeric literals work in Ada.  But it
> is not how things work in C, where the value and type of an expression
> is determined entirely by the expression itself, independently of the
> context.

Strictly speaking, the type of a numeric literal in Ada is
<universal_integer> or <universal_real>.  Both types are anonymous,
have effectively infinite precision, and exist only at compile time.
There's an implicit conversion to the type determined by the context
(one of the few implicit conversions in Ada).

The effect is similar to what you'd get if the type of a literal
depending on its context.

[...]

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

#403793

On 2026-10-29 09:30, David Brown wrote:
> On 29/10/2026 00:08, Janis Papanagnou wrote:
>> On 2026-10-28 21:27, Keith Thompson wrote:
>> [...]
>>> But 0.1f
>>> and 0.1 are of different types.  If they happen to behave the same way
>>> in some context, it's a consequence of the C language rules.
>>
>> Yes, sure. Only that I think that context should suffice to interpret
>> "0.1" appropriately!
>>
> 
> Do you mean that you think it would have been better if the rules of C 
> were different, so that the context always determined how "0.1" was to 
> be interpreted? 

(I think my opinion here is irrelevant since "C" is what it is.)

But, yes, my question was whether it would haven been necessary
(language design-wise!) to have those tags in the first place.

> That's not an unreasonable feature for a programming 
> language - AFAIUI, that is how numeric literals work in Ada.  But it is 
> not how things work in C, where the value and type of an expression is 
> determined entirely by the expression itself, independently of the context.
> 
> I hate to try to speculate as to whether the C philosophy or the Ada 
> philosophy here is more common -

(I also have no interest in speculations.)

> but I don't know of any languages other 
> than Ada that make the type of literals dependent on their use or 
> context.  There are of course many languages that might follow the Ada 
> path, unbeknownst to me.  (You can have fun making class types in C++, 
> and no doubt other languages, that emulate this behaviour, but it is not 
> part of the language.)

(Here I had started writing examples from other languages, but it
got long and no end to see, and it's anyway most likely considered
off-topic, so I decided to just stop here.)

Thanks for your elaborations on the question.

Janis

> [...]

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

#403796

On 29/10/2026 19:57, Janis Papanagnou wrote:
> On 2026-10-29 09:30, David Brown wrote:
>> On 29/10/2026 00:08, Janis Papanagnou wrote:
>>> On 2026-10-28 21:27, Keith Thompson wrote:
>>> [...]
>>>> But 0.1f
>>>> and 0.1 are of different types.  If they happen to behave the same way
>>>> in some context, it's a consequence of the C language rules.
>>>
>>> Yes, sure. Only that I think that context should suffice to interpret
>>> "0.1" appropriately!
>>>
>>
>> Do you mean that you think it would have been better if the rules of C 
>> were different, so that the context always determined how "0.1" was to 
>> be interpreted? 
> 
> (I think my opinion here is irrelevant since "C" is what it is.)

There's nothing wrong with having an opinion on what might or might not 
have been better, or what you might like in other languages.  The 
pointless discussions come from claiming C can be, or needs to be, "fixed".

But it's fine to stop here if you like.

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

#403800

On 2026-10-29 20:56, David Brown wrote:
> 
> There's nothing wrong with having an opinion on what might or might not 
> have been better, or what you might like in other languages.  The 
> pointless discussions come from claiming C can be, or needs to be, "fixed".

"Abandon all hope, ye who enter here." :-)

> But it's fine to stop here if you like.

Yes, I think it makes little sense. It's also hard to compare
languages on a specific feature alone without taking its whole
design into account. The 'F' tag is just a detail of the issue
(or "issue", in quotes, if you prefer) with types in "C". (IMO)

Janis

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

#403798

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> Note: my argumentation is based on questioning the existence of 'F'.
> So I'd appreciate to hear of any enlightening application cases, ones
> that would be impossible when 'F' in literals wouldn't be present.

In C the word is constants, not literals.

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

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

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

csiph-web