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
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
if ai generates me some functions it puts everywhere this f at the and
yet it add zeros so instead of .1 i got 0.1f
and i obviously dont like it
i write hvever some codes when i need speed so the question is may it
give some difference?
i mean .1 maybe can be treated as doube constants so mabe occupies some
more memory (?) or uses some casting in coplutations (?)
i doubt it probably it makes difference but im strictly not sure
The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes
code easier to read. The difference between 0.1 and 0.1f with
their binary representations is a another matter.
#include <stdio.h>
int
main(void)
{
double d;
d = 0.1f;
printf("%.13a\n", d);
d = 0.1;
printf("%.13a\n", d);
return (0);
}
% cc -o z t.c && ./z
0x1.99999a0000000p-4
0x1.999999999999ap-4
The real number is 0.1 is not exactly representable in a binary
floating point format. See
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
if ai generates me some functions it puts everywhere this f at the and
yet it add zeros so instead of .1 i got 0.1f
and i obviously dont like it
i write hvever some codes when i need speed so the question is may it
give some difference?
i mean .1 maybe can be treated as doube constants so mabe occupies some
more memory (?) or uses some casting in coplutations (?)
i doubt it probably it makes difference but im strictly not sure
The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes
code easier to read. The difference between 0.1 and 0.1f with
their binary representations is a another matter.
#include <stdio.h>
int
main(void)
{
double d;
d = 0.1f;
printf("%.13a\n", d);
d = 0.1;
printf("%.13a\n", d);
return (0);
}
% cc -o z t.c && ./z
0x1.99999a0000000p-4
0x1.999999999999ap-4
The real number is 0.1 is not exactly representable in a binary
floating point format. See
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
Steven G. Kargl pisze:^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
if ai generates me some functions it puts everywhere this f at the and
yet it add zeros so instead of .1 i got 0.1f
and i obviously dont like it
i write hvever some codes when i need speed so the question is may it
give some difference?
i mean .1 maybe can be treated as doube constants so mabe occupies
some more memory (?) or uses some casting in coplutations (?)
i doubt it probably it makes difference but im strictly not sure
The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes code
easier to read. The difference between 0.1 and 0.1f with their binary
representations is a another matter.
#include <stdio.h>
int main(void)
{
double d;
d = 0.1f; printf("%.13a\n", d);
d = 0.1; printf("%.13a\n", d);
return (0);
}
% cc -o z t.c && ./z 0x1.99999a0000000p-4 0x1.999999999999ap-4
The real number is 0.1 is not exactly representable in a binary
floating point format. See
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
but the question is: can using .1 instead of 0.1f make me any harm in
code? like things get slower in runtime? (assuming i use floats in code
not doubles, and the code is a bit time critical like rasterisation goes
on floats) why the ai so maniacally puts that f?
On Tue, 27 Oct 2026 18:50:09 +0100, fir wrote:
Steven G. Kargl pisze:^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
if ai generates me some functions it puts everywhere this f at the and >>>> yet it add zeros so instead of .1 i got 0.1f
and i obviously dont like it
i write hvever some codes when i need speed so the question is may it
give some difference?
i mean .1 maybe can be treated as doube constants so mabe occupies
some more memory (?) or uses some casting in coplutations (?)
i doubt it probably it makes difference but im strictly not sure
The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes code
easier to read. The difference between 0.1 and 0.1f with their binary
representations is a another matter.
#include <stdio.h>
int main(void)
{
double d;
d = 0.1f; printf("%.13a\n", d);
d = 0.1; printf("%.13a\n", d);
return (0);
}
% cc -o z t.c && ./z 0x1.99999a0000000p-4 0x1.999999999999ap-4
The real number is 0.1 is not exactly representable in a binary
floating point format. See
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
Here is your answer.
but the question is: can using .1 instead of 0.1f make me any harm in
code? like things get slower in runtime? (assuming i use floats in code
not doubles, and the code is a bit time critical like rasterisation goes
on floats) why the ai so maniacally puts that f?
Without seeing code and not knowing whether you are concerned with
the propagation of floating point errors, the only answer that one can
give for your first two questions is "yes, no, maybe".
AI is likely appending the f because you instructed AI to use a
float type. Why not ask AI why it appends the f?
I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point arithmetic
for pricing.
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
if ai generates me some functions it puts everywhere this f at the
and yet it add zeros so instead of .1 i got 0.1f
and i obviously dont like it
i write hvever some codes when i need speed so the question is may
it give some difference?
i mean .1 maybe can be treated as doube constants so mabe occupies
some more memory (?) or uses some casting in coplutations (?)
i doubt it probably it makes difference but im strictly not sure
The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes
code easier to read. The difference between 0.1 and 0.1f with
their binary representations is a another matter.
#include <stdio.h>
int
main(void)
{
double d;
d = 0.1f;
printf("%.13a\n", d);
d = 0.1;
printf("%.13a\n", d);
return (0);
}
% cc -o z t.c && ./z
0x1.99999a0000000p-4
0x1.999999999999ap-4
The real number is 0.1 is not exactly representable in a binary
floating point format. See
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point arithmetic
for pricing.
Steven G. Kargl pisze:
On Tue, 27 Oct 2026 18:50:09 +0100, fir wrote:
Steven G. Kargl pisze:
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
it says: i add f that the number would be float type instead of doublebut the question is: can using .1 instead of 0.1f make me any harm in
code? like things get slower in runtime? (assuming i use floats in
code not doubles, and the code is a bit time critical like
rasterisation goes on floats) why the ai so maniacally puts that f?
Without seeing code and not knowing whether you are concerned with the
propagation of floating point errors, the only answer that one can give
for your first two questions is "yes, no, maybe".
AI is likely appending the f because you instructed AI to use a float
type. Why not ask AI why it appends the f?
float x=a*1.5;
it also says in such above case the multiplication would be in double
then converted to float - bout for me its hard to belive
% 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.
On Tue, 27 Oct 2026 18:40:52 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
if ai generates me some functions it puts everywhere this f at
the and yet it add zeros so instead of .1 i got 0.1f
and i obviously dont like it
i write hvever some codes when i need speed so the question is
may it give some difference?
i mean .1 maybe can be treated as doube constants so mabe
occupies some more memory (?) or uses some casting in
coplutations (?)
i doubt it probably it makes difference but im strictly not sure
The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes
code easier to read. The difference between 0.1 and 0.1f with
their binary representations is a another matter.
#include <stdio.h>
int
main(void)
{
double d;
d = 0.1f;
printf("%.13a\n", d);
d = 0.1;
printf("%.13a\n", d);
return (0);
}
% cc -o z t.c && ./z
0x1.99999a0000000p-4
0x1.999999999999ap-4
The real number is 0.1 is not exactly representable in a binary
floating point format. See
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point
arithmetic for pricing.
At least, unlike favorite AI of fir, Amazon was not using
single-precision.
I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point arithmetic
for pricing.
(quip)"Coding around Unicode grapheme clusters is a character-building exercise."
(quip)"defmicro: error: expansion is larger than original form: switch to defmacro."
(prinl (quip))"This could be the year of the TXR desktop; I can feel it!"
(put-line (quip))TXR kind of supports IEEE 754.00000000000003 floating-point.
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
On Tue, 27 Oct 2026 20:15:20 +0100, fir wrote:
Steven G. Kargl pisze:
On Tue, 27 Oct 2026 18:50:09 +0100, fir wrote:
Steven G. Kargl pisze:
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
(snip)
it says: i add f that the number would be float type instead of doublebut the question is: can using .1 instead of 0.1f make me any harm in
code? like things get slower in runtime? (assuming i use floats in
code not doubles, and the code is a bit time critical like
rasterisation goes on floats) why the ai so maniacally puts that f?
Without seeing code and not knowing whether you are concerned with the
propagation of floating point errors, the only answer that one can give
for your first two questions is "yes, no, maybe".
AI is likely appending the f because you instructed AI to use a float
type. Why not ask AI why it appends the f?
float x=a*1.5;
it also says in such above case the multiplication would be in double
then converted to float - bout for me its hard to belive
I do not know where to begin to address the above. Perhaps,
find a copy of K&R to read.
scott@slp53.sl.home (Scott Lurndal) writes:
I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point arithmetic
for pricing.
Send them an email saying you were overcharged and want a refund
of 0.000000000001 cents. ;)
On 10/27/2026 12:29 PM, Tim Rentsch wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
˙˙˙ Total
˙˙˙ 75.71000000000001 USD
Appears they may be using FP instead of integer fixed point arithmetic
for pricing.
Send them an email saying you were overcharged and want a refund
of 0.000000000001 cents.˙ ;)
ROFL!
On Tue, 27 Oct 2026 20:15:20 +0100, fir wrote:
Steven G. Kargl pisze:
On Tue, 27 Oct 2026 18:50:09 +0100, fir wrote:
Steven G. Kargl pisze:
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
(snip)
it says: i add f that the number would be float type instead of doublebut the question is: can using .1 instead of 0.1f make me any harm in
code? like things get slower in runtime? (assuming i use floats in
code not doubles, and the code is a bit time critical like
rasterisation goes on floats) why the ai so maniacally puts that f?
Without seeing code and not knowing whether you are concerned with the
propagation of floating point errors, the only answer that one can give
for your first two questions is "yes, no, maybe".
AI is likely appending the f because you instructed AI to use a float
type. Why not ask AI why it appends the f?
float x=a*1.5;
it also says in such above case the multiplication would be in double
then converted to float - bout for me its hard to belive
I do not know where to begin to address the above. Perhaps,
find a copy of K&R to read.
On Tue, 27 Oct 2026 21:43:42 +0200
Michael S <already5chosen@yahoo.com> wrote:
On Tue, 27 Oct 2026 18:40:52 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu>
writes:
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
if ai generates me some functions it puts everywhere this f at
the and yet it add zeros so instead of .1 i got 0.1f
and i obviously dont like it
i write hvever some codes when i need speed so the question is
may it give some difference?
i mean .1 maybe can be treated as doube constants so mabe
occupies some more memory (?) or uses some casting in
coplutations (?)
i doubt it probably it makes difference but im strictly not
sure
The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes
code easier to read. The difference between 0.1 and 0.1f with
their binary representations is a another matter.
#include <stdio.h>
int
main(void)
{
double d;
d = 0.1f;
printf("%.13a\n", d);
d = 0.1;
printf("%.13a\n", d);
return (0);
}
% cc -o z t.c && ./z
0x1.99999a0000000p-4
0x1.999999999999ap-4
The real number is 0.1 is not exactly representable in a binary >floating point format. See
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
I ordered a couple of blu-rays from amazon last week, and the confirmation email had the following for the total price:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point
arithmetic for pricing.
At least, unlike favorite AI of fir, Amazon was not using
single-precision.
BTW, 75.71000000000001 looks like 67 * 1.13 in IEEE binary64, but
rounded up rather than to nearest.
Steven G. Kargl pisze:
On Tue, 27 Oct 2026 18:50:09 +0100, fir wrote:it says: i add f that the number would be float type instead of double
Steven G. Kargl pisze:˙˙˙ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
if ai generates me some functions it puts everywhere this f at the and >>>>> yet it add zeros so instead of .1 i got 0.1f
and i obviously dont like it
i write hvever some codes when i need speed so the question is may it >>>>> give some difference?
i mean .1 maybe can be treated as doube constants so mabe occupies
some more memory (?) or uses some casting in coplutations (?)
i doubt it probably it makes difference but im strictly not sure
The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes code
easier to read.˙ The difference between 0.1 and 0.1f with their binary >>>> representations is a another matter.
#include <stdio.h>
int main(void)
{
˙˙˙˙ double d;
˙˙˙˙ d = 0.1f; printf("%.13a\n", d);
˙˙˙˙ d = 0.1; printf("%.13a\n", d);
˙˙˙˙ return (0);
}
% cc -o z t.c && ./z 0x1.99999a0000000p-4 0x1.999999999999ap-4
The real number is 0.1 is not exactly representable in a binary
floating point format.˙ See
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
˙˙˙ Here is your answer.
but the question is: can using .1 instead of 0.1f make me any harm in
code? like things get slower in runtime? (assuming i use floats in code
not doubles, and the code is a bit time critical like rasterisation goes >>> on floats)˙ why the ai so maniacally puts that f?
Without seeing code and not knowing whether you are concerned with
the propagation of floating point errors, the only answer that one can
give for your first two questions is "yes, no, maybe".
AI is likely appending the f because you instructed AI to use a
float type.˙ Why not ask AI why it appends the f?
float x=a*1.5;
it also says in such above case the multiplication would be in double
then converted to float - bout for me its hard to belive
(i some cases ai not quite tells the truth and i cant easily validate it)
it also not gives stright answe if pushed - it says more liek id depends
on flags, compiler may or may
so this is no good answer
(and i asume there may be soem simple answer here i dont know
(and i suspect its rather - no it will generate float no silly conversions
if no that would be bad)
On 2026-10-27, Scott Lurndal <scott@slp53.sl.home> wrote:
I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point arithmetic
for pricing.
That reminds of a joke I have in the TXR Lisp fortune module,
intended for displaying a random quip at REPL startup.
Oh, look, I got it after just a couple of tries:
This is the TXR Lisp interactive listener of TXR 302.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
(quip)"Coding around Unicode grapheme clusters is a character-building exercise."
(quip)"defmicro: error: expansion is larger than original form: switch to defmacro."
(prinl (quip))"This could be the year of the TXR desktop; I can feel it!"
"This could be the year of the TXR desktop; I can feel it!"
(put-line (quip))TXR kind of supports IEEE 754.00000000000003 floating-point.
t
:)
FP is fine for pricing: look at how ridiculously close to 75.71
the above approximation is. You just have to make sure never to
let enough error accumulate so that an intermediate value
is suddenly closer to the wrong penny value than the right one.
(Actually you don't even want to get anywhere near that level
of error.)
fir pisze:
Steven G. Kargl pisze:ai is besides obviously great - it just drawed me even a small cosmonaut right now
On Tue, 27 Oct 2026 18:50:09 +0100, fir wrote:it says: i add f that the number would be float type instead of double
Steven G. Kargl pisze:˙˙˙ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
if ai generates me some functions it puts everywhere this f at the >>>>>> and
yet it add zeros so instead of .1 i got 0.1f
and i obviously dont like it
i write hvever some codes when i need speed so the question is may it >>>>>> give some difference?
i mean .1 maybe can be treated as doube constants so mabe occupies >>>>>> some more memory (?) or uses some casting in coplutations (?)
i doubt it probably it makes difference but im strictly not sure
The leading zero in 0.1 or 0.1f is irrelevant, but (to me) makes code >>>>> easier to read.˙ The difference between 0.1 and 0.1f with their binary >>>>> representations is a another matter.
#include <stdio.h>
int main(void)
{
˙˙˙˙ double d;
˙˙˙˙ d = 0.1f; printf("%.13a\n", d);
˙˙˙˙ d = 0.1; printf("%.13a\n", d);
˙˙˙˙ return (0);
}
% cc -o z t.c && ./z 0x1.99999a0000000p-4 0x1.999999999999ap-4
The real number is 0.1 is not exactly representable in a binary
floating point format.˙ See
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
˙˙˙ Here is your answer.
but the question is: can using .1 instead of 0.1f make me any harm in
code? like things get slower in runtime? (assuming i use floats in code >>>> not doubles, and the code is a bit time critical like rasterisation
goes
on floats)˙ why the ai so maniacally puts that f?
Without seeing code and not knowing whether you are concerned with
the propagation of floating point errors, the only answer that one can
give for your first two questions is "yes, no, maybe".
AI is likely appending the f because you instructed AI to use a
float type.˙ Why not ask AI why it appends the f?
float x=a*1.5;
it also says in such above case the multiplication would be in double
then converted to float - bout for me its hard to belive
(i some cases ai not quite tells the truth and i cant easily validate it)
it also not gives stright answe if pushed - it says more liek id
depends on flags, compiler may or may
so this is no good answer
(and i asume there may be soem simple answer here i dont know
(and i suspect its rather - no it will generate float no silly
conversions
if no that would be bad)
https://www.youtube.com/watch?v=aZ1F4soMRHE
its code is not even longLet me ponder a guess... You have no idea how/why it works?
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:The number 0.1 cannot be represented exactly in binary.
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.
On Tue, 27 Oct 2026 20:15:20 +0100, fir wrote:
Steven G. Kargl pisze:
On Tue, 27 Oct 2026 18:50:09 +0100, fir wrote:
Steven G. Kargl pisze:
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
(snip)
it says: i add f that the number would be float type instead of doublebut the question is: can using .1 instead of 0.1f make me any harm in
code? like things get slower in runtime? (assuming i use floats in
code not doubles, and the code is a bit time critical like
rasterisation goes on floats) why the ai so maniacally puts that f?
Without seeing code and not knowing whether you are concerned with the
propagation of floating point errors, the only answer that one can give
for your first two questions is "yes, no, maybe".
AI is likely appending the f because you instructed AI to use a float
type. Why not ask AI why it appends the f?
float x=a*1.5;
it also says in such above case the multiplication would be in double
then converted to float - bout for me its hard to belive
I do not know where to begin to address the above. Perhaps,What K&R said about the matter is far less precise, and in parts,
find a copy of K&R to read.
So, 0.1 and 0.1f have different values, and might be even moredifferent
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.
On 2026-10-27 15:54, Steven G. Kargl wrote:
I do not know where to begin to address the above. Perhaps,What K&R said about the matter is far less precise, and in parts,
find a copy of K&R to read.
obsolete. in particular, float values were always automatically
converted to double for purposes of calculations.
On 2026-10-27, Scott Lurndal <scott@slp53.sl.home> wrote:
I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
FP is fine for pricing: look at how ridiculously close to 75.71
the above approximation is. You just have to make sure never to
let enough error accumulate so that an intermediate value
is suddenly closer to the wrong penny value than the right one.
(Actually you don't even want to get anywhere near that level
of error.)
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".
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.
However, if you need double precision, you shouldn't be using the
"f" suffix.
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.
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.
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.
James Kuyper <jameskuyper@alumni.caltech.edu> writes:Yes, that should have been 6.4.5.3p4.
[...]
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.
Using 0.1f because you don't realize that you actually need doubleYou 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.
On 2026-10-27 18:53, Keith Thompson wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:Yes, that should have been 6.4.5.3p4.
[...]
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.
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.
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.
but the question is: can using .1 instead of 0.1f make me any harm in code? like things get slower in runtime? (assuming i use floats in code
not doubles, and the code is a bit time critical like rasterisation goes on floats) why the ai so maniacally puts that f?
i gues the answer is NOT but maybe soem can show at least one case it could be
worse?
float x=a*1.5;
it also says in such above case the multiplication would be in double then converted to float - bout for me its hard to belive
(i some cases ai not quite tells the truth and i cant easily validate it)
it also not gives stright answe if pushed - it says more liek id depends on flags, compiler may or may
so this is no good answer
(and i asume there may be soem simple answer here i dont know
(and i suspect its rather - no it will generate float no silly conversions
if no that would be bad)
(numerator (/ 1 100)) => 1
(denominator (/ 1 100) => 100
Oh, but the ai is his nest of books. Almost like the tommyknockers from Stephen King. The residents of Haven started making things that they did not understand at all.
fir <profesor.fir@gmail.com> writes:
but the question is: can using .1 instead of 0.1f make me any harm in code? >> like things get slower in runtime? (assuming i use floats in code
not doubles, and the code is a bit time critical like rasterisation goes on >> floats) why the ai so maniacally puts that f?
dunno, the Gnu Libc has many options for floats/doubles. You can use a
prefix of `-' and such. check gnu libc manual on google.
i gues the answer is NOT but maybe soem can show at least one case it could be
worse?
12.12.10 Parsing a Template String
----------------------------------
GNU Libc --- have fun...
I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point arithmetic
for pricing.
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
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
fir pisze:ai says even fast math not enebles that but there is a flag
Steven G. Kargl pisze:maybe no wonder i was not aware of this if this is so stupid it no come
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
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
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.
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.
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.)
On 2026-10-27 15:54, Steven G. Kargl wrote:
On Tue, 27 Oct 2026 20:15:20 +0100, fir wrote:
Steven G. Kargl pisze:
On Tue, 27 Oct 2026 18:50:09 +0100, fir wrote:
Steven G. Kargl pisze:
On Tue, 27 Oct 2026 11:53:55 +0100, fir wrote:
(snip)
but the question is: can using .1 instead of 0.1f make me any
harm in code? like things get slower in runtime? (assuming i
use floats in code not doubles, and the code is a bit time
critical like rasterisation goes on floats) why the ai so
maniacally puts that f?
Without seeing code and not knowing whether you are concerned
with the propagation of floating point errors, the only answer
that one can give for your first two questions is "yes, no,
maybe".
AI is likely appending the f because you instructed AI to use a
float type. Why not ask AI why it appends the f?
it says: i add f that the number would be float type instead of
double
float x=a*1.5;
it also says in such above case the multiplication would be in
double then converted to float - bout for me its hard to belive
The standard requires that "The usual arithmetic conversions are
performed on the operands." (6.5.6p4). Those conversions are
described in (6.3.2.8), and require that, in a*1.5, the value of a
must be converted to a double, and that the multiplication be
carried out using double arithmetic. However, no conversion is
required for a*1.5f, and the multiplication is carried out using
float arithmetic. [...]
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.
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 ?
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".
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.
(should i also write 0.0f insetad of 0 BTW?)
Kaz Kylheku <046-301-5902@kylheku.com> writes:
On 2026-10-27, Scott Lurndal <scott@slp53.sl.home> wrote:
I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
[...]
FP is fine for pricing: look at how ridiculously close to 75.71
the above approximation is. You just have to make sure never to
let enough error accumulate so that an intermediate value
is suddenly closer to the wrong penny value than the right one.
And how do you do that?
(Actually you don't even want to get anywhere near that level
of error.)
An arbitrarily small error can result in an ambiguity. If you
calculate a result that should, mathematically, be very close to
75.715, it could round either to 75.71 or to 75.72.
I presume there are financial regulations that specify exactly how
these calculations are to be performed. I have no idea what those >regulations say, but anyone writing financial code had better know
about the requirements and implement them correctly.
but i not tested/talked yetai says even fast math not enebles that but there is a flag
-fsingle-precision-constant.
On Wed, 28 Oct 2026 07:55:11 +0100, fir wrote:
but i not tested/talked yetai 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.
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.
Steven G. Kargl pisze:
On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:there is something like integer*float multiplication , or not?
(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.
if so 25*a and 25.*a or 25.0f*a could make a difference
Steven G. Kargl pisze:
On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:there is something like integer*float multiplication , or not?
(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.
if so 25*a and 25.*a or 25.0f*a could make a difference
On 28/10/2026 01:49, Lawrence D?Oliveiro wrote:uffix?
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? s
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.
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:If you're working with values of type float, the "f" suffix is more
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.
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'.
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.
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 theIs there any situation where you *should* use the ?f? suffix?
"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.
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.
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 lisp, you can use fractions, ratios, very large doubles. It is
somewhat slow with floating point usually. Ratios I like. 1/100 -
that is it.
On Wed, 28 Oct 2026 02:19:24 -0400, steve g wrote:
Try lisp, you can use fractions, ratios, very large doubles. It is
somewhat slow with floating point usually. Ratios I like. 1/100 -
that is it.
Python has all that. Plus overloads for actual infix operators.
David Brown <david.brown@hesbynett.no> writes:suffix?
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 theIs there any situation where you *should* use the ?f?
"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;
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 theIs there any situation where you *should* use the ?f? suffix?
"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.
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
(should i also write 0.0f insetad of 0 BTW?)
A lot of context removed. No. IMO, if you have
a numerical constant that can be written as an
integer and that integer is less than 2^P
where P is the precision of the floating point
type of interest (here, 2^P means 2 raised to
the Pth power), then simply write the numerical
constant as an integer. It's easier to read.
float foo(float a) {
float x = 25 * a;
return (x);
}
A compiler ought to convert 25 in the above to
25.f as 25 is exactly representable (at least in
IEEE-754 binary32 format) in float.
I disagree. Yes, the int constant 25 is implicitly converted to float
as part of the "usual arithmetic conversions". But I find
float x = 25.0 * a;
or even
float x = 25.0f * a;
clearer than
float x = 25 * a;
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.
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.
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.
On Wed, 28 Oct 2026 13:31:06 -0700, Keith Thompson wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
[...]
float foo(float a) {
float x = 25 * a;
return (x);
}
A compiler ought to convert 25 in the above to
25.f as 25 is exactly representable (at least in
IEEE-754 binary32 format) in float.
I disagree. Yes, the int constant 25 is implicitly converted to float
as part of the "usual arithmetic conversions". But I find
float x = 25.0 * a;
or even
float x = 25.0f * a;
clearer than
float x = 25 * a;
ROTL. You find '25 * a' too difficult to realize
that it is twenty-five times a. The 2 or 3 extra
digits (i.e., '.', '0', and 'f') are nothing but
fluff.
On Wed, 28 Oct 2026 13:31:06 -0700, Keith Thompson wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 07:51:13 +0100, fir wrote:
(should i also write 0.0f insetad of 0 BTW?)
A lot of context removed. No. IMO, if you have
a numerical constant that can be written as an
integer and that integer is less than 2^P
where P is the precision of the floating point
type of interest (here, 2^P means 2 raised to
the Pth power), then simply write the numerical
constant as an integer. It's easier to read.
float foo(float a) {
float x = 25 * a;
return (x);
}
A compiler ought to convert 25 in the above to
25.f as 25 is exactly representable (at least in
IEEE-754 binary32 format) in float.
I disagree. Yes, the int constant 25 is implicitly converted to float
as part of the "usual arithmetic conversions". But I find
float x = 25.0 * a;
or even
float x = 25.0f * a;
clearer than
float x = 25 * a;
ROTL. You find '25 * a' too difficult to realize
that it is twenty-five times a. The 2 or 3 extra
digits (i.e., '.', '0', and 'f') are nothing but
fluff.
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 thatMy logical expectation is based on knowing C.
might stem from (knowing) the inherent mechanisms and quirks of the
C-language not necessarily what one would logically expect.
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 beSure, a compiler can generate code to store (float)0.1 in f without
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'.
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.
(Also, you misspelled "ROFL", and you don't need parentheses on the
return statement, particularly if you dislike fluff.)
On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
(Also, you misspelled "ROFL", and you don't need parentheses on the
return statement, particularly if you dislike fluff.)
Yeah, I was laugh too hard while typing ;-)
Parentheses is a habit from BSD kernel source file style guide.
% man 9 style
...
Values in return statements should be enclosed in parentheses.
I also have debugging macros RETURNI() that require parens.
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
(Also, you misspelled "ROFL", and you don't need parentheses on the
return statement, particularly if you dislike fluff.)
Yeah, I was laugh too hard while typing ;-)
Parentheses is a habit from BSD kernel source file style guide.
Now is a good time to start unlearning that habit.
% man 9 style
...
Values in return statements should be enclosed in parentheses.
I also have debugging macros RETURNI() that require parens.
That strengthens the motivation not to use parentheses with
return statements, to emphasize that they are different from
the macros.
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!
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.
On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
(Also, you misspelled "ROFL", and you don't need parentheses on the
return statement, particularly if you dislike fluff.)
Yeah, I was laugh too hard while typing ;-)
Parentheses is a habit from BSD kernel source file style guide.
Now is a good time to start unlearning that habit.
Why? What harm do the parentheses cause?
Unlearning is not likely to happen. I've been a long-time
contributor to FreeBSD, and have no plans to stop. Feel
free to check the git history on FreeBSD libm sources.
My finger prints are all over the code. So, yeah, I know
a enough about floating point arithmetic and C standard
requirements to be dangerous.
% man 9 style
...
Values in return statements should be enclosed in parentheses.
I also have debugging macros RETURNI() that require parens.
That strengthens the motivation not to use parentheses with
return statements, to emphasize that they are different from
the macros.
Do you ignore the style requirements of all the projects
that you may have worked on, and simply use whatever
your personal preferences are?
On Wed, 28 Oct 2026 08:39:23 +0100
David Brown <david.brown@hesbynett.no> 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.
I'd still likely prefer to write it as (float)0.1 instead of 0.1f.
It somewhat depends on my mood in specific day, but likelihood is
certainly not in favor of 0.1f.
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 theIs there any situation where you *should* use the ?f? suffix?
"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.
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 theIs there any situation where you *should* use the ?f? suffix?
"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,
I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point arithmetic
for pricing.
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.
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.1fYes, sure. Only that I think that context should suffice to
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.
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.
On 28/10/2026 21:25, Michael S wrote:[...]
I'd still likely prefer to write it as (float)0.1 instead of 0.1f.That seems a bit excessive to me, but okay. The principle is the
It somewhat depends on my mood in specific day, but likelihood is
certainly not in favor of 0.1f.
same, making it clear to the reader and the compiler that no
double-precision arithmetic is involved.
[...]I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point
arithmetic
for pricing.
And this is why you should use the lowest value denominator when
storing monetary values -- store USD values in cents, CNY values
in fen, EUR values in cents, etc...
makendo <makendo@makendo.invalid> writes:
[...]I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point
arithmetic
for pricing.
And this is why you should use the lowest value denominator when
storing monetary values -- store USD values in cents, CNY values
in fen, EUR values in cents, etc...
That's not good enough. Discounts, sales taxes, and compound
interest can easily result in amounts that are not multiples of
one cent, which must then be rounded or truncated to the nearest
cent following whatever financial rules are in effect.
On 29/10/2026 13:01, Keith Thompson wrote:
makendo <makendo@makendo.invalid> writes:
[...]I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
˙˙˙˙ Total
˙˙˙˙ 75.71000000000001 USD
Appears they may be using FP instead of integer fixed point
arithmetic
for pricing.
And this is why you should use the lowest value denominator when
storing monetary values -- store USD values in cents, CNY values
in fen, EUR values in cents, etc...
That's not good enough.˙ Discounts, sales taxes, and compound
interest can easily result in amounts that are not multiples of
one cent, which must then be rounded or truncated to the nearest
cent following whatever financial rules are in effect.
What is "good enough" depends on the context.˙ For a lot of situations, floating point, or rounding to the nearest dollar (or thousand dollars,
or pounds, or whatever) can be fine.˙ You can happily use values in
cents for your shop prices.
[snip]
Why? What harm do the parentheses cause?
I can't see that parentheses here cause any actual harm - but they are >certainly unnecessary fluff, and do no good.
Every extra level of parentheses adds to the cognitive effort required
to understand and interpret an expression. It takes longer to read, and
has a higher chance of misinterpretation. If the parenthesis are
necessary - "(a + b) * c" - then this is clearly a cost worth paying. >Sometimes parentheses are not necessary, but /reduce/ the cognitive
effort, such as "(a > 2) && (a < 5)". Again, the parentheses are then a
good thing (albeit subjectively).
But in "return (x);", they add nothing but cognitive effort. The C >programmer's brain has to consider and reject the possibility that this
is a function call or a macro invocation. The effort is small, but >nonetheless wasted.
Let me put it another way. What benefit do you think there is from
these parentheses? Why does the FreeBSD style guide recommend them? I
can see benefits in consistency of style once that usage has been >established, but why have them in the first place?
[snip]
% man 9 style
...
Values in return statements should be enclosed in parentheses.
I also have debugging macros RETURNI() that require parens.
That strengthens the motivation not to use parentheses with
return statements, to emphasize that they are different from
the macros.
Do you ignore the style requirements of all the projects
that you may have worked on, and simply use whatever
your personal preferences are?
When working on code with particular style requirements, it makes sense
to follow those style requirements - even if you disagree with the >requirements. When working on other code, you are then freed from
following rules that are unnecessary or counter-productive.
If I were contributing code to FreeBSD and it /requires/ parentheses in >return statements for the code to be accepted, I'd put parentheses in
return statements. If it merely /recommends/ them, I would not do so -
but would change my mind if other FreeBSD contributors made a fuss about
it. In no other code would I use them, and in code reviews I would ask
for them to be removed.
But I would not bother about them in throw-away Usenet code, except if
the post was complaining about other unnecessary "fluff" :-)
On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
(Also, you misspelled "ROFL", and you don't need parentheses on the
return statement, particularly if you dislike fluff.)
Yeah, I was laugh too hard while typing ;-)
Parentheses is a habit from BSD kernel source file style guide.
Now is a good time to start unlearning that habit.
Why? What harm do the parentheses cause?
Let me put it another way. What benefit do you think there is from
these parentheses? Why does the FreeBSD style guide recommend them? I
can see benefits in consistency of style once that usage has been established, but why have them in the first place?
On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
[...], and you don't need parentheses on the
return statement, particularly if you dislike fluff.)
[...]
Parentheses is a habit from BSD kernel source file style guide.
Now is a good time to start unlearning that habit.
Why? What harm do the parentheses cause?
Unlearning is not likely to happen. [...]
[BSD style][...]
% man 9 style
...
Values in return statements should be enclosed in parentheses.
[...]
Do you ignore the style requirements of all the projects
that you may have worked on, and simply use whatever
your personal preferences are?
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 thatMy logical expectation is based on knowing C.
might stem from (knowing) the inherent mechanisms and quirks of the
C-language not necessarily what one would logically expect.
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 beSure, a compiler can generate code to store (float)0.1 in f without
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'.
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. [...]
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 2026-10-28 21:50, Steven G. Kargl wrote:
On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
(Also, you misspelled "ROFL", and you don't need parentheses on the
return statement, particularly if you dislike fluff.)
Yeah, I was laugh too hard while typing ;-)
Parentheses is a habit from BSD kernel source file style guide.
Now is a good time to start unlearning that habit.
Why? What harm do the parentheses cause?
They can lead to people thinking that return is a function, even if they nominally know better. What would you think of
return (a=b).retval;
You might never write such code, and might never read it either, but you should have no trouble parsing it. Do you?
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?
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.)
[...]
On 2026-10-28 21:50, Steven G. Kargl wrote:
On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
(Also, you misspelled "ROFL", and you don't need parentheses on the
return statement, particularly if you dislike fluff.)
Yeah, I was laugh too hard while typing ;-)
Parentheses is a habit from BSD kernel source file style guide.
Now is a good time to start unlearning that habit.
Why? What harm do the parentheses cause?
They can lead to people thinking that return is a function, even if they >nominally know better.
What would you think of
return (a=b).retval;
You might never write such code, and might never read it either, but you >should have no trouble parsing it. Do you?
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.)
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.
[...]
But again, the whole premise (that a programmer familiar with C
would ever think that `return` is a function) is silly.
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.
makendo <makendo@makendo.invalid> writes:
[...]I ordered a couple of blu-rays from amazon last week, and the
confirmation email had the following for the total price:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point
arithmetic
for pricing.
And this is why you should use the lowest value denominator when
storing monetary values -- store USD values in cents, CNY values
in fen, EUR values in cents, etc...
That's not good enough. Discounts, sales taxes, and compound
interest can easily result in amounts that are not multiples of
one cent, which must then be rounded or truncated to the nearest
cent following whatever financial rules are in effect.
On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
(Also, you misspelled "ROFL", and you don't need parentheses on the
return statement, particularly if you dislike fluff.)
Yeah, I was laugh too hard while typing ;-)
Parentheses is a habit from BSD kernel source file style guide.
Now is a good time to start unlearning that habit.
Why? What harm do the parentheses cause?
Unlearning is not likely to happen. I've been a long-time
contributor to FreeBSD, and have no plans to stop. Feel
free to check the git history on FreeBSD libm sources.
My finger prints are all over the code. So, yeah, I know
a enough about floating point arithmetic and C standard
requirements to be dangerous.
% man 9 style
...
Values in return statements should be enclosed in parentheses.
I also have debugging macros RETURNI() that require parens.
That strengthens the motivation not to use parentheses with
return statements, to emphasize that they are different from
the macros.
Do you ignore the style requirements of all the projects
that you may have worked on, and simply use whatever
your personal preferences are?
On Thu, 29 Oct 2026 10:45:16 +0100, David Brown wrote:
Let me put it another way. What benefit do you think there is from
these parentheses? Why does the FreeBSD style guide recommend them?
I can see benefits in consistency of style once that usage has been
established, but why have them in the first place?
As we all know, FreeBSD is derived from software developed by
the CSRG at UC Berkeley during the 70's. FreeBSD adopted the
Kernel Normal Format (KNF) from CSRG. You will need to contact
a former member of CSRG such as Bostik, McKusick, Joy, Leffler,
etc. and them why KNF requires ().
Perhaps, the C compiler from 40 or so years ago required
parentheses in a return statement. Or, just maybe, members of
CSRG read K&R and noticed the authors of the book consistently
use paretheses in their examples. Ah yes, let's look at
the documentation:
% man 9 style
HISTORY
This manual page was originally based on the src/admin/style/style
file from the 4.4BSD-Lite2 release, with frequent updates to
reflect the current practice and desire of the FreeBSD project.
src/admin/style/style is a codification by the CSRG of the
programming style of Ken Thompson and Dennis Ritchie in Version6
AT&T UNIX.
So, it seems to be a preference of Ritchie.
On Thu, 29 Oct 2026 11:56:38 -0400, James Kuyper wrote:[...]
On 2026-10-28 21:50, Steven G. Kargl wrote:
Why? What harm do the parentheses cause?
They can lead to people thinking that return is a function, even if they
nominally know better. What would you think of
return (a=b).retval;
You might never write such code, and might never read it either, but you
should have no trouble parsing it. Do you?
Never written nor seen such a line of code. Of course, a random
line of code taken out of context may have many interpretations
or no interpretation at all. I likely know less than 25% of
what C can do as I am primarily interested in only C23 7.12 and
Annex F and G.
I do find it interesting that in a newgroup purportedly concerned
with discussions about the C programming language, I seem to have
been the only person in this thread to show a complete self-contained
piece of code so fir can see the consequences of not understanding
floating point arithmetic.
In article <11bvqbn$3g0tj$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 2026-10-28 21:50, Steven G. Kargl wrote:
On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
(Also, you misspelled "ROFL", and you don't need parentheses on the >>>>>> return statement, particularly if you dislike fluff.)
Yeah, I was laugh too hard while typing ;-)
Parentheses is a habit from BSD kernel source file style guide.
Now is a good time to start unlearning that habit.
Why? What harm do the parentheses cause?
They can lead to people thinking that return is a function, even if they >>nominally know better.
What? This is an incredibly weak argument.
If someone thought that `return` was a function, then why
wouldn't they think that `if` or `while` were also functions?
Or `sizeof`, and so on?
But again, the whole premise (that a programmer familiar with C
would ever think that `return` is a function) is silly.
They can lead to people thinking that return is a function ...
On Thu, 29 Oct 2026 10:45:16 +0100, David Brown wrote:
Let me put it another way. What benefit do you think there is from
these parentheses? Why does the FreeBSD style guide recommend them? I
can see benefits in consistency of style once that usage has been
established, but why have them in the first place?
As we all know, FreeBSD is derived from software developed by
the CSRG at UC Berkeley during the 70's. FreeBSD adopted the
Kernel Normal Format (KNF) from CSRG. You will need to contact
a former member of CSRG such as Bostik, McKusick, Joy, Leffler,
etc. and them why KNF requires ().
Perhaps, the C compiler from 40 or so years ago required
parentheses in a return statement. Or, just maybe, members of
CSRG read K&R and noticed the authors of the book consistently
use paretheses in their examples. Ah yes, let's look at
the documentation:
% man 9 style
HISTORY
This manual page was originally based on the src/admin/style/style file
from the 4.4BSD-Lite2 release, with frequent updates to reflect the
current practice and desire of the FreeBSD project.
src/admin/style/style is a codification by the CSRG of the programming
style of Ken Thompson and Dennis Ritchie in Version˙6 AT&T UNIX.
So, it seems to be a preference of Ritchie.
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.
You may be one of the few people who's willing to engage with fir.
I didn't reply to him because I don't read his posts.
Are you the same person as steve g <Sgonedes1977@gmail.com>?
I envy in particular the Japanese on this -- they don't have
monetary units smaller than 1 yen, and as such misuse of floats in
monetary calculations are far less likely in Japan.
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Thu, 29 Oct 2026 10:45:16 +0100, David Brown wrote:
Let me put it another way. What benefit do you think there is from
these parentheses? Why does the FreeBSD style guide recommend them?
I can see benefits in consistency of style once that usage has been
established, but why have them in the first place?
As we all know, FreeBSD is derived from software developed by
the CSRG at UC Berkeley during the 70's. FreeBSD adopted the
Kernel Normal Format (KNF) from CSRG. You will need to contact
a former member of CSRG such as Bostik, McKusick, Joy, Leffler,
etc. and them why KNF requires ().
Perhaps, the C compiler from 40 or so years ago required
parentheses in a return statement. Or, just maybe, members of
CSRG read K&R and noticed the authors of the book consistently
use paretheses in their examples. Ah yes, let's look at
the documentation:
% man 9 style
HISTORY
This manual page was originally based on the src/admin/style/style
file from the 4.4BSD-Lite2 release, with frequent updates to
reflect the current practice and desire of the FreeBSD project.
src/admin/style/style is a codification by the CSRG of the
programming style of Ken Thompson and Dennis Ritchie in Version6
AT&T UNIX.
So, it seems to be a preference of Ritchie.
It may have been simply long-standing habit rather than preference.
In the early days of C parentheses around return expressions were
required, not optional. I've been programming in C long enough to
have been influenced by that requirement (and later learned to undo
it).
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
(Also, you misspelled "ROFL", and you don't need parentheses on the
return statement, particularly if you dislike fluff.)
Yeah, I was laugh too hard while typing ;-)
Parentheses is a habit from BSD kernel source file style guide.
Now is a good time to start unlearning that habit.
Why? What harm do the parentheses cause?
Wrong question. The important question is what benefit do they
give? Granted, there may be circumstances where there is some
benefit. But what benefit justifies using parentheses in *all* >circumstances?
Unlearning is not likely to happen. I've been a long-time
contributor to FreeBSD, and have no plans to stop. Feel
free to check the git history on FreeBSD libm sources.
My finger prints are all over the code. So, yeah, I know
a enough about floating point arithmetic and C standard
requirements to be dangerous.
% man 9 style
...
Values in return statements should be enclosed in parentheses.
I also have debugging macros RETURNI() that require parens.
That strengthens the motivation not to use parentheses with
return statements, to emphasize that they are different from
the macros.
Do you ignore the style requirements of all the projects
that you may have worked on, and simply use whatever
your personal preferences are?
Please note what I said. I did not say never to use parentheses.
What I did say is that now is a good time to start unlearning the
habit of (always) using parentheses. If you're writing code
destined for FreeBSD, by all means put in the extra parentheses.
On the other hand, if you're writing code to put in a posting for >comp.lang.c, it's more common not to use extra parentheses. When
in Rome, do as the Romans do. If you have a compelling reason to
use such redundant parentheses here in the newsgroup, please tell
us what it is. Otherwise, is it you who is ignoring the style
norms of the group who will be reading your code?
On Thu, 29 Oct 2026 11:56:38 -0400, James Kuyper wrote:
They can lead to people thinking that return is a function ...
There shouldn't be a return statement at all. Smashing together
the assignment of the function result with termination of function
execution seems to me a code smell.
In article <86se1oku25.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
(Also, you misspelled "ROFL", and you don't need parentheses on the >>>>>> return statement, particularly if you dislike fluff.)
Yeah, I was laugh too hard while typing ;-)
Parentheses is a habit from BSD kernel source file style guide.
Now is a good time to start unlearning that habit.
Why? What harm do the parentheses cause?
Wrong question. The important question is what benefit do they
give? Granted, there may be circumstances where there is some
benefit. But what benefit justifies using parentheses in *all* >>circumstances?
Consistency with existing code and conformance with an
externally mandated style guide, obviously.
Unlearning is not likely to happen. I've been a long-time
contributor to FreeBSD, and have no plans to stop. Feel
free to check the git history on FreeBSD libm sources.
My finger prints are all over the code. So, yeah, I know
a enough about floating point arithmetic and C standard
requirements to be dangerous.
% man 9 style
...
Values in return statements should be enclosed in parentheses.
I also have debugging macros RETURNI() that require parens.
That strengthens the motivation not to use parentheses with
return statements, to emphasize that they are different from
the macros.
Do you ignore the style requirements of all the projects
that you may have worked on, and simply use whatever
your personal preferences are?
Please note what I said. I did not say never to use parentheses.
What I did say is that now is a good time to start unlearning the
habit of (always) using parentheses. If you're writing code
destined for FreeBSD, by all means put in the extra parentheses.
On the other hand, if you're writing code to put in a posting for >>comp.lang.c, it's more common not to use extra parentheses. When
in Rome, do as the Romans do. If you have a compelling reason to
use such redundant parentheses here in the newsgroup, please tell
us what it is. Otherwise, is it you who is ignoring the style
norms of the group who will be reading your code?
This newsgroup has no "norms" for code style. Period.
You are stating your preference as if it is some agreed upon, de
facto standard. It is not, nor is it a requirement for posting
here. No one posting here is obligated to omit the parentheses
to satisfy the whims of you, me, or anyone else. Hell, they can
unironically use the GNU style if they really want.
OP: you want to parenthesize the expression in a `return`
statement because that's what you're used to from FreeBSD? Go
for it. Some folks may find it unnecessary; that's fine. But
don't listen to someone trying to tell you that you're violating
some set of invisible mores by doing so; that nonsense.
C23, Annex A shows the syntax rule: 'return expression_{opt}'
with _{opt} denoting a subscript. Unsurprisingly, 6.5.2 shows
primary-expression:
...
( expression )
...
so, the code I posted with 'return (0)' is standard conforming.
[...][...]
In my personal coding style, I try to avoid making things that are not function calls look like function calls. In a function call, there's no space between the function name and the left parenthesis. [...]
[...]
And in the example that started this subthread, I probably wouldn't
have mentioned the parentheses if the poster hadn't been complaining
about "fluff".
On Thu, 29 Oct 2026 11:56:38 -0400, James Kuyper wrote:
They can lead to people thinking that return is a function ...
There shouldn?t be a return statement at all. Smashing together the assignment of the function result with termination of function
execution seems to me a code smell.
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.
On 2026-10-30 00:29, Keith Thompson wrote:
[...][...]
In my personal coding style, I try to avoid making things that are
not
function calls look like function calls. In a function call, there's no
space between the function name and the left parenthesis. [...]
I suppose we should read the second sentence also as your "personal
coding style".
In my personal coding style there's usually always a
space.
[...]
How would you do calculations involving compound interest payments
without floating-point arithmetic? And why would you want to?
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
In my personal coding style there's usually always a space.
Then you're objectively wrong.
(I kid, I kid!)
How would you do calculations involving compound interest payments
without floating-point arithmetic?
And why would you want to?
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.)
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <11bvqbn$3g0tj$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 2026-10-28 21:50, Steven G. Kargl wrote:
On Wed, 28 Oct 2026 17:59:19 -0700, Tim Rentsch wrote:
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:
On Wed, 28 Oct 2026 16:39:00 -0700, Keith Thompson wrote:
(Also, you misspelled "ROFL", and you don't need parentheses on the >>>>>>> return statement, particularly if you dislike fluff.)
Yeah, I was laugh too hard while typing ;-)
Parentheses is a habit from BSD kernel source file style guide.
Now is a good time to start unlearning that habit.
Why? What harm do the parentheses cause?
They can lead to people thinking that return is a function, even if they >>> nominally know better.
What? This is an incredibly weak argument.
If someone thought that `return` was a function, then why
wouldn't they think that `if` or `while` were also functions?
Or `sizeof`, and so on?
I agree that it's a bit of a weak argument, but I wouldn't call it
incredibly weak.
In my personal coding style, I try to avoid making things that are not function calls look like function calls. In a function call, there's no space between the function name and the left parenthesis. I don't use
that style for anything other than function calls (or invocations of function-like macros). Not because I don't know return and sizeof are keywords, but because it's just a little bit easier to read the code
if distinctions like that are clear.
Examples:
func(42); // function call, or maybe a macro invocation
return 42; // not return(42); or even "return (42);
if (cond) // not if(cond)
sizeof (int) // not sizeof(int)
sizeof obj // not sizeof(obj) or sizeof (obj)
The idea is to make the code just a little bit clearer and easier to
read. If I see something that looks it would be a function call except
that the prefix is a keyword, it's *very slightly* annoying.
Parentheses on a return statement are allowed, but they're part of the expression, not part of the syntax of the return statement, and they're superfluous. I don't write `return (42);` for the same reason I don't
write `x = (42);`.
And of course *all* of these rules can be overridden by a coding
standard or by the existing style of the surrounding code.
Would there be a problem with fixed-point arithmetic (that internallyYou could make a library for rational numbers (two integers) arithmetic
uses a few more than just two decimals for rounding etc.) but that is
using basically a fixed-point representation?
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.
Janis Papanagnou wrote:
Would there be a problem with fixed-point arithmetic (that internallyYou could make a library for rational numbers (two integers) arithmetic where the denominator is a power of ten. If the CPU has decimal
uses a few more than just two decimals for rounding etc.) but that is
using basically a fixed-point representation?
arithmetic, implement it in assembly.
In article <11bvqbn$3g0tj$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
[snip]
They can lead to people thinking that return is a function, even if they >>>nominally know better.
What? This is an incredibly weak argument.
If someone thought that `return` was a function, then why
wouldn't they think that `if` or `while` were also functions?
Or `sizeof`, and so on?
I agree that it's a bit of a weak argument, but I wouldn't call it
incredibly weak.
In my personal coding style, I try to avoid making things that are not >function calls look like function calls. In a function call, there's no >space between the function name and the left parenthesis. I don't use
that style for anything other than function calls (or invocations of >function-like macros). Not because I don't know return and sizeof are >keywords, but because it's just a little bit easier to read the code
if distinctions like that are clear.
[snip examples]
[snip]
The premise (at least for me) is not that someone would *think*
that return is a function, but that making a return statement not
look too much like a function call makes the code just a little
bit easier to read.
And in the example that started this subthread, I probably wouldn't
have mentioned the parentheses if the poster hadn't been complaining
about "fluff".
You could make a library for rational numbers (two integers) arithmetic where the denominator is a power of ten.
If the CPU has decimal arithmetic, implement it in assembly.
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"
[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.
I doubt if this is the start of a habit or pattern, however.
On 2026-10-30 01:50, Lawrence D?Oliveiro wrote:
[...]
How would you do calculations involving compound interest payments
without floating-point arithmetic? And why would you want to?
Because what gets in and what comes out is just exact fixed point?
And you need more an exact transformation to and from the internal
values? And exact representation with BCD more than binary floating
point? (Mind the 0.10 issue!) - I think there was a reason why with
COBOL, the COmmon Business Oriented Language, there was - at least >historically - fixed-point arithmetic used for the financial sector?
(But please CMIIW.)
Would there be a problem with fixed-point arithmetic (that internally
uses a few more than just two decimals for rounding etc.) but that is
using basically a fixed-point representation?
And we saw in some post this hilarious sample of an (Amazon?) bill.
(Not that this couldn't have been fixed even/also with FP-arithmetic.)
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
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.
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.
On 30/10/2026 10:39, chine.bleu wrote:
Janis Papanagnou wrote:
Would there be a problem with fixed-point arithmetic (that internallyYou could make a library for rational numbers (two integers)
uses a few more than just two decimals for rounding etc.) but that is
using basically a fixed-point representation?
arithmetic where the denominator is a power of ten. If the CPU has
decimal arithmetic, implement it in assembly.
It does not make much sense to talk about a library for rational
numbers, then restrict it to denominators with powers of ten.˙ When you
need exactly reproducible decimals, one option is to use a fixed number
of places and then used scaled integers (a.k.a. fixed-point arithmetic)
- basically hold your values in "long long int" types with a constant
scale factor of 1'000'000, or similar.
If you want to be able to handle different scale factors easily, then decimal floating point formats are appropriate.˙ These are standardised
in ISO/IEC 60559, and supported in C as _Decimal32, _Decimal64 and _Decimal128.˙ The types are optional in C, but supported at least by gcc
on "big" target systems.˙ If the target hardware has appropriate instructions for them, the compiler should use that - that is vastly
better than using assembly.
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.
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".
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
On 10/27/2026 5: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
Never give up precision easily.˙ It will always come back to bite you.
Lynn
On 10/30/2026 10:00 PM, Lynn McGuire wrote:
On 10/27/2026 5: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
Never give up precision easily.˙ It will always come back to bite you.
Lynn
Tell the AI to stop the nonsense.
Lynn
On Fri, 10/30/2026 11:01 PM, Lynn McGuire wrote:
On 10/30/2026 10:00 PM, Lynn McGuire wrote:
On 10/27/2026 5: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
Never give up precision easily.˙ It will always come back to bite you.
Lynn
Tell the AI to stop the nonsense.
Lynn
You can do that. The trick to being a vibe coder,
is knowing what to put in the prompt.
And this is why, even if you have "negative interest" in LLM-AI,
you should at least do enough experiments to detect their dimensionality (their linear thinking when used in isolation and without
a harness).
There is a big big difference, between what Fir is doing,
and what professionals right now are doing.
[Teaser]
https://www.theregister.com/devops/2026/09/18/microsoft-agentically-ports-copilot-runtime-to-rust-for-120k/5297549
[Details]
https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/
On the one hand, the $120,000 worth of tokens, seems expensive. But
on the other hand, the staff it would have taken to do the equivalent
would not have been free.
Even an expert, he still made a mistake in corralling the machines
and preventing them from "cheating". The non-determinism means
you can never stop learning about what guard statements to add.
The code review is still the bottleneck, and lots of operations outside
of Microsoft, do not see the gains of the "all-in" "experimental"
approach shown in the above.
Even if you're not interested in such things, you have to track
the capabilities, to understand how your ass is going to get kicked.
For example, you may have a superior product to the upstarts vibe-coding
an equivalent. But now you are going to have to do extra marketing
to ensure your existing customers "do not run away".
The getcraft site has been making (what it claims are) equivalents
to commercial applications like the Adobe suite and Microsoft Office.
By no means are these equivalent, not even close. But what the
existence of these things do, is they lead to customers "testing
all sorts of shit" and diluting a lot of careful work you might
have done to get where you are. I tested a couple of those getcraft in
a VM, and there was "excessive CPU usage". The engine is Electron
(for cross-platform usage).
Paul
David Brown <david.brown@hesbynett.no> writes:
On 28/10/2026 21:25, Michael S wrote:[...]
I'd still likely prefer to write it as (float)0.1 instead of 0.1f.That seems a bit excessive to me, but okay. The principle is the
It somewhat depends on my mood in specific day, but likelihood is
certainly not in favor of 0.1f.
same, making it clear to the reader and the compiler that no
double-precision arithmetic is involved.
Except that, at least in the abstract machine, `(float)0.1` produces
a value of type double and converts it to float. It's likely that
a compiler would generate the same code as for `0.1f`, but I'd want
to confirm that if it mattered. (Actually, I'd just write `0.1f`.)
Paul pisze:
On Fri, 10/30/2026 11:01 PM, Lynn McGuire wrote:i wouldnt say i do˙ vibe coding..i do normal coding wit a help of ai assistant..vibe coding may be something different than i do
On 10/30/2026 10:00 PM, Lynn McGuire wrote:
On 10/27/2026 5: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
Never give up precision easily.˙ It will always come back to bite you. >>>>
Lynn
Tell the AI to stop the nonsense.
Lynn
You can do that. The trick to being a vibe coder,
is knowing what to put in the prompt.
And this is why, even if you have "negative interest" in LLM-AI,
you should at least do enough experiments to detect their dimensionality
(their linear thinking when used in isolation and without
a harness).
There is a big big difference, between what Fir is doing,
and what professionals right now are doing.
˙˙ [Teaser]
˙˙˙ https://www.theregister.com/devops/2026/09/18/microsoft-
agentically-ports-copilot-runtime-to-rust-for-120k/5297549
˙˙ [Details]
˙˙˙ https://github.blog/ai-and-ml/generative-ai/migrating-the-github-
copilot-runtime-to-rust-using-copilot/
On the one hand, the $120,000 worth of tokens, seems expensive. But
on the other hand, the staff it would have taken to do the equivalent
would not have been free.
Even an expert, he still made a mistake in corralling the machines
and preventing them from "cheating". The non-determinism means
you can never stop learning about what guard statements to add.
The code review is still the bottleneck, and lots of operations outside
of Microsoft, do not see the gains of the "all-in" "experimental"
approach shown in the above.
Even if you're not interested in such things, you have to track
the capabilities, to understand how your ass is going to get kicked.
For example, you may have a superior product to the upstarts vibe-coding
an equivalent. But now you are going to have to do extra marketing
to ensure your existing customers "do not run away".
The getcraft site has been making (what it claims are) equivalents
to commercial applications like the Adobe suite and Microsoft Office.
By no means are these equivalent, not even close. But what the
existence of these things do, is they lead to customers "testing
all sorts of shit" and diluting a lot of careful work you might
have done to get where you are. I tested a couple of those getcraft in
a VM, and there was "excessive CPU usage". The engine is Electron
(for cross-platform usage).
˙˙˙ Paul
On 10/31/2026 12:30 AM, fir wrote:
Paul pisze:
On Fri, 10/30/2026 11:01 PM, Lynn McGuire wrote:i wouldnt say i do˙ vibe coding..i do normal coding wit a help of ai
On 10/30/2026 10:00 PM, Lynn McGuire wrote:
On 10/27/2026 5: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
Never give up precision easily.˙ It will always come back to bite you. >>>>>
Lynn
Tell the AI to stop the nonsense.
Lynn
You can do that. The trick to being a vibe coder,
is knowing what to put in the prompt.
And this is why, even if you have "negative interest" in LLM-AI,
you should at least do enough experiments to detect their dimensionality >>> (their linear thinking when used in isolation and without
a harness).
There is a big big difference, between what Fir is doing,
and what professionals right now are doing.
˙˙ [Teaser]
˙˙˙ https://www.theregister.com/devops/2026/09/18/microsoft-
agentically-ports-copilot-runtime-to-rust-for-120k/5297549
˙˙ [Details]
˙˙˙ https://github.blog/ai-and-ml/generative-ai/migrating-the-github-
copilot-runtime-to-rust-using-copilot/
On the one hand, the $120,000 worth of tokens, seems expensive. But
on the other hand, the staff it would have taken to do the equivalent
would not have been free.
Even an expert, he still made a mistake in corralling the machines
and preventing them from "cheating". The non-determinism means
you can never stop learning about what guard statements to add.
The code review is still the bottleneck, and lots of operations outside
of Microsoft, do not see the gains of the "all-in" "experimental"
approach shown in the above.
Even if you're not interested in such things, you have to track
the capabilities, to understand how your ass is going to get kicked.
For example, you may have a superior product to the upstarts vibe-coding >>> an equivalent. But now you are going to have to do extra marketing
to ensure your existing customers "do not run away".
The getcraft site has been making (what it claims are) equivalents
to commercial applications like the Adobe suite and Microsoft Office.
By no means are these equivalent, not even close. But what the
existence of these things do, is they lead to customers "testing
all sorts of shit" and diluting a lot of careful work you might
have done to get where you are. I tested a couple of those getcraft in
a VM, and there was "excessive CPU usage". The engine is Electron
(for cross-platform usage).
˙˙˙ Paul
assistant..vibe coding may be something different than i do
At least you don't let do all of your coding.
On 2026-10-29 20:49, Dan Cross wrote:
[...]
But again, the whole premise (that a programmer familiar with C>> would ever think that `return` is a function) is silly.
Yes, that's hard to believe.
On 2010-08-28, Tony Clough wrote that "One possible problem with C
as compared to other languages like Perl or Shell is that function
calls require parentheses which leads to cluttered code. (But there
are some funny exceptions in the standard library though, eg return
and size_of do not need parentheses)"
On Sun, 1 Nov 2026 17:15:23 -0500, James Kuyper wrote:
On 2010-08-28, Tony Clough wrote that "One possible problem with C
as compared to other languages like Perl or Shell is that function
calls require parentheses which leads to cluttered code. (But there
are some funny exceptions in the standard library though, eg return
and size_of do not need parentheses)"
sizeof does require parentheses if you pass it a type, not for an
expression (except for the usual precedence reasons).
Not sure why that is ...
On Wed, 28 Oct 2026 16:05:06 -0700"The accuracy of the floating-point operations (+, -, *, /) and of most
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
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" compilerOne way to get stronger requirements is to require that
is doing such optimization on IEEE-754 compliant platform in absence of non-compliance flags like fast-math.
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
On Sun, 1 Nov 2026 17:15:23 -0500, James Kuyper wrote:
On 2010-08-28, Tony Clough wrote that "One possible problem with C
as compared to other languages like Perl or Shell is that function
calls require parentheses which leads to cluttered code. (But there
are some funny exceptions in the standard library though, eg return
and size_of do not need parentheses)"
sizeof does require parentheses if you pass it a type, not for an
expression (except for the usual precedence reasons).
Not sure why that is ...
Because if parentheses were not required around the type name, it would result in ambiguities. (I don't have an example off the top of my
head.)
but the question is: can using .1 instead of 0.1f make me any harm inYou might get a warning because of the precision loss.
code? ...
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point arithmetic
for pricing.
Am 27.10.2026 um 19:40 schrieb Scott Lurndal:
Total
75.71000000000001 USD
Appears they may be using FP instead of integer fixed point arithmetic
for pricing.
If you have a proper fp to decimal runtime function this actually
won't happen. That's while numbers which would result in the above
output would always be rounded correctly. That's safe since you'd
need billions of computations that wouldn't result to such results
by accident.
If you have a proper fp to decimal runtime function this actually
won't happen.
On 2026-10-29 17:55, Janis Papanagnou wrote:
On 2026-10-29 20:49, Dan Cross wrote:
[...]
But again, the whole premise (that a programmer familiar with C
would ever think that `return` is a function) is silly.
Agreed. The misconception is far more common among those
who aren't very familiar with C.
Yes, that's hard to believe.
See
It's not, by any means, a common misconception, but it does occur.
In article <11c8dls$2chr0$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 2026-10-29 17:55, Janis Papanagnou wrote:
On 2026-10-29 20:49, Dan Cross wrote:
[...]
But again, the whole premise (that a programmer familiar with C
would ever think that `return` is a function) is silly.
Agreed. The misconception is far more common among those
who aren't very familiar with C.
It is not common at all.
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
David Brown <david.brown@hesbynett.no> writes:
On 28/10/2026 21:25, Michael S wrote:
[...]
I'd still likely prefer to write it as (float)0.1 instead of 0.1f.
It somewhat depends on my mood in specific day, but likelihood is
certainly not in favor of 0.1f.
That seems a bit excessive to me, but okay. The principle is the
same, making it clear to the reader and the compiler that no
double-precision arithmetic is involved.
Except that, at least in the abstract machine, `(float)0.1` produces
a value of type double and converts it to float. It's likely that
a compiler would generate the same code as for `0.1f`, but I'd want
to confirm that if it mattered. (Actually, I'd just write `0.1f`.)
Maybe the code will be the same. But in general going via doubles
produces less accurate result, [...]
antispam@fricas.org (Waldek Hebisch) writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
David Brown <david.brown@hesbynett.no> writes:
On 28/10/2026 21:25, Michael S wrote:
[...]
I'd still likely prefer to write it as (float)0.1 instead of 0.1f.
It somewhat depends on my mood in specific day, but likelihood is
certainly not in favor of 0.1f.
That seems a bit excessive to me, but okay. The principle is the
same, making it clear to the reader and the compiler that no
double-precision arithmetic is involved.
Except that, at least in the abstract machine, `(float)0.1` produces
a value of type double and converts it to float. It's likely that
a compiler would generate the same code as for `0.1f`, but I'd want
to confirm that if it mattered. (Actually, I'd just write `0.1f`.)
Maybe the code will be the same. But in general going via doubles
produces less accurate result, [...]
What makes you think using a double will produce a less accurate
result?
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 4 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 190:54:21 |
| Calls: | 222 |
| Files: | 21,513 |
| Messages: | 85,912 |