Add templates for ieee754 types

[BobSmun]

Adds binary floating point and decimal (both binary and decimal encoding) floating point types specified by IEEE 754 2019

Designed as templates, to allow various parameters to be modified (exponent bit length, significand bit length, exponent bias), enabling the creation of types that may not be explicitly defined but are otherwise compatible

[BobSmun]

Some progress notes:

• endian modification of templates are affected by Template parameters (and locals) are unintuitively affected by endianness PatternLanguage#119
• binary floating points tested against a very small handful of native float / double types
• decimal floating point still needs testing
• is there a framework for unit testing patterns using multiple examples?

[paxcut]

I am aware this is just a draft but there are some details that may have been overlooked. This post is only to attract attention to those details.

• There isn't a single header in the include type folder that defines a namespace using the name of the header. The namespace used is always just type. The name of the include file is used as the name of the type being defined. Is there a valid reason to stray from the standard?

• Beware that if the header file is imported (not included) then any macro defined in the importing file is not propagated to the imported files. Thus, if you #define IEEE754_SUPPRESS_USAGE_WARNING or IEEE754_UNSEAL and then import type.ieee754_binary the defines will have no effect on the ieee754_binary header. Only #include "type/ieee754_binary.pat" will allow suppressing warnings or unseal the struct.

is there a framework for unit testing patterns using multiple examples?

Yes there is. Check for example the tests for the tiff format.

There are a lot more issues(eg inf,nan) but seeing that this is untested draft they may be addressed as work continues.

[BobSmun]

Thought it would be better to kick things off as a draft PR, than for me to forget entirely

• namespace - to me, the ieee754 part makes more sense as a namespace than embedded in the type name (type::ieee754::binary vs type::ieee754_binary) and seems important enough to keep as part of the type 'path' one way or the other. I do agree that it is a rare instance, among the other types, of trying to group things in that way. Dropping the type namespace was less intentional and I will add that in next revision

• macro defines - Ahh yes, that was something I forgot to point out with the earlier 'progress' comment. These were more ideas I was playing with, to allow for a kind of debug functionality via feature flags. As noted, only works with #include. I suspect there is a better way to do that, that would also work with #import - such as perhaps using the in specifier on global variables - assuming the feature flags make enough sense to survive, of course

Started writing these with the initial intention to only display, but started experimenting with transform in ieee754_binary to try to improve their usability as a numeric type. Wouldn't be surprised if things like inf / nan weren't translated well with that change. Also, only very minor optimizations were done (primarily the bit shifts and some ternaries), to try to keep things readable while decoding the IEEE standard

[WerWolv]

Thanks a lot! Would love to have these merged if everything's ready