LabVIEW Idea Exchange

[#1]

The updated to IEEE 754 adds a half-float and a platform independent quad float. We have a project where a data source will be giving us values in half floats (16-bit). It would also be nice to support quad floats (128-bit) since the current EXT datatype is platform dependent.

[#2]

I kudo'd the idea, because I'm a big fan of IEEE 754.

Let's dig a little bit deeper...

This would be easier if the processor manufacturers (e.g., of x86, PowerPC, etc.) supported these formats.  Otherwise, we have to do them all in software, which is generally slower.  (E.g., with LabVIEW for Sun on the SPARC architecture, we implemented Extended precision the same as the new IEEE quad format, but it was all in software.  It was precise but slow.  By the way, because of this, the platform-independent save format in LabVIEW for Extendeds is also the 128-bit IEEE quad format.)

Then there are the math libraries that sit on top of the processor.  Microsoft doesn't give us high-level development tools for the 80-bit Extended floats, so we just write that code in assembly language.  On the flip side, Sun gave us Extended (quad float) math libraries, even though their processor didn't support the format directly.  So, both LabVIEW for Windows and LabVIEW for Sun supported Extended.  HP, on the other hand, gave us neither a processor that supported extended (PA-RISC) nor math libraries that supported Extended.  So LabVIEW for HP treated Extended as 64-bit values.

So, without processors and/or low-level math libraries (add, subtract, multiply, divide, square root, a few transcendental functions) that support these new formats, it will be difficult to have full support for these data types.  And by "full support", I mean all numeric functions, the Analysis library, etc.

While we wait for this support from our vendors, what about having a conversion library that converts half-float to/from float or double?  Would this suffice?

[#3]

Understood. A conversion library would be perfect. We don't need to support quads for our project. The halfs will be cast up to DBL anyway to play nice with the rest of our software. Not sure if we'll do it in a DLL or twiddle the bits in LabVIEW.

[#4]

I would love to vote for this idea. After reading Brian's comments I decided not. Without processor support, many people can be disappointed with the performance.

[#5]

It's hard enough just to get full support for SGL!  Let's start with that...

[#6]

Fixed link for Get full support for SGL.

[#7]

Sorry!  I do wish the "http:" default in the Link dialog was either absent or selected.