Not Half bad: Microsoft back to 16 bits with new storage-saving type in .NET 5

Microsoft shone light today on a new type, Half, lurking within the depths of .NET 5 Preview 7, aimed at adding another IEEE 754 format as well as saving a bit of storage space. While float (equivalent to binary32) and double (equivalent to binary64) have long been familiar to users of the framework, binary16 has been missing …

[Version 1.0]

32-bit measurment accuracy

I live with these frickin' problems all the time when people make physical measurements that are generally accurate to no less than a quarter of a millimeter and then store and manipulate the measurements using floating point - creating "accurate" (the sales people love to tell everyone it's high accuracy) measurements that have digits suggesting the measurement resolution is about the diameter of an electron after they do a little trigonometry.

[Kevin McMurtrie]

Re: 32-bit measurment accuracy

Actually double is best for intermediate calculations if performance isn't an issue. A mix of addition and subtraction operations that should be mathematically commutative are not so when they're floats or doubles because the precision varies as the accumulator fluctuates. It can lead to maddening bugs where the final precision is far lower than required until the order of operations is tuned. Float does this sooner than you'd expect but it's very unlikely to happen with a double.

Forgetting to round off when displaying floats and doubles to humans whole different problem.

[Binraider]

Re: 32-bit measurment accuracy

Many industrial flow computers in the UK use 16bit registers to record the output of pressure readings, themselves transmitted by analogue 4-20mA on a Wheatstone bridge to the DAC. The underlying sensors are often duplicated with ranges of 0-100 or 0-1000mbar differentials. Without fail, noise is observed on the 16bit Conversion. For very low flow rates especially this is a problem for the sensor response is non linear, much steeper, and more uncertain at the bottom of the range.

Most sites never get anywhere near design flow rate (=1000mbar differential) because they are designed to deal with very high day-after-tomorrow winters. In other words an awful lot of flow data is subject to big errors across the board. I would’t care, but said common flow computers have got 32bit registers available, that simply aren’t used for no good reason. Swapping to them would effectively eliminate at least this noise/error.

The two gentleman that practically put the regime in have both retired, I’ve long since moved to another job. Knowledge will be lost and forgotten. Ho hum!

[Anonymous Coward]

In the next release they'll no doubt reinvent a type to store 3 digits or (upper-case) letters in a 16-bit word.

[Pascal Monett]

"the total precision was actually 11 bits"

Count on Borkzilla to not actually be capable of clearly specifying how its stuff works.

[Warm Braw]

Re: "the total precision was actually 11 bits"

It's already clearly defined and it's mostly domain-specific for certain graphics environments and ML.

[adnim]

"For when precision isn't so import"

All the time then with MS product?

[Korev]

Re: "For when precision isn't so import"

You've Excelled yourself there...

[Chairman of the Bored]

I hereby propose...

...when they get around to creating new operators for type half we get a new assignment operator called HALFASS

[steamnut]

Really?

Is it April 1st perchance?

[Concrete Gannet]

Not bfloat16?

All the cool kids are using bfloat16 (https://en.wikipedia.org/wiki/Bfloat16_floating-point_format), with an 8 bit exponent, so a wider range but less precision than Half. Why not that, as well as or instead of the IEEE half-precision type.

[JassMan]

Re: Not bfloat16?

You're forgetting that Borkzilla always check to see if an ISO or IEEE standard exists then studiously avoid using it. Presumably, all part of the 'not invented here' policy to ensure they can patent it and make interoperability impossible without paying licensing fees.

[Bill Gray]

Re: Not bfloat16?

Errmmm... if you look at the Fine Article, you'll see that this _does_ use the IEEE floating point standard for 16-bit numbers. Admittedly, if you simply leap to the assumption that Micros~1 would create its own standard, you'll usually be right. But not this time.

[Steve Channell]

This is for GPGPU integration

.net support for struct (value types) means it can natively shape blocks of memory for GPGU execution, Half is good for GPU shader code, for ML or execution on GeForce GPU.

Next addition will be full GPU integration like the unsuccessful C++ AMP

http://www.ilgpu.net/

https://docs.microsoft.com/en-us/dotnet/api/system.span-1?view=netcore-3.1