boyne@hplvli.HP.COM (Art Boyne) (05/29/90)
richard@pantor.UUCP (Richard Sargent) writes: >> People want hex float so they can represent 7/4096, say, without >> worrying about flipping a digit and making hash. >I don't get it. Why would you code some indecipherable >'magic' fraction rather than just simply declare: > float fract = 7.0/4096.0; >and let the optimizer/compiler turn that into the correct >constant? Because algorithms to calculate trigonometric, hyperbolic, etc., functions require *exact* values down to the LSB for maximum accuracy. I have seen experimentation done with the LSB as part of efforts to improve accuracy (increase the LSB of this constant, decrease it on this other constant). It is easier, and you are more assured of getting the exact value, if you simply specify the value in hex rather than writing 1.708984374999999E-4. Look into articles on numerical analysis and computation of transcendental functions to learn of the need for exact values. Art Boyne, boyne@hplvla.hp.com
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/05/90)
In article <8924@celit.fps.com> ps@fps.com (Patricia Shanahan) writes: >If it does affect the final answer, and it overflows, it is usually best >to stop the calculation immediately and re-think the treatment of that value. I would rather say, it's an indication that there is an error in the algorithm, as is any case where something that "can't happen" does happen. It would be much better to hear about this during software development than to have incorrect computations silently performed after product delivery. (Whether occurrence of an exception is more traumatic than subtly incorrect results depends strongly on the application.) >The best case for proceeding with an out-of-range input is when smoothing >is going to be used to allow for the possibility that a few input values >are totally wrong. Treatment of "outliers" is an interesting topic in (practical) statistics, but seldom is it considered appropriate to use them the same as ordinary data. Often the preferred treatment is to totally exclude them from the computation. >A truly logical high level language use of IEEE 754 would have to make >explicit allowance for the possibility that "x > y" is neither true nor >false, but meaningless ... I am afraid that any attempt to extend high >level languages to expose IEEE to the user program will have to be >inconsistent in one of several ways. I would think so! For example, a consistent (and traditional) mathematical treatment of "infinity" could have been accomplished in either of two ways. In one, which allows for both minus and plus infinities, the infinity is not considered an actual number, but rather as a way of expressing the unbounded behavior of a function as the domain approaches some point. For example, "the limit of tan(x) as x approaches pi/2 from below is plus infinity", while "the limit of tan(x) as x approaches pi/2 from above is minus infinity". To say that the value of tan(pi/2) "is" either of these is simply incorrect; that point is a singularity, and behavior in its vicinity is more complicated than such a simplistic (IEEE FP-like) model can accommodate. The other common consistent treatment of "infinity" occurs when the real number field is completed, which can be done in essentially only one way, namely the complex number field. The domain of complex numbers can be made into a manifold (which is highly desirable) by adding a SINGLE "point at infinity"; not multiple distinct infinities. Instead of following either well-established and logical mathematical practice, IEEE 754's notion of infinities is an illegitimate combination of these: treating the limit meaning as designating actual numbers. >There is however, from a computer manufacturer point of view, tremendous >utility in having an industry standard floating point format and rounding >rules. For the forseeable future, we will be able to buy, in just about >any required technology, off the shelf implementations of floating point >hardware that will accept the same internal representation of floating >point numbers. Ah, but they don't seem to be the same! I've encountered different byte orderings among implementations of IEEE 754. I agree that a standard format would be useful (if done properly), but all the extra illogical baggage that accompanies the partially-standardized format in IEEE 754 is unjustified. Perhaps the reasonable thing to specify would be "conformance with floating-point format specifications of IEEE 754". It doesn't seem that that constrains the format sufficiently, though. (For my own applications I developed a different standard floating-point data transmission format that is inexpensively implemented using practically any existing floating-point architecture. While not suitable as an industry standard, it serves my needs much better than IEEE 754 which was supposed to do so.)