Don wrote:
This is another small imperfection we should get rid of.
The floating point types have a property called ".min", but unlike the
integer ".min", it's not the minimum!
This naming stupidity is inherited from C++. The minimum float is
-float.max. Instead, float.min is the minimum representable positive
normalized number.
(BTW there are also representable "subnormal" numbers between 0 and
float.min. So the name 'min' is _completely_ inappropriate, it's not
even the minimum absolute value).
This misnaming is bad because (a) it causes confusion; and (b) it
interfere with generic code, requiring special cases.
We should rename this while we have the chance. I don't think we should
depart too far from the C/C++ name, but anything other than ".min" will
work. I propose:
real.min ----> real.min_normal
Comments:
(1) Embedded underscores are probably not ideal, but they are already in
use in the floating point properties mant_dig, and the rarely used
max_10_exp, max_exp, min_10_exp, min_exp. They're also used in
foreach_reverse, and in the built-in version identifiers, such as X86_64
and D_InlineAsm_X86. So there seems no reason to avoid them here. But if
you have a much better idea for a name, speak now!
After I read your floating-point article on the DMD web site that name
has been bothering me too. I vote for changing it.
I wouldn't worry about the underscore, as there is already precedence
for using them in keywords and built-in properties. If people don't like
that, we should also change the others.
Would it make sense to redefine real.min to mean -real.max? It would at
least be consistent with the meaning of int.min, and perhaps it would
find use in generic code.
-Lars
