short float ???

short float ???

Post by jacob navi » Thu, 02 Jul 2009 01:33:46


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.

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.
 
 
 

short float ???

Post by jacob navi » Thu, 02 Jul 2009 01:40:19


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.

 
 
 

short float ???

Post by lawrence.j » Thu, 02 Jul 2009 05:52:46


That seems entirely reasonable.


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
 
 
 

short float ???

Post by Keith Thom » Thu, 02 Jul 2009 07:38:08


XXXX@XXXXX.COM writes:


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


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) XXXX@XXXXX.COM < http://www.yqcomputer.com/ ~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
 
 

short float ???

Post by jacob navi » Thu, 02 Jul 2009 08:01:25


For printf they are promoted to double precision when passed to it


trivial


Just add the "fh" suffix.


Yes


FH suffix


Yes

and probably a few other things I

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.
 
 
 

short float ???

Post by James Kuyp » Thu, 02 Jul 2009 19:19:12


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.
 
 
 

short float ???

Post by Giacomo Ca » Fri, 03 Jul 2009 00:01:25


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
 
 
 

short float ???

Post by Lew Pitche » Fri, 03 Jul 2009 00:17:01

On July 1, 2009 11:01, in comp.std.c, Giacomo Catenazzi ( XXXX@XXXXX.COM )




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://www.yqcomputer.com/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
 
 
 

short float ???

Post by jacob navi » Fri, 03 Jul 2009 00:42:46


16 bit float: 1 bit sign, 5 bits exponent, 10 bits mantissa


Yes.


ATI is planning a 24 bit format, but there is no date or specifications
available


Correct


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.



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.



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.yqcomputer.com/ . *** ia.edu/~lcc-win32
 
 
 

short float ???

Post by Lew Pitche » Fri, 03 Jul 2009 00:57:50

n July 1, 2009 11:42, in comp.std.c, jacob navia ( XXXX@XXXXX.COM ) wrote:


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?


So, we now have two competing hardware definitions for a "short float".


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?


Again, so why tie your proposal of a generic "short float" to NVIDIA and
Intel?


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.


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?


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?


You are welcome.

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


 
 
 

short float ???

Post by Vincent Le » Fri, 03 Jul 2009 00:58:13

In article <4a4b8403$0$17076$ XXXX@XXXXX.COM >,





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 Lefre < XXXX@XXXXX.COM > - Web: < http://www.yqcomputer.com/ ;
100% accessible validated (X)HTML - Blog: < http://www.yqcomputer.com/ ;
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
 
 
 

short float ???

Post by jacob navi » Fri, 03 Jul 2009 01:17:01


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?


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.yqcomputer.com/ . *** ia.edu/~lcc-win32
 
 
 

short float ???

Post by Eric Sosma » Fri, 03 Jul 2009 01:32:55


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.


Not a problem: `short double' and `long short float' are still
available. ;-)

--
XXXX@XXXXX.COM
 
 
 

short float ???

Post by jacob navi » Fri, 03 Jul 2009 01:36:20

ew Pitcher wrote:

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.


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



Excuse me but

Float a,b,c;

c = a+b;

This can be done in single precision...


Not at all.


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



Again: I have never said that.




--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
 
 

short float ???

Post by Keith Thom » Fri, 03 Jul 2009 01:39:41

Lew Pitcher < XXXX@XXXXX.COM > writes:

[...]
[...]

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 (The_Other_Keith) XXXX@XXXXX.COM < http://www.yqcomputer.com/ ~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"