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: Ian Bush on 23 Apr 2008 07:15 As if by magic, Horand.Gassmann(a)googlemail.com appeared ! > On Apr 23, 2:15 am, "James Van Buskirk" <not_va...(a)comcast.net> wrote: >> <andrej.panj...(a)climatechange.qld.gov.au> wrote in message >> >> news:a8338933-0afe-4e7f-b106-04cb2d84d492(a)a23g2000hsc.googlegroups.com... >> >> > Quite a few compilers support different representations for LOGICAL >> > types: 1 byte, 2 byte 4 byte...and 8 byte? >> > What applications are there for 8 byte LOGICAL types? (Or for 2 byte >> > types?) >> >> Storage association rules require than a default INTEGER takes up >> the same space as a default LOGICAL. N1601.pdf, section 16.4.3.1: > > This looks to me like a hole in the language. Is there a > SELECTED_LOGICAL_KIND that would allow me to specify (portably) the > smallest available logical type, for instances where I do not want to > burn up 128 bits to store T/F values in a large array? Not in 95 - but I have half a feeling that that may have been corrected in 2003. However a quick search does not support this ... I suppose that given the SELECTED* functions are based on the range and precision of the numbers that the kind can represent they don't map over quite so well to logicals, where there are always only 2 values, Ian
From: Janne Blomqvist on 23 Apr 2008 07:37 On 2008-04-23, Horand.Gassmann(a)googlemail.com <Horand.Gassmann(a)googlemail.com> wrote: > This looks to me like a hole in the language. Is there a > SELECTED_LOGICAL_KIND that would allow me to specify (portably) the > smallest available logical type, for instances where I do not want to > burn up 128 bits to store T/F values in a large array? No, though you can use integer arrays and the bit twiddling intrinsics. For example, the function below calculates the number of primes up to 'm', storing them into the integer array 'prime' using 1 bit per number: module nsib_m implicit none function nsib (m) integer, parameter :: bs = bit_size (1) integer, intent(in) :: m integer, dimension(0:m/bs) :: prime integer :: nsib, i, j prime = -1 nsib = 0 do i = 2, floor (sqrt (real (m))) if (btest (prime(i/bs), mod (i, bs))) then do j = i * i, m, i prime(j/bs) = ibclr (prime(j/bs), mod (j, bs)) end do nsib = nsib + 1 end if end do do i = ceiling (sqrt (real (m))), m nsib = nsib + ibits (prime(i/bs), mod (i, bs), 1) end do end function nsib end module nsib_m Admittedly not as convenient as an array of logicals, but if you really need it, it can be done. And of course, if you really care about portability, you should initialize the array using another method than the one above. -- Janne Blomqvist
From: Gary Scott on 23 Apr 2008 08:30 Richard Maine wrote: > e p chandler <epc8(a)juno.com> wrote: > > >>2. Is it legal to set aside 8 bytes for a REAL but use only 4? > > > Yes, though that would be a slightly odd choice for reals, which can > often use the extra precision. Still, it is definitely legal. Comparable > things have been done with various compilers in the past. I don't recall > that exact one, but I have seen: > > Integers that take 4 bytes of storage, but only use 2 of them. > > Double precision reals that take 128 bytes of storage, but only use 80 > of them. > > Considering the subject of the thread, logicals that take any of several > sizes, but only use one bit. > > And a few other such variants, which have been mentioned here in the > past. > And it is quite common to store foreign/non-native data types within native datatypes and process them using various bit manipulation routines. For example, we have packed data streams for defined embedded processors that use 11-bit integers and 24 bit reals because it meets the particular signal range needs and packing the most information in the serial data stream. -- Gary Scott mailto:garylscott(a)sbcglobal dot net Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html If you want to do the impossible, don't hire an expert because he knows it can't be done. -- Henry Ford
From: jamesgiles on 23 Apr 2008 14:35 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. The significand is only 24-bits, so the relative error of operations is about 10^(-6). I "only" a few hundred billion operations you could easily be down to just the sign bit on some traditionally stable algorithms. That's less than a minute these days. As it becomes practical to run larger problems longer this will only become steadily more of a problem. Given that both integer and floating point is getting to need more than 32-bit values, I don't think it's unlikely at all that 64-bit defaults would soon be common. -- 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 14:59
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? 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 |