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 | 16 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 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2026-10-28 22:33 +0000 |
| Message-ID | <11btt7k$2rple$1@dont-email.me> |
| In reply to | #403752 |
On 28/10/2026 22:12, Michael S wrote:
> On Wed, 28 Oct 2026 14:26:05 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 28/10/2026 01: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.
>>>
>>> Try thinking harder.
>>>
>>> I use the "f" suffix all the time in my code, because I do not want
>>> double precision. In many situations, single precision arithmetic
>>> is at least twice as fast as double precision - in some situations
>>> it can be two orders of magnitude faster.
>>
>> If you define objects as type float rather than double, do you have
>> examples of code where using 0.1f rather than 0.1 makes a difference?
>>
>> One simple example: These two declarations result in identical code
>> using gcc:
>>
>> float f = 0.1f;
>> float f = 0.1;
>>
>
> David almost certainly was talking about use of 0.1f in arithmetic
> expressions rather than in simple initialization.
>
>
Yeah, intermediate calculations using 64 bits can give a different and
more precise result even after it has been converted to 32 bits.
For example this:
#include <stdio.h>
int main(void) {
float a = 0.1f * 0.1f;
float b = 0.1 * 0.1;
printf("%20.20f\n", a);
printf("%20.20f\n", b);
printf("%20.20f\n", 1 - a * 100);
printf("%20.20f\n", 1 - b * 100);
}
Displays:
0.01000000070780515671
0.00999999977648258209
-0.00000011920928955078
0.00000000000000000000
on gcc 9.x on x64.
It will need the compiler to do the reduction, but DB is likely using a
cross-compiler so it is not being done within target device,
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-29 11:01 +0100 |
| Message-ID | <11bv5ij$37mbb$2@dont-email.me> |
| In reply to | #403755 |
On 28/10/2026 23:33, bartc wrote:
> On 28/10/2026 22:12, Michael S wrote:
>> On Wed, 28 Oct 2026 14:26:05 -0700
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 28/10/2026 01: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.
>>>>
>>>> Try thinking harder.
>>>>
>>>> I use the "f" suffix all the time in my code, because I do not want
>>>> double precision. In many situations, single precision arithmetic
>>>> is at least twice as fast as double precision - in some situations
>>>> it can be two orders of magnitude faster.
>>>
>>> If you define objects as type float rather than double, do you have
>>> examples of code where using 0.1f rather than 0.1 makes a difference?
>>>
>>> One simple example: These two declarations result in identical code
>>> using gcc:
>>>
>>> float f = 0.1f;
>>> float f = 0.1;
>>>
>>
>> David almost certainly was talking about use of 0.1f in arithmetic
>> expressions rather than in simple initialization.
>>
>>
>
> Yeah, intermediate calculations using 64 bits can give a different and
> more precise result even after it has been converted to 32 bits.
>
> For example this:
>
> #include <stdio.h>
>
> int main(void) {
> float a = 0.1f * 0.1f;
> float b = 0.1 * 0.1;
>
> printf("%20.20f\n", a);
> printf("%20.20f\n", b);
> printf("%20.20f\n", 1 - a * 100);
> printf("%20.20f\n", 1 - b * 100);
> }
>
>
> Displays:
>
> 0.01000000070780515671
> 0.00999999977648258209
> -0.00000011920928955078
> 0.00000000000000000000
>
> on gcc 9.x on x64.
>
> It will need the compiler to do the reduction, but DB is likely using a
> cross-compiler so it is not being done within target device,
Generally, yes. (Though for this code, the compiler would pre-calculate
the results at compile time.) My calculations need to be as precise as
required for their use - but anything beyond that is just a waste. And
if the microcontroller has hardware single-precision floating point but
no double-precision, that wasted runtime is massive.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-28 16:05 -0700 |
| Message-ID | <11btv32$2rgo2$1@kst.eternal-september.org> |
| In reply to | #403752 |
Michael S <already5chosen@yahoo.com> writes:
> On Wed, 28 Oct 2026 14:26:05 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> David Brown <david.brown@hesbynett.no> writes:
[...]
>> > I use the "f" suffix all the time in my code, because I do not want
>> > double precision. In many situations, single precision arithmetic
>> > is at least twice as fast as double precision - in some situations
>> > it can be two orders of magnitude faster.
>>
>> If you define objects as type float rather than double, do you have
>> examples of code where using 0.1f rather than 0.1 makes a difference?
>>
>> One simple example: These two declarations result in identical code
>> using gcc:
>>
>> float f = 0.1f;
>> float f = 0.1;
>
> David almost certainly was talking about use of 0.1f in arithmetic
> expressions rather than in simple initialization.
Agreed -- and I asked him for examples. (And no, didn't mean to
suggest that there are no such examples.)
And now that I've thought about it a bit more, here's a possible
example:
float f = rand(); // prevent optimization
f *= 0.1;
// f *= 0.1f;
With 0.1, f is promoted to double before being multiplied by 0.1, and
the result is converted to float. With 0.1f, double is not involved.
And in the generated x86_64 assembly from gcc, I see cvtss2sd and
cvtsd2ss when I use 0.1 that don't appear when I use 0.1f.
Both expressions *might* yield the same result (and do in the small
handful of cases I've checked), but it would take more analysis
than I'm willing to perform to prove it in all cases.
I was too quick to assume that if a compiler sees 0.1 in an expression
involving float operands, it can safely treat it as 0.1f. Since 0.1
causes the usual arithmetic conversions to convert the other operand
from float to double, I was very probably wrong.
I can still imagine a compiler optimizing `f *= 0.1;` to use
float arithmetic. I wonder if there are more clear-cut examples.
I'm assuming that FLT_EVAL_METHOD==0, meaning that float expressions
are evaluated as float. If FLT_EVAL_METHOD==1, float expressions
are evaluated to the range and precision of type double.
--
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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-30 11:58 +0200 |
| Message-ID | <20261030115805.0000644a@yahoo.com> |
| In reply to | #403757 |
On Wed, 28 Oct 2026 16:05:06 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > On Wed, 28 Oct 2026 14:26:05 -0700 > > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> David Brown <david.brown@hesbynett.no> writes: > [...] > >> > I use the "f" suffix all the time in my code, because I do not > >> > want double precision. In many situations, single precision > >> > arithmetic is at least twice as fast as double precision - in > >> > some situations it can be two orders of magnitude faster. > >> > >> If you define objects as type float rather than double, do you have > >> examples of code where using 0.1f rather than 0.1 makes a > >> difference? > >> > >> One simple example: These two declarations result in identical code > >> using gcc: > >> > >> float f = 0.1f; > >> float f = 0.1; > > > > David almost certainly was talking about use of 0.1f in arithmetic > > expressions rather than in simple initialization. > > Agreed -- and I asked him for examples. (And no, didn't mean to > suggest that there are no such examples.) > > And now that I've thought about it a bit more, here's a possible > example: > > float f = rand(); // prevent optimization > f *= 0.1; > // f *= 0.1f; > > With 0.1, f is promoted to double before being multiplied by 0.1, and > the result is converted to float. With 0.1f, double is not involved. > And in the generated x86_64 assembly from gcc, I see cvtss2sd and > cvtsd2ss when I use 0.1 that don't appear when I use 0.1f. > > Both expressions *might* yield the same result (and do in the small > handful of cases I've checked), but it would take more analysis > than I'm willing to perform to prove it in all cases. > Since we're talking about single precision, analysis is not necessary. Any hypothesis can be easily tested by exhausting. In case of (float)(f * 0.1) == f * 0.1f, it fails for almost exactly one fifth of the numbers, including 1.00000011920928955f - the next float after 1.0f. > I was too quick to assume that if a compiler sees 0.1 in an expression > involving float operands, it can safely treat it as 0.1f. Since 0.1 > causes the usual arithmetic conversions to convert the other operand > from float to double, I was very probably wrong. > > I can still imagine a compiler optimizing `f *= 0.1;` to use > float arithmetic. I wonder if there are more clear-cut examples. > I don't know what exactly is allowed by the Standard (that is, I know what's written, I don't know how peoples with lowyers attitude can interpret it), but will be extremely surprised if any "major" compiler is doing such optimization on IEEE-754 compliant platform in absence of non-compliance flags like fast-math. > I'm assuming that FLT_EVAL_METHOD==0, meaning that float expressions > are evaluated as float. If FLT_EVAL_METHOD==1, float expressions > are evaluated to the range and precision of type double. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-29 10:59 +0100 |
| Message-ID | <11bv5dt$37mbb$1@dont-email.me> |
| In reply to | #403752 |
On 28/10/2026 23:12, Michael S wrote: > On Wed, 28 Oct 2026 14:26:05 -0700 > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> David Brown <david.brown@hesbynett.no> writes: >>> On 28/10/2026 01: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. >>> >>> Try thinking harder. >>> >>> I use the "f" suffix all the time in my code, because I do not want >>> double precision. In many situations, single precision arithmetic >>> is at least twice as fast as double precision - in some situations >>> it can be two orders of magnitude faster. >> >> If you define objects as type float rather than double, do you have >> examples of code where using 0.1f rather than 0.1 makes a difference? >> >> One simple example: These two declarations result in identical code >> using gcc: >> >> float f = 0.1f; >> float f = 0.1; >> > > David almost certainly was talking about use of 0.1f in arithmetic > expressions rather than in simple initialization. > Yes, that is the most relevant usage. But I would not write "float f = 0.1;" either. "float f = 0.1f;" is more explicit, and it would not risk accidentally triggering any static analysis (or human analysis) that checks for unintended use of doubles. (gcc's "-Wdouble-promotion" does not trigger on "float f = 0.1;", but other tools might.)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-28 14:34 -0700 |
| Message-ID | <11btppc$2qhsd$1@dont-email.me> |
| In reply to | #403696 |
On 10/28/2026 12:39 AM, David Brown wrote: > On 28/10/2026 01: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. > > Try thinking harder. > > I use the "f" suffix all the time in my code, because I do not want > double precision. In many situations, single precision arithmetic is at > least twice as fast as double precision - in some situations it can be > two orders of magnitude faster. > > Same here. I am mostly creating graphics related things. double precision in a GPU might not be there. Now, if I am doing something that needs higher precision, tends to be with deep zooms or granularity in a vector field, then double is okay. But I need to beware that the shaders might not support double.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-29 11:06 +0100 |
| Message-ID | <11bv5rl$37s52$1@dont-email.me> |
| In reply to | #403744 |
On 28/10/2026 22:34, Chris M. Thomasson wrote: > On 10/28/2026 12:39 AM, David Brown wrote: >> On 28/10/2026 01: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. >> >> Try thinking harder. >> >> I use the "f" suffix all the time in my code, because I do not want >> double precision. In many situations, single precision arithmetic is >> at least twice as fast as double precision - in some situations it can >> be two orders of magnitude faster. >> >> > > Same here. I am mostly creating graphics related things. double > precision in a GPU might not be there. Now, if I am doing something that > needs higher precision, tends to be with deep zooms or granularity in a > vector field, then double is okay. But I need to beware that the shaders > might not support double. You can also see it in SIMD. A 128-bit SIMD register might be useable for 4 single-precision values and parallel operations, while only 2 can be handled for double-precision. Obviously details will vary by SIMD implementation, but singles are going to be at least twice as fast in general.
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2026-10-28 15:08 +0100 |
| Message-ID | <11bsvlm$2jn3$1@news.gegeweb.eu> |
| In reply to | #403671 |
On 10/28/26 01: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.
Explicit is better than implicit ?
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-28 07:49 -0700 |
| Message-ID | <86pkwtnamg.fsf@linuxsc.com> |
| In reply to | #403712 |
tTh <tth@none.invalid> writes: > On 10/28/26 01: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. > > Explicit is better than implicit ? Not always, but in this case there is no "implicit" way. If a floating-point constant has an "f" suffix it's of type float, and if it doesn't it's of type double. Having a suffix necessarily changes the meaning.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-28 14:36 -0700 |
| Message-ID | <11btptm$2qhsd$2@dont-email.me> |
| In reply to | #403671 |
On 10/27/2026 5:49 PM, 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. Well, say you want the result from a frag shader to be pixel perfect to a CPU version of it. Using double on the CPU can cause a headache.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-27 15:53 -0700 |
| Message-ID | <11bra0u$1uh9q$2@kst.eternal-september.org> |
| In reply to | #403660 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> 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".
I think you gave the wrong subsection number, and you didn't specify
which version of the standard you're quoting from. 6.5.4.3 is
"Unary arithmetic operators" in the current standard, though it
may be different in different editions. The wording you quoted
is from 6.4.4.3p4 in N3220 (C23).
(I'd like the C standard to adopt named subsections, as used in
the C++ standard.)
[...]
> 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.
Using 0.1 in a context where it will be converted to float is likely
to be harmless. Converting 0.1 to float is likely to yield the same
value as 0.1f. That's probably not guaranteed, but if there is a
difference it's probably insignificant.
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-10-27 21:55 -0400 |
| Message-ID | <11brkmg$22567$1@dont-email.me> |
| In reply to | #403667 |
On 2026-10-27 18:53, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > [...] >> 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". > > I think you gave the wrong subsection number, ... Yes, that should have been 6.4.5.3p4. > ... and you didn't specify > which version of the standard you're quoting from. The latest working draft I have access to, n3685.pdf, C202y. It refers to C23, and to dates as late as August 2025, using the past tense. ...>> 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. > > Using 0.1 in a context where it will be converted to float is likely > to be harmless. Converting 0.1 to float is likely to yield the same > value as 0.1f. That's probably not guaranteed, but if there is a > difference it's probably insignificant. Using 0.1f because you don't realize that you actually need double precision could be problematic. This thread was started by fir - I wouldn't rule out such a possibility.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-27 19:02 -0700 |
| Message-ID | <11brl35$1uh9q$5@kst.eternal-september.org> |
| In reply to | #403675 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2026-10-27 18:53, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> [...]
>>> 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".
>>
>> I think you gave the wrong subsection number, ...
> Yes, that should have been 6.4.5.3p4.
>
>> ... and you didn't specify
>> which version of the standard you're quoting from.
>
> The latest working draft I have access to, n3685.pdf, C202y. It refers
> to C23, and to dates as late as August 2025, using the past tense.
The draft closest to the C23 standard is N3220.
The latest C2y draft is N3998, just released a few days ago.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3998.pdf
[...]
>> Using 0.1 in a context where it will be converted to float is likely
>> to be harmless. Converting 0.1 to float is likely to yield the same
>> value as 0.1f. That's probably not guaranteed, but if there is a
>> difference it's probably insignificant.
>
> Using 0.1f because you don't realize that you actually need double
> precision could be problematic. This thread was started by fir - I
> wouldn't rule out such a possibility.
Sure -- but I did specify "where it will be converted to 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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-28 08:56 +0100 |
| Message-ID | <11bs9qs$26dq0$3@dont-email.me> |
| In reply to | #403667 |
On 27/10/2026 23:53, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > [...] >> 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". > > I think you gave the wrong subsection number, and you didn't specify > which version of the standard you're quoting from. 6.5.4.3 is > "Unary arithmetic operators" in the current standard, though it > may be different in different editions. The wording you quoted > is from 6.4.4.3p4 in N3220 (C23). > > (I'd like the C standard to adopt named subsections, as used in > the C++ standard.) > Section numbering in the C standards was fine until C23 - from C90 to C17, almost all changes added new numbered sections without changing the existing ones. But C23 had too many changes, and some things were renumbered. So I /was/ happy with numbered, rather than named, sections. Going forward, however, I agree with you - named subsections seem the best choice for consistent references.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-28 08:01 -0700 |
| Message-ID | <86ld7hna2x.fsf@linuxsc.com> |
| In reply to | #403660 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > 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". Yes, except implementations are allowed to represent floating-point constants using a greater range and precision than the nominal type would imply. So 0.1 and 0.1f could have the same value.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-27 13:08 -0700 |
| Message-ID | <11br0b1$1r6p7$1@dont-email.me> |
| In reply to | #403612 |
On 10/27/2026 3:53 AM, 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 Why not ask the ai, again... ;^) 0.1f == .1f
[toc] | [prev] | [standalone]
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
Back to top | Article view | comp.lang.c
csiph-web