Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #403612 > unrolled thread

.5 against 0.5f

Back to article view | Back to comp.lang.c

Contents

  .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-27 11:53 +0100
    Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-27 17:45 +0000
      Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-27 18:50 +0100
        Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-27 19:01 +0000
          Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-27 20:15 +0100
            Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-27 19:54 +0000
              Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:10 -0700
                Re: .5 against 0.5f steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:20 -0400
              Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-27 21:35 +0100
              Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 18:00 -0400
                Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-27 22:15 +0000
                Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 06:54 -0700
            Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-27 21:57 +0100
              Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 14:18 -0700
            Re: .5 against 0.5f steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:19 -0400
              Re: .5 against 0.5f Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-28 21:54 +0000
                Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:58 -0700
        Re: .5 against 0.5f steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:11 -0400
          Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 23:21 -0700
      Re: .5 against 0.5f scott@slp53.sl.home (Scott Lurndal) - 2026-10-27 18:40 +0000
        Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-27 12:29 -0700
          Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:11 -0700
            Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:25 -0700
        Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-27 21:43 +0200
          Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-27 22:05 +0200
            Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-27 22:51 +0200
        Re: .5 against 0.5f Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-27 20:05 +0000
          Re: .5 against 0.5f bartc <bc@freeuk.com> - 2026-10-27 21:03 +0000
          Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 15:41 -0700
            Re: .5 against 0.5f scott@slp53.sl.home (Scott Lurndal) - 2026-10-28 16:23 +0000
        Re: .5 against 0.5f steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:25 -0400
        Re: .5 against 0.5f makendo <makendo@makendo.invalid> - 2026-10-29 18:04 +0800
      Re: .5 against 0.5f Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-27 19:58 +0000
      Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 17:43 -0400
        Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 18:06 -0400
          Re: .5 against 0.5f Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-28 00:49 +0000
            Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 18:23 -0700
              Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 16:38 +0100
                Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 13:27 -0700
                  Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 00:08 +0100
                    Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:56 -0700
                    Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 09:30 +0100
            Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 21:41 -0400
              Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 08:45 +0100
            Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 01:50 +0000
              Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 07:32 +0100
                Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 07:51 +0100
                  Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 07:55 +0100
                    Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 16:27 +0000
                      Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 17:44 +0100
                  Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 16:22 +0000
                    Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 19:15 +0100
                      Re: .5 against 0.5f fir <profesor.fir@gmail.com> - 2026-10-28 19:47 +0100
                      Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 19:10 +0000
                    Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 13:31 -0700
                      Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-28 22:44 +0000
                        Re: .5 against 0.5f Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-29 00:27 +0100
                        Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:39 -0700
                          Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 00:22 +0000
                            Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 17:59 -0700
                              Re: .5 against 0.5f "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-29 01:50 +0000
                                Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 10:45 +0100
            Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 08:39 +0100
              Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-28 22:25 +0200
                Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 10:48 +0100
              Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 14:26 -0700
                Re: .5 against 0.5f Michael S <already5chosen@yahoo.com> - 2026-10-29 00:12 +0200
                  Re: .5 against 0.5f bartc <bc@freeuk.com> - 2026-10-28 22:33 +0000
                    Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 11:01 +0100
                  Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:05 -0700
                  Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 10:59 +0100
              Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:34 -0700
                Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-29 11:06 +0100
            Re: .5 against 0.5f tTh <tth@none.invalid> - 2026-10-28 15:08 +0100
              Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 07:49 -0700
            Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:36 -0700
        Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 15:53 -0700
          Re: .5 against 0.5f James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-10-27 21:55 -0400
            Re: .5 against 0.5f Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 19:02 -0700
          Re: .5 against 0.5f David Brown <david.brown@hesbynett.no> - 2026-10-28 08:56 +0100
        Re: .5 against 0.5f Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 08:01 -0700
    Re: .5 against 0.5f "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:08 -0700

Page 1 of 5  [1] 2 3 4 5  Next page →

#403612 — .5 against 0.5f

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

[toc] | [next] | [standalone]

#403628

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

-- 
steve

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

#403630

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?


i gues the answer is NOT but maybe soem can show at least one case it 
could be worse?

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

#403634

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?

-- 
steve

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

#403636

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:
>>>
>>>> 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?
> 
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

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

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

#403641

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
> 

I do not know where to begin to address the above.  Perhaps,
find a copy of K&R to read.

-- 
steve

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

#403646

On 10/27/2026 12:54 PM, 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
>>
> 
> I do not know where to begin to address the above.  Perhaps,
> find a copy of K&R to read.
> 

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.

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

#403686

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:


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

Thank you!

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

#403651

On 27/10/2026 20: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
>>
> 
> I do not know where to begin to address the above.  Perhaps,
> find a copy of K&R to read.
> 

For your benefit (not for Fir's), the multiplication of "a * 1.5" would 
be done in double precision (unless "a" is a "long double").  The 
resulting double value would then be converted to a single-precision float.

Whether "a * 1.5f" is done as single (float) or double depends on the 
type of "a" - if it is a "double", then the float value 1.5f gets 
converted to a double (and may be slightly different from 1.5) and the 
multiplication is done as double precision.  If "a" is of type "float", 
then the multiplication is done as single precision.

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

#403661

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. How the
multiplication is carried out is determined without regard to what type
the result will be stored in. This means that the value of a*1.5 will
have to be converted back to float before storing it in x, while a value
of a*1.5f has no such conversion.

> 
> I do not know where to begin to address the above.  Perhaps,
> find a copy of K&R to read.
What K&R said about the matter is far less precise, and in parts,
obsolete. in particular, float values were always automatically
converted to double for purposes of calculations.

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

#403663

On Tue, 27 Oct 2026 18:00:47 -0400, James Kuyper wrote:

> On 2026-10-27 15:54, Steven G. Kargl wrote:

> 
>> I do not know where to begin to address the above.  Perhaps,
>> find a copy of K&R to read.
> What K&R said about the matter is far less precise, and in parts,
> obsolete. in particular, float values were always automatically
> converted to double for purposes of calculations.

Yes, I know.  I suppose I could have pointing to 
N3220.pdf (working draft of C23 I have sitting around), 
but I assumed that would have fallen on blinded
eyes.

PS: K&R is still one of my favorite books for learning
a programming language; even if it is somewhat dated.

-- 
steve

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

#403711

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

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

Maybe.  IIANM the C standard allows floating operations to be
carried out in greater precision than the nominal type of the
expression, and thus a*1.5f might very well be carried out using,
e.g., the same operations as would be used by double.

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

#403655

fir pisze:
> 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:
>>>>
>>>>> 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?
>>
> 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
> 
> (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)
> 
> 
ai is besides obviously great - it just drawed me even a small cosmonaut 
right now

https://www.youtube.com/watch?v=aZ1F4soMRHE


its code is not even long




static float3 astronaut_v[512];
static int astronaut_tri[1024][3];
static unsigned astronaut_color[1024];
static int astronaut_vertex_count=0;
static int astronaut_triangle_count=0;
static int astronaut_initialized=0;

void AstronautVertex(float x,float y,float z)
{
	if(astronaut_vertex_count>=512) return;
	astronaut_v[astronaut_vertex_count++]=f3(x,y,z);
}

void AstronautTriangle(int a,int b,int c,unsigned color)
{
	if(astronaut_triangle_count>=1024) return;
	int i=astronaut_triangle_count++;
	astronaut_tri[i][0]=a;
	astronaut_tri[i][1]=b;
	astronaut_tri[i][2]=c;
	astronaut_color[i]=color;
}

void AstronautQuad(int a,int b,int c,int d,unsigned color)
{
	AstronautTriangle(a,b,c,color);
	AstronautTriangle(a,c,d,color);
}

void AstronautBox(float x,float y,float z,float sx,float sy,float 
sz,unsigned color)
{
	int b=astronaut_vertex_count;
	if(b+8>512 || astronaut_triangle_count+12>1024) return;

	AstronautVertex(x-sx,y-sy,z-sz);
	AstronautVertex(x+sx,y-sy,z-sz);
	AstronautVertex(x+sx,y+sy,z-sz);
	AstronautVertex(x-sx,y+sy,z-sz);
	AstronautVertex(x-sx,y-sy,z+sz);
	AstronautVertex(x+sx,y-sy,z+sz);
	AstronautVertex(x+sx,y+sy,z+sz);
	AstronautVertex(x-sx,y+sy,z+sz);

	AstronautQuad(b,b+3,b+2,b+1,color);
	AstronautQuad(b+4,b+5,b+6,b+7,color);
	AstronautQuad(b,b+1,b+5,b+4,color);
	AstronautQuad(b+1,b+2,b+6,b+5,color);
	AstronautQuad(b+2,b+3,b+7,b+6,color);
	AstronautQuad(b+3,b,b+4,b+7,color);
}

void AstronautBuild(void)
{
	if(astronaut_initialized) return;
	astronaut_vertex_count=0;
	astronaut_triangle_count=0;

	// Buty.
	AstronautBox(-4,24,1,3.5f,3,5.5f,0x343b43);
	AstronautBox( 4,24,1,3.5f,3,5.5f,0x343b43);
	AstronautBox(-4,22.5f,3,3.2f,1.1f,3.5f,0x68747d);
	AstronautBox( 4,22.5f,3,3.2f,1.1f,3.5f,0x68747d);

	// Nogi i kolana.
	AstronautBox(-4,17,0,2.8f,5.5f,3.5f,0xd5d8d6);
	AstronautBox( 4,17,0,2.8f,5.5f,3.5f,0xd5d8d6);
	AstronautBox(-4,11,0,3,2.3f,3.8f,0x626c74);
	AstronautBox( 4,11,0,3,2.3f,3.8f,0x626c74);
	AstronautBox(-4,7,0,2.8f,3.8f,3.3f,0xe1e2dc);
	AstronautBox( 4,7,0,2.8f,3.8f,3.3f,0xe1e2dc);
	AstronautBox(-4,17,3.5f,2.4f,0.9f,0.7f,0xf28a32);
	AstronautBox( 4,17,3.5f,2.4f,0.9f,0.7f,0xf28a32);

	// Tułów i kombinezon.
	AstronautBox(0,-1,0,7,9,4.5f,0xd9dcd8);
	AstronautBox(0,-1,4.2f,5.5f,6.5f,0.8f,0xb5c0c2);
	AstronautBox(0,-1,5,3.7f,3.5f,0.5f,0x303b43);

	// Panel sterowania na piersi.
	AstronautBox(0,-3,5.65f,2.8f,2.6f,0.35f,0x505c64);
	AstronautBox(-1,-3.5f,6.05f,0.65f,0.65f,0.15f,0xf28a32);
	AstronautBox( 1,-3.5f,6.05f,0.65f,0.65f,0.15f,0x5a9bb5);
	AstronautBox(-1,-1.9f,6.05f,0.4f,0.35f,0.15f,0xd8d8d0);
	AstronautBox( 1,-1.9f,6.05f,0.4f,0.35f,0.15f,0xd8d8d0);

	// Pas i boczne kieszenie.
	AstronautBox(0,5,0,7.2f,1.3f,4.8f,0x424b52);
	AstronautBox(-6,2,0,1.5f,2.2f,3.5f,0x778087);
	AstronautBox( 6,2,0,1.5f,2.2f,3.5f,0x778087);
	AstronautBox(-6,2,3.4f,0.8f,1.4f,0.5f,0xf28a32);
	AstronautBox( 6,2,3.4f,0.8f,1.4f,0.5f,0xf28a32);

	// Plecak za tułowiem.
	AstronautBox(0,-1,-5.5f,5.5f,7.5f,2.5f,0x69747b);
	AstronautBox(0,-1,-8,4.2f,5.5f,0.5f,0x343e47);
	AstronautBox(-3,-1,-8.6f,0.8f,4,0.4f,0xf28a32);
	AstronautBox( 3,-1,-8.6f,0.8f,4,0.4f,0xf28a32);
	AstronautBox(0,-6,-8.3f,2.5f,1,0.4f,0xbac2c3);
	AstronautBox(0, 4,-8.3f,2.5f,1,0.4f,0xbac2c3);

	// Ramiona.
	AstronautBox(-9,-3,0,3,5,3.5f,0xd8dbd7);
	AstronautBox( 9,-3,0,3,5,3.5f,0xd8dbd7);
	AstronautBox(-9,-6,0,3.1f,1,3.8f,0xf28a32);
	AstronautBox( 9,-6,0,3.1f,1,3.8f,0xf28a32);
	AstronautBox(-11,-1,0,2.1f,4,3,0xd8dbd7);
	AstronautBox( 11,-1,0,2.1f,4,3,0xd8dbd7);

	// Rękawice.
	AstronautBox(-12,3,0,2.2f,2.5f,2.7f,0x505b64);
	AstronautBox( 12,3,0,2.2f,2.5f,2.7f,0x505b64);
	AstronautBox(-12,3,2.1f,1.6f,1.7f,0.7f,0x7d878d);
	AstronautBox( 12,3,2.1f,1.6f,1.7f,0.7f,0x7d878d);

	// Szyja i pierścień hełmu.
	AstronautBox(0,-10,0,4,1.5f,4,0x6a747b);
	AstronautBox(0,-11,0,5.6f,1.2f,5.6f,0x858e94);
	AstronautBox(0,-11,0,4.7f,0.7f,4.7f,0xf28a32);

	// Kask.
	AstronautBox(0,-17,0,6.5f,6,5.5f,0xdde0dc);
	AstronautBox(0,-17,4.5f,5.3f,4.2f,1.5f,0x303b43);
	AstronautBox(0,-17,5.8f,4.4f,3.2f,0.5f,0x111d2a);
	AstronautBox(0,-17,6.1f,3.7f,2.5f,0.3f,0x16435c);
	// Boki kasku i mocowania.
	AstronautBox(-6.6f,-17,0,1.2f,2.8f,2.8f,0x69757d);
	AstronautBox( 6.6f,-17,0,1.2f,2.8f,2.8f,0x69757d);
	AstronautBox(-7.2f,-17,0,0.7f,2,2,0xf28a32);
	AstronautBox( 7.2f,-17,0,0.7f,2,2,0xf28a32);

	// Detale skafandra.
	AstronautBox(-6,7,3,0.8f,1.4f,0.6f,0xf28a32);
	AstronautBox( 6,7,3,0.8f,1.4f,0.6f,0xf28a32);
	AstronautBox(-2,10,3,0.7f,1.5f,0.6f,0x505b64);
	AstronautBox( 2,10,3,0.7f,1.5f,0.6f,0x505b64);
	AstronautBox(0,7,3,1.3f,0.6f,0.6f,0xf28a32);

	astronaut_initialized=1;
}

void DrawAstronaut3DPos(Position *p,float scale)
{
	AstronautBuild();

	for(int i=0;i<astronaut_triangle_count;i++)
	{
		float3 va=astronaut_v[astronaut_tri[i][0]];
		float3 vb=astronaut_v[astronaut_tri[i][1]];
		float3 vc=astronaut_v[astronaut_tri[i][2]];

		float3 
a=f3((*p).pos.x+(va.x*(*p).right.x+va.y*(*p).down.x+va.z*(*p).dir.x)*scale,
		 
(*p).pos.y+(va.x*(*p).right.y+va.y*(*p).down.y+va.z*(*p).dir.y)*scale,
		 
(*p).pos.z+(va.x*(*p).right.z+va.y*(*p).down.z+va.z*(*p).dir.z)*scale);

		float3 
b=f3((*p).pos.x+(vb.x*(*p).right.x+vb.y*(*p).down.x+vb.z*(*p).dir.x)*scale,
		 
(*p).pos.y+(vb.x*(*p).right.y+vb.y*(*p).down.y+vb.z*(*p).dir.y)*scale,
		 
(*p).pos.z+(vb.x*(*p).right.z+vb.y*(*p).down.z+vb.z*(*p).dir.z)*scale);

		float3 
c=f3((*p).pos.x+(vc.x*(*p).right.x+vc.y*(*p).down.x+vc.z*(*p).dir.x)*scale,
		 
(*p).pos.y+(vc.x*(*p).right.y+vc.y*(*p).down.y+vc.z*(*p).dir.y)*scale,
		 
(*p).pos.z+(vc.x*(*p).right.z+vc.y*(*p).down.z+vc.z*(*p).dir.z)*scale);

		FillDepthTriangle3D(a,b,c,astronaut_color[i]);
	}
}

void DrawAstronaut(void)
{
	static Position p;
	static int initialized=0;

	if(!initialized)
	{
		p.pos=f3(100,0,1700);
		p.right=f3(1,0,0);
		p.down=f3(0,1,0);
		p.dir=f3(0,0,1);
		initialized=1;
	}

	RollIt(&p,0.0005f);
	DrawAstronaut3DPos(&p,1.0f);
}

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

#403657

On 10/27/2026 1:57 PM, fir wrote:
> fir pisze:
>> 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:
>>>>>
>>>>>> 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?
>>>
>> 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
>>
>> (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)
>>
>>
> ai is besides obviously great - it just drawed me even a small cosmonaut 
> right now
> 
> https://www.youtube.com/watch?v=aZ1F4soMRHE
> 
> 
> its code is not even long
Let me ponder a guess... You have no idea how/why it works?

[...]

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

#403685

fir <profesor.fir@gmail.com> writes:


> 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

you could use ratios.

> (i some cases ai not quite tells the truth and i cant easily validate it)

Hahha... TMS?

> 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

Welcome to programming :)

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

Unlikely.

> if no that would be bad)

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.

If you want real speed with numbers I would look into fortran (actually
I would not).

 -> (numerator (/ 1 100)) => 1
 -> (denominator (/ 1 100) => 100

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

#403749

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.

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

#403751

On 10/28/2026 2:54 PM, Lawrence D’Oliveiro wrote:
> 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.

Python is pretty nice when I need to use it. Python 2 or Python 3? ;^)

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

#403684

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

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

#403687

steve g <Sgonedes1977@gmail.com> writes:
> 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.

fir was asking about a C language issue, nothing to do with GNU libc or
any other implementation of the C standard library.

What on Earth does "prefix of `-'" refer to?

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

That has nothing to do with the question, which was about 0.1 vs. 0.1f
in C source code.  And that question has already been discussed at some
length.

I don't want to discourage you from posting, but maybe you should
concentrate on asking questions rather than trying to answer them.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#403632

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

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

Page 1 of 5  [1] 2 3 4 5  Next page →

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

csiph-web