Re: Why no 'Floor for fixed point types

[Nick Roberts <nick.roberts@acm.org>]

Randy Brukardt wrote:

>>>>Do you think fixed point types should have a Floor attribute?
>>>
>>>The original answer to this showed that for some fixed point types,
 >>>it wouldn't be possible to implement it accurately. Thus, it is much
 >>>better to show what you are doing via a conversion to an appropriate
 >>>float type. Hopefully the compiler can note the easy cases and
 >>>eliminate the float operations.
>>
>>To my mind, I would not expect this form of optimisation in any compiler.
> 
> Why not? If a coding style is common, compiler writers will go out
 > their way to optimize it. Particularly if there are customers who
 > care. It's the same reason that we don't need Float => Integer rounding
 > attributes -- compilers can and should optimize the case of the
 > attribute surrounded by the type conversion.

I've never seen or heard of it. But I don't know how broad my experience is 
of these things. I don't doubt that it /could/ be done.

>>Would it not be reasonable to provide 'Floor for fixed-point types which
>>fulfil certain conditions?
>>
>>For example, it might be required that the delta be less than 1.0 (and
>>that the range includes at least one integer). Alternatively, it might
 >>be required that the delta is precisely 1.0 (with conditions on the
 >>range).
> 
> To make sense, the 'Small (the delta is irrelevant) would have to be
 > 1/<some integer>. The default powers of 2 and 10 would work, but not
 > Eachus's PI/2000.

Actually, I think, to really make sense, both 'Delta and 'Small would have 
to be exactly 1.0, and the range ought to be required to be non-null and of 
two integral values not equal to each other.

>>These conditions might be imposed statically (erroneous) or dynamically
>>(raising an exception). I suppose the dynamic option would fit easier with
>>the possibility of the fixed point type being a generic formal.
> 
> Yes, it couldn't be a legality check - that would be a "generic contract
> model violation". Typically, that's how otherwise good ideas get shot down -
> by someone saying "contract model violation".
> 
> And it would be weird for this to be a dynamic check. The problem, after
> all, is one of accuracy, not that the operation doesn't make sense
> mathematically. If 'floor worked like the mixed multiply, it would OK, but
> that seems like overkill for a minor problem.

I think I agree with you here.

>>After all, if Float'Floor(Float(X)) is going to produce a silly result
>>(without itself raising Constraint_Error), what's wrong with
>>Some_Fixed'Floor(X) raising Constraint_Error? Surely that would actually
>>be better?
> 
> But Float'Floor(Float(X)) *will* produce a reasonable result. The problem
 > is that it may not be possible to represent that result as a value of
> Some_Fixed (if the type doesn't have integer values).

I disagree that the result would be reasonable. If we had:

    type Measured_Weight is delta 0.02 range 0.20 .. 0.80;
    W: Measured_Weight;

then of course Float'Floor(Float(W)) would be certain to produce 0.0 
regardless of the (valid) value of W. In these kinds of case, it just 
doesn't make sense to find the floor of W at all. Trying to do so would 
indicate a programming error, and it would be better for it to produce an 
error (preferably at compile time, but better an error when executed than 
just blithely carrying on).

 > Producing one of the "nearby" model numbers [the normal handling of
 > accuracy issues] wouldn't make sense for this function (if you ask
 > for an integer value, getting 3.14159 would be surprising).

I agree!

Perhaps in the case of the above example the programmer may have meant (or 
would have decided, having thought harder) to have found 
Float'Floor(Float(W)*1000) and displayed the resulting three digits (maybe 
on a 7-segment display). This thought suggests to me that you are 
essentially right, Randy. To my mind, it makes sense to convert to Float if 
one is then going to scale by some orders of magnitude before calculating a 
floor.

I don't think it is likely to be a (sensible) requirement for a compiler to 
optimise an expression such as Integer(Float'Floor(Float(W)*1000)) to 
eliminate the actual conversion to (and from) a floating point 
representation in these kinds of cases, because I doubt that they would be 
at all speed-critical.

I'm not really sure of all the practical uses of calculating the floor of a 
number. Can you think of any realistic situation where the speed of a 
Integer(Float'Floor(Float(...)) expression would be that important?

In fact, could the same be said of Integer(Float'Rounding(...)) expressions?

-- 
Nick Roberts