I might still prefer this way. But we would need to document that these types are not intended to be equivalent to binary32, binary64, etc. in IEEE754.
Nod, they're functionally equivalent, not bit-for-bit equivalent. John.
Adding a sentence or two in the docs should be sufficient.
PS we could also use float_single_t, float_double_t, float_quad_t etc.
Those are also good names. But somehow I feel that adding
yet another set of names might just be going in the wrong direction.
I would still stick with float32_t, float64_t, etc. But I could easily
be swayed to another naming convention. Can anyone come up with
any with convincing reason why a certain naming convention
should be selected, or why not?
John, do you have any kind of strong tendency?
My personal favorites are:
1) float32_t, float64_t, etc...
2) float_single_t, float_double_t, float_quad_t, etc...
3) float24_t, float53_t, etc...
Sincerely, Chris.
On Friday, November 1, 2013 5:54 PM, John Maddock
I might still prefer this way. But we would need to document that these types are not intended to be equivalent to binary32, binary64, etc. in IEEE754.
Nod, they're functionally equivalent, not bit-for-bit equivalent. John. PS we could also use float_single_t, float_double_t, float_quad_t etc. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost