Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #403612 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-10-27 11:53 +0100 |
| Last post | 2026-10-27 13:08 -0700 |
| Articles | 20 on this page of 136 — 18 participants |
Back to article view | Back to comp.lang.c
.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 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-30 11:12 -0700
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 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-30 12:02 -0700
Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-30 21:01 +0100
Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 21:41 -0400
Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 08:45 +0100
Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 01:50 +0000
Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 07:32 +0100
Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 07:51 +0100
Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 07:55 +0100
Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 16:27 +0000
Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 17:44 +0100
Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 16:22 +0000
Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 19:15 +0100
Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 19:47 +0100
Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 19:10 +0000
Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 13:31 -0700
Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 22:44 +0000
Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 00:27 +0100
Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:39 -0700
Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 00:22 +0000
Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 17:59 -0700
Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 01:50 +0000
Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 10:45 +0100
Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-29 14:56 +0000
Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 16:34 +0000
Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 15:47 -0700
Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-30 01:17 +0000
Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 16:46 -0700
Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-29 11:56 -0400
Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 17:57 +0000
Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 16:06 -0700
Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-30 00:21 +0000
Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-29 19:49 +0000
Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 22:55 +0100
Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 16:29 -0700
Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 03:57 +0100
Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 20:53 -0700
Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 05:06 +0100
Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-30 09:33 +0100
Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-30 10:58 +0000
Re: .5 against 0.5f Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-29 23:46 +0000
Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 18:37 -0700
Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-30 04:22 +0100
Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 17:58 +0100
Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 15:42 -0700
Re: .5 against 0.5f cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-30 01:27 +0000
Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-30 02:08 +0000
Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 19:37 -0700
Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 08:39 +0100
Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-28 22:25 +0200
Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 10:48 +0100
Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-29 04:59 -0700
Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 14:26 -0700
Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-29 00:12 +0200
Re: .5 against 0.5f bartc <bc@freeuk.com> - 2026-10-28 22:33 +0000
Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 11:01 +0100
Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:05 -0700
Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-30 11:58 +0200
Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 10:59 +0100
Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:34 -0700
Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 11:06 +0100
Re: .5 against 0.5f tTh <tth@none.invalid> - 2026-10-28 15:08 +0100
Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 07:49 -0700
Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:36 -0700
Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 15:53 -0700
Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 21:55 -0400
Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 19:02 -0700
Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 08:56 +0100
Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 08:01 -0700
Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:08 -0700
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-29 13:39 -0700 |
| Message-ID | <86wlr0kzqc.fsf@linuxsc.com> |
| In reply to | #403759 |
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]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-29 16:56 -0700 |
| Message-ID | <11c0mfg$3pmvb$4@kst.eternal-september.org> |
| In reply to | #403798 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> 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.
For now. In the latest C2y draft, they're called literals.
Proposal: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3189.htm
Draft standard: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3998.pdf
(You've said before that you dislike this change.)
In any case, the term "literal" is unambiguous, even if it's not
currently used by the C standard.
--
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]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-30 04:38 +0100 |
| Message-ID | <11c13eq$2t866$6@dont-email.me> |
| In reply to | #403809 |
On 2026-10-30 00:56, Keith Thompson wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> 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. > > For now. In the latest C2y draft, they're called literals. > > Proposal: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3189.htm > Draft standard: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3998.pdf > > (You've said before that you dislike this change.) > > In any case, the term "literal" is unambiguous, even if it's not > currently used by the C standard. Thanks for answering him. (As I'm yet again ignoring him I wouldn't have noticed his statement.) For other readers I remind that I'm not necessarily using C-standard terms if there's terms common in CS existing that either appear more appropriately describing things, or if I'm generalizing facts beyond "C". It's noteworthy that the new C-standard draft is using that term;[*] I didn't know that, so also thanks also for that information. Janis [*] May we interpret that fact as C-standard terms might eventually converge to a more commonly accepted "beyond C standard" terminology? (I expect no answer. - It was just some pondering aloud.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-30 09:11 +0100 |
| Message-ID | <11c1jg6$2kc6$1@dont-email.me> |
| In reply to | #403819 |
On 30/10/2026 04:38, Janis Papanagnou wrote: > On 2026-10-30 00:56, Keith Thompson wrote: >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> 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. >> >> For now. In the latest C2y draft, they're called literals. >> >> Proposal: https://www.open-std.org/jtc1/sc22/wg14/www/docs/ >> n3189.htm >> Draft standard: https://www.open-std.org/jtc1/sc22/wg14/www/docs/ >> n3998.pdf >> >> (You've said before that you dislike this change.) >> >> In any case, the term "literal" is unambiguous, even if it's not >> currently used by the C standard. > > Thanks for answering him. (As I'm yet again ignoring him I wouldn't > have noticed his statement.) > > For other readers I remind that I'm not necessarily using C-standard > terms if there's terms common in CS existing that either appear more > appropriately describing things, or if I'm generalizing facts beyond > "C". The preference should be to use the C standard terms in this group - or to add brief comments for clarity. (Sometimes it is also worth adding comments for clarity even when using C standard terms.) The C standard uses terms like "object" and "byte" in a way that is unusual in the wider scope of computer science. But sometimes computer science courses use different terms, as do different programming languages and different parts of the world, and things change over time - often there is no single "standard CS" term, and often there is no fixed definition of a term commonly used in computer science. Many of the terms used in the C standard have the strong advantage of having specific definitions given in the standard itself. If in doubt, being a little extra explicit is better than being misunderstood! In the particular case of "constant", I think the root issue is that the word is overused. "integer constant" and "integer constant expression" are significantly different things in the C standards - it would seem logical to think that an "integer constant expression" evaluates to an "integer constant", but that is not the case. "const int x = 1;" does not define an "integer constant" or an "integer constant expression", while "constexpr int y = 1;" makes "y" and "integer constant expression" but not an "integer constant". Meanwhile, "Hello, world!" is a "string literal", not a "string constant". When C was young and fresh, there were far fewer constant things - and the terminology made sense. As more constant things (like "const" and then "constexpr") were added, it became less clear. C++ has called 123 an "integer literal" for ages, and it makes sense for C to follow suit. I doubt if this is the start of a habit or pattern, however. > > It's noteworthy that the new C-standard draft is using that term;[*] > I didn't know that, so also thanks also for that information. > > Janis > > [*] May we interpret that fact as C-standard terms might eventually > converge to a more commonly accepted "beyond C standard" terminology? > (I expect no answer. - It was just some pondering aloud.) >
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-30 14:54 +0100 |
| Message-ID | <11c27j3$2t866$10@dont-email.me> |
| In reply to | #403826 |
On 2026-10-30 09:11, David Brown wrote: > On 30/10/2026 04:38, Janis Papanagnou wrote: >> On 2026-10-30 00:56, Keith Thompson wrote: >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>> 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. >>> >>> For now. In the latest C2y draft, they're called literals. >>> >>> Proposal: https://www.open-std.org/jtc1/sc22/wg14/www/docs/ >>> n3189.htm >>> Draft standard: https://www.open-std.org/jtc1/sc22/wg14/www/docs/ >>> n3998.pdf >>> >>> (You've said before that you dislike this change.) >>> >>> In any case, the term "literal" is unambiguous, even if it's not >>> currently used by the C standard. >> >> Thanks for answering him. (As I'm yet again ignoring him I wouldn't >> have noticed his statement.) >> >> For other readers I remind that I'm not necessarily using C-standard >> terms if there's terms common in CS existing that either appear more >> appropriately describing things, or if I'm generalizing facts beyond >> "C". > > The preference should be to use the C standard terms in this group - or Like there's no CLC coding style (as recently demanded and rebutted) it's also, IMO, presumptuous to demand posters to use terms defined in the C-standards documents. Moreover, as I recently learned, even the standard-C documents seem to adjust their terminology. As I explained already, I'm using the terms that appear to me to be most appropriate to describe things. In cases where there's multiple options I'm gladly using the terms preferred in the C-standard docs, given that I know them. I certainly consider it presumptuous to demand from posters to read (all or every new version of) the C-standard to talk about "C". > to add brief comments for clarity. (Sometimes it is also worth adding > comments for clarity even when using C standard terms.) The C standard > uses terms like "object" and "byte" in a way that is unusual in the > wider scope of computer science. But sometimes computer science courses > use different terms, as do different programming languages and different > parts of the world, and things change over time - often there is no > single "standard CS" term, and often there is no fixed definition of a > term commonly used in computer science. That's all correct. As I mentioned elsewhere already - I think also in a reply to a post of yours, about the same topic - I'm gladly explaining (if necessary) not only every word in my posts that are unclear to you but also the implied semantics if necessary. (Mind that, as opposed to you and some others, while you may do that, I'm *not* discussing the _C-standard_ here. You should make yourself clear that there's a difference between talking about all aspects of the language or exchange specifically about the formal aspects of "C". What makes perfectly sense for the former group is, to say the least, arguable for the general, non-specialized disputants.) > Many of the terms used in the C > standard have the strong advantage of having specific definitions given > in the standard itself. Fine. > > If in doubt, being a little extra explicit is better than being > misunderstood! No doubt. > > In the particular case of "constant", I think the root issue is that the > word is overused. "integer constant" and "integer constant expression" I think in the post you are referring to I described a different thing; I spoke about a constant literal. And the (IMO unnecessary) dispute had been about "literal" not about "constant". - And we heard that "literal" is even the new term used in the (draft) C-standard! > [snip digressions about "integer constant" and "constant expressions"] > [snip more digressions on early C-"constants"] > [...] C++ has called 123 > an "integer literal" for ages, and it makes sense for C to follow suit. Yes, and I agree with that choice. (I'm using the word "literal" for all programming languages if I want to talk about literals.) > > I doubt if this is the start of a habit or pattern, however. I think it's pointless to make guesses. (I'm certainly continuing to use those terms that I think are best fitting. And if you (or others) have problems understanding them I'm gladly explaining them, as said. Especially since I think the time spent on an explanation of a good term is much better spent than the time wasted for a discussion like the one you restarted here yet another time.) Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-30 15:25 +0100 |
| Message-ID | <11c29cu$alhk$1@dont-email.me> |
| In reply to | #403836 |
On 30/10/2026 14:54, Janis Papanagnou wrote: > On 2026-10-30 09:11, David Brown wrote: >> On 30/10/2026 04:38, Janis Papanagnou wrote: >>> On 2026-10-30 00:56, Keith Thompson wrote: >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>>> 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. >>>> >>>> For now. In the latest C2y draft, they're called literals. >>>> >>>> Proposal: https://www.open-std.org/jtc1/sc22/wg14/www/docs/ >>>> n3189.htm >>>> Draft standard: https://www.open-std.org/jtc1/sc22/wg14/www/docs/ >>>> n3998.pdf >>>> >>>> (You've said before that you dislike this change.) >>>> >>>> In any case, the term "literal" is unambiguous, even if it's not >>>> currently used by the C standard. >>> >>> Thanks for answering him. (As I'm yet again ignoring him I wouldn't >>> have noticed his statement.) >>> >>> For other readers I remind that I'm not necessarily using C-standard >>> terms if there's terms common in CS existing that either appear more >>> appropriately describing things, or if I'm generalizing facts beyond >>> "C". >> >> The preference should be to use the C standard terms in this group - or > > Like there's no CLC coding style (as recently demanded and rebutted) Agreed. > it's also, IMO, presumptuous to demand posters to use terms defined > in the C-standards documents. "Demand" is far too strong a word. It is not presumptuous or onerous to /prefer/ standard terms for a given language in a language-specific Usenet group. Discussing what is and is not supported and required by the C standards is par for the course in comp.lang.c, and understanding the standard terms is an important part of that. We don't need to be obsessive about it unless it is an important detail of the issue being discussed, as long things are clear enough. > Moreover, as I recently learned, even > the standard-C documents seem to adjust their terminology. This has happened /once/, in the space of about 40 years. It's not as if they change terms on a regular basis! > > As I explained already, I'm using the terms that appear to me to be > most appropriate to describe things. In cases where there's multiple > options I'm gladly using the terms preferred in the C-standard docs, > given that I know them. Fair enough. The important thing, as I see it, is that people in a discussion know what each other is talking about. > > I certainly consider it presumptuous to demand from posters to read > (all or every new version of) the C-standard to talk about "C". I would certainly agree on that, and I don't think anyone has made such demands. > >> to add brief comments for clarity. (Sometimes it is also worth adding >> comments for clarity even when using C standard terms.) The C >> standard uses terms like "object" and "byte" in a way that is unusual >> in the wider scope of computer science. But sometimes computer >> science courses use different terms, as do different programming >> languages and different parts of the world, and things change over >> time - often there is no single "standard CS" term, and often there is >> no fixed definition of a term commonly used in computer science. > > That's all correct. > > As I mentioned elsewhere already - I think also in a reply to a post > of yours, about the same topic - I'm gladly explaining (if necessary) > not only every word in my posts that are unclear to you but also the > implied semantics if necessary. You tend to write very clearly - it's a rarity that your posts are misunderstood, I think. > > (Mind that, as opposed to you and some others, while you may do that, > I'm *not* discussing the _C-standard_ here. You should make yourself > clear that there's a difference between talking about all aspects of > the language or exchange specifically about the formal aspects of "C". > What makes perfectly sense for the former group is, to say the least, > arguable for the general, non-specialized disputants.) It is certainly the case that there are times when detailed consideration of the exact language and terms of the standards are important to the discussion, and plenty of times when they are not. I have nothing against loser language when loser language is easier to use for the point at hand. > >> Many of the terms used in the C standard have the strong advantage of >> having specific definitions given in the standard itself. > > Fine. > >> >> If in doubt, being a little extra explicit is better than being >> misunderstood! > > No doubt. > >> >> In the particular case of "constant", I think the root issue is that >> the word is overused. "integer constant" and "integer constant >> expression" > > I think in the post you are referring to I described a different thing; > I spoke about a constant literal. And the (IMO unnecessary) dispute had > been about "literal" not about "constant". - And we heard that "literal" > is even the new term used in the (draft) C-standard! > I am not sure if I was referring to a particular post - and I am not sure if there was a "dispute" at all (unless you count Tim's post). It's okay for someone to comment on the term used in the C standard without it implying that your post was wrong to use a different term. In this particular case, I personally prefer "literal" to "constant". It's the term used in the C2y draft, it is also used in the C++ standards, and consistent with current C standards use of "string literals" and "compound literals". But it can also be useful for people to know that "integer constant" is the term for 123 in current C, not "integer literal". One use of that knowledge is if people want to look up more information on quality reference sites (like cppreference.com) or in the standards themselves - it's easier if you know the standard terms. If you want to know the exact rules for "integer constants", and try to search the standards for "integer literal", you'll find no hits except, bizarrely, a mention of "binary integer literals" in the list of changes to standards versions. >> [snip digressions about "integer constant" and "constant expressions"] >> [snip more digressions on early C-"constants"] > >> [...] C++ has called 123 an "integer literal" for ages, and it makes >> sense for C to follow suit. > > Yes, and I agree with that choice. (I'm using the word "literal" for all > programming languages if I want to talk about literals.) > >> >> I doubt if this is the start of a habit or pattern, however. > > I think it's pointless to make guesses. (I'm certainly continuing to > use those terms that I think are best fitting. And if you (or others) > have problems understanding them I'm gladly explaining them, as said. > Especially since I think the time spent on an explanation of a good > term is much better spent than the time wasted for a discussion like > the one you restarted here yet another time.) > > Janis >
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-30 14:45 +0000 |
| Message-ID | <11c2ahf$b2m$1@reader2.panix.com> |
| In reply to | #403838 |
In article <11c29cu$alhk$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 30/10/2026 14:54, Janis Papanagnou wrote: >> [snip] >> it's also, IMO, presumptuous to demand posters to use terms defined >> in the C-standards documents. > >"Demand" is far too strong a word. It is not presumptuous or onerous to >/prefer/ standard terms for a given language in a language-specific >Usenet group. Discussing what is and is not supported and required by >the C standards is par for the course in comp.lang.c, and understanding >the standard terms is an important part of that. We don't need to be >obsessive about it unless it is an important detail of the issue being >discussed, as long things are clear enough. I agree with both of you: mutual understanding should be the goal, and while a preference for the language used in the standard is certainly fine, there are unfortunately several examples around here of the type of person who favors pedantic attention to detail over that kind understanding. My own view is that this is not useful, and actively harmful. It certainly does not paint those posters in a positive light, as they appear to be more concerned with the minutia of the standard's phrasing than they are with its content, and are wholy unconcerned with usefully conveying anything of substance to a reader. Fixation on minor details feels like an excuse to find fault with a poster, then used to refrain from deeper engagement with whatever point they are raising, even if it is well considered and thoughtful. That's not holding conversation to a standard of quality; it is simplistic and reductive. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-30 12:02 -0700 |
| Message-ID | <11c2pk9$gqls$1@kst.eternal-september.org> |
| In reply to | #403838 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> It is certainly the case that there are times when detailed
> consideration of the exact language and terms of the standards are
> important to the discussion, and plenty of times when they are not. I
> have nothing against loser language when loser language is easier to
> use for the point at hand.
[...]
That sounded a lot harsher than you intended until I realized you had
misspelled "looser".
--
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-30 21:01 +0100 |
| Message-ID | <11c2t3m$id3b$1@dont-email.me> |
| In reply to | #403848 |
On 30/10/2026 20:02, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> It is certainly the case that there are times when detailed >> consideration of the exact language and terms of the standards are >> important to the discussion, and plenty of times when they are not. I >> have nothing against loser language when loser language is easier to >> use for the point at hand. > [...] > > That sounded a lot harsher than you intended until I realized you had > misspelled "looser". > Oops - yes, it was a misspelling. Thanks for catching it, as I agree it sounded really bad! (My apologies to Janis if he felt I was somehow insulting him - it was not at all intentional.) Little red wiggles under misspelt words are great in general, but don't help much when the misspelling is also a valid word.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-10-27 21:41 -0400 |
| Message-ID | <11brjrn$21vfh$1@dont-email.me> |
| In reply to | #403671 |
On 2026-10-27 20:49, Lawrence D’Oliveiro wrote: > 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. I've used systems where float was significantly faster than double, I wouldn't be surprised if someone claimed that this no longer the case on any modern machine, but I would be surprised if they had done a sufficiently careful search to justify being certain about that. I've seen applications where the lower precision of float was acceptable, and the extra speed of float was essential to meeting speed requirements.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-28 08:45 +0100 |
| Message-ID | <11bs97j$26dq0$2@dont-email.me> |
| In reply to | #403673 |
On 28/10/2026 02:41, James Kuyper wrote: > On 2026-10-27 20:49, Lawrence D’Oliveiro wrote: >> 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. > > I've used systems where float was significantly faster than double, I > wouldn't be surprised if someone claimed that this no longer the case on > any modern machine, but I would be surprised if they had done a > sufficiently careful search to justify being certain about that. > If they were certain about it, then they certainly would not have done a careful enough search. > I've seen applications where the lower precision of float was > acceptable, and the extra speed of float was essential to meeting speed > requirements. People use 16-bit and 8-bit floating point formats too. I expect that these days, most floating point calculations executed across the world are 8 bit. Once you have enough precision that your calculations are accurate enough for your required application, there's little point in using bigger formats - especially if speed is relevant.
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2026-10-28 01:50 +0000 |
| Message-ID | <11brkco$21oj5$1@dont-email.me> |
| In reply to | #403671 |
On Wed, 28 Oct 2026 00:49:19 -0000 (UTC), Lawrence D’Oliveiro wrote:
> 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.
% cat j8.c
float
foo(int n, float *x)
{
float s = 0;
for (int i = 0; i < n; ++i) {
s += x[i] * 0.1;
}
return (s);
}
% cc -o z.s -O3 -S j8.c && grep cvts z.s
cvtss2sd %xmm2, %xmm2
cvtss2sd %xmm0, %xmm0
cvtsd2ss %xmm2, %xmm0
cvtss2sd %xmm3, %xmm2
cvtss2sd %xmm0, %xmm0
cvtsd2ss %xmm2, %xmm0
cvtss2sd %xmm0, %xmm1
cvtss2sd %xmm0, %xmm0
cvtsd2ss %xmm0, %xmm0
That's a lot of useless conversion if 0.1f would have been
good enough. Change 0.1 to 0.1f in the above code.
% cc -o z.s -O3 -S j8.c && grep cvts z.s | wc -l
0
HTH
--
steve
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-10-28 07:32 +0100 |
| Message-ID | <11bs4tj$26daj$1@dont-email.me> |
| In reply to | #403674 |
Steven G. Kargl pisze:
> On Wed, 28 Oct 2026 00:49:19 -0000 (UTC), Lawrence D’Oliveiro wrote:
>
>> 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.
>
> % cat j8.c
> float
> foo(int n, float *x)
> {
> float s = 0;
> for (int i = 0; i < n; ++i) {
> s += x[i] * 0.1;
> }
> return (s);
> }
>
> % cc -o z.s -O3 -S j8.c && grep cvts z.s
> cvtss2sd %xmm2, %xmm2
> cvtss2sd %xmm0, %xmm0
> cvtsd2ss %xmm2, %xmm0
> cvtss2sd %xmm3, %xmm2
> cvtss2sd %xmm0, %xmm0
> cvtsd2ss %xmm2, %xmm0
> cvtss2sd %xmm0, %xmm1
> cvtss2sd %xmm0, %xmm0
> cvtsd2ss %xmm0, %xmm0
>
> That's a lot of useless conversion if 0.1f would have been
> good enough. Change 0.1 to 0.1f in the above code.
>
> % cc -o z.s -O3 -S j8.c && grep cvts z.s | wc -l
> 0
>
> HTH
>
if so its totally terrible, i was kinda not aware of that
i would say its wrong and stupid probably becouse in float computations
such numbers should be floats imo in doubles it should be doubles
i should run my own test but im too exhausted
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-10-28 07:51 +0100 |
| Message-ID | <11bs613$26knh$1@dont-email.me> |
| In reply to | #403691 |
fir pisze:
> Steven G. Kargl pisze:
>> On Wed, 28 Oct 2026 00:49:19 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>
>>> 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.
>>
>> % cat j8.c
>> float
>> foo(int n, float *x)
>> {
>> float s = 0;
>> for (int i = 0; i < n; ++i) {
>> s += x[i] * 0.1;
>> }
>> return (s);
>> }
>>
>> % cc -o z.s -O3 -S j8.c && grep cvts z.s
>> cvtss2sd %xmm2, %xmm2
>> cvtss2sd %xmm0, %xmm0
>> cvtsd2ss %xmm2, %xmm0
>> cvtss2sd %xmm3, %xmm2
>> cvtss2sd %xmm0, %xmm0
>> cvtsd2ss %xmm2, %xmm0
>> cvtss2sd %xmm0, %xmm1
>> cvtss2sd %xmm0, %xmm0
>> cvtsd2ss %xmm0, %xmm0
>>
>> That's a lot of useless conversion if 0.1f would have been
>> good enough. Change 0.1 to 0.1f in the above code.
>>
>> % cc -o z.s -O3 -S j8.c && grep cvts z.s | wc -l
>> 0
>>
>> HTH
>>
>
> if so its totally terrible, i was kinda not aware of that
>
>
> i would say its wrong and stupid probably becouse in float computations
> such numbers should be floats imo in doubles it should be doubles
>
>
> i should run my own test but im too exhausted
>
maybe no wonder i was not aware of this if this is so stupid it no come
to my mind
(should i also write 0.0f insetad of 0 BTW?)
as to optimistation there is probably a flag wjich turns it off 0 i mean
replace .1 as doube as .1 as floats when it can help to remove this
conversions
but im not sure which one in gcc probably -ffast-math
but i not tested/talked yet
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-10-28 07:55 +0100 |
| Message-ID | <11bs68h$26knh$2@dont-email.me> |
| In reply to | #403692 |
fir pisze:
> fir pisze:
>> Steven G. Kargl pisze:
>>> On Wed, 28 Oct 2026 00:49:19 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>>
>>>> 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.
>>>
>>> % cat j8.c
>>> float
>>> foo(int n, float *x)
>>> {
>>> float s = 0;
>>> for (int i = 0; i < n; ++i) {
>>> s += x[i] * 0.1;
>>> }
>>> return (s);
>>> }
>>>
>>> % cc -o z.s -O3 -S j8.c && grep cvts z.s
>>> cvtss2sd %xmm2, %xmm2
>>> cvtss2sd %xmm0, %xmm0
>>> cvtsd2ss %xmm2, %xmm0
>>> cvtss2sd %xmm3, %xmm2
>>> cvtss2sd %xmm0, %xmm0
>>> cvtsd2ss %xmm2, %xmm0
>>> cvtss2sd %xmm0, %xmm1
>>> cvtss2sd %xmm0, %xmm0
>>> cvtsd2ss %xmm0, %xmm0
>>>
>>> That's a lot of useless conversion if 0.1f would have been
>>> good enough. Change 0.1 to 0.1f in the above code.
>>>
>>> % cc -o z.s -O3 -S j8.c && grep cvts z.s | wc -l
>>> 0
>>>
>>> HTH
>>>
>>
>> if so its totally terrible, i was kinda not aware of that
>>
>>
>> i would say its wrong and stupid probably becouse in float
>> computations such numbers should be floats imo in doubles it should be
>> doubles
>>
>>
>> i should run my own test but im too exhausted
>>
> maybe no wonder i was not aware of this if this is so stupid it no come
> to my mind
> (should i also write 0.0f insetad of 0 BTW?)
>
> as to optimistation there is probably a flag wjich turns it off 0 i mean
> replace .1 as doube as .1 as floats when it can help to remove this
> conversions
>
> but im not sure which one in gcc probably -ffast-math
>
> but i not tested/talked yet
ai says even fast math not enebles that but there is a flag
-fsingle-precision-constant.
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2026-10-28 16:27 +0000 |
| Message-ID | <11bt7p9$2i0ag$2@dont-email.me> |
| In reply to | #403693 |
On Wed, 28 Oct 2026 07:55:11 +0100, fir wrote:
>> but i not tested/talked yet
> ai says even fast math not enebles that but there is a flag
>
>
> -fsingle-precision-constant.
It is a poor decision to depend on any specific compiler's
options unless you intend to never use any other compiler.
With clang, I see
% cc -o z.s -S -O3 -fsingle-precision-constant j8.c
cc: warning: optimization flag '-fsingle-precision-constant' is not
supported [-Wignored-optimization-argument]
HTH
--
steve
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-28 17:44 +0100 |
| Message-ID | <11bt8ph$2jb4n$1@dont-email.me> |
| In reply to | #403726 |
On 28/10/2026 17:27, Steven G. Kargl wrote: > On Wed, 28 Oct 2026 07:55:11 +0100, fir wrote: > > >>> but i not tested/talked yet >> ai says even fast math not enebles that but there is a flag >> >> >> -fsingle-precision-constant. > > It is a poor decision to depend on any specific compiler's > options unless you intend to never use any other compiler. It is fine to do so in non-portable code. Most of my work is specifically targeting gcc, and if the code is better (clearer, safer to maintain, more efficient) as a result of compiler-specific flags or compiler-specific extensions, that's fine. Of course, if the same results can be achieved without non-portable flags or extensions, that is better. The key use of flags like this is for microcontrollers with hardware support for single-precision floating point, but not for double precision - which then needs to be handled by software routines. The use of "-fsingle-precision-constant" is primarily for handling third-party code or other code that you don't want to change, but where you want to use single precision as much as possible. For your own code on such devices, you would use "f" suffixes. The "-Wdouble-promotion" flag is also very useful here - it will let you know if you have accidentally promoted a float (such as by using a double-precision constant in an expression).
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2026-10-28 16:22 +0000 |
| Message-ID | <11bt7ff$2i0ag$1@dont-email.me> |
| In reply to | #403692 |
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]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-10-28 19:15 +0100 |
| Message-ID | <11bte4h$2lmho$1@dont-email.me> |
| In reply to | #403724 |
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]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-10-28 19:47 +0100 |
| Message-ID | <11btg0s$2mjpd$1@dont-email.me> |
| In reply to | #403730 |
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]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web