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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fae85d3a03b5f78c X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: Fixed-point Date: 1997/04/11 Message-ID: <334E763C.68B4@lmtas.lmco.com>#1/1 X-Deja-AN: 232325280 References: <333C08A7.446B9B3D@innocon.com> <1997Mar30.111252.1@eisner> Organization: Lockheed Martin Tactical Aircraft Systems Newsgroups: comp.lang.ada Date: 1997-04-11T00:00:00+00:00 List-Id: Larry Kilgallen wrote: > > In article , bobduff@world.std.com (Robert A Duff) writes: > > In article <333C08A7.446B9B3D@innocon.com>, > > Jeff Carter wrote: > >>"The designers of Ada ... tried to get too fancy. Instead of restricting > >>the type to words commensurate with the natural word length of the > >>computer, they gave us a more general definition that allows for words > >>of any bit length and any resolution. ... [T]he end result was the same: > >>fixed-point operations are so slow in Ada that few people bother to use > >>the type, and many Ada shops prohibit their use as a matter programming > >>style." > > > > Sounds like nonsense, to me. Implementations of Ada's fixed-point types > > *do* use "natural word length" to store data, and do operations. And > > the language definition encourages that. So what's the problem? > > The problem is that while folks on this newsgroup so far unanimously > disagree with the published remarks, for the publication readership > the slam against Ada goes unchallenged. Someone who has experience > with fixed-point types should write a polite rebuttal and send it to > the publication. Some comments: (1) One important sentence was left out of this quote (the last ellipse): "I've never been quite clear as to whether the problem came from this very general (and somewhat unrealistic) definition, or simply from the fact that the compiler builders weren't interested in fixed-point arithmetic and tended to add it as an afterthought." There are certainly some compilers out there that do not perform fixed-point efficiently. Since Mr. Crenshaw does say that he's not sure why this is the case, I don't think it's fair to call his comments "nonsense". (2) There's some other context that's left out as well. Mr. Crenshaw's series is on how to do fixed point efficiently in C/C++. He provides actual C/C++ code to do this. I've been translating this code into Ada, and I do find it to be quite efficient - more so that the Ada built-in fixed point type, for my particular Ada compiler. Any rebuttal should include actual results comparing Mr. Crenshaw's algorithms to the ones used in a particular Ada implementation. Of course, Mr. Crenshaw's algorithms limit the type range, etc. - which I believe was his point. (3) Although the article does say that Ada is inefficient, his remarks should be compared to what he says about other languages: "This discussion gives me an excuse to vent one of my major frustrations against high-order languages like C, C++, and Pascal. The designers of the CPUs are well aware that the product of two N-bit numbers is a 2N-bit result. Virtually every processor that supports multiplication at all provides for this double-length product. The CPU isn't the problem, the language that hides that double-length result is.... At least two languages [JOVIAL and Ada] have attempted to provide for true fixed-point arithmetic... JOVIAL is now used only for maintaining aerospace software that hasn't yet been converted to Ada." (4) Here's some information if anyone wants to write a letter to the editor: Embedded Systems Programming Volume 10, Number 4 (April 1997) "More on Multiplication," Programmer's Toolbox by Jack W. Crenshaw. Mr. Crenshaw can be reached at 72325.1327@compuserve.com. Editor-in-chief Lindsey Vereen can be reached at lvereen@mfi.com. ESP has a web page at www.embedded.com. The April '97 issue is at http://www.embedded.com/97/toc9704.htm but unfortunately this column isn't included. > > Generally I see this soft of "call for rebuttal" on the Team Ada > mailing list, but I suppose finding such uniform opinion on c.l.a > is a good "trial by fire" for the concept of a rebuttal. > > Larry Kilgallen -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com