Neuchips Tapes Out Recommendation Accelerator for World-Beating
Accuracy:
https://www.eetimes.com/neuchips-tapes-out-recommendation-accelerator-for-world-beating-accuracy/

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.

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.

w
On 6/24/22 2:42 PM, 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.
>
> 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.

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

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.

On Saturday, June 25, 2022 at 10:13:18 AM UTC+2, gah4 wrote:
> 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.

But that does not mean a special real kind is unreachable: it would appear in the list of supported real kinds and with KIND= you can also get variables of that special kind ...

Regards,

Arjen

On 6/27/22 9:41 AM, Arjen Markus wrote:
> On Saturday, June 25, 2022 at 10:13:18 AM UTC+2, gah4 wrote:
>> 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.
>
> But that does not mean a special real kind is unreachable: it would appear in the list of supported real kinds and with KIND= you can also get variables of that special kind ...

Yes, if the programmer knows the kind, he could just define the
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

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 Thursday, June 30, 2022 at 2:16:31 AM UTC+12, Beliavsky wrote:
> 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.
The ones I see are medical textbooks and I have been flagging them as spam too.