How to deal with "missing points" in arrays
in [Fortran]
|
From: William Clodius on 10 Jun 2010 10:00 deltaquattro <deltaquattro(a)gmail.com> wrote: > On 10 Giu, 05:36, robert.corb...(a)oracle.com wrote: > > On Jun 9, 2:41 pm, Gib Bogle <g.bo...(a)auckland.no.spam.ac.nz> wrote: > > > > > glen herrmannsfeldt wrote: > I don't recommend the LOGICAL variable > > > method, unless it is > necessary to have all REAL values legal. If > > > you need portability > to older compilers, you could do conditional > > > compilation on a > test for NaN or 9.9999e30 (fits in single precision > > > on most > machines), or 9.9999e99 (in double precision on many > > > machines). > > > > > Is 9.9999e30 exactly representable? Anyway, why not use 1.0e30, which > > > definitely is? I like your idea of incrementally modifying true > > > values that hit the "missing point" value. > [..] > > > > Bob Corbett > > Hi Bob, > > so this means that I wouldn't be able to test for equivalence against > 9.9999e30 or 1.0E30? Alas, I forgot one shouldn't test for equivalence > with floating point numbers... > > Best > > Sergio Rossi Formally you cannot test for equality against them. In principle you could define a parameter of the desired REAL kind in effect give it the closest value to 1.0E30 and test against that. But as Richard noted that is error prone. -- Bill Clodius los the lost and net the pet to email
From: deltaquattro on 10 Jun 2010 10:10 On 10 Giu, 16:00, wclod...(a)lost-alamos.pet (William Clodius) wrote: > deltaquattro <deltaquat...(a)gmail.com> wrote: > > <snip> > > Hi, Bill, > > > yours is a variation on point 1 (define a corresponding LOGICAL array > > for each REAL(r8) array), isn't it? So you suggest to define an extra > > array for each of my arrays, which works as a flag array. I don't > > understand exactly how to form the array. You talk about strings of > > lenght 1, but TOO_LOW, TOO_HIGH, etc., UNPROCESSED are not of length 1 > > and they are of different length. I guess the array should be of type > > CHARACTER(LEN=MAXL) where MAXL is the length of the longest string. Am > > I right? Thanks > > > Sergio Rossi > > CHARACTER(1), PARAMETER :: TOO_LOW ='L', & > TOO_HIGH = 'H', UNPROCESSED='U', 'VALID='V' > ... > CHARACTER(1) :: FLAG_ARRAY(MAXL) > ... > FLAG_ARRAY(:) = UNPROCESSED > ... > FLAG_ARRAY(I) = TOO_LOW > ... > FLAG_ARRAY(I) = TOO_HIGH > ... > FLAG_AARRAY(I) = VALID > ... > > -- > Bill Clodius > los the lost and net the pet to email Hi Bill, perfect, looks very readable and easy to implement. Will do it right now. Thanks, Best Regards Sergio Rossi
From: Richard Maine on 10 Jun 2010 12:09 deltaquattro <deltaquattro(a)gmail.com> wrote: > You're right, glenn pointed that out too. I was really surprised to > learn that LOGICAL and REAL occupy the same space. Default logical and real date back to when almost *EVERYTHING* had the same size (typically the word size of the machine). The only exceptions were double precision and complex, which used two storage units. There was nothng that used less than a storage unit. Realize that there existed multiple machines in that era that could not access chunks of memory any smaller than the word size. Some of these machines were among the ones very widely used for scientific and engineering computation; they were not arcane special cases. On those machines, manipulating anything smaller than the word size was substantially more awkward and slower than just using a whole word. You pretty much had to get the whole word into a register and use masking and shifting operations to extract the smaller piece. Then if you wanted to write a value, you had to read the word, mask and shift the new value into it, and then write it back out. As Tobias noted, logicals did not tend to be a big performance issue anyway, either in time or space. Good thing, because if you optimized them for space usage (by using less than a whole word), you would have killed their speed. That's even still so if you ise less than a byte. One just didn't normally have huge arrays of logicals. Instead, one had a few logicals used to control options or some such thing. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Richard Maine on 10 Jun 2010 12:10 deltaquattro <deltaquattro(a)gmail.com> wrote: > Ok, so you're for the solution using LOGICAL arrays. Do you think it > would be better to implement a "parallel" logical array for each real > array, or to define arrays of derived type like: > > type safearray > logical :: isvalid > real(r8):: cell > end type Either works. Depends which is most convenient for other reasons. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 10 Jun 2010 13:26
William Clodius <wclodius(a)lost-alamos.pet> wrote: (snip, someone wrote) >> so this means that I wouldn't be able to test for equivalence against >> 9.9999e30 or 1.0E30? Alas, I forgot one shouldn't test for equivalence >> with floating point numbers... > Formally you cannot test for equality against them. In principle you > could define a parameter of the desired REAL kind in effect give it the > closest value to 1.0E30 and test against that. But as Richard noted that > is error prone. The language has no rule against equality tests for floating point values, but one does have to be careful. X=0.3+0.3 if(x.ne.0.6) print *,'surprise!' Testing for the exact value assigned to a variable should be fairly reliable, but there are still pitfalls. The library conversion routines may be different from those of the compiler. That is, reading a value as input data may not give exactly the same value as a constant in the program. Either could change with time, as new versions of the compiler or library are generated. With separate compilation, you could notice the difference between constants generated by different compiler versions. Not so likely, but there could be difference in optimization levels. I can't think of why that would be true, but I wouldn't want to bet that it wasn't possible. -- glen |