JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for COMP-FORTRAN-90 Archives


COMP-FORTRAN-90 Archives

COMP-FORTRAN-90 Archives


COMP-FORTRAN-90@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

COMP-FORTRAN-90 Home

COMP-FORTRAN-90 Home

COMP-FORTRAN-90  2000

COMP-FORTRAN-90 2000

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

constant kinds

From:

Richard Maine <[log in to unmask]>

Reply-To:

Richard Maine <[log in to unmask]>

Date:

Tue, 14 Nov 2000 09:12:59 -0800 (PST)

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (103 lines)

Robert Kernell writes:
 > Hi. I am teaching a Fortran class and I was wondering...
 > 
 > Is there any use for specifying kinds for constants?

Absolutely.  You have to specify the kind any time that you need
a non-default kind.  For reals, you can alternatively specify
double precision in cases where that is appropriate.  That's
a way of specifying a kind - I'm not sure from the question whether
you are talking about specifying kinds at all or whether you are
talking about the distnction between specifying double precision
using the kind syntax vs the double precision syntax.

If you are questioning whether one needs to specify kinds at all
(whether by kind syntax or double precision syntax), then the answer
is that it is very important in many applications.  The value

  3.14159265358979323846264338327950

is single precision, independent of the number of digits written (and
independent on whether I remembered them all correctly).  If you
expected more precision, then you better say so, either by using kind
or double precision syntax.  Otherwise you'll likely have an
unexpected precision loss.  Or, if you do something like pass this as
an actual argument to a subroutine expecting a different kind, it is
likely to produce complete gibberish (likely off by a few hundred
orders of magnitude).

I would be a serious mis-service to students to give them the
impression that kinds can often be ignored.  This quite often
results in code that either doesn't compile at all, gives garbage
results, or just gives results with far less precision than
expected and required.  One should instead take it as the default
assumption that the kind *USUALLY* matters unless you are in a
context where you know that it doesn't.  Its easier to describe
the contexts where it doesn't matter than those where it does.
For the kind of a constant not to matter, you need two conditions

1. It must be in a context where any kind is allowed.  Generally
   this means contexts where the value will automatically be
   converted to the appropriate kind.  This would include things
   like operands to arithmetic operations, or the right hand
   side of assignment statements.

2. The value must either be one whose precision doesn't matter
   to the application or one that you know to be exactly representable
   in the lower precision.  (The standard doesn't actually guarantee
   that any floating point values are exactly representable, but in
   practice it is very safe to assume that small values with no
   fractional part are exactly representable).  There are certainly
   plenty of cases where a loss of precision doesn't really matter.
   (If I ask for a label on a plot to be written in characters 0.2
   inches high, I really don't care at all if they end up as
   0.200007).

If *EITHER* of these conditions fails to hold, then kind matters.

(I've neglected range here.  It can matter for some things - though
it's not as often an issue as precision is for reals.  And I've also
concentrated on reals - approximations aren't an issue with integers,
but range often is).

If you are asking about the distinction between using kind syntax
versus double precision syntax, that is mostly a matter of
portability, and it has little to do with constants in particular.
The same question applies to variable declarations.  If you use
kind syntax, you can make the code portable among machines of
different precisions.  If you just use double precision on a
32-bit workstation, you'll likely find that is not what you really
want when you port the code to a Cray.

Of course, just using either syntax doesn't magically make your code
easy to port or not, any more than avoiding GOTO statements magically
makes your code well-structured.  It is quite possible to write code
using kind syntax that won't port easily at all.  Hard-wiring explicit
kind numbers would be a good start - doing arithmetic with kind
numbers would make it worse.  It is also possible to write f77-style
code with sufficient care so that it is a simple global edit to port
the code to machines of different precisions - I used to do that, as
did plenty of other people.

The difference is that the kind syntax facilitates portability,
whereas with single/double precision, you are depending completely
on programmer conventions (and the programmer had better have a
pretty well thought out set of them).

Plus kind syntax supports more than 2 precisions.  The vendor
extensions to do so with other syntaxes are not particularly
good about portability.

If your students are likely to be writing libraries that use generics
to support multiple precisions, then life is a bit more complicated,
as has been discussed here before.  But generally, there are a lot
more users of such libraries than writers of them (one would hope).

-- 
Richard Maine
[log in to unmask]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

December 2023
February 2023
November 2022
September 2022
February 2022
January 2022
June 2021
November 2020
September 2020
June 2020
May 2020
April 2020
December 2019
October 2019
September 2019
March 2019
February 2019
January 2019
November 2018
October 2018
September 2018
August 2018
July 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
April 2015
March 2015
January 2015
December 2014
November 2014
October 2014
August 2014
July 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
July 2013
June 2013
May 2013
April 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
August 2010
July 2010
June 2010
March 2010
February 2010
January 2010
December 2009
October 2009
August 2009
July 2009
June 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
January 2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
1997


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager