Page 1 of 1

[v2.0.11] Signed hexadecimal double-precision floating-point value

Posted: 05 Jan 2024, 12:38
by Rohwedder
Manual: https://www.autohotkey.com/docs/v2/lib/Format.htm#Types
Quote: For example, Format("{:a}", 255) returns 0x1.fe0000p+7.
Here it returns: 0x1.fe00000000000p+7

(When will Autohotkey be able to calculate mathematically with such hex numbers?)
PI = 3.1415926535897931 = 0x1.921fb54442d18p+1

Re: [v2.0.11] Signed hexadecimal double-precision floating-point value

Posted: 05 Jan 2024, 13:43
by Ragnar
In v1, this returns 0x1.fe0000p+7. The difference is probably due to the following change mentioned in https://www.autohotkey.com/docs/v2/v2-changes.htm#types:
The default format specifier for floating-point numbers is now .17g (was 0.6f), which is more compact and more accurate in many cases. The default cannot be changed, but Format can be used to get different formatting.

Re: [v2.0.11] Signed hexadecimal double-precision floating-point value

Posted: 19 Jan 2024, 07:15
by lexikos
The example is incorrect, but the documentation otherwise doesn't specify the default number of digits. If you want a specific number, you must specify it.

Format("{:a}", 255) internally does the equivalent of _swprintf(target, L"%a", 255.0). The C runtime is entirely responsible for deciding the default precision and doing the formatting. v1 is compiled with Visual C++ 2010, whereas current versions are compiled with Visual C++ 2022. The current documentation for a says "Default precision is 13". I assume that wasn't true for 2010.

The "default format specifier" is used by the default formatting. "{:a}" clearly provides a format specifier. If "{}" or "{:s}" was used instead, the default format specifier for floating-point numbers still wouldn't be used, because 255 is not a floating-point number.

Re: [v2.0.11] Signed hexadecimal double-precision floating-point value

Posted: 15 Feb 2024, 18:45
by Ragnar
I've moved this topic from "Bug Reports" to "Suggestions on Documentation Improvements".

Re: [v2.0.11] Signed hexadecimal double-precision floating-point value  Topic is solved

Posted: 07 Mar 2024, 08:52
by Ragnar
Thanks for reporting. I've fixed this and some other Format examples.