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,e0423f8984d47f76 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-17 13:56:30 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Problems converting Float to Integer efficiently Date: Fri, 17 Oct 2003 15:57:32 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: 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:1103 Date: 2003-10-17T15:57:32-05:00 List-Id: "Dr. Adrian Wrigley" wrote in message news:Ku4hb.8589$RU4.82535@newsfep4-glfd.server.ntli.net... > It's a bit disappointing that the compiler does not produce code like this for > some "obvious" source code. I dislike Ada's default of rounding to nearest, and > it seems that a series of Float=>Integer attributes might help the compiler. Not really, and they would be messy to define. When we discussed this in the ARG, we concluded that compilers ought to recognize the pattern Integer(Float'Truncation(Foo)), etc. if that will generate better code (it usually will). In particular, the code needed to round the float as part of the conversion to Integer should be omitted (it is already an integer value). That actually will be in the AARM as a note to implementors (see AI-267). So, if you are not getting good code from this, you should complain to your implementor. This is not a language issue, just a quality of implementation one. Randy.