(-)Inf and NaN cannot be fully avoided by trying to prevent AutoHotkey from generating them because DLL calls can return them (i.e. Log(0) is not the primary problem here). However they are handled, they should be handled consistently.
Code: Select all
; This works in current v2. Inf := -Log(0) NaN := Inf - Inf MsgBox(Type(Inf)) ; => "Float" MsgBox(Inf is "Float") ; => 0 MsgBox(Type(NaN)) ; => "Float" MsgBox(NaN is "Float") ; => 0
More mysteriously, Inf is "alnum", Inf is "alpha", and Inf is "lower" are all true, but this is not true of -Inf.
Based on what other programming languages do (e.g. C, C++, and Python), and therefore what people have come to expect, I suggest classifying (-)Inf and NaN as Float (as Type does but is does not).
This has the unfortunate implication of making NaN is "number" true using the current scheme.
Perhaps the current scheme should be changed to make is "number" return true only for finite numeric values (i.e. numeric values other than (-)Inf and NaN). Asking if something is a number is most often done to ensure performing arithmetic on it will work correctly. At least there should be some way to ask this question. is "numeric" could be introduced to include (-)Inf and NaN ('numerical' algorithms often make use of "not-a-number" values) for when programmers want to allow these values to pass through a check.
I cannot imagine an excuse for classifying positive infinity as lowercase.