Re: Why no 'Floor for fixed point types

["Randy Brukardt" <randy@rrsoftware.com>]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:bns7j9$15h0a9$1@ID-25716.news.uni-berlin.de...
> 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.

> 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.

> 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.

> 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). 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).

                 Randy.