Floating number representation

[Antoine Chalons]

Hi all,

SGL have 1bit for sign, 8bits for exponent and 23bits for mantissa

DBL have 1bit for sign, 11bits for exponent and 52bits for mantissa

I'm looking for the same info about EXT representation and the context help says it varies on different platform. The G Programming Reference Manual says (Appendix A)this :

EXT on Windows have 80bits (1,16,64) that's 81 :S

EXT on PowerMacs have 128bits and are 2 DBLs tied together ((1,11,52)(1,11,52))

Is that still true, because the document seems to be quite old and I suspect MacOS platform to have changed :-o

Where can I find the up-to-date information on that ?

Thanks

[mje]

I'd expect that mac's have gone to the 80bit standard as well now that they're Intel, but it's no more than a hunch.

Easiest way to find out would be watch the memory footprint of a VI increase as you make a large array of EXT numbers on a mac system. I don't have one handy to test though...

[Antoine Chalons]

QUOTE (MJE @ Aug 8 2008, 05:00 PM)

I'd expect that mac's have gone to the 80bit standard as well now that they're Intel, but it's no more than a hunch.

That what I suspect as well but I wonder about UNIX on which MacOS is based...

QUOTE (MJE @ Aug 8 2008, 05:00 PM)

Easiest way to find out would be watch the memory footprint of a VI increase as you make a large array of EXT numbers on a mac system. I don't have one handy to test though...

Good idea, I'll test that !

Still, that information must be available somewhere :-o, anyone knows ?

[jdunham]

QUOTE (Antoine Châlons @ Aug 8 2008, 08:10 AM)

Still, that information must be available somewhere :-o, anyone knows ?

If you search the LabVIEW help for "extended mantissa", it comes right up.

It says that Windows, Linux and Mac Intel, EXT is 80 bit, and Mac PowerPC is 64 bit (same as DBL).

you should be able to cast the EXT value to a string and count the bytes, or send an email to support@ni.com; either of those would get you an authoritative answer.

[Antoine Chalons]

QUOTE (jdunham @ Aug 10 2008, 01:22 AM)

If you search the LabVIEW help for "extended mantissa", it comes right up.

It says that Windows, Linux and Mac Intel, EXT is 80 bit, and Mac PowerPC is 64 bit (same as DBL).

you should be able to cast the EXT value to a string and count the bytes, or send an email to support@ni.com; either of those would get you an authoritative answer.

Thanks for the hint, I couldn't find it because I was using the "index" tab instead of the "search" tab in the LV context help.

So that's IEEE extended-precision format :

EXT on Windows and MacIntel have 80bits (1,15,64)

[Aristos Queue]

QUOTE (Antoine Châlons @ Aug 11 2008, 01:44 AM)

Thanks for the hint, I couldn't find it because I was using the "index" tab instead of the "search" tab in the LV context help.

We've talked about removing the "index" tab now that the search tab is more efficient. It's sort of the difference between Yahoo and Google -- a human generated index of keywords only works if your mind works the same as the particular human that generated the index. The search will find all the words used in the text. Now that we have a better "page rank" system for the results, the search tab should generally be more helpful than the index.

[eaolson]

QUOTE (Aristos Queue @ Aug 11 2008, 08:42 AM)

We've talked about removing the "index" tab now that the search tab is more efficient. It's sort of the difference between Yahoo and Google -- a human generated index of keywords only works if your mind works the same as the particular human that generated the index. The search will find all the words used in the text. Now that we have a better "page rank" system for the results, the search tab should generally be more helpful than the index.

Maybe it's just because my mind does actually work the same as that particular human, but I find the opposite to be true. Mostly because the search tab searches on every word you typed in, without regards to context, and searches every possible form of the words you used (format, formatting, formatter, etc.) It almost always finds a bunch of property pages for something unrelated to what I want. Example: search on "format specifier" or "error code" and your search results aren't very useful.

[Rolf Kalbermatter]

QUOTE (jdunham @ Aug 9 2008, 06:22 PM)

If you search the LabVIEW help for "extended mantissa", it comes right up.

you should be able to cast the EXT value to a string and count the bytes, or send an email to support@ni.com; either of those would get you an authoritative answer.

No! Unless they changed something in LabVIEW >= 8.2, casting or flattening will always give you a 16 byte memory for every single EXT. The reason for this is that LabVIEW tries to maintain a consistent flattened memory stream format on all platforms so it goes through the extra hassles of not only byteswapping the data to maintain Big Endian format on the flattened side but also of extending the plattform specific EXT format to the biggest possible common denomiator which is the now obsolete 16 byte extended format of the 68K floating point unit.

Rolf Kalbermatter