Final committee draft of Fortran 2008 available
Van Snyder
At this time, ANSI and ISO rules allow only editorial changes, or
technical changes that are necessary to correct an error. New features,
or significant changes in existing features (including removing them)
are not permitted.
The current draft is available from
http://tinyurl.com/2s79s4
http://j3-fortran.org/doc/meeting/190/09-007r3.pdf
ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1791.pdf
You should send comments to your national body, which then officially
reports them to ISO.
US: ANSI, contact j...@j3-fortran.org
UK: BCS or BSI?, contact d.mux...@bcs.org.uk
Germany: DIN, contact wwa...@math.tu-dresden.de or Reinhol...@lrz.de
Netherlands: NEN, contact to...@moene.org
Japan: JSA?, contact tak...@edogawa-u.ac.jp
I don't know contacts for other countries. Try google.
Each national body could have a different deadline.
US comments are due to ANSI by 29 November 2009. Comments will be processed
at PL22.3 (erstwhile J3) meeting 190, 9-13 November 2009. To assure consideration,
papers should be submitted by 26 October 2009. See http://j3-fortran.org. Also
see http://j3-fortran.org/doc/standing/links/013.txt for the format of papers.
Submit papers to the committee librarian, Dan Nagle <dann...@verizon.net>.
--
Van Snyder | What fraction of Americans believe
Van.S...@jpl.nasa.gov | Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or
disapproved by JPL, CalTech, NASA, the President, or anybody else.
nm...@cam.ac.uk
Van Snyder <vsn...@math.jpl.nasa.gov> wrote:
>The final committee draft of Fortran 2008 is available for public review.
>
>At this time, ANSI and ISO rules allow only editorial changes, or
>technical changes that are necessary to correct an error. New features,
>or significant changes in existing features (including removing them)
>are not permitted.
My understanding is that isn't so, but the route to such things is
by sending the draft back to the working group, and telling them
to do the job over. I.e. produce a new FCD.
That's more a pedantic niggle than anything else :-)
Regards,
Nick Maclaren.
Richard Maine
> In article <h8u6k0$75s$1...@news.jpl.nasa.gov>,
> Van Snyder <vsn...@math.jpl.nasa.gov> wrote:
> >The final committee draft of Fortran 2008 is available for public review.
> >
> >At this time, ANSI and ISO rules allow only editorial changes, or
> >technical changes that are necessary to correct an error. New features,
> >or significant changes in existing features (including removing them)
> >are not permitted.
>
> My understanding is that isn't so, but the route to such things is
> by sending the draft back to the working group, and telling them
> to do the job over. I.e. produce a new FCD.
I think they might have to go back even further than that, setting the
process back several years. Some of us think that would be a good idea,
but I've got a fairly good idea what the odds of that are. Might as well
play the lottery. :-(
> That's more a pedantic niggle than anything else :-)
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
>
>> >At this time, ANSI and ISO rules allow only editorial changes, or
>> >technical changes that are necessary to correct an error. New features,
>> >or significant changes in existing features (including removing them)
>> >are not permitted.
>>
>> My understanding is that isn't so, but the route to such things is
>> by sending the draft back to the working group, and telling them
>> to do the job over. I.e. produce a new FCD.
>
>I think they might have to go back even further than that, setting the
>process back several years. Some of us think that would be a good idea,
>but I've got a fairly good idea what the odds of that are. Might as well
>play the lottery. :-(
Could be - you know the rules better than I do. My point is that the
commenting public does have the option to propose that, and it has
happened in the past with some standards. I agree with you about the
odds ....
Regards,
Nick Maclaren.
GaryScott
> The final committee draft of Fortran 2008 is available for public review.
>
> At this time, ANSI and ISO rules allow only editorial changes, or
> technical changes that are necessary to correct an error. New features,
> or significant changes in existing features (including removing them)
> are not permitted.
>
> The current draft is available from
>
>
> You should send comments to your national body, which then officially
> reports them to ISO.
>
> US: ANSI, contact j...@j3-fortran.org
> Germany: DIN, contact wwal...@math.tu-dresden.de or Reinhold.Ba...@lrz.de
> Netherlands: NEN, contact t...@moene.org
> Japan: JSA?, contact tak...@edogawa-u.ac.jp
> I don't know contacts for other countries. Try google.
>
> Each national body could have a different deadline.
>
> US comments are due to ANSI by 29 November 2009. Comments will be processed
> at PL22.3 (erstwhile J3) meeting 190, 9-13 November 2009. To assure consideration,
> papers should be submitted by 26 October 2009. Seehttp://j3-fortran.org. Also
> Submit papers to the committee librarian, Dan Nagle <danna...@verizon.net>.
>
> --
> Van Snyder | What fraction of Americans believe
> Any alleged opinions are my own and have not been approved or
> disapproved by JPL, CalTech, NASA, the President, or anybody else.
My God -- It's full of stars...and a whole bunch of pages!
What the heck is a "coshape"? Sounds like an invented unixy term. Is
that a "coarray shape" or a statement that an object has the same
shape as something else? Lucy, got some splainin to do.
steve
> The final committee draft of Fortran 2008 is available for public review.
>
> At this time, ANSI and ISO rules allow only editorial changes, or
> technical changes that are necessary to correct an error. New features,
> or significant changes in existing features (including removing them)
> are not permitted.
>
> The current draft is available from
>
> http://tinyurl.com/2s79s4http://j3-fortran.org/doc/meeting/190/09-007r3.pdfftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1791.pdf
>
The document is almost unreadable with xpdf and probably other acrobat
readers due to the ugly red boxes drawn around the internal
hyperlinks.
A description of the problem can be found at
https://bugs.launchpad.net/ubuntu/+source/evince/+bug/156643
The fix is described in comment #9 where the latex hyperref pack
needs:
% this disables the boxes around links
\usepackage[pdftex, pdfborderstyle={/S/U/W 0}]{hyperref}
Any chance that the documents can be regenerated?
--
steve
steve
> On Sep 17, 1:36 pm, vsny...@math.jpl.nasa.gov (Van Snyder) wrote:
>
> > The final committee draft of Fortran 2008 is available for public review.
>
> > At this time, ANSI and ISO rules allow only editorial changes, or
> > technical changes that are necessary to correct an error. New features,
> > or significant changes in existing features (including removing them)
> > are not permitted.
>
> > The current draft is available from
>
>
> The document is almost unreadable with xpdf and probably other acrobat
> readers due to the ugly red boxes drawn around the internal
> hyperlinks.
>
>
> The fix is described in comment #9 where the latex hyperref pack
> needs:
>
> % this disables the boxes around links
> \usepackage[pdftex, pdfborderstyle={/S/U/W 0}]{hyperref}
>
> Any chance that the documents can be regenerated?
Here's a rather ugly workaround.
sed s/Border\\[0\]/Border\\[0\ 0\ 0\]/ 09-007r3.pdf > a.pdf
--
steve
robin
>The final committee draft of Fortran 2008 is available for public review.
>
>At this time, ANSI and ISO rules allow only editorial changes, or
>technical changes that are necessary to correct an error. New features,
>or significant changes in existing features (including removing them)
>are not permitted.
The draft should have been proof read prior to being submitted
for public comment.
In many places, the text breaks into font so small it is barely readable (4 point?)
Many of the "definitions" in Section 1 are in terms of other terms
that are not defined, or are not defined at all.
The definitions are not arranged in alphabetical order,
and obviously-related definitions are not grouped.
Examples:
1.3.22 Coarray defined in terms of corank (which is not defined)
1.3.23 cobound is defined in terms of pattern (which is not defined)
1.3.4 array is defined in terms of a rectangular pattern (which in the case of
a vector it is not)
1.3.8.1 effective argument is not defined
Nor is a dummy argument defined.
1.3.9 attribute is a "property of an entity determines its uses",
which reads more like a cryptic crossword clue.
1.3.38 corank. Why isn't this with 1.3.22 ?
1.3.38 cosubscript, ditto
defined in terms of an image selector.
1.3.64 dummy - miniature font used
1.3.54.1 dummy data object defined in terms of data object
1.3.57 definition of "elemental" is woolly.
1.3.74 image is an instance of a Fortran program
1.3.103.1 dummy procedure ??
1.3.134.1 Atomic subroutine ?? ATOM ?? atomically ??
Note 4.6
473 and other constants are not examples of signed constants.
Note 4.9
erroneously includes some unsigned constants.
5.12
The SUBROUTINE statement is not an example of a DIMENSION attribute specification
5.15
The SUBROUTINE statement is not an example of an INTENT specification.
5.4.5 Codimension statement. There is no indication of what it does or means.
Note 5.29
CHARACTER, INTEGER and REAL statements are not examples of DATA statements.
It would have been helpful had new/revised text been displayed in
a different color, such as red.
David Muxworthy
> The draft should have been proof read prior to being submitted
> for public comment.
>
> In many places, the text breaks into font so small it is barely readable (4 point?)
You seem to have used a partially corrupt copy of the document. Try
the version at
ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1791.pdf
> Many of the "definitions" in Section 1 are in terms of other terms
> that are not defined, or are not defined at all.
Some of your criticisms are valid - some are not, for example:
> 1.3.23 cobound is defined in terms of pattern (which is not defined)
Agreed pattern is not defined, but cobound is not defined in terms of
pattern.
> It would have been helpful had new/revised text been displayed in
> a different color, such as red.
No, it wouldn't have been helpful. There would have been as much red as
black. For an overview of new features, see pages xiii and xiv, or for
more detail WG5 document N1735 on the WG5 website. For an overview of
coarrays see WG5 document N1787.
David Muxworthy
anal...@hotmail.com
wrote:
> robin wrote:
> > The draft should have been proof read prior to being submitted
> > for public comment.
>
> > In many places, the text breaks into font so small it is barely readable (4 point?)
>
> You seem to have used a partially corrupt copy of the document. Try
>
> > Many of the "definitions" in Section 1 are in terms of other terms
> > that are not defined, or are not defined at all.
>
> Some of your criticisms are valid - some are not, for example:
>
> > 1.3.23 cobound is defined in terms of pattern (which is not defined)
>
> Agreed pattern is not defined, but cobound is not defined in terms of
> pattern.
>
> > It would have been helpful had new/revised text been displayed in
> > a different color, such as red.
>
> No, it wouldn't have been helpful. There would have been as much red as
> black. For an overview of new features, see pages xiii and xiv, or for
> more detail WG5 document N1735 on the WG5 website. For an overview of
> coarrays see WG5 document N1787.
>
> David Muxworthy
So f08 has been specified, without a single full-featured f03 compiler
being out there (AFAIK).
Any comments along the lines of "Quo Vadis, Fortran" would be welcome.
The arguably poor position of Fortran in the computing world isn't
going to be helped much if compilers do not follow a lineal evolutiuon
path. The risk of balkanization (a la the short-lived F project) ,
with vendors offering subsets of standard features and their own
extensions seems very real.
Jim Xia
> US: ANSI, contact j...@j3-fortran.org
> UK: BCS or BSI?, contact d.muxwor...@bcs.org.uk
> Germany: DIN, contact wwal...@math.tu-dresden.de or Reinhold.Ba...@lrz.de
> Netherlands: NEN, contact t...@moene.org
> I don't know contacts for other countries. Try google.
For Canadian comments, if any, send them to jim...@ca.ibm.com
Cheers,
Jim
Richard Maine
> So f08 has been specified, without a single full-featured f03 compiler
> being out there (AFAIK).
That was the core of my formal comment on the previous f08 public draft.
J3 wasn't interested and pretty much brushed me off (making me no feel
it worth my submitting the same formal comment again).
> The arguably poor position of Fortran in the computing world isn't
> going to be helped much if compilers do not follow a lineal evolutiuon
> path. The risk of balkanization (a la the short-lived F project) ,
> with vendors offering subsets of standard features and their own
> extensions seems very real.
Yep, that too. I'm not used to agreeing with "analyst"; seems like I do
this time though.
robin
<4ab78647$1...@mk-nntp-2.news.uk.tiscali.com>...
>robin wrote:
>
>> The draft should have been proof read prior to being submitted
>> for public comment.
>>
>> In many places, the text breaks into font so small it is barely readable (4 point?)
>
>You seem to have used a partially corrupt copy of the document. Try
>the version at
>ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1791.pdf
>
>> Many of the "definitions" in Section 1 are in terms of other terms
>> that are not defined, or are not defined at all.
>
>Some of your criticisms are valid - some are not, for example:
>
>> 1.3.23 cobound is defined in terms of pattern (which is not defined)
>
>Agreed pattern is not defined, but cobound is not defined in terms of
>pattern.
cobound is defined in terms of codimension,
which in turn is defined in terms of pattern. (1.3.24)
>> It would have been helpful had new/revised text been displayed in
>> a different color, such as red.
>No, it wouldn't have been helpful.
Well I think that it would.
> There would have been as much red as
>black. For an overview of new features, see pages xiii and xiv,
My posted comments are principally about the inadequate definitions,
and the need for proofreading.
> or for
>more detail WG5 document N1735 on the WG5 website. For an overview of
>coarrays see WG5 document N1787.
My comments are about the document as presented.
robin
The syntax of OPEN statement is incorrect. (9.5.6.2)
The options are not alternatives, but one or more options
may be included in an OPEN statements.
Where more than one option is given, a comma is required
to separate them.
Similarly for CLOSE (9.5.7.2)
and for READ (9.6.1-2)
etc
Dan Nagle
On 2009-09-22 10:37:50 -0400, "robin" <rob...@bigpond.com> said:
> The syntax of OPEN statement is incorrect. (9.5.6.2)
> The options are not alternatives, but one or more options
> may be included in an OPEN statements.
> Where more than one option is given, a comma is required
> to separate them.
>
> Similarly for CLOSE (9.5.7.2)
> and for READ (9.6.1-2)
Do you know how to read the BNF, including
the assumed syntax rules?
Do you know you must read the BNF in conjunction
with the applicable constraints?
--
Cheers!
Dan Nagle
Dan Nagle
On 2009-09-22 10:37:49 -0400, "robin" <rob...@bigpond.com> said:
>>> 1.3.23 cobound is defined in terms of pattern (which is not defined)
>>
>> Agreed pattern is not defined, but cobound is not defined in terms of
>> pattern.
>
> cobound is defined in terms of codimension,
> which in turn is defined in terms of pattern. (1.3.24)
You do know that when a term is not defined
within the document, its ordinary English meaning applies?
--
Cheers!
Dan Nagle
robin
Is there a requirement that a REAL take the same space as an INTEGER?
I didn't find one in Chapt 5. May have missed it?
In the spec of a type-declaration-stmt in Chapt 5.2.1,
declaration-type-spec is not defined.
The problem with CMPLX does not seen to have been rectified --
despite long discussion in this n.g.
Why the functions SHIFTL, SHIFTR, and POPPAR?
SHIFTL and SHIFTR ARE the same as ISHFT,
POPPAR is the same as IAND(x,1).
Perhaps thinking of phasing out ISHFT? If so, OK.
The document is careful to spell out the representations of
integers, and to give formulas for ERF, GAMMA, etc, etc, etc,
but fails to provide formulas for the six Bessel functions,
or even a reference.
robin
Do you have something constructive to say?
Have a good day.
robin
IF (and that's a big IF) you had read the draft, and IF
you actually knew BNF, then you would know that
the cited definitions are not BNF.
Try to have a good day.
nm...@cam.ac.uk
robin <rob...@bigpond.com> wrote:
>Van Snyder wrote in message ...
>>The final committee draft of Fortran 2008 is available for public review.
>
>Is there a requirement that a REAL take the same space as an INTEGER?
>I didn't find one in Chapt 5. May have missed it?
That's because it's not there, and wasn't in Fortran 90, either.
Try chapter 16.
>In the spec of a type-declaration-stmt in Chapt 5.2.1,
>declaration-type-spec is not defined.
Yes, it is. 4.3.1.
>The problem with CMPLX does not seen to have been rectified --
>despite long discussion in this n.g.
WHICH problem? If you mean that its default KIND is bad, that can't
be solved compatibly.
Regards,
Nick Maclaren.
nm...@cam.ac.uk
If you knew a little more about BNF and its history, you would
firstly have not posted that erroneous statement about OPEN etc.
and secondly would know that BNF is a generic term (and has been
for 40+ years).
Look in 1.4, specifically 1.4.1 and 1.4.3.
>
>Try to have a good day.
>
>
Regards,
Nick Maclaren.
Dan Nagle
On 2009-09-23 09:14:49 -0400, "robin" <rob...@bigpond.com> said:
> POPPAR is the same as IAND(x,1).
Not close.
Can you say "population count" ?
Do you know what it means?
robin's analysis of the shift procedures would benefit
from a reading of their "Arguments." subclauses.
Some of the new shift procedures were taken from HPF
and were added in the interests of portability, and
because many vendors had already implemented them.
--
Cheers!
Dan Nagle
glen herrmannsfeldt
< In article <dbpum.42568$ze1....@news-server.bigpond.net.au>,
< robin <rob...@bigpond.com> wrote:
<>The problem with CMPLX does not seen to have been rectified --
<>despite long discussion in this n.g.
< WHICH problem? If you mean that its default KIND is bad,
< that can't be solved compatibly.
I believe the idea of a COMPLEX function has been suggested
in this group before.
Personally, I find the use of REAL as both the real part
of a complex expression, and the convert to REAL of the
appropriate kind at least a little confusing, but a little
late to change that. If the type names were consistently
used (INTEGER, REAL, COMPLEX), then it wouldn't seem so bad.
-- glen
Dan Nagle
On 2009-09-23 12:10:36 -0400, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
> I believe the idea of a COMPLEX function has been suggested
> in this group before.
This issue was specifically discussed at the Tokyo meeting
of J3 and WG5. I can't recall exactly why, but it failed
for some reason. Perhaps it was "too close" to cmplx(),
or perhaps there was some other reason.
ISTR being somewhat in favor, but there were bigger fish
to fry at that meeting.
Perhaps WG5's minutes of the meeting have a clue. I'm
too busy today to check.
--
Cheers!
Dan Nagle
nm...@cam.ac.uk
Dan Nagle <dann...@verizon.net> wrote:
>On 2009-09-23 12:10:36 -0400, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
>
>> I believe the idea of a COMPLEX function has been suggested
>> in this group before.
>
>This issue was specifically discussed at the Tokyo meeting
>of J3 and WG5. I can't recall exactly why, but it failed
>for some reason. Perhaps it was "too close" to cmplx(),
>or perhaps there was some other reason.
I was there, too, and that is precisely my recollection :-(
>ISTR being somewhat in favor, but there were bigger fish
>to fry at that meeting.
Precisely. My recollection is that the proposal wasn't fully baked,
and people felt that they didn't have time to think it through and
finish baking it. But I can't remember anything more.
Regards,
Nick Maclaren.
robin
I am amazed that J3 would actually promote the use of
the fixed constants 4 and 8 as kinds for REAL statements.
Yet is does so in C.1.1-1.
That entire sub-sections 1 and 2 need to be deleted,
and KIND(0.0) and KIND(0.0D0) be substituted for a re-written
sub-section 1.
steve
What seems to be completely amazing is that you've missed
the entire point of C.1.1.
--
steve
Dan Nagle
On 2009-09-23 19:14:56 -0400, "robin" <rob...@bigpond.com> said:
> I am amazed that J3 would actually promote the use of
> the fixed constants 4 and 8 as kinds for REAL statements.
> Yet is does so in C.1.1-1.
>
> That entire sub-sections 1 and 2 need to be deleted,
> and KIND(0.0) and KIND(0.0D0) be substituted for a re-written
> sub-section 1.
kind( 0.0) and kind( 0.0d0) are not very portable.
Are they supposed to be 32-bit and 64-bit reals,
or 64-bit and 128-bit reals?
I'm not endorsing the use of literal kind values;
I guess the Annexes didn't get as much attention
as they deserve.
--
Cheers!
Dan Nagle
Richard Maine
Nah. That's not amazing at all - much more like about what I'd expect.
:-(
robin
>
>On 2009-09-23 09:14:49 -0400, "robin" <rob...@bigpond.com> said:
>
>> POPPAR is the same as IAND(x,1).
>
>Not close.
With POPCNT it is. POPPAR is trivial, as I said.
>Can you say "population count" ?
>Do you know what it means?
Did you not know about the procedure POPCNT?
It's right next to POPPAR in Chapt 13, and on the same page.
They even spell it out for you that POPPAR uses POPCNT !
As John Cleese said, "How could you miss [it]?"
>robin's analysis of the shift procedures would benefit
>from a reading of their "Arguments." subclauses.
Had you actually read the draft, you would have seen that
the functions quoted, namely, SHIFTL and SHIFTR
are EXACTLY the same as ISHFT with a signed shift amount.
They are all elemental functions.
>Some of the new shift procedures were taken from HPF
>and were added in the interests of portability, and
>because many vendors had already implemented them.
SHIFTL and SHIFTR are already implemented as ISHFT.
robin
>In article <dbpum.42568$ze1....@news-server.bigpond.net.au>,
>robin <rob...@bigpond.com> wrote:
>>Van Snyder wrote in message ...
>>>The final committee draft of Fortran 2008 is available for public review.
>>
>>Is there a requirement that a REAL take the same space as an INTEGER?
>>I didn't find one in Chapt 5. May have missed it?
>
>That's because it's not there, and wasn't in Fortran 90, either.
>Try chapter 16.
>
>>In the spec of a type-declaration-stmt in Chapt 5.2.1,
>>declaration-type-spec is not defined.
>
>Yes, it is. 4.3.1.
That's not ch. 5.2.1 where it's needed.
There's no cross-reference there to it either.
>>The problem with CMPLX does not seen to have been rectified --
>>despite long discussion in this n.g.
>
>WHICH problem? If you mean that its default KIND is bad, that can't
>be solved compatibly.
There are at least 2 ways to solve it, and they were discussed at length.
robin
>robin <rob...@bigpond.com> wrote:
>>Dan Nagle wrote in message ...
>>>On 2009-09-22 10:37:50 -0400, "robin" <rob...@bigpond.com> said:
>>>
>>>> The syntax of OPEN statement is incorrect. (9.5.6.2)
>>>> The options are not alternatives, but one or more options
>>>> may be included in an OPEN statements.
>>>> Where more than one option is given, a comma is required
>>>> to separate them.
>>>>
>>>> Similarly for CLOSE (9.5.7.2)
>>>> and for READ (9.6.1-2)
>>>
>>>Do you know how to read the BNF, including
>>>the assumed syntax rules?
>>>
>>>Do you know you must read the BNF in conjunction
>>>with the applicable constraints?
>>
>>IF (and that's a big IF) you had read the draft, and IF
>>you actually knew BNF, then you would know that
>>the cited definitions are not BNF.
>
>If you knew a little more about BNF and its history, you would
>firstly have not posted that erroneous statement about OPEN etc.
It isn't erroneous. You should read those sections.
This document is essentially something for implementers,
and therefore needs to be quite clear and unequivocal
and precise as to meaning.
As it stands, the draft fails to do that, and it fails the general community
because it obfuscates what it attempts to disseminate --
In point of fact, the draft document elevates obfuscation to an art form,
with its "The optional comma shall not be omitted".
>and secondly would know that BNF is a generic term (and has been
>for 40+ years).
BNF has been around for 50 years, believe it or not.
>Look in 1.4, specifically 1.4.1 and 1.4.3.
Please do try to look at them today. It would be of benefit to you,
because it would help you to avoid making fatuous remarks.
robin
+On Sep 23, 4:14 pm, "robin" <robi...@bigpond.com> wrote:
+> Van Snyder wrote in message ...
+> >The final committee draft of Fortran 2008 is available for public review.
+>
+> I am amazed that J3 would actually promote the use of
+> the fixed constants 4 and 8 as kinds for REAL statements.
+> Yet is does so in C.1.1-1.
+>
+> That entire sub-sections 1 and 2 need to be deleted,
+> and KIND(0.0) and KIND(0.0D0) be substituted for a re-written
+> sub-section 1.
+What seems to be completely amazing is that you've missed
+the entire point of C.1.1.
I missed no such thing.
What you missed entirely is the point that I was making,
namely, that here is an example promoting the use of constants for kinds.
robin
>steve <kar...@comcast.net> wrote:
>
>> On Sep 23, 4:14 pm, "robin" <robi...@bigpond.com> wrote:
>> > Van Snyder wrote in message ...
>> > >The final committee draft of Fortran 2008 is available for public review.
>> >
>> > I am amazed that J3 would actually promote the use of
>> > the fixed constants 4 and 8 as kinds for REAL statements.
>> > Yet is does so in C.1.1-1.
>> >
>> > That entire sub-sections 1 and 2 need to be deleted,
>> > and KIND(0.0) and KIND(0.0D0) be substituted for a re-written
>> > sub-section 1.
>>
>> What seems to be completely amazing is that you've missed
>> the entire point of C.1.1.
>
>Nah. That's not amazing at all - much more like about what I'd expect.
>:-(
Back to making denigrating remarks, I see!
That's why you have been in my viper file for the past few years.
You repeatedly make personal attacks on posters in this newsgroup.
robin
>
>On 2009-09-23 19:14:56 -0400, "robin" <rob...@bigpond.com> said:
>
>> I am amazed that J3 would actually promote the use of
>> the fixed constants 4 and 8 as kinds for REAL statements.
>> Yet is does so in C.1.1-1.
>>
>> That entire sub-sections 1 and 2 need to be deleted,
>> and KIND(0.0) and KIND(0.0D0) be substituted for a re-written
>> sub-section 1.
>
>kind( 0.0) and kind( 0.0d0) are not very portable.
That's what J3 recommended.
Had you read sub-section 2, you would have noticed that.
I merely took what they recommended and suggested that
that be incorporated in a re-written C.1.1.
>Are they supposed to be 32-bit and 64-bit reals,
>or 64-bit and 128-bit reals?
They can be anyting that the compiler provides.
And they are fully portable (not just "not very portable").
I note that you have not posted anything about that
in re C1.1-2.
Dan Nagle
On 2009-09-24 10:34:46 -0400, "robin" <rob...@bigpond.com> said:
> Dan Nagle wrote in message ...
>> Are they supposed to be 32-bit and 64-bit reals,
>> or 64-bit and 128-bit reals?
>
> They can be anyting that the compiler provides.
> And they are fully portable (not just "not very portable").
<splork!>
Thereby giving us the newspeak definition of "portable".
"They're fully portable, being anything the compiler provides!"
Really, folks, I can't make this up.
--
Cheers!
Dan Nagle
robin
>The final committee draft of Fortran 2008 is available for public review.
The principal descriptions of the intrinsic functions are not listed in the index.
For some functions (including some of the new functions),
there's no mention of them anywhere in the index.
Only those function names that happened to be mentioned somewhere
in the text have entries in the index. But those index references do not include
a reference to the princiupal description.
Of course I have not checked every single intrinsic. But of those that
I did check, the above applies, and there are enough of them to suggest
that all have been omitted.
robin
>Hello,
>
>On 2009-09-24 10:34:46 -0400, "robin" <rob...@bigpond.com> said:
>
>> Dan Nagle wrote in message ...
>
>>> or 64-bit and 128-bit reals?
>>
>> They can be anyting that the compiler provides.
>> And they are fully portable (not just "not very portable").
>
><splork!>
Still behaving like a pig, I see.
>Thereby giving us the newspeak definition of "portable".
By your own admission, you claimed:
"kind( 0.0) and kind( 0.0d0) are not very portable."
In point of fact, they are fully portable, as a compiler
is required to provide both single precision and another higher precision.
That makes KIND(0.0) and KIND(0.0D0) FULLY PORTABLE.
BTW, you still haven't explained why you didn't complain
about the draft promoting KIND(0.0) and KIND(0.0D0).
It has not gone innociced that in this thread that neither you
nor Maine nor Maclaren has initiated not even one original post
commenting on the draft. What does that signify?
Dick Hendrickson
> Dan Nagle wrote in message ...
>> Hello,
>>
>> On 2009-09-24 10:34:46 -0400, "robin" <rob...@bigpond.com> said:
>>
>>> Dan Nagle wrote in message ...
>>>> kind( 0.0) and kind( 0.0d0) are not very portable.
>>>> Are they supposed to be 32-bit and 64-bit reals,
>>>> or 64-bit and 128-bit reals?
>>> They can be anyting that the compiler provides.
>>> And they are fully portable (not just "not very portable").
>> <splork!>
>
> Still behaving like a pig, I see.
>
>> Thereby giving us the newspeak definition of "portable".
>
> By your own admission, you claimed:
> "kind( 0.0) and kind( 0.0d0) are not very portable."
>
> In point of fact, they are fully portable, as a compiler
> is required to provide both single precision and another higher precision.
>
> That makes KIND(0.0) and KIND(0.0D0) FULLY PORTABLE.
They are fully portable for some restricted definitions
of "fully portable". For large codes, many people
consider execution time to be a significant consideration.
Forcing slow 128 bit real arithmetic when much faster 64 bit
is good enough isn't "portable" for those people. That's
what Dan meant when he wrote "not very portable"; perhaps
he meant to say "not usefully portable in all cases", but
he's not as long winded as I.
>
> BTW, you still haven't explained why you didn't complain
> about the draft promoting KIND(0.0) and KIND(0.0D0).
I wouldn't read C.1.1 as promoting either 4 and 8 (your
original hypothesis) or KIND(0.0) and KIND(0.0D0). The
second paragraph starts with "To avoid the use of ... 4 or 8"
which is hardly "promoting". It gives a one sentence
description of KIND(0.0) and KIND(0.0D0) and then goes
on for 4 or 5 lines about SELECTED_REAL_KIND. Going from
bad to good is a reasonable way to describe alternatives.
>
> It has not gone innociced that in this thread that neither you
> nor Maine nor Maclaren has initiated not even one original post
> commenting on the draft. What does that signify?
>
>
That this is neither the time nor the place to make technical
comments about the draft. It's a good place to ask questions
and get answers.
Dick Hendrickson
Dan Nagle
On 2009-09-25 11:30:14 -0400, "robin" <rob...@bigpond.com> said:
Oh joy, c.l.f's Pet Grump and Village Idiot
has returned. Let's see where the "discussion" leads.
> Dan Nagle wrote in message ...
>> Hello,
>>
>> On 2009-09-24 10:34:46 -0400, "robin" <rob...@bigpond.com> said:
>>
>>> Dan Nagle wrote in message ...
>>
>>>> kind( 0.0) and kind( 0.0d0) are not very portable.
>>>> Are they supposed to be 32-bit and 64-bit reals,
>>>> or 64-bit and 128-bit reals?
>>>
>>> They can be anyting that the compiler provides.
>>> And they are fully portable (not just "not very portable").
>>
>> <splork!>
>
> Still behaving like a pig, I see.
The Great and Powerful robin has not diverted attention
from the funny little man behind the curtain.
>> Thereby giving us the newspeak definition of "portable".
>
> By your own admission, you claimed:
> "kind( 0.0) and kind( 0.0d0) are not very portable."
>
> In point of fact, they are fully portable, as a compiler
> is required to provide both single precision and another higher precision.
>
> That makes KIND(0.0) and KIND(0.0D0) FULLY PORTABLE.
On the contrary, since kind( 0.0) and kind( 0.0d0)
are merely circumlocutions for default real
and double precision, they are not very portable.
Note that the lack of portability of default real
and double precision was the motivation for introducing
the kind mechanism in the first place. Did robin
notice that?
> BTW, you still haven't explained why you didn't complain
> about the draft promoting KIND(0.0) and KIND(0.0D0).
Why should I? The standard mentions them
only to show a better way in the next sentence.
But then, "context" is beyond robin.
> It has not gone innociced that in this thread that neither you
> nor Maine nor Maclaren has initiated not even one original post
> commenting on the draft. What does that signify?
That all three of us had read it months ago? or as it
was being written? Not to mention, read it with comprehension?
BTW, thanks for mentioning me along with Richard
and Nick. I'm honored. :-) (or honoured, for Nick) :-)
Nick submitted his comments along with the rest
of the UK comments, then appeared in Tokyo and Las Vegas
to work towards resolving the issues raised. What
has robin done beyond publicly displaying his
misunderstanding of the text?
oo
--
Cheers!
Dan Nagle
robin
>Hello,
>
>
>Oh joy, c.l.f's Pet Grump and Village Idiot
>has returned.
I see that you are talking about yourself.
> Let's see where the "discussion" leads.
>
>> Dan Nagle wrote in message ...
>>> Hello,
>>>
>>> On 2009-09-24 10:34:46 -0400, "robin" <rob...@bigpond.com> said:
>>>
>>>> Dan Nagle wrote in message ...
>>>
>>>>> kind( 0.0) and kind( 0.0d0) are not very portable.
>>>>> Are they supposed to be 32-bit and 64-bit reals,
>>>>> or 64-bit and 128-bit reals?
>>>>
>>>> They can be anyting that the compiler provides.
>>>> And they are fully portable (not just "not very portable").
>>>
>>> <splork!>
>>
>> Still behaving like a pig, I see.
>
>The Great and Powerful robin has not diverted attention
>from the funny little man behind the curtain.
You have turned into a rude and arrogant pig.
>>> Thereby giving us the newspeak definition of "portable".
>>
>> By your own admission, you claimed:
>> "kind( 0.0) and kind( 0.0d0) are not very portable."
>>
>> In point of fact, they are fully portable, as a compiler
>> is required to provide both single precision and another higher precision.
>>
>> That makes KIND(0.0) and KIND(0.0D0) FULLY PORTABLE.
>
>On the contrary, since kind( 0.0) and kind( 0.0d0)
>are merely circumlocutions for default real
>and double precision, they are not very portable.
The draft doesn't agree with you.
It has promoted them (Para 2).
>Note that the lack of portability of default real
>and double precision was the motivation for introducing
>the kind mechanism in the first place. Did robin
>notice that?
It was to deal with the changing world, wherein more than
two real precisions were available on very many systems.
As well as that, more than one integer precision was available
on many systems.
The same goes for character sets.
It seems that you have not noticed that using SELECTED_REAL_KIND
doesn't guarantee that a program is portable.
The reason? S_R_C returns negative values when the request is
not met, and under those circumstances compilation does not
proceed. As well, it can spoil generic user procedures when two
kind values become equal. That is scarcely portable.
>> BTW, you still haven't explained why you didn't complain
>> about the draft promoting KIND(0.0) and KIND(0.0D0).
>
>Why should I? The standard mentions them
We're talking about the draft.
>only to show a better way in the next sentence.
>But then, "context" is beyond robin.
The draft doesn't say it's a better way. In point of fact,
It PROMOTES kinds 4 and 8 and states (para 3)
"it is good practice to use them".
>> It has not gone innoticed that in this thread that neither you
>> nor Maine nor Maclaren has initiated not even one original post
>> commenting on the draft. What does that signify?
>
>That all three of us had read it months ago?
I doubt it. Not in the context of the entire book.
Had you done so, you would have discovered the errors that I have noted,
including the omission of an entire chapter from the index.
There are evidently many more errors (based on Weinberg's
[or was it Knuth's?] "thesis" on errors in texts).
> or as it
>was being written? Not to mention, read it with comprehension?
You obviously have not done that.
>BTW, thanks for mentioning me along with Richard
>and Nick. I'm honored. :-) (or honoured, for Nick) :-)
>
>Nick submitted his comments along with the rest
>of the UK comments, then appeared in Tokyo and Las Vegas
>to work towards resolving the issues raised. What
>has robin done beyond publicly displaying his
>misunderstanding of the text?
>
>oo
So, you're still acting like a rude arrogant pig, I see.
What is evident is that you are afraid of anything critical
about your "pet" project. The fact remains that you have let
all these mistakes get through.
And I have not mis-understood the text.
What do you not understand about "it is good practice to use them
[viz, literal kind types]".
robin
It's not a hypothesis. It is fact.
The language is "One can select ..." and "This is accomplished by ".
There is no suggestion nor hint that this is a bad practice.
> or KIND(0.0) and KIND(0.0D0).
Certainly that is promoted.
> The
>second paragraph starts with "To avoid the use of ... 4 or 8"
>which is hardly "promoting".
See para 3.
> It gives a one sentence
>description of KIND(0.0) and KIND(0.0D0) and then goes
>on for 4 or 5 lines about SELECTED_REAL_KIND.
Both statements assume that the reader wants to avoid the use.
It has not been established why the use should be avoided.
In point of fact, para 3 says that the above methods [para 1 and para 2]
should be used, "rather than using the kind values directly".
> Going from
>bad to good is a reasonable way to describe alternatives.
Unfortunately it is not. It is unsound pedagogical practice,
as any educationalist will tell you. The right way is the one
that should be introduced.
A driving instructor doesn't involve his pupil in a collision,
and then advise him/her how to avoid doing that.
Good practices are introduced first.
>> It has not gone innoticed that in this thread that neither you
>> nor Maine nor Maclaren has initiated not even one original post
>> commenting on the draft. What does that signify?
>That this is neither the time nor the place to make technical
>comments about the draft. It's a good place to ask questions
>and get answers.
My question was rhetorical, of course.
And in any case, this IS a forum for making comments about
anything of interest. And since the Draft is available for public comment,
this is an appropriate time and place to make comments about it.
nm...@cam.ac.uk
robin <rob...@bigpond.com> wrote:
>Dick Hendrickson wrote in message <7i48blF...@mid.individual.net>...
>>
>>original hypothesis)
>
>It's not a hypothesis. It is fact.
>The language is "One can select ..." and "This is accomplished by ".
>There is no suggestion nor hint that this is a bad practice.
One can also respond to your posts, but that is also bad practice.
>> Going from
>>bad to good is a reasonable way to describe alternatives.
>
>Unfortunately it is not. It is unsound pedagogical practice,
>as any educationalist will tell you. The right way is the one
>that should be introduced.
No, I don't. When used appropriately, it is good practice.
>>> It has not gone innoticed that in this thread that neither you
>>> nor Maine nor Maclaren has initiated not even one original post
>>> commenting on the draft. What does that signify?
>
>>That this is neither the time nor the place to make technical
>>comments about the draft. It's a good place to ask questions
>>and get answers.
>
>My question was rhetorical, of course.
That's not the adjective I would have used. I made my first comments
some time ago, in the proper forum.
Regards,
Nick Maclaren.
steve
> And I have not mis-understood the text.
> What do you not understand about "it is good practice to use them
> [viz, literal kind types]".
Perhaps, you should read the entire sentence instead of cherry
picking a portion of the middle clause.
"As kind values have no portable meaning, a good practice is to
use them in programs only through named constants as described
above (for example, SINGLE, IEEE SINGLE, DOUBLE, and QUAD), rather
than using the kind values directly."
I'd say that 'rather than using the kind values directly' is a
fairly concise recommendation to not use literal kind types. If
you read the entire section, you'll see that 'only through named
constants as described above' is referring to paragraph two's
discussion of SELECT_*_KIND.
--
steve