Re: A newbie question

From: Richard E Maine (nospam_at_see.signature)
Date: 01/28/05 

Date: Fri, 28 Jan 2005 11:00:20 -0800

In article <1106903840.776423.121950@c13g2000cwb.googlegroups.com>,
 "ayagnam@gmail.com" <ayagnam@gmail.com> wrote:

> when dealing with exponential representation of real (any precision)
> numbers i prefer to use two things
>
> 1. i always use 'd' instead of 'e'

I recommend against using such a rule. There are situations where this
is just plain *WRONG* and will not work. A trivial example is an actual
argument for a nongeneric procedure (such as most user-written ones),
where the dummy is single precision.

What I recommend is that you think about what precision is appropriate
for each case when you write it. Doesn't have to be a long thought.
Doesn't need to be any longer or more complicated a thought than it
would take you to recall your rule to write that "d".

It can even be as simple a rule as making it a habit to write real
literals as double precision unless there is reason otherwise. In fact,
I'll offer that as my "translation" of your rule. My main point is that
the thought be in terms of what precision is appropriate instead of what
syntax to use. If you think of it as using double precision, then you
are far more likely to "wake up" and notice the cases where you need
some different precision. If you think of it as being part of the syntax
of a real literal, then you are far more likely to miss it.

This echoes a theme I've mentioned occasionally at the standards
committee meetings - the ill-advisedness of expressing semantic
requirements in terms of syntax. If, for example, a variable is to be
prohibited from having the SAVE attribute, I tend to recommend that the
prohibition be expressed in terms like that referring to the attribute -
not in terms of SAVE appearing in the syntax. There have been multiple
cases where requirements like that were expressed in terms of the
syntax, giving rise to interpretation questions when there are other
syntaxes for expressing the same thing. (In the case of the SAVE
attribute, the variable could alternatively be listed in a SAVE
statement, there could be a SAVE statement with no list, or the variable
might implicitly get the SAVE attribute from initialization - all of
those are different syntactic ways that can result in the same
attribute).

So my message is just to think first in terms of the meaning instead of
syntax. In your case the meaning is the precision. Let the desired
syntax be a deduction from the desired meaning. You may well end up with
the same answer (probably most of the time you will). But by skipping
that step of thinking about the meaning, you make it more likely that
you will fail to notice the cases where something different is needed. 

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Relevant Pages

  • Re: The Asymmetry of Identity
    ... commentary that falls outside mathematics. ... syrastiline syntax in mathematics is perceived as essentially divorced ... from meaning. ... there are models of natural language processing ...
    (sci.logic)
  • Re: The Asymmetry of Identity
    ... commentary that falls outside mathematics. ... syrastiline syntax in mathematics is perceived as essentially divorced ... from meaning. ... there are models of natural language processing ...
    (sci.logic)
  • Re: Reading complex multidimensionalarrays from C
    ... precision complex, but I don't think that the rationalizations hold up... ... compiler that does this, which makes the question a bit academic. ... The real*16 syntax is nonstandard and thus a compiler can do anything ... But supporting a particular real precision involves ...
    (comp.lang.fortran)
  • Re: Reading complex multidimensionalarrays from C
    ... they can support a quad precision real without also supporting a quad ... compiler that does this, which makes the question a bit academic. ... The real*16 syntax is nonstandard and thus a compiler can do anything ... But supporting a particular real precision involves ...
    (comp.lang.fortran)
  • Re: How to define the input type in TextBox?
    ... RickyChan wrote: ... The syntax for managed C++ was changed in VC2005, and your code appears to use that syntax. ... I would certainly recommend that you get a book on C++/CLI if you want to use it However I would also recommend that you consider carefully whether C++/CLI is the way you want to go; for most people using C# is a much better way to target the .NET framework. ...
    (microsoft.public.vc.language)