reasons for failure
in [Fortran]
|
Prev: Clarify An Old Question: define a user data containing array with dimensions decided in running time
Next: Clarify An Old Question: define a user data containing array with ?dimensions decided in running time
From: Uno on 23 May 2010 17:46 dpb wrote: > Uno wrote: > ... > >> But every implementation we talk about around here associates a >> greater integer with increased width in the representation, right? >> >> It seems like low-hanging fruit for a good idea to make standard next >> time around. > ... > > For what purpose, pray??? Isn't that ordering necessary to make this source work: [wrote Tobias upthread] > PS: If I want to use double precision or - if present - the next higher > precsion, I use: > integer, parameter :: qp = & > max(kind(0.0d0), selected_real_kind(precision(0.0d0)+1)) -- Uno
From: Richard Maine on 23 May 2010 18:12 Uno <merrilljensen(a)q.com> wrote: > Richard Maine wrote: > > Kinds should not be identified numerically at all, > > What would serve as a way to indicate failure? (presumably failureof things like selected_real_kind to find a suitable kind). The same way as we do now, suitably abstracted. That shouldn't be a particularly difficult abstraction. (The ability to abstract things is *VERY* important in programming. Without abstraction, you would have to write different programs to add 2+2 or 2+3; abstraction allows you to recognize that these are both cases of adding two numbers.) How do we indicate failure now? By returning special values that are invalid as kind values. Those special values happen to be numeric now, but that's just because kind values are numeric. If that is not sufficient clue, then.... well I'll not bother to elaborate further anyway, as it isn't going to happen (and because anyone with a pretext of doing language design should drop the pretext if they even needed that much clue). > I wanted to ask this back in the thread with the hollerith constants, > where the scheme was somewhat dependent on having a 4-byte integer. > > Is there a portable to ask for one with a call to selected_int_kind? Not 100% guaranteed portable as of now, athough I think f2008 adopted a proposal of mine to make it simple and portable. For f90/f95/f2003, it will suffice in practice to do something like selected_int_kind(9). That's what I use. That doesn't strictly guarantee a 4-byte integer... but you won't find any compilers where that's not what you get. A somewhat obscure way to sort of guarantee a 4-byte integer in f2003 is to use the C interop stuff (see C_INT32_T). But it seems a bit odd to go via C interop for such a thing if you aren't actually needing it for C interop. That does assume both that you have a compiler that supports the f2003 C interop stuff, and that the targetted companion C processor has int32_t. On the whole, I'd say you are beter off to just use the selected_int_kind(9) as it will work on more compilers (namely all of them that actually exist for f90 or later). -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: dpb on 23 May 2010 18:37 Uno wrote: > dpb wrote: >> Uno wrote: >> ... >> >>> But every implementation we talk about around here associates a >>> greater integer with increased width in the representation, right? >>> >>> It seems like low-hanging fruit for a good idea to make standard next >>> time around. >> ... >> >> For what purpose, pray??? > > Isn't that ordering necessary to make this source work: > > [wrote Tobias upthread] >> PS: If I want to use double precision or - if present - the next higher >> precsion, I use: >> integer, parameter :: qp = & >> max(kind(0.0d0), selected_real_kind(precision(0.0d0)+1))
From: dpb on 23 May 2010 18:39 Uno wrote: .... > Isn't that ordering necessary to make this source work: > > [wrote Tobias upthread] >> PS: If I want to use double precision or - if present - the next higher >> precsion, I use: >> integer, parameter :: qp = & >> max(kind(0.0d0), selected_real_kind(precision(0.0d0)+1)) Heavens, NO!!! First, look carefully at the parentheses nesting and then at the definition of what PRECISION() returns... --
From: dpb on 24 May 2010 08:40
dpb wrote: > Uno wrote: > ... > >> Isn't that ordering necessary to make this source work: >> >> [wrote Tobias upthread] >>> PS: If I want to use double precision or - if present - the next higher >>> precsion, I use: >>> integer, parameter :: qp = & >>> max(kind(0.0d0), selected_real_kind(precision(0.0d0)+1)) > > Heavens, NO!!! .... Ooops, sorry, I forgot the MAX() call...that does, indeed assume the ordering; I was focused on thinking you were looking at the addition operation. I don't believe the above is guaranteed to work by Standard although it probably does in practice for current compilers (including those of which I'm aware which isn't even close to the universe of those available). -- |