info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
OT: New Floating Point Format
136 views
Skip to first unread message
Gary Scott
Jun 24, 2022, 12:00:02 PM6/24/22
to
Neuchips Tapes Out Recommendation Accelerator for World-Beating
Accuracy:
https://www.eetimes.com/neuchips-tapes-out-recommendation-accelerator-for-world-beating-accuracy/
Accuracy:
https://www.eetimes.com/neuchips-tapes-out-recommendation-accelerator-for-world-beating-accuracy/
gah4
Jun 24, 2022, 3:43:03 PM6/24/22
to
For those TL;DR, they are (there are more than one) 8 bit formats.
Or, to keep up with the recent discussion.
REAL*1
There are even unsigned forms.
Ron Shepard
Jun 25, 2022, 2:05:10 AM6/25/22
to
w
I once worked on a lossy data compression method for iterative
procedures that required only 3 or 4 bits of precision each iteration. I
implemented it in fixed-point arithmetic, packed into integer words, but
floating point would have also worked alright. In this 8-bit
representation, that would have been 1 sign bit, 4 exponent bits, and 3
mantissa bits (4 counting the hidden bit). The final result was a 64-bit
floating point vector, but it was accumulated over several iterations, 3
or 4 bits at a time.
$.02 -Ron Shepard
procedures that required only 3 or 4 bits of precision each iteration. I
implemented it in fixed-point arithmetic, packed into integer words, but
floating point would have also worked alright. In this 8-bit
representation, that would have been 1 sign bit, 4 exponent bits, and 3
mantissa bits (4 counting the hidden bit). The final result was a 64-bit
floating point vector, but it was accumulated over several iterations, 3
or 4 bits at a time.
$.02 -Ron Shepard
gah4
Jun 25, 2022, 4:13:18 AM6/25/22
to
On Friday, June 24, 2022 at 11:05:10 PM UTC-7, Ron Shepard wrote:
(snip, I wrote)
> > REAL*1
> I once worked on a lossy data compression method for iterative
> procedures that required only 3 or 4 bits of precision each iteration. I
> implemented it in fixed-point arithmetic, packed into integer words, but
> floating point would have also worked alright. In this 8-bit
> representation, that would have been 1 sign bit, 4 exponent bits, and 3
> mantissa bits (4 counting the hidden bit). The final result was a 64-bit
> floating point vector, but it was accumulated over several iterations, 3
> or 4 bits at a time.
It seems though that it allows, or can allow, for different exponent
bits by 1s. SELECTED_REAL_KIND only allows counting
in units of 3.32 bits, so too coarse for this system.
And then there is unsigned.
(snip, I wrote)
> > REAL*1
> I once worked on a lossy data compression method for iterative
> procedures that required only 3 or 4 bits of precision each iteration. I
> implemented it in fixed-point arithmetic, packed into integer words, but
> floating point would have also worked alright. In this 8-bit
> representation, that would have been 1 sign bit, 4 exponent bits, and 3
> mantissa bits (4 counting the hidden bit). The final result was a 64-bit
> floating point vector, but it was accumulated over several iterations, 3
> or 4 bits at a time.
bits by 1s. SELECTED_REAL_KIND only allows counting
in units of 3.32 bits, so too coarse for this system.
And then there is unsigned.
Arjen Markus
Jun 27, 2022, 10:42:03 AM6/27/22
to
Regards,
Arjen
Ron Shepard
Jun 27, 2022, 12:38:02 PM6/27/22
to
appropriate parameter constant in a single place, and let that
definition propagate throughout the rest of the code in the usual way.
Also, there have been suggestions in the past to allow an optional
argument to selected_real_kind to specify the precision in bits rather
than decimal digits. That could be added at any time, in a backward
compatible way, once it is practically useful.
I realize in these discussions how many programmers do not appreciate
how well designed and how flexible the fortran kind system really is.
Compare to C for example, where each of these floating point kinds that
differ by one mantissa bit from each other is specified with some
obscure incantation of "short short long short long short...".
There are two modifications that might have been useful back when f90
first introduced this into the language. One is to have separate kind
values for different types, and the other would have been to have the
kind values be a type distinct from other integers. Either or both of
those things might have helped programmers eliminate coding errors. But
overall, it works very well in practice even as is, with almost
unlimited ability to expand and adapt in the future if/when these kinds
of floating point types become available.
$.02 -Ron Shepard
Beliavsky
Jun 29, 2022, 10:16:31 AM6/29/22
to
On Friday, June 24, 2022 at 3:43:03 PM UTC-4, gah4 wrote:
> On Friday, June 24, 2022 at 9:00:02 AM UTC-7, Gary Scott wrote:
> > Neuchips Tapes Out Recommendation Accelerator for World-Beating
> > Accuracy:
> > https://www.eetimes.com/neuchips-tapes-out-recommendation-accelerator-for-world-beating-accuracy/
> I would hope the new floating point formats are on-topic here.
Recently there has been much spam about pirated textbooks posted in the Google Groups interface of comp.lang.fortran. I have been flagging it as spam and encourage others to do so. I think posts with an indirect connection to Fortran are fine here and at least show that the forum is still alive.
> On Friday, June 24, 2022 at 9:00:02 AM UTC-7, Gary Scott wrote:
> > Neuchips Tapes Out Recommendation Accelerator for World-Beating
> > Accuracy:
> > https://www.eetimes.com/neuchips-tapes-out-recommendation-accelerator-for-world-beating-accuracy/
> I would hope the new floating point formats are on-topic here.
jfh
Jun 29, 2022, 5:14:18 PM6/29/22
to
0 new messages