curious about 8 byte LOGICAL...
in [Fortran]
|
Prev: CVF help -- was: Re: It Hurts When I Do This -- diversion...
Next: Reading unknown number of lines in unknown number of files
From: Gordon Sande on 23 Apr 2008 15:09 On 2008-04-23 15:59:53 -0300, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> said: > jamesgiles(a)att.net wrote: >> On Apr 22, 11:50 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> >> wrote: > >>> Even with cheap memory, I find it unlikely that the default will >>> be eight byte integer and real, with 16 byte double precision. >>> (Until good hardware support for 16 byte reals.) > >> IEEE is standardizing it as we speak (actually, it's behind >> schedule). IEEE single is no longer of sufficient precision for even >> moderate length scientific/numerical programs. > > I would say that there are still plenty of problems where 24 bits > is enough, but yes, for larger problems, especially those that depend > on matrix arithmetic, finite difference, or other precision losing > operations, it isn't. For video graphics (video games) isn't > a 24 bit significand enough? > > But are we really at the point where affordable hardware will be > available for scientific programming? I believe that cheap floating > point (8087, 80287, and successors) are available because spreadsheet > programs started needing them. Scientific programming doesn't have > enough economy of scale, but business users do. Do business users > need the extra precision? Do serious business accounting in the (old) Italian lira, or Japanese yen and suddenly you need more precision. But then you are likely to go to decimal which is often quite long as well. And then there is Zimbabwe where the inflation is probably faster than data entry so it is not much of a market to miss. > Note that IBM has supported extended precision (REAL*16) since > the 360/85, and it was standard on S/370 and later models. > (Well, DXR wasn't in hardware until somewhat more recently.) > > VAX has H-float, but I believe it was done as software emulation > on most implementations. I did hear that the 11/730 has it in > microcoded hardware. > > I don't believe that either ever had as much use as one > might expect. > > -- glen
From: GaryScott on 23 Apr 2008 15:24 On Apr 23, 1:59 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > jamesgi...(a)att.net wrote: > > On Apr 22, 11:50 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> > > wrote: > >>Even with cheap memory, I find it unlikely that the default will > >>be eight byte integer and real, with 16 byte double precision. > >>(Until good hardware support for 16 byte reals.) > > IEEE is standardizing it as we speak (actually, it's behind > > schedule). IEEE single is no longer of sufficient precision for even > > moderate length scientific/numerical programs. > > I would say that there are still plenty of problems where 24 bits > is enough, but yes, for larger problems, especially those that depend > on matrix arithmetic, finite difference, or other precision losing > operations, it isn't. For video graphics (video games) isn't > a 24 bit significand enough? > > But are we really at the point where affordable hardware will be > available for scientific programming? I believe that cheap floating > point (8087, 80287, and successors) are available because spreadsheet > programs started needing them. Scientific programming doesn't have > enough economy of scale, but business users do. Do business users > need the extra precision? > > Note that IBM has supported extended precision (REAL*16) since > the 360/85, and it was standard on S/370 and later models. > (Well, DXR wasn't in hardware until somewhat more recently.) > > VAX has H-float, but I believe it was done as software emulation > on most implementations. I did hear that the 11/730 has it in > microcoded hardware. > > I don't believe that either ever had as much use as one > might expect. We used to use Harris' 48-bit and 96-bit reals quite extensively in our airframe and avionics models. > > -- glen
From: jamesgiles on 23 Apr 2008 15:56 On Apr 23, 12:59 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: ... > But are we really at the point where affordable hardware will be > available for scientific programming? [...] Are we really to the point where the Fortran community can disregard scientific programming whether it's affordable or not? It is my perception that few programmers still bother with Fortran unless they work for or do business with large "linguistically inertial" institutions that still use it heavily. All *that* crowd still buys the big iron. > Note that IBM has supported extended precision (REAL*16) since > the 360/85, and it was standard on S/370 and later models. > (Well, DXR wasn't in hardware until somewhat more recently.) > > VAX has H-float, but I believe it was done as software emulation > on most implementations. I did hear that the 11/730 has it in > microcoded hardware. > > I don't believe that either ever had as much use as one > might expect. I didn't expect either to have much use. I thought those features were introduced to try to grab market share from CDC and later from Cray. But neither IBM nor DEC were ever really competitive in that market. A market that you now seem to imply should be disregarded. In any case, I don't buy your argument that 64-bit integer/float defaults can't happen until cheap hardware 128-bit float is common. I think the two things are completely separable. Cray didn't have hardware double, but I never really ran into people that wished the default precision was half-word. In any case, isn't this an argument to no real point? If you are programming on a platform that has 32-bit arithmetic still in hardware it's likely the compiler will have a switch that permits you to retain that size as your default if you wish. In the near-term the reverse is likely to be true: if you want REAL/INTEGER/LOGICAL to default to 64-bit you'll have to specify a compiler option for that. If you neighbor doesn't choose to do so, then (s)he won't have to. If you try to inter-operate your codes, the compiler will catch the mismatch (TKR checking). -- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare
From: glen herrmannsfeldt on 23 Apr 2008 16:05 Gordon Sande wrote: (snip regarding floating point precision and the future) > Do serious business accounting in the (old) Italian lira, or Japanese > yen and suddenly you need more precision. But then you are likely to > go to decimal which is often quite long as well. And then there is > Zimbabwe where the inflation is probably faster than data entry so > it is not much of a market to miss. Do you really need more precision? What is the smallest Lira coin? I suppose for non-cash transactions it could be done to one Lira. I have seen house prices advertised such as $399,995 when you would think $400,000 would be close enough. (Maybe I didn't see any for $399,999 though.) Maybe Zimbabwe should use a log scale to avoid that problem. When computing the national debt of the US, is there any point in computing it down to the cent, or even dollar? The nearest million dollars might be possible. -- glen
From: Gordon Sande on 23 Apr 2008 16:36
On 2008-04-23 17:05:30 -0300, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> said: > Gordon Sande wrote: > (snip regarding floating point precision and the future) > >> Do serious business accounting in the (old) Italian lira, or Japanese >> yen and suddenly you need more precision. But then you are likely to >> go to decimal which is often quite long as well. And then there is >> Zimbabwe where the inflation is probably faster than data entry so >> it is not much of a market to miss. > > Do you really need more precision? > > What is the smallest Lira coin? > > I suppose for non-cash transactions it could be done to one Lira. > > I have seen house prices advertised such as $399,995 when you > would think $400,000 would be close enough. > (Maybe I didn't see any for $399,999 though.) They are gaming the search schemes of real estate MLS systems. Better to list at 399,950 and refuse to lower than to be prepared to lower from 425,000 but have no shows because the search cutoff is at 400,000. Been there, done that on the advice of a good real estate agent. > Maybe Zimbabwe should use a log scale to avoid that problem. > > When computing the national debt of the US, is there any point > in computing it down to the cent, or even dollar? > The nearest million dollars might be possible. > > -- glen For a bank the assets are typically several billions of dollars. Lira were around 1000 to the dollar. A bank that can not balance its books to the unit is in accounting trouble. There are lots of accounts for tellers errors and such but those must also be to the unit in the accounts. I once had the misfortune of having to deliver the bad news that an accounting package in Fortran single precision even on a 48 bit Burroughs was not up to the task. The vendor who had signed up to provide things was not pleased to have to do much more work than they thought they committed to. But at least they found out early enough that they delivered when they had committed to. |