From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6a77269912f77a70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-31 14:28:43 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Why no 'Floor for fixed point types Date: Fri, 31 Oct 2003 16:25:40 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3F99FBE1.1030601@comcast.net> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:1879 Date: 2003-10-31T16:25:40-06:00 List-Id: "Nick Roberts" 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/. 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.