short float ???
jacob navia
In a previous message I asked this question but it got swamped by the
discussion about vector extensions (that has degenerated into
discussions about everything else, as it happens when the people in
comp.lang.c come into play)
Specifically I want to suggest that we use the combination of
short float
to describe a floating point data type of half precision (16 bits)
This format is used in the NVIDIA graphic cards and will be available
in the x86 instruction set beginning 2010.
I would like to know if there would be any problem in using that
combination, and if it could be included in the upcoming standard.
jacob navia
P.S. I forgot this, and it is essential...
For machines that do not support this format, short float should be
identical to float, in the same way as long double can be the same
as double.
lawrenc...@siemens.com
>
> Specifically I want to suggest that we use the combination of
>
> short float
>
> to describe a floating point data type of half precision (16 bits)
That seems entirely reasonable.
> I would like to know if there would be any problem in using that
> combination, and if it could be included in the upcoming standard.
Problems? Not that I can think of, assuming you get the promotion rules
right. In particular, I think you'll want something similar to the
integer promotions to apply to short floats and convert them to floats
in similar contexts.
Included in the upcoming standard? Probably not due to insuficient
utility, lack of existing implementations, and scope of changes
required.
--
Larry Jones
I wonder if I can grow fangs when my baby teeth fall out. -- Calvin
Keith Thompson
> jacob navia <ja...@jacob.remcomp.fr> wrote:
>>
>> Specifically I want to suggest that we use the combination of
>>
>> short float
>>
>> to describe a floating point data type of half precision (16 bits)
>
> That seems entirely reasonable.
>
>> I would like to know if there would be any problem in using that
>> combination, and if it could be included in the upcoming standard.
>
> Problems? Not that I can think of, assuming you get the promotion rules
> right. In particular, I think you'll want something similar to the
> integer promotions to apply to short floats and convert them to floats
> in similar contexts.
And/or short floats could be promoted to double in the same contexts
where floats are promoted to double. (Having short float promote
to float in some contexts and to double in others might be too
confusing.)
> Included in the upcoming standard? Probably not due to insuficient
> utility, lack of existing implementations, and scope of changes
> required.
We'd need new *printf/*scanf formats, new constants in <float.h>,
new functions in <math.h>, and <complex.h>, new functionality for
the existing macros in <tgmath.h>, a new syntax for short float
constants, new promotion rules, and probably a few other things I
haven't thought of.
If we're going to go in the direction of adding more types like this,
what I'd like to see is a mechanism for defining signed, unsigned,
and floating-point types in terms of their characteristics (size,
range, etc.), and perhaps a way of defining the predefined types
(int, long double, unsigned char, ...) in terms of this new
mechanism. But I'm not holding my breath.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacob navia
> lawrenc...@siemens.com writes:
>> jacob navia <ja...@jacob.remcomp.fr> wrote:
>>> Specifically I want to suggest that we use the combination of
>>>
>>> short float
>>>
>>> to describe a floating point data type of half precision (16 bits)
>> That seems entirely reasonable.
>>
>>> I would like to know if there would be any problem in using that
>>> combination, and if it could be included in the upcoming standard.
>> Problems? Not that I can think of, assuming you get the promotion rules
>> right. In particular, I think you'll want something similar to the
>> integer promotions to apply to short floats and convert them to floats
>> in similar contexts.
>
> And/or short floats could be promoted to double in the same contexts
> where floats are promoted to double. (Having short float promote
> to float in some contexts and to double in others might be too
> confusing.)
>
>> Included in the upcoming standard? Probably not due to insuficient
>> utility, lack of existing implementations, and scope of changes
>> required.
>
> We'd need new *printf/*scanf formats,
For printf they are promoted to double precision when passed to it
> new constants in <float.h>,
trivial
> new functions in <math.h>, and <complex.h>,
Just add the "fh" suffix.
> new functionality for
> the existing macros in <tgmath.h>,
Yes
> a new syntax for short float
> constants,
FH suffix
> new promotion rules,
Yes
and probably a few other things I
> haven't thought of.
>
> If we're going to go in the direction of adding more types like this,
> what I'd like to see is a mechanism for defining signed, unsigned,
> and floating-point types in terms of their characteristics (size,
> range, etc.), and perhaps a way of defining the predefined types
> (int, long double, unsigned char, ...) in terms of this new
> mechanism. But I'm not holding my breath.
>
I have already proposed a mechanism. In any case this type exists
already in graphic cards, and will be used more and more for
applications where speed is essential, you need more dynamic range than
1/65536 and you want to save space. Essentially graphic applications.
Intel/AMD will introduce it next year.
James Kuyper
That phrasing implies implies only two choices for short float: exactly
16 bit, or identical to float. I would recommend replacing "should" with
"could", thereby implying that short float could be a type intermediate
between 16 bits and whichever type the implementation chooses for float.
Perhaps that's what you meant to imply?
That would be more consistent with the way the standard currently
handles float/double/long double and short int/int/long int/long long int.
Giacomo Catenazzi
> Hi
>
> In a previous message I asked this question but it got swamped by the
> discussion about vector extensions (that has degenerated into
> discussions about everything else, as it happens when the people in
> comp.lang.c come into play)
>
> Specifically I want to suggest that we use the combination of
>
> short float
>
> to describe a floating point data type of half precision (16 bits)
>
> This format is used in the NVIDIA graphic cards and will be available
> in the x86 instruction set beginning 2010.
16-bit for a floats seems too small.
Could you give us the precision, the range and expected use
of such floats?
My concern are about the use:
- speed: but in this case C will use double precision calculations,
thus removing the speed advantage
- size: (to store huge amount of data).
The second one requires very few changes in C, but the first one
(which I think it is the intention) give big problem to C
language.
ciao
cate
Lew Pitcher
wrote:
I have similar questions that I'd like Jacob to address.
Jacob: you mention that "this format is used in the NVIDIA graphic cards,
and will be available in the x86 instruction set beginning 2010".
1) /Which/ format is "this format"? Is the floatingpoint format used in
NVIDIA cards the /same/ format as will be available in the x86
instructionset? What about other GPUs and processors that support a "short
floatingpoint" format natively?
2) Although those specific platforms are fairly popular, they do not make up
the entirety of the C platform universe. Can you expand on why a "short
floatingpoint" format tailored to these platforms, rather than, say, a
floatingpoint format tailored to the existing RISC or FPGA/embedded
platforms available now?
3) Do you intend that C perform computations with your proposed "short
float", or will standard promotion rules apply and computations be
performed in "long float" equivalents (after promotion)? If so, then what
benefit does "short float" provide on the platforms you mentioned?
4) In a previous post, you replied (my summary, not your actual words) that
other changes to the C language that would be necessitated by your
proposed "short float" would be trivial. To me, /someone/ has to do the
actual dog-work of detailing those changes, and making a proposal as to
what the standard should say, and that /someone/ should be the person who
makes the initial "short float" proposal that initiated the changes. Are
you prepared to flesh out your proposal, including guidance on how all
those other details should look? If not, then /who/?
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
jacob navia
> I have similar questions that I'd like Jacob to address.
>
> Jacob: you mention that "this format is used in the NVIDIA graphic cards,
> and will be available in the x86 instruction set beginning 2010".
>
> 1) /Which/ format is "this format"?
16 bit float: 1 bit sign, 5 bits exponent, 10 bits mantissa
> Is the floatingpoint format used in
> NVIDIA cards the /same/ format as will be available in the x86
> instructionset?
Yes.
> What about other GPUs and processors that support a "short
> floatingpoint" format natively?
>
ATI is planning a 24 bit format, but there is no date or specifications
available
> 2) Although those specific platforms are fairly popular, they do not make up
> the entirety of the C platform universe.
Correct
> Can you expand on why a "short
> floatingpoint" format tailored to these platforms, rather than, say, a
> floatingpoint format tailored to the existing RISC or FPGA/embedded
> platforms available now?
>
The standard should just make the provision that a short float
floating point format may be available. I have never said that it should
be an specific format. For instance "long double" can be 80 bits
(x86) or 128 bits (sparc). The standard never specifies which format
is to be used for long double, just that it should be bigger or
equal to double. In the same vein the standard should never say what
format short float should have. Just that it should be smaller or
equal than float.
> 3) Do you intend that C perform computations with your proposed "short
> float",
Yes of course, if not it doesn't make any sense. This supposes hardware
support. If not this format makes little sense.
Its main objective is to provide a wide dynamic range with a small
memory footprint. NVIDIA uses this format extensively in image
brightness to accommodate the wide range available to the human eye.
> or will standard promotion rules apply and computations be
> performed in "long float" equivalents (after promotion)? If so, then what
> benefit does "short float" provide on the platforms you mentioned?
>
> 4) In a previous post, you replied (my summary, not your actual words) that
> other changes to the C language that would be necessitated by your
> proposed "short float" would be trivial. To me, /someone/ has to do the
> actual dog-work of detailing those changes, and making a proposal as to
> what the standard should say, and that /someone/ should be the person who
> makes the initial "short float" proposal that initiated the changes. Are
> you prepared to flesh out your proposal, including guidance on how all
> those other details should look? If not, then /who/?
>
I will add this format as soon as it is available for the x86
platform. I will add the necessary modifications to header files
printf, scanf etc, and make a proposal.
Thanks for your input
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Lew Pitcher
> Lew Pitcher wrote:
>> I have similar questions that I'd like Jacob to address.
>>
>> Jacob: you mention that "this format is used in the NVIDIA graphic cards,
>> and will be available in the x86 instruction set beginning 2010".
>>
>> 1) /Which/ format is "this format"?
>
> 16 bit float: 1 bit sign, 5 bits exponent, 10 bits mantissa
In which bit is the sign? What does 0 signify?
In which bits are the exponent? What range? Base?
In which bits are the mantissa? Hidden 1? What range, base?
>> Is the floatingpoint format used in
>> NVIDIA cards the /same/ format as will be available in the x86
>> instructionset?
>
> Yes.
>
>> What about other GPUs and processors that support a "short
>> floatingpoint" format natively?
>>
>
> ATI is planning a 24 bit format, but there is no date or specifications
> available
So, we now have two competing hardware definitions for a "short float".
>> 2) Although those specific platforms are fairly popular, they do not make
>> up the entirety of the C platform universe.
>
> Correct
>
>> Can you expand on why a "short
>> floatingpoint" format tailored to these platforms, rather than, say, a
>> floatingpoint format tailored to the existing RISC or FPGA/embedded
>> platforms available now?
>>
>
> The standard should just make the provision that a short float
> floating point format may be available. I have never said that it should
> be an specific format.
Yet you point to two platforms on which such a format is (or will be)
supported. Why did you mention NVIDIA and Intel at all? Why couldn't
your "short float" proposal stand on it's own?
> For instance "long double" can be 80 bits
> (x86) or 128 bits (sparc). The standard never specifies which format
> is to be used for long double, just that it should be bigger or
> equal to double. In the same vein the standard should never say what
> format short float should have. Just that it should be smaller or
> equal than float.
Again, so why tie your proposal of a generic "short float" to NVIDIA and
Intel?
>> 3) Do you intend that C perform computations with your proposed "short
>> float",
>
> Yes of course, if not it doesn't make any sense. This supposes hardware
> support. If not this format makes little sense.
So, you propose that "short float" be exempt from the pattern of promotion
rules that govern other values, and specifically the pattern of promotion
for floatingpoint numbers, where float always promotes to double ("long
float") and all floatingpoint computations (float or double) are done in
double precision.
> Its main objective is to provide a wide dynamic range with a small
> memory footprint. NVIDIA uses this format extensively in image
> brightness to accommodate the wide range available to the human eye.
It sounds like you would like the C standard to exempt "short float" from
the regular promotion rules just so that, on some platforms, it is easier
to work with hardware that provides a similar implementation. For the other
platforms, those that don't support a native small floatingpoint format in
hardware, your proposal would require that all C implementations provide
two floatingpoint math supports, one for "short float", and one for double
precision. Why should the standard support this overhead?
>> or will standard promotion rules apply and computations be
>> performed in "long float" equivalents (after promotion)? If so, then what
>> benefit does "short float" provide on the platforms you mentioned?
>>
>> 4) In a previous post, you replied (my summary, not your actual words)
>> that other changes to the C language that would be necessitated by your
>> proposed "short float" would be trivial. To me, /someone/ has to do the
>> actual dog-work of detailing those changes, and making a proposal as to
>> what the standard should say, and that /someone/ should be the person who
>> makes the initial "short float" proposal that initiated the changes. Are
>> you prepared to flesh out your proposal, including guidance on how all
>> those other details should look? If not, then /who/?
>>
>
> I will add this format as soon as it is available for the x86
> platform. I will add the necessary modifications to header files
> printf, scanf etc, and make a proposal.
Given your position that "short float" shouldn't/won't follow the existing
floatingpoint rules, it seems like additional language exemptions will be
necessary. Specifically, the promotion rules for variadic functions will
have to change to permit "short float" to pass through unchanged (i.e. as
an argument to printf(), etc.)
The followon changes seem to be, contrary to your opinion, non-trivial.
Again, for the purposes of formalizing your proposal, who will follow-up
with the details on the /other/ changes to the standard that "short float"
will require?
> Thanks for your input
You are welcome.
Vincent Lefevre
jacob navia <ja...@nospam.org> wrote:
> Lew Pitcher wrote:
> > I have similar questions that I'd like Jacob to address.
> >
> > Jacob: you mention that "this format is used in the NVIDIA graphic cards,
> > and will be available in the x86 instruction set beginning 2010".
> >
> > 1) /Which/ format is "this format"?
> 16 bit float: 1 bit sign, 5 bits exponent, 10 bits mantissa
This is different from the binary16 format from the IEEE 754 standard,
which has a 5-bit exponent and a 11-bit significand (thanks to the
implicit leading bit).
--
Vincent Lef�vre <vin...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
jacob navia
> In article <4a4b8403$0$17076$ba4a...@news.orange.fr>,
> jacob navia <ja...@nospam.org> wrote:
>
>> Lew Pitcher wrote:
>>> I have similar questions that I'd like Jacob to address.
>>>
>>> Jacob: you mention that "this format is used in the NVIDIA graphic cards,
>>> and will be available in the x86 instruction set beginning 2010".
>>>
>>> 1) /Which/ format is "this format"?
>
>> 16 bit float: 1 bit sign, 5 bits exponent, 10 bits mantissa
>
> This is different from the binary16 format from the IEEE 754 standard,
> which has a 5-bit exponent and a 11-bit significand (thanks to the
> implicit leading bit).
>
No, it is not different. I just do not count the implicit bit
obviously.
Please do not try to misunderstand things or show how clever
you are. To avoid that, I declare here:
"Mr Lefevre is much more intelligent than jacob navia"
Satisfied?
Eric Sosman
> On July 1, 2009 11:42, in comp.std.c, jacob navia (ja...@nospam.org) wrote:
>
>> Lew Pitcher wrote:
>>> I have similar questions that I'd like Jacob to address.
>>>
>>> Jacob: you mention that "this format is used in the NVIDIA graphic cards,
>>> and will be available in the x86 instruction set beginning 2010".
>>>
>>> 1) /Which/ format is "this format"?
>> 16 bit float: 1 bit sign, 5 bits exponent, 10 bits mantissa
>
> In which bit is the sign? What does 0 signify?
> In which bits are the exponent? What range? Base?
> In which bits are the mantissa? Hidden 1? What range, base?
Why would that be relevant? The Standard does not specify this
sort of thing for any other floating-point type, so why should it do
so for a `short float'? Instead, the Standard would need to choose
suitable <float.h> macro names and specify their allowed ranges.
>> ATI is planning a 24 bit format, but there is no date or specifications
>> available
>
> So, we now have two competing hardware definitions for a "short float".
Not a problem: `short double' and `long short float' are still
available. ;-)
jacob navia
>>> What about other GPUs and processors that support a "short
>>> floatingpoint" format natively?
>>>
>> ATI is planning a 24 bit format, but there is no date or specifications
>> available
>
> So, we now have two competing hardware definitions for a "short float".
>
Obviously we will have more. Like long double, short float can vary
from machine to machine. The 16 bit format is included in the
proposed revision to the IEEE754 standard.
>> The standard should just make the provision that a short float
>> floating point format may be available. I have never said that it should
>> be an specific format.
>
> Yet you point to two platforms on which such a format is (or will be)
> supported. Why did you mention NVIDIA and Intel at all? Why couldn't
> your "short float" proposal stand on it's own?
>
If there were no platforms/hardware that USES that format
this discussion would be purely academic. That is why I mentioned
real platforms that use this format.
>> For instance "long double" can be 80 bits
>> (x86) or 128 bits (sparc). The standard never specifies which format
>> is to be used for long double, just that it should be bigger or
>> equal to double. In the same vein the standard should never say what
>> format short float should have. Just that it should be smaller or
>> equal than float.
>
> Again, so why tie your proposal of a generic "short float" to NVIDIA and
> Intel?
>
I did not tie my proposal to that format at all. You are reading
something I did not write. I said that the specific format of
short float should be left unspecified as in long double.
>>> 3) Do you intend that C perform computations with your proposed "short
>>> float",
>> Yes of course, if not it doesn't make any sense. This supposes hardware
>> support. If not this format makes little sense.
>
> So, you propose that "short float" be exempt from the pattern of promotion
> rules that govern other values, and specifically the pattern of promotion
> for floatingpoint numbers, where float always promotes to double ("long
> float") and all floatingpoint computations (float or double) are done in
> double precision.
>
Excuse me but
Float a,b,c;
c = a+b;
This can be done in single precision...
>> Its main objective is to provide a wide dynamic range with a small
>> memory footprint. NVIDIA uses this format extensively in image
>> brightness to accommodate the wide range available to the human eye.
>
> It sounds like you would like the C standard to exempt "short float" from
> the regular promotion rules just so that, on some platforms, it is easier
> to work with hardware that provides a similar implementation.
Not at all.
> For the other
> platforms, those that don't support a native small floatingpoint format in
> hardware, your proposal would require that all C implementations provide
> two floatingpoint math supports, one for "short float", and one for double
> precision. Why should the standard support this overhead?
>
This is not true. Nowhere do I propose that. The
promotion rules are the same as for float. This
must be since for all platforms where this format is
not available short float is equal to float, and
the only modification for the compiler is to parse
short float as if it would have parsed just "float".
>>> or will standard promotion rules apply and computations be
>>> performed in "long float" equivalents (after promotion)? If so, then what
>>> benefit does "short float" provide on the platforms you mentioned?
>>>
>>> 4) In a previous post, you replied (my summary, not your actual words)
>>> that other changes to the C language that would be necessitated by your
>>> proposed "short float" would be trivial. To me, /someone/ has to do the
>>> actual dog-work of detailing those changes, and making a proposal as to
>>> what the standard should say, and that /someone/ should be the person who
>>> makes the initial "short float" proposal that initiated the changes. Are
>>> you prepared to flesh out your proposal, including guidance on how all
>>> those other details should look? If not, then /who/?
>>>
>> I will add this format as soon as it is available for the x86
>> platform. I will add the necessary modifications to header files
>> printf, scanf etc, and make a proposal.
>
> Given your position that "short float" shouldn't/won't follow the existing
> floatingpoint rules, it seems like additional language exemptions will be
> necessary.
Again: I have never said that.
Keith Thompson
> On July 1, 2009 11:42, in comp.std.c, jacob navia (ja...@nospam.org) wrote:
>> The standard should just make the provision that a short float
>> floating point format may be available. I have never said that it should
>> be an specific format.
>
> Yet you point to two platforms on which such a format is (or will be)
> supported. Why did you mention NVIDIA and Intel at all? Why couldn't
> your "short float" proposal stand on it's own?
I see nothing wrong with providing real-world examples to justify a
proposed language change. For example, if long double didn't already
exist, it wouldn't make much sense to propose adding it if there
weren't hardware (or at least widespread software) support for it.
The final proposal, if there is one, should be compatible with
existing 16-bit floating-point formats, but shouldn't directly
depend on them; it needs to be generic enough to be implemented
even on systems that don't have the hardware support that motivated
the suggestion. (jacob has covered this by permitting short float
to have the same representation as float.)
Keith Thompson
[...]
> This is not true. Nowhere do I propose that. The
> promotion rules are the same as for float. This
> must be since for all platforms where this format is
> not available short float is equal to float, and
> the only modification for the compiler is to parse
> short float as if it would have parsed just "float".
The compiler still has to treat it as a distinct type, even if it has
the same representation. For example this:
short float *sfp = 0;
float *fp = sfp;
would require a diagnostic.
lawrenc...@siemens.com
>
> So, you propose that "short float" be exempt from the pattern of promotion
> rules that govern other values, and specifically the pattern of promotion
> for floatingpoint numbers, where float always promotes to double ("long
> float") and all floatingpoint computations (float or double) are done in
> double precision.
That hasn't been true since K&R -- ANSI/ISO C does not automatically
promote float to double in expressions, only in unprototyped function
calls.
I would suggest that short float should behave analogously to short int
in that it's always (conceptually) promoted to float in expressions and
trust that the as-if rule will allow implementations to avoid the actual
promotion in the cases where it makes sense to do so.
--
Larry Jones
Santa's gonna skip this block for years. -- Calvin
Keith Thompson
Hmm. Personally, I think that's too complicated. I'd say leave
short float as short float in expressions. If it's easier to do
computations in float, or even in double, that's already permitted
by 6.3.1.8p2
Remember that the default argument promotions promote float to double
(e.g., in calls to variadic functions). Do we want a short float to
be implicitly promoted to float *and then* to double in some contexts?
The real problem here is that C defines a fixed set of predefined
numeric types, and there are usually either too few or too many of
them with respect to the formats defined by the hardware.
C99 added "long long" to permit integer types wider than "long", but
it also added extended integer types, enabling implementations to
support arbitrary integer formats without adding new keywords or
repeat existing ones. Why not add extended floating-point types? An
implementation could provide a type float16_t in <floattypes.h>, along
with whatever macros go along with it. Meanwhile, implementations for
systems that don't have 16-bit floating-point wouldn't have to be
changed.
Flash Gordon
> Vincent Lefevre wrote:
>> In article <4a4b8403$0$17076$ba4a...@news.orange.fr>,
>> jacob navia <ja...@nospam.org> wrote:
>>
>>> Lew Pitcher wrote:
>>>> I have similar questions that I'd like Jacob to address.
>>>>
>>>> Jacob: you mention that "this format is used in the NVIDIA graphic
>>>> cards,
>>>> and will be available in the x86 instruction set beginning 2010".
>>>>
>>>> 1) /Which/ format is "this format"?
>>
>>> 16 bit float: 1 bit sign, 5 bits exponent, 10 bits mantissa
>>
>> This is different from the binary16 format from the IEEE 754 standard,
>> which has a 5-bit exponent and a 11-bit significand (thanks to the
>> implicit leading bit).
>
> No, it is not different. I just do not count the implicit bit
> obviously.
If it is the IEEE 754 format, I think you should have mentioned this as
well in your initial proposal (you might have done, I've not checked) as
it supports your case.
Adding equivalents of Annex F and Annex G would be significant extra
work, but might be useful as an addition to your "short float" proposal.
After all, it might be useful for users to be able to determine if it is
IEEE 754!
> Please do not try to misunderstand things or show how clever
> you are. To avoid that, I declare here:
>
> "Mr Lefevre is much more intelligent than jacob navia"
>
> Satisfied?
That does not help your case. You would do better to just post the
correction and leave off the sarcasm.
--
Flash Gordon
Flash Gordon
> Lew Pitcher wrote:
>>>> What about other GPUs and processors that support a "short
>>>> floatingpoint" format natively?
<snip>
>>> The standard should just make the provision that a short float
>>> floating point format may be available. I have never said that it should
>>> be an specific format.
>>
>> Yet you point to two platforms on which such a format is (or will be)
>> supported. Why did you mention NVIDIA and Intel at all? Why couldn't
>> your "short float" proposal stand on it's own?
>
> If there were no platforms/hardware that USES that format
> this discussion would be purely academic. That is why I mentioned
> real platforms that use this format.
I agree that pointing out the hardware which supports something narrower
that is allowed for float was a good supporting point for your argument
and you were correct to mention it.
>>> For instance "long double" can be 80 bits (x86) or 128 bits (sparc).
>>> The standard never specifies which format
>>> is to be used for long double, just that it should be bigger or
>>> equal to double. In the same vein the standard should never say what
>>> format short float should have. Just that it should be smaller or
>>> equal than float.
>>
>> Again, so why tie your proposal of a generic "short float" to NVIDIA and
>> Intel?
>
> I did not tie my proposal to that format at all. You are reading
> something I did not write. I said that the specific format of
> short float should be left unspecified as in long double.
I agree that you did not tie it to a specific format, although I can see
how it could be miss-read as doing that. I would suggest that the
proposal should state that the same model is used as for the other
floating-point types, and provide suitable limits on the values just as
is done for the existing floating-point types.
>>>> 3) Do you intend that C perform computations with your proposed "short
>>>> float",
>>> Yes of course, if not it doesn't make any sense. This supposes hardware
>>> support. If not this format makes little sense.
>>
>> So, you propose that "short float" be exempt from the pattern of
>> promotion
>> rules that govern other values, and specifically the pattern of promotion
>> for floatingpoint numbers, where float always promotes to double ("long
>> float") and all floatingpoint computations (float or double) are done in
>> double precision.
>>
>
> Excuse me but
>
> Float a,b,c;
>
> c = a+b;
>
> This can be done in single precision...
Having just checked section 6.3.1.8 of N1256 Jacob is correct. For
arithmetic conversion to double is only done "if the corresponding real
type of either operand is double"
Note that the implementation is *allowed* to use a higher precision
(without changing the type), and I suggest this permission should apply
to the proposed "short float" as well.
I think the confusion might be because the maths functions take doubles
as parameters.
There is still the question of promotion as a parameter to varidac and
unprototyped functions.
>>> Its main objective is to provide a wide dynamic range with a small
>>> memory footprint. NVIDIA uses this format extensively in image
>>> brightness to accommodate the wide range available to the human eye.
>>
>> It sounds like you would like the C standard to exempt "short float" from
>> the regular promotion rules just so that, on some platforms, it is easier
>> to work with hardware that provides a similar implementation.
>
> Not at all.
Agreed. See above.
>> For the other
>> platforms, those that don't support a native small floatingpoint
>> format in
>> hardware, your proposal would require that all C implementations provide
>> two floatingpoint math supports, one for "short float", and one for
>> double
>> precision. Why should the standard support this overhead?
>
> This is not true. Nowhere do I propose that. The
> promotion rules are the same as for float. This
So you propose that when passed to varidac and non-proptotyped finctions
it is converted to double?
> must be since for all platforms where this format is
> not available short float is equal to float, and
> the only modification for the compiler is to parse
> short float as if it would have parsed just "float".
Well, as Keith points out it would have to treat it as a distinct type
(pointers etc), but I don't see that as being a major challenge for any
sanely written compiler.
>>>> or will standard promotion rules apply and computations be
>>>> performed in "long float" equivalents (after promotion)? If so, then
>>>> what
>>>> benefit does "short float" provide on the platforms you mentioned?
>>>>
>>>> 4) In a previous post, you replied (my summary, not your actual words)
>>>> that other changes to the C language that would be necessitated by your
>>>> proposed "short float" would be trivial. To me, /someone/ has to do the
>>>> actual dog-work of detailing those changes, and making a proposal as to
>>>> what the standard should say, and that /someone/ should be the
>>>> person who
>>>> makes the initial "short float" proposal that initiated the changes.
>>>> Are
>>>> you prepared to flesh out your proposal, including guidance on how all
>>>> those other details should look? If not, then /who/?
>>>>
>>> I will add this format as soon as it is available for the x86
>>> platform. I will add the necessary modifications to header files
>>> printf, scanf etc, and make a proposal.
>>
>> Given your position that "short float" shouldn't/won't follow the
>> existing
>> floatingpoint rules, it seems like additional language exemptions will be
>> necessary.
>
> Again: I have never said that.
Agreed.
Jacob, I suggest when you update your proposal you include references to
the appropriate sections of the standard specifying how float is treated
in each case, and explain that the rules for your proposed "short float"
are the same. It's extra work for you, but it might make it easier for
you to get people to accept that it would not be that major a change.
Personally I see no major problems with your proposal (only lack of
detail which someone would need to write down). So if it is as useful as
you claim (and I accept it could be) then I would be in favour of it. I
have no use for it myself though, so I'm not going to be working on it!
--
Flash Gordon
Eric Sosman
> [...]
> The real problem here is that C defines a fixed set of predefined
> numeric types, and there are usually either too few or too many of
> them with respect to the formats defined by the hardware.
>
> C99 added "long long" to permit integer types wider than "long", but
> it also added extended integer types, enabling implementations to
> support arbitrary integer formats without adding new keywords or
> repeat existing ones. Why not add extended floating-point types? An
> implementation could provide a type float16_t in <floattypes.h>, along
> with whatever macros go along with it. Meanwhile, implementations for
> systems that don't have 16-bit floating-point wouldn't have to be
> changed.
It could be difficult to come up with an appropriate
parameterization. Note that even for the extended integer
types it turned out that the bit-count alone was not enough
to describe the type: the exact, least, and fast flavors
had to be invented to augment the descriptions. F-P types,
with their additional trade-offs between range and precision,
would be even more complicated.
The good old VAX (a machine in the "too many types for C"
category) supports/ed four floating-point formats: 32, 64, 64,
and 128 bits wide. Yes, the two 64-bit formats are distinct:
one has more exponent bits, the other has more fraction bits.
Clearly, `float64_t' can't disambiguate them. (Alpha's even
worse: Its four F-P types are 32, 32, 64, and 64 bits wide,
IIRC.)
Keith Thompson
[...]
> Having just checked section 6.3.1.8 of N1256 Jacob is correct. For
> arithmetic conversion to double is only done "if the corresponding
> real type of either operand is double"
>
> Note that the implementation is *allowed* to use a higher precision
> (without changing the type), and I suggest this permission should
> apply to the proposed "short float" as well.
>
> I think the confusion might be because the maths functions take
> doubles as parameters.
But C99 has float, double, and long double versions of the <math.h>
functions (C90 didn't, but reserved the names for future
standardization). And the <tgmath.h> macros handle all three types.
> There is still the question of promotion as a parameter to varidac and
> unprototyped functions.
Right.
I think the real sources of the confusion are:
1. In K&R C, all float operands were implicitly converted to double;
C89 dropped this rule.
2. float arguments are promoted to double for variadic and
unprototyped functions.
3. Implementations are permitted to evaluate intermediate expressions
in greater precision, though this doesn't change the type
(C99 6.3.1.8p2).
It's not difficult to (incorrectly) infer from all this that there's a
general rule that floats are promoted to double.
Keith Thompson
Good point. So maybe the standard shouldn't try to define the
parameters (size, speed, etc.) that specify an extended floating-point
type.
Remember that int8_t, intfast32_t, et al aren't (necessarily) extended
types; they're typically just typedefs for existing predefined types.
An implementation might define, say, a type __int128 that's wider than
any of the standard types; note that "__int128" is in the
implementation's namespace. It would then add a set of typedefs
(int128_t, int_fast128_t, int_least128_t, intmax_t) to <stdint.h>.
Similarly, an implementation might define a type __float16, and create
some appropriate typedef in a new <stdfloat.h> header.
For <stdint.h>, names of the form (int|uint)N_t, (int|uint)leastN_t,
and (int|uint)fastN_t are reserved. For <stdfloat.h>, names of the
form float*_t could be reserved, allowing the implementation to put
whatever information it likes in the name. A VAX implementation might
provide floatF_t, floatD_t, floatG_t, and floatH_t. Some of these
would be typedefs for float, double, and long float, and others would
be typedefs for extended types.
Hallvard B Furuseth
> Remember that int8_t, intfast32_t, et al aren't (necessarily) extended
> types; they're typically just typedefs for existing predefined types.
> For <stdint.h>, names of the form (int|uint)N_t, (int|uint)leastN_t,
> and (int|uint)fastN_t are reserved. For <stdfloat.h>, names of the
> form float*_t could be reserved, allowing the implementation to put
> whatever information it likes in the name. A VAX implementation might
> provide floatF_t, floatD_t, floatG_t, and floatH_t. Some of these
> would be typedefs for float, double, and long float, and others would
> be typedefs for extended types.
I'm not sure how much a stdint-like approach is worth for floats.
Number of bits + signedness is enough to specify an integer, but it
takes at least 2 bitcounts to specify a float: exponent and mantissa.
Possibly another which describes what happens with very large/small
numbers: If the exponent grows to use more bits in some such cases (I
seem to remember hearing about such floats), and if/whether NaN, Inf,
etc. work.
Combining all these could give - well, not the cube of the number of
possibe bitcounts you'll need, since some parameter combinations are too
silly, but I imagine it could be a hefty number of macros. I don't do
numerical computing though, so I don't know if I'm describing a
real-life problem or just a theoretical one.
If it's a real-life problem, 'short float' sounds rather better to me.
For a second attempt at parametrized floats/integers I'd suggest to add
magic to the preprocessor so it expands e.g. UINT_TYPE(18) or
FLOAT_TYPE(16, 5) to the desired existing types. Except that's far out
of scope for this discussion.
--
Hallvard
Keith Thompson
> Keith Thompson writes:
>> Remember that int8_t, intfast32_t, et al aren't (necessarily) extended
>> types; they're typically just typedefs for existing predefined types.
>> (...)
>> For <stdint.h>, names of the form (int|uint)N_t, (int|uint)leastN_t,
>> and (int|uint)fastN_t are reserved. For <stdfloat.h>, names of the
>> form float*_t could be reserved, allowing the implementation to put
>> whatever information it likes in the name. A VAX implementation might
>> provide floatF_t, floatD_t, floatG_t, and floatH_t. Some of these
>> would be typedefs for float, double, and long float, and others would
>> be typedefs for extended types.
>
> I'm not sure how much a stdint-like approach is worth for floats.
>
> Number of bits + signedness is enough to specify an integer, but it
> takes at least 2 bitcounts to specify a float: exponent and mantissa.
> Possibly another which describes what happens with very large/small
> numbers: If the exponent grows to use more bits in some such cases (I
> seem to remember hearing about such floats), and if/whether NaN, Inf,
> etc. work.
Right, which is why I suggested *not* using sizes to parameterize the
typedef names in the hypothetical new <stdfloat.h> header.
The idea is that extended floating-point types (analagous to C99's
extended integer types) would provide a mechanism for adding new
system-specific FP types, and the typedefs in <stdfloat.h> would
provide more programmer-friendly ways to refer to them.
It would admittedly be difficult to write portable code using these
types. But if you know that a particular implementation provides
float16_t, you might write something like:
#include <stdfloat.h>
#ifdef FLOAT16_MAX
typedef float16_t small_float;
#else
typedef float small_float;
#endif
> Combining all these could give - well, not the cube of the number of
> possibe bitcounts you'll need, since some parameter combinations are too
> silly, but I imagine it could be a hefty number of macros. I don't do
> numerical computing though, so I don't know if I'm describing a
> real-life problem or just a theoretical one.
>
> If it's a real-life problem, 'short float' sounds rather better to me.
Yes, that would be easier in some ways. My concern is that it
would add clutter to an already cluttered system of predefined
types, and require extra work even for implementations that don't
support anything narrower than float. In addition, the extended
type approach is more flexible; it would allow an implementation to
support, say, both 16-bit and 24-bit FP, while keeping 32-bit float.
And it could cover lcc-win's qfloat as well (though perhaps with a
different name).
C's mechanism of defining fundamental types by combinations of
keywords just doesn't scale well, and waiting for a new version of
the standard to add a type is impractical. A lot of people already
think "long long" went too far.
> For a second attempt at parametrized floats/integers I'd suggest to add
> magic to the preprocessor so it expands e.g. UINT_TYPE(18) or
> FLOAT_TYPE(16, 5) to the desired existing types. Except that's far out
> of scope for this discussion.
Ada has a nice system for defining numeric types in terms of their
ranges and other attributes. The syntax wouldn't fit into C, but
perhaps the concepts would.
Eric Sosman
Looks to me like a great way to encourage portability problems.
You probably know that on the VAX, `floatD_t' and `floatH_t' mean(*)
the native 8+56 and 15+113 binary floating-point types. But you
might not know that on the DeathStation 9000, those same two names
refer to(*) decimal and hexadecimal (IBM S/3x0) floating-point ...
(*) In our imaginations, of course.
Absent a reasonably portable specification of what goes in the
"D" and "H" positions, and what it means, I'd think that support
for unusual F-P types should be a matter for compiler extensions.
If a compiler wants to provide a `__float24_t', fine -- at least
the people who decide to use it will have made a conscious decision
to sacrifice portability to achieve their ends.
Keith Thompson
I think I agree.
The advantage of <stdint.h> is that it provides a portable set of type
names; some of them are optional, but it's always possible to test
whether they exist, and the names have known meanings. <stdfloat.h>
wouldn't provide those advantages -- unless we define a way to encode
characteristics of the types in the typedef names, but that gets ugly
fast.
If we drop the <stdfloat.h> part of the idea, it might still make
sense for the standard to define "extended floating-point types",
analagous to the extended integer types briefly described in C99
6.2.5. On the other hand, perhaps the existing permission to provide
extensions makes this superfluous. I suspect that 6.2.5 explicitly
mentions extended integer types just so they can be used in
<stdint.h>.
The question is, for these 16-bit floating-point formats, should
compilers just support them as an extension (which is already
permitted), or is it worth adding the "short float" syntax to bring
them into the standard type model. The former is much more flexible
and can be done without waiting for a new standard. The latter makes
it possible to write portable code that can take advantage of the new
shorter formats if they exist, but it only adds one new type (see my
previous remarks about cluttering an already cluttered system of
predefined types).
At this point, I have no strong opinion either way.
Geoff
<ja...@jacob.remcomp.fr> wrote:
>This format is used in the NVIDIA graphic cards and will be available
>in the x86 instruction set beginning 2010.
For what purpose? How is Intel going to handle these instructions in
their compilers and what does it do for graphics drivers? Why would
this be needed in the standard rather than as an extension?
If the standard changes every time some chip vendor comes out with a
new instruction set will there ever be a standard?
Dik T. Winter
...
> I would suggest that short float should behave analogously to short int
> in that it's always (conceptually) promoted to float in expressions and
> trust that the as-if rule will allow implementations to avoid the actual
> promotion in the cases where it makes sense to do so.
Be aware that with floating-point the as-if rules can prohibit most expressions
to be evaluated in short-float in that case.
I think that the rules should be as is currently the case with float itself.
I.e. the expressions are conceptually evaluated in the type itself but there
is allowance to use higher precision in the evluation.
On the other hand, care should be taken with deciding the minimal requirements.
If they are too much tied to a 1,5,10+1 format that would disallow possible
other formats where exponent bits are traded in with mantissa bits.
With that format SFLT_DIG would be 3, but also with 1,6,9+1 or 1,5,10 it
would be 3.
I would say that when SFLT_RADIX equals 2 that SFLT_MANT_DIG should be at
least 10 to allow SFLT_DIG to be 3 (less than 3 appears, to me, overly
short).
In a similar way the other minimal requirements should be considered.
And I have no idea whether DSP's have a small floating-point format, if so,
they should also be considered (I think they are also used in audio chips).
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter
> jacob navia wrote:
...
> >>> 16 bit float: 1 bit sign, 5 bits exponent, 10 bits mantissa
> >>
> >> This is different from the binary16 format from the IEEE 754 standard,
> >> which has a 5-bit exponent and a 11-bit significand (thanks to the
> >> implicit leading bit).
> >
> > No, it is not different. I just do not count the implicit bit
> > obviously.
>
> If it is the IEEE 754 format, I think you should have mentioned this as
> well in your initial proposal (you might have done, I've not checked) as
> it supports your case.
It should have been mentioned as 1,5,10+1. There are still implementations
around without hidden bit.
Dik T. Winter
> jacob navia wrote:
...
>
Depends on the application. With audio en video, where range is much more
important than precision they will work.
> My concern are about the use:
> - speed: but in this case C will use double precision calculations,
> thus removing the speed advantage
Current C already allows expressions with floats only to be evaluatied in the
precision of floats.
Dik T. Winter
> On Tue, 30 Jun 2009 18:33:46 +0200, jacob navia
> <ja...@jacob.remcomp.fr> wrote:
>
> >This format is used in the NVIDIA graphic cards and will be available
> >in the x86 instruction set beginning 2010.
>
> For what purpose? How is Intel going to handle these instructions in
> their compilers and what does it do for graphics drivers? Why would
> this be needed in the standard rather than as an extension?
Be aware that the NVIDIA cards are already used in computations rather than
graphics only... They are also used as separate computational engines.
Dik T. Winter
> Vincent Lefevre wrote:
...
> >> 16 bit float: 1 bit sign, 5 bits exponent, 10 bits mantissa
> >
> > This is different from the binary16 format from the IEEE 754 standard,
> > which has a 5-bit exponent and a 11-bit significand (thanks to the
> > implicit leading bit).
>
> No, it is not different. I just do not count the implicit bit
> obviously.
That is not obvious at all. There are still systems around without implicit
leading bit. There is even a IEEE format without implicit bit...
Giacomo Catenazzi
> In article <beksh6-...@jones.homeip.net> lawrenc...@siemens.com writes:
> ...
> > I would suggest that short float should behave analogously to short int
> > in that it's always (conceptually) promoted to float in expressions and
> > trust that the as-if rule will allow implementations to avoid the actual
> > promotion in the cases where it makes sense to do so.
>
> Be aware that with floating-point the as-if rules can prohibit most expressions
> to be evaluated in short-float in that case.
I think this is a generic problem with float maths, but some (most?) of compiler
have a special argument to use fast-math, e.g. by relaxing the as-if rule.
I think this (short float) is the same case, if one user trusts compiler
implementation and does appropriate tests, the rules could be relaxed (but in a
non-conform manner).
> And I have no idea whether DSP's have a small floating-point format, if so,
> they should also be considered (I think they are also used in audio chips).
I see that it is used only on video/image formats (which seems to use the
proposed IEEE754 format). Anyway I wonder that such tiny floats are still
signed (or still near symmetric).
ciao
cate
jacob navia
> On Tue, 30 Jun 2009 18:33:46 +0200, jacob navia
> <ja...@jacob.remcomp.fr> wrote:
>
>> This format is used in the NVIDIA graphic cards and will be available
>> in the x86 instruction set beginning 2010.
>
> For what purpose?
I repeat: this format is used mainly in graphics to represent a wide
range of illumination data.
> How is Intel going to handle these instructions in
> their compilers
I do not know. Ask Intel
> and what does it do for graphics drivers?
This is a very small format that allows to store 4 data in the same
space that stores a single double data. This means the I/O is reduced
> Why would
> this be needed in the standard rather than as an extension?
>
Because is a natural part of the floating point range and is
already in the proposed revision to the IEEE 754 standard.
> If the standard changes every time some chip vendor comes out with a
> new instruction set will there ever be a standard?
No. There will never be a definite standard for all eternity. C evolves
and the standard evolves with the new requirements.
That's life.
Eric Sosman
> Geoff wrote:
>> [...]
>> Why would
>> this be needed in the standard rather than as an extension?
>>
> Because is a natural part of the floating point range and is
> already in the proposed revision to the IEEE 754 standard.
An unpersuasive answer. The fact that a platform defines
a format for something does not mean that the format deserves
its own C type. Where, for example, is the C type corresponding
to the Program Status Word, or the MMU register?
To paraphrase Jerome Frank[*], "Must every little format
have a type name all its own?"
[*] I'd misremembered it as due to Clemenceau, but the Net
says Frank. Most of the Net, anyhow: At least one page says
the quote was due to a Colonel House. The nice part about the
Net is that a surplus of information can obscure the truth.
--
Eric Sosman
eso...@ieee-dot-org.invalid
jacob navia
> jacob navia wrote:
>> Geoff wrote:
>>> [...]
>>> Why would
>>> this be needed in the standard rather than as an extension?
>>>
>> Because is a natural part of the floating point range and is
>> already in the proposed revision to the IEEE 754 standard.
>
> An unpersuasive answer. The fact that a platform defines
> a format for something does not mean that the format deserves
> its own C type. Where, for example, is the C type corresponding
> to the Program Status Word, or the MMU register?
>
int
How would you represent this 16 bit floats then?
As integers?
Lew Pitcher
> Eric Sosman wrote:
>> jacob navia wrote:
>>> Geoff wrote:
>>>> [...]
>>>> Why would
>>>> this be needed in the standard rather than as an extension?
>>>>
>>> Because is a natural part of the floating point range and is
>>> already in the proposed revision to the IEEE 754 standard.
>>
>> An unpersuasive answer. The fact that a platform defines
>> a format for something does not mean that the format deserves
>> its own C type. Where, for example, is the C type corresponding
>> to the Program Status Word, or the MMU register?
>>
> The program status word or the MMU has a type already
>
> int
>
> How would you represent this 16 bit floats then?
>
> As integers?
If it were obscure enough, then a structure of bitfields would do.
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Vincent Lefevre
jacob navia <ja...@nospam.org> wrote:
> No, it is not different. I just do not count the implicit bit
> obviously.
How could I know? The 16-bit float is designed for speed rather for
precision, so that it is not obvious that an implicit bit is used.
Also, this is a group about a standard. Please try to be more
rigorous and count the implicit bit as required by the definition
of a significand (which is the right word here, not "mantissa").
--
Vincent Lef�vre <vin...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Vincent Lefevre
jacob navia <ja...@nospam.org> wrote:
> The 16 bit format is included in the proposed revision to the
> IEEE754 standard.
which is no longer a proposed revision, but now *the* IEEE-754
standard (and the 1985 version is no longer a standard).
Vincent Lefevre
Flash Gordon <sm...@spam.causeway.com> wrote:
> Note that the implementation is *allowed* to use a higher precision
> (without changing the type), and I suggest this permission should apply
> to the proposed "short float" as well.
but not when __STDC_IEC_559__ is defined. I wonder whether Annex F
should also be updated to say that "short float" matches the IEEE-754
binary16 format.
Flash Gordon
> jacob navia wrote:
>> Geoff wrote:
>>> [...]
>>> Why would
>>> this be needed in the standard rather than as an extension?
>>>
>> Because is a natural part of the floating point range and is
>> already in the proposed revision to the IEEE 754 standard.
>
> An unpersuasive answer. The fact that a platform defines
> a format for something does not mean that the format deserves
> its own C type. Where, for example, is the C type corresponding
> to the Program Status Word, or the MMU register?
<snip>
Be fair, I doubt that the IEEE 754 standard covers only one platform. If
it did, I doubt they would have bothered with the standard! So, in my
opinion, the existence of the standard for a small floating point type
is an argument (but not a conclusive one) in favour of there being a
type in C that can be mapped on to it.
It won't help me in my programming, so I'm fairly neutral on the idea.
I suppose one option which would cover the processors Jacob is
interested in would be extended floating point types (named
__float_anything) and a header stdfloat.h which provides optional typedefs
float_xxxx_yyyy
where xxxx is a reference to a specific IEEE standard (e.g. 754) and
yyyy is a reference to a specific type defined by that standard. This
reduces the problem of the multiplicity of parameters at the expense of
less flexibility (if it isn't standardised you don't get it!
Obviously you would ant appropriate macros as well, e.g. format specifiers.
I don't think this is perfect either, just another possibility.
--
Flash Gordon
Vincent Lefevre
Flash Gordon <sm...@spam.causeway.com> wrote:
> I suppose one option which would cover the processors Jacob is
> interested in would be extended floating point types (named
> __float_anything) and a header stdfloat.h which provides optional typedefs
> float_xxxx_yyyy
> where xxxx is a reference to a specific IEEE standard (e.g. 754) and
> yyyy is a reference to a specific type defined by that standard. This
> reduces the problem of the multiplicity of parameters at the expense of
> less flexibility (if it isn't standardised you don't get it!
The IEEE-754 standard allows extendable precision formats, where the
precision p and the maximum exponent emax can be specified (almost)
independently.
Hallvard B Furuseth
>Hallvard B Furuseth <h.b.fu...@usit.uio.no> writes:
>> Number of bits + signedness is enough to specify an integer, but it
>> takes at least 2 bitcounts to specify a float: exponent and mantissa.
> Right, which is why I suggested *not* using sizes to parameterize the
> typedef names in the hypothetical new <stdfloat.h> header.
Sorry, I misread your floatF_t etc.
> The idea is that extended floating-point types (analagous to C99's
> extended integer types) would provide a mechanism for adding new
> system-specific FP types, and the typedefs in <stdfloat.h> would
> provide more programmer-friendly ways to refer to them.
>
> It would admittedly be difficult to write portable code using these
> types. But if you know that a particular implementation provides
> float16_t, you might write something like:
>
> #include <stdfloat.h>
> #ifdef FLOAT16_MAX
> typedef float16_t small_float;
> #else
> typedef float small_float;
> #endif
But without a relatively short list of standard float*_t names to look
for in <stdfloat.h>, there's no automatic way to find these names. The
program or user must read the compiler doc to find them, and then choose
for each platform. So such a <stdfloat.h> doesn't sound very different
from just having extended float types with implementation-defined names.
>> (...)
>> If it's a real-life problem, sounds rather better to me.
>
> Yes, that would be easier in some ways. My concern is that it
> would add clutter to an already cluttered system of predefined
> types, and require extra work even for implementations that don't
> support anything narrower than float. In addition, the extended
> type approach is more flexible; it would allow an implementation to
> support, say, both 16-bit and 24-bit FP, while keeping 32-bit float.
> And it could cover lcc-win's qfloat as well (though perhaps with a
> different name).
True. OK, I'm out of opinions:-)
--
Hallvard
BGB / cr88192
"jacob navia" <ja...@jacob.remcomp.fr> wrote in message
news:h2depl$gcr$1...@news.motzarella.org...
> Hi
>
> In a previous message I asked this question but it got swamped by the
> discussion about vector extensions (that has degenerated into discussions
> about everything else, as it happens when the people in comp.lang.c come
> into play)
>
> Specifically I want to suggest that we use the combination of
>
> short float
>
> to describe a floating point data type of half precision (16 bits)
>
> in the x86 instruction set beginning 2010.
>
> combination, and if it could be included in the upcoming standard.
cool idea, I may go add this as it is much less ugly than my current syntax:
__float16
or such...