From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 30 Apr 93 17:34:21 GMT From: news.crd.ge.com!e7sa!groleau@uunet.uu.net (Wes Groleau X7574) Subject: Fixed point definition Message-ID: List-Id: I have to disagree with some of the fixed point discussion. If your system REQUIREMENT is that the precision be to 0.1, then you write "delta 0.1". If your system REQUIREMENT is that values lower than 0.5 not be accepted, then you write "range 0.5 .." The fact that 0.5 itself can't be represented is NOT a violation of the requirement. However, a conversion from an exact 0.5 in float or ASCII/fixed_io should NOT raise a constraint_error. It should be rounded into the range. Whether or not the LRM says so is not my concern (attention 9X folks!) On the other hand, if the REQUIREMENT is that 0.5 be accepted, then one must write code to ensure that this happens. A related topic: As someone pointed out, a validated compiler may use extra bits for greater precision as long as the model numbers are representable. There are at least two compilers that do this, such that 'SMALL does not always give the value of the least-significant bit--even when set by a rep. spec. The project I'm on has to interface with pre-existing items in hardware and in other languages. Because of this 'SMALL discrepancy (no pun intended), fixed point on these interfaces has to use integers and/or packed records on and explicit scaling in Ada source code. This is clearly contrary to the Ada goal of supporting abstraction. The cause of this is also IMHO contrary to the purpose of rep. specs: to allow the programmer, when necessary, to control representation. (another attention 9X folks!) Wes G.