CustomFloat!(5, 2).epsilon yields infinity instead of expected 0.03125.
In my oppinion, if denormalized numbers are allowed, epsilon should just be sign=0, exponent=0, significand=1. I don't know, how IEEE defines epsilon, if denormalized numbers are not allowed.
Comment #1 by dlang — 2019-10-02T18:02:12Z
What I wrote about the general case is wrong. Sorry.
Comment #2 by bugzilla — 2019-10-09T09:56:50Z
Meanwhile I found out, that .epsilon can be really snappish. In some cases it can only be displayed as denormalized value. If denormalized values are not supported, epsilon cannot be represented at all.
For me, the question arises, what to do in such cases.
a) Just not define .epsilon for these types? Might be hard to implement.
b) Use NaN? But what, if NaN is not available?
c) Use the smallest value greater 0 instead? In rare cases, even this value might not exist. CustomFloat(7,1,CustomFloatFlags.allowDenormZeroOnly | CustomFloatFlags.nan). Here only +/- 0 and NaN exists.
d) Use 1+epsilon - 1. This leaves the answer to this question to the routine converting real to CustomFloat. But in some cases 1+epsilon does not exist too, see above. But if it exists, it's much simpler to construct than epsilon itself.
e) Use return type real? I expect some other trouble with that approach.
I tend to d) + completely prohibiting types, where this doesn't work. These are stange types that are of no use anyway.