• Advertisement
Sign in to follow this  

C99 Hexfloats

This topic is 2087 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Back in August paphi made a couple of suggestions, including one I just attempted to use - and then went looking in the docs, WIP, and unplanned items, when it only almost worked. That suggestion was C99 hexfloats. These are one of the nicest ways to encode a floating point literal that is not really accurately expressible in decimal. Andreas, approximately when (a version; patches welcome as I don't have time; I don't want in the language) would this be potentially available?

What I got when I attempted was rather interesting however, and could be perceived as a bug:

float x = 0x219AEFp-24;
// X gets the value 2202351.0f, which is hex 0x219AEF. The data from the p to the ; was ignored!


I worked around it by simply doing the conversion myself:


float x = float(0x219AEF) / (2 << 23); // Don't forget to decrement the exponent when converting!

Share this post


Link to post
Share on other sites
Advertisement
You can write (1 << 24) and not decrement it by 1.

Share this post


Link to post
Share on other sites
Very true! I was so caught up in the workaround, and in thinking about it as shorthand for pow(2, N), that I missed that. Thanks!

Share this post


Link to post
Share on other sites
Personally, in all my 25+ years of programming experience I've never seen the use of hex floats. smile.png

I can understand their usefulness when a precise number is wanted, but I don't consider this a priority for AngelScript. Personally I will not spend time on implementing this anytime soon. However, should you feel inclined to implement it yourself I'll gladly include it in the library.

Paphi's other suggestion of custom literal constants, i.e. tokens that get converted to a registered type during the build itself (similar to string constants) is also a low priority item, and still on my to-do list for a distant release.



The fact that the 'p-24' part was ignored in your script above must be a bug. It should have given you a parser error as the 'p' should have been interpreted as an identifier. I'll look into this and have it fixed. Edited by Andreas Jonsson

Share this post


Link to post
Share on other sites
Just got around to test this, and the bug that the parser was ignoring the invalid suffix 'p-24' had already been fixed in the WIP.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement