Mr Hermannsfeldt writes: <begin extract> Now, it is true that DFP helps with some of those problems, but when programming in a high-level language one generally doesn't know what kind of floating point will be used. Some, like HFP, give a truncated quotient on divide (except on the 360/91), others a rounded result. If you want identical results on all systems, you have to be very careful with rounding modes. (Even if you know its DFP, you might not be able to set the rounding mode.) </end extract>
I am happy with his concession that "DFP helps with some of these problems", but I find the rest of this passage puzzling. I cannot imagine not knowing what kind of floating-point is used or selectable by a statement-level procedural language (SLPL) implementation I am using. I use PL/I a lot, particularly for throwaway, investigational routines; and for my purposes I most of the time choose to have it use BFP. Rounding modes I specify in trivial, macro-generated assembly-language subroutines. SLPLs are convenient, but they always represent someone else's (not always congenial) world view. When I can, I avoid C and its dialects because I find their world view uncongenial, and in general I use assembly language to modify the behavior of an SLPL when I find that behavior unsatisfactory. I have no objection to the teaching of a little programming to demystify computing (in much the way that a little physics is taught to secondary-school students). That said, people who cannot tame an SLPL, make it do their wills, are not professional programmers in any meaningful sense. It is not clear to me that they any longer have useful work to do. (There was a time when one needed to be able to program a little in order to use computers at all, but that time is long past.) John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
