J3 Responses to Public Comments
Dan Nagle
J3's response to the public comments
has been posted to J3's web site at
http://www.j3-fortran.org/doc/year/08/08-272.html
html format is used to enable access
to the primary documents as links.
I'm very proud of J3's efforts last week at 185.
9 people in 4.5 days processed about 75 documents.
For each paper, we had to read it, understand it,
analyze it, reckon a response, and then get the words
right to make it happen.
We weren't able to include "large" changes,
but we did include "small" changes where we could.
Where an issue was too difficult, we submitted
an interpretation request to document the issue
for future processing.
--
Cheers!
Dan Nagle
Ron Ford
> J3's response to the public comments
> has been posted to J3's web site at
>
> http://www.j3-fortran.org/doc/year/08/08-272.html
Wow, Dan, that looks like a mountain of work.
I noticed in J3's reply to FX a misspelling:
Unfortunately, the premise that intrinsic assignement between character
variables of different kind is allowed is wrong. See table 7.10 on page 152
of the draft: "Type conformance for the intrinsic assignment". Character
assignments are only allowed for "the same kind type parameter". J3
believes the mapping between characters of different kind is difficult to
define. Consequently, J3 declines to make this addition.
Maybe this thread could consider corrections, in particular typos.
--
We must respect the other fellow's religion, but only in the sense and to
the extent that we respect his theory that his wife is beautiful and his
children smart. 5
H. L. Mencken
Dan Nagle
On 2008-08-19 20:23:45 -0400, Ron Ford <r...@example.invalid> said:
> I noticed in J3's reply to FX a misspelling:
>
> Unfortunately, the premise that intrinsic assignement between character
> variables of different kind is allowed is wrong.
Sorry, no one caught it. :-(
--
Cheers!
Dan Nagle
Ron Ford
There's others, but no big deal: it's way to much pressure to have to think
and spell at the same time. That's why God created peer review.
The response that *really* caught my eye was to Richard, who shares my
opinion regarding f08. (He didn't even ask to borrow it.)
It sounded like something Condoleeza would say.:-(
--
We are here and it is now. Further than that, all human knowledge is
moonshine. 3
H. L. Mencken
Richard Maine
> J3's response to the public comments
> has been posted to J3's web site at
>
> http://www.j3-fortran.org/doc/year/08/08-272.html
...
> I'm very proud of J3's efforts last week at 185.
Indeed. Obviously a lot of work there (and handily presented, too; kudos
to whoever did that). On skimming, I find that I disagree with a few
things, to no great surprise, though mostly not major stuff.
I didn't really expect acceptance of my comment, though I felt I should
make it anyway. Probably the one other big thing is about the biggest
single new feature in the draft. I share Bob Corbett's concern about
co-arrays. (Hmm. I haven't studied it, but I wonder if an implementation
might be able to squeek by with allowing only a single image and then
making most of the co-array stuff pretty much collapse into extra rank
of ordinary arrays.)
One somewhat trivial point I noticed. I also disagree with the reply to
Corbett's comment about the multiple models for generic intrinsics
(J32024). The descriptive model for generic intrinsics changed a while
back. I think it was between f90 and f95, but I'd have to go look to
check. It used to be the model of the generic intrinsics being described
as though they were collections of specifics just like user generics.
But that model fell apart, largely for reasons like those mentioned in
the reply. The "new" model (as of f95 or so) is that the intrinsic
generics are described without reference to specifics. I think that new
model should be consistently used everywhere. I thought that it was. It
appears to me that C542 is an erroneous remnant of the older model. I
think Bob has just plain found in this remnant an error that should be
fixed. C542 doesn't even make sense as is; there are no such things as
the specific intrinsic procedures that it talks about (with the very few
exceptions that are holdovers from f66). In some cases, for the reasons
mentioned in the reply, there can't be. Yes, this error isn't new to
f2008; I see the same thing in f2003. But it still ought to be fixed,
probably just by removing that part of the constraint. After all, we do
allow a user to override an intrinsic, and we provide a long and
complicated (largely for historical reasons, I think) algorithm to
define exactly how such overrides work. So I don't see why declaring the
intrinsic attribute explicitly has to suddenly make that a no-no,
particularly when it is as ill-defined as this. I think this one should
be an interp.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Gary Scott
> On Wed, 20 Aug 2008 00:02:27 GMT, Dan Nagle posted:
>
>
>>J3's response to the public comments
>>has been posted to J3's web site at
>>
>>http://www.j3-fortran.org/doc/year/08/08-272.html
>
>
> Wow, Dan, that looks like a mountain of work.
>
> I noticed in J3's reply to FX a misspelling:
>
> Unfortunately, the premise that intrinsic assignement between character
> variables of different kind is allowed is wrong. See table 7.10 on page 152
> of the draft: "Type conformance for the intrinsic assignment". Character
> assignments are only allowed for "the same kind type parameter". J3
> believes the mapping between characters of different kind is difficult to
> define. Consequently, J3 declines to make this addition.
Would that mapping just constitute the concept of a code page (point)
translation table? That doesn't seem very hard. It could say something
generic like the mapping will achieve to the maximum extent possible the
same character glyph possibly of a different style or typeface. I don't
think anyone would expect a perfect translation since the same glyph
might not even exist in the other character set.
>
> Maybe this thread could consider corrections, in particular typos.
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Richard Maine
> Ron Ford wrote:
> > I noticed in J3's reply to FX a misspelling:
> >
> > Unfortunately, the premise that intrinsic assignement between character
> > variables of different kind is allowed is wrong. See table 7.10 on page 152
> > of the draft: "Type conformance for the intrinsic assignment". Character
> > assignments are only allowed for "the same kind type parameter". J3
> > believes the mapping between characters of different kind is difficult to
> > define. Consequently, J3 declines to make this addition.
>
> Would that mapping just constitute the concept of a code page (point)
> translation table? That doesn't seem very hard. It could say something
> generic like the mapping will achieve to the maximum extent possible the
> same character glyph possibly of a different style or typeface. I don't
> think anyone would expect a perfect translation since the same glyph
> might not even exist in the other character set.
Um, you start out by saying it wouldn't be hard. Then you follow on by
waving your arms and saying that the definition would just be to do as
well as possible? Sounds like you pretty much demonstrated the point
that it is hard to define precisely and portably. And if it isn't
precise and portable, then the benefits of "standardizing" it seem
questionable. You'll get different implementations doing it differently,
followed by complaints that the standard didn't actually standardize it
usefully.
It isn't as though it is difficult for the user to do such translation
tables. The main benefit of standardizing it would be the portability...
which you don't get with the arn-waving approach.
Ah. Dinner call. Gotta go. That will have to do, though I don't think I
said some parts very wel.
Gary Scott
> Gary Scott <garyl...@sbcglobal.net> wrote:
>
>
>>Ron Ford wrote:
>
>
>>>I noticed in J3's reply to FX a misspelling:
>>>
>>>Unfortunately, the premise that intrinsic assignement between character
>>>variables of different kind is allowed is wrong. See table 7.10 on page 152
>>>of the draft: "Type conformance for the intrinsic assignment". Character
>>>assignments are only allowed for "the same kind type parameter". J3
>>>believes the mapping between characters of different kind is difficult to
>>>define. Consequently, J3 declines to make this addition.
>>
>>Would that mapping just constitute the concept of a code page (point)
>>translation table? That doesn't seem very hard. It could say something
>>generic like the mapping will achieve to the maximum extent possible the
>>same character glyph possibly of a different style or typeface. I don't
>>think anyone would expect a perfect translation since the same glyph
>>might not even exist in the other character set.
>
>
> Um, you start out by saying it wouldn't be hard. Then you follow on by
> waving your arms and saying that the definition would just be to do as
> well as possible? Sounds like you pretty much demonstrated the point
> that it is hard to define precisely and portably. And if it isn't
> precise and portable, then the benefits of "standardizing" it seem
> questionable. You'll get different implementations doing it differently,
> followed by complaints that the standard didn't actually standardize it
> usefully.
Theres no arm waving there. It isn't hard to characterize this
functionality. Code point translation is well understood, been
implented in various operating systems and applications for many
decades. A precise definition of the contents of the code pages isn't
necessary to describe the general desired behavior. It isn't a problem
in the mast majority of usages that the mapping isn't perfect, that it
cant handle situations where the glyphs don't exist in one or the other
code page. You could even make those cases a one for one mapping to the
same code point value. Surely there are standards in this area that
could be referenced.
>
> It isn't as though it is difficult for the user to do such translation
> tables. The main benefit of standardizing it would be the portability...
> which you don't get with the arn-waving approach.
No, it isn't difficult for the user to perform such translations, even
in Fortran (much easier in REXX tho). But it would be a nice addition.
>
> Ah. Dinner call. Gotta go. That will have to do, though I don't think I
> said some parts very wel.
>
--
Gary Scott
James Giles
...
> [...] Code point translation is well understood, been
> implented in various operating systems and applications for many
> decades. A precise definition of the contents of the code pages isn't
> necessary to describe the general desired behavior. It isn't a
> problem in the mast majority of usages that the mapping isn't
> perfect, that it cant handle situations where the glyphs don't exist
> in one or the other code page. You could even make those cases a one
> for one mapping to the same code point value. Surely there are
> standards in this area that could be referenced.
The problem is that these issues are beyond the scope of the
Fortran standard. I think the committee should just go ahead
with permitting mixed-KIND character operations and use
the "implementation dependent" description. Then in the
section notes they should reference the appropriate other
standards (ASCII, ISO-8859-*, EBCDIC, etc.). Those
other standards are where the appropriate correspondences
are defined.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
"Simplicity is prerequisite for reliability" -- E. W. Dijkstra
Reinhold Bader
[...]
> I didn't really expect acceptance of my comment, though I felt I should
> make it anyway. Probably the one other big thing is about the biggest
> single new feature in the draft. I share Bob Corbett's concern about
> co-arrays. (Hmm. I haven't studied it, but I wonder if an implementation
> might be able to squeek by with allowing only a single image and then
> making most of the co-array stuff pretty much collapse into extra rank
> of ordinary arrays.)
a large class of parallel patterns which needs at least two images to run correctly,
and/or without blocking.
[...]
Dan Nagle
On 2008-08-19 21:22:58 -0400, nos...@see.signature (Richard Maine) said:
> Indeed. Obviously a lot of work there (and handily presented, too; kudos
> to whoever did that).
Thanks. Steve Lionel wrote the first draft. I polished it a bit,
and added the results from Friday papers, and those in the Post.
> I share Bob Corbett's concern about
> co-arrays.
Well, the complaint about coarrays is one of those fact-free complaints
that's hard to rebut just due to the lack of specifics.
OK, so something way cool may drop from the sky someday
that's better than coarrays. So what?
_What_ is going to magically appear, on _which_ day,
that's _how much_ better than coarrays, based upon _what_ criteria?
If you ask a specific question, you might, or might not,
have a point. Best must not kill better, especially when best
has not yet been made plainly to appear.
But I doubt parallel Fortran will disappear
as everyone rewrites their parallel codes in Fortress. :-)
> (Hmm. I haven't studied it, but I wonder if an implementation
> might be able to squeek by with allowing only a single image and then
> making most of the co-array stuff pretty much collapse into extra rank
> of ordinary arrays.)
Yes, it's allowed under the size and complexity clause.
One of the complaints about coarrays (from a vendor)
is that "my customers don't want or need parallelism".
To which the answer is given "you don't need parallel
execution". Which gets the reply "oh, if I parse
the square brackets, my customers will demand parallel execution".
As the ol' country judge said, "Pick a story, son. Stick with it."
> The "new" model (as of f95 or so) is that the intrinsic
> generics are described without reference to specifics. I think that new
> model should be consistently used everywhere. I thought that it was.
But, in fact, intrinsics like sqrt() are modeled just fine
as a collection of specifics (sqrt(), dsqrt(), csqrt()).
But things like *loc() (really, anything with the dim= present)
can't even be described as one function, let alone modeled
as a collection of specifics.
--
Cheers!
Dan Nagle
Richard Maine
Yes, I think that's what I said. Some could be modeled the old way.
Others simply cannot. All can be modelled the new way.
1. Consistency is good as a general principle. Perhaps not as a hobbling
mandate (cite Emerson), but certainly as a guide. Consistency is
possible and indeed quite easy in this case, though only if one sticks
to the "new" (as of f95 or so) model.
2. You didn't answer the one specific, concrete criticism at all. (I
might relate this to the elided material on specific versus general
comments. I had a specific criticism, but you have given only a general
answer, which doesn't address that specific). The constraint that Bob
refered to (C542) is plain nonsense as is. It refers to the old model,
which is nowhere defined. It talks about the specific interfaces that
don't exist and cannot exist in all cases. Even for the cases where one
could express things in terms of specific interfaces, the standard
doesn't do that (with a *VERY* small list of exceptions, and even there
it is incomplete - sqrt doesn't have standard specifics for double
complex or for any real kinds other than single or double). So the
constraint at best refers to undefined concepts, with the reader left to
speculate as to exactly what these alleged specifics might be. Is it
just the ones with specific names? Is it all the ones where it is
possible to reverse engineer a plausible set of specifics? How about the
cases where one could express the functionality defined by the standard
via multiple incompatible sets of specifics? (Yes, plenty of such cases
exist). The reader's speculation is going to be particularly hard for
the cases where, as you quite properly note, there can be no such
specifics. Even by the most generous of interpretations, this constraint
is ill-defined. I happen to think that the best resolution is to drop
part of the constraint, but if not that, at least it needs fixing so
that it actually says whatever it is that it means instead of leaving it
to guesswork.
Ron Ford
> Gary Scott wrote:
> ...
>> [...] Code point translation is well understood, been
>> implented in various operating systems and applications for many
>> decades. A precise definition of the contents of the code pages isn't
>> necessary to describe the general desired behavior. It isn't a
>> problem in the mast majority of usages that the mapping isn't
>> perfect, that it cant handle situations where the glyphs don't exist
>> in one or the other code page. You could even make those cases a one
>> for one mapping to the same code point value. Surely there are
>> standards in this area that could be referenced.
>
> The problem is that these issues are beyond the scope of the
> Fortran standard. I think the committee should just go ahead
> with permitting mixed-KIND character operations and use
> the "implementation dependent" description. Then in the
> section notes they should reference the appropriate other
> standards (ASCII, ISO-8859-*, EBCDIC, etc.). Those
> other standards are where the appropriate correspondences
> are defined.
James seems to have been the second most-effective commentor this time
around, behind Bob Corbett. I've never used the g0 edit descriptor. Does
someone have a snippet to illustrate its use?
What follows is the text of the the recommendation and the response:
commentor's Subject was "The g0 edit descriptor"
According to the draft document:
C1007 (R1006) For the G edit descriptor, d shall be specified if and only
if w is not zero.
To me this eliminates any value the g0 feature might have. What's needed is
something like list-directed output but with the precision controlled by
the programmer.
For example, in order for an input item to have the same internal value as
the original value that was output, the output must generally carry at
least 9 digits (for IEEE single precision).
If the ability to specify d were present, G would probably become my main
output edit descriptor. I was looking forward to g0 before I found that it
wasn't allowed a d part.
J3 Response
J3 agrees that this would be a useful feature, and proposes the following
edits.
In the draft at subclause 10.3.2
Delete "and only if" from C1007
Add new constraint after C1007:
"C1007+ (R1006) For the G edit descriptor, e shall not be specified if w is
zero."
In the draft at subclause 10.7.5.1
Replace "the external field occupies w positions; for real or complex data"
with "the external field occupies w positions. For real or complex data"
In the draft at subclause 10.7.5.2.2 paragraph 2
Replace with: "When used to specify the output of real or complex data, the
G0 and G0.d edit descriptors follow the rules for the ESw.dEe edit
descriptor. Reasonable processor-dependent values of w, d (if not
specified), and e are used with each output value."
!end excerpt
Steve Lionel
> James seems to have been the second most-effective commentor this time
> around, behind Bob Corbett. I've never used the g0 edit descriptor. Does
> someone have a snippet to illustrate its use?
You have not seen it because it's new in the F2008 draft. In F95 (and
maybe F90) the G format can be used with any intrinsic type for input or
output. But through F2003, it requires that you specify a width for all
types. There was a desire to allow reals and complexes to be output
with "minimal" width as one can for integers with I0.
As it was explained to me, there had been a proposal to add some sort of
CSV-like formatting to Fortran to provide for data interchange. That
got shot down, but in its place two items did make it in to the F08
draft: G0 and "unlimited format items". G0 is along the lines of I0 in
that the "processor" determines the width for the output value. While
the standard does not say so explicitly, the expectation is that this
will be the minimum width necessary to represent the value. G0 does
this for all types, not just integers. G0 is allowed for output only,
not input.
The comment you refer to said that G0 was less useful because it did not
allow the minimum number of digits to be specified for real and complex
values. J3 agreed and amended the text to allow "d" to be specified on
output.
The notion was that with G0 and the unlimited format item (this allows
you to use * as the repeat count for a format group) you could have a
truly generalized output format for arbitrary data.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
glen herrmannsfeldt
(snip)
> The notion was that with G0 and the unlimited format item (this allows
> you to use * as the repeat count for a format group) you could have a
> truly generalized output format for arbitrary data.
How about an A0 that would write character data after
trimming trailing blanks? It seems that G is allowed for
CHARACTER data, so G0 would also work.
-- glen
Dan Nagle
An a0 edit descriptor that effectively is an a edit descriptor
for a list item that is trim( list-item) was a priority of mine
for f08. But in the competition for space in f08, it lost.
I haven't had the time or too much inclination to fuss
with it since then.
Battling the anti-coarrays forces is *much* more important.
It has taken an amount of my time all out of proportion
to the quality of arguments made against coarrays.
g0 and *( ... ) were done "on the cheap" to do it quickly,
without too much effort. The idea was to get something
to write CSV files without disrupting the schedule.
James Giles' comment gave the opportunity to fix it a bit.
I'm glad we were able to do so. Note that Steve Lionel
wrote the papers at his first meeting, a real accomplishment.
--
Cheers!
Dan Nagle
Ron Ford
> Hello,
>
> On 2008-08-25 17:08:18 -0400, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
>
> Battling the anti-coarrays forces is *much* more important.
> It has taken an amount of my time all out of proportion
> to the quality of arguments made against coarrays.
This was one of Bob Corbett's comments which J3 rejected:
Public Review Comment J32005 from Robert Corbett
commentor's Subject was "Coarrays should be optional"
The Fortran 2008 draft should not be approved unless coarrays are made
optional.
Coarrays are too new to belong in Fortran 2008. Many models for parallel
programming have been developed. Coarrays are not clearly superior to these
other models. Making coarrays optional would allow further development of
coarrays without creating problems if other models of parallel programming
prove more successful.
J3 Response
Coarrays have been implemented in commercially available compilers for a
decade, which is longer than the typical lifetime of a Fortran standard.
The SPMD programming model implemented in Fortran with coarrays is that
used by MPI, which is the most successful parallel programming model
available. Previous experience with optional parts of the standard is that
they are not widely implemented. Since the most often voiced complaint
about coarrays is that they are not widely available, this is not an
appropriate course of action. The status of coarrays in the proposed
Fortran standard has been extensively debated and balloted, and J3 believes
the outcome should not be changed.
!end excerpt
There are at least ways to disagree with J3 here:
1) You have a qualified opinion on the merits of co-arrays and disagree
with J3.
2) You couldn't hit co-arrays with a baseball but think that it is more on
the plates of implementors, who have not achieved a single compiler for
standard(n-1).
Dan advances the notion that f08 improves f95 and has little to do with f03
non-implementation.
--
When a new source of taxation is found it never means, in practice, that
the old source is abandoned. It merely means that the politicians have two
ways of milking the taxpayer where they had one before. 8
H. L. Mencken
Dan Nagle
On 2008-08-25 18:36:49 -0400, Ron Ford <r...@example.invalid> said:
> 1) You have a qualified opinion on the merits of co-arrays and disagree
> with J3.
Supporters of coarrays, generally, have written parallel programs.
Opponents, generally, have not.
> 2) You couldn't hit co-arrays with a baseball but think that it is more on
> the plates of implementors, who have not achieved a single compiler for
> standard(n-1).
The sticking point for f03 is PDTs. They're *much* harder
than their supporters imagined (or the vendors either FTM).
Implementors are implementing coarrays ahead of many f03 features.
I guess they are responding to their customers rather than being
fussy about revision numbers.
> Dan advances the notion that f08 improves f95 and has little to do with f03
> non-implementation.
When some one shows me otherwise, I'll stop making the claim. :-)
--
Cheers!
Dan Nagle
Ron Ford
> Hello,
>
> On 2008-08-25 18:36:49 -0400, Ron Ford <r...@example.invalid> said:
>
>> 1) You have a qualified opinion on the merits of co-arrays and disagree
>> with J3.
>
> Supporters of coarrays, generally, have written parallel programs.
> Opponents, generally, have not.
Dr. Reid posted a link to technical information on co-arrays, and it looked
like a lot of technical reports: they have that pdf form that one sees in
contemporary computer standards and a wealth of information that is not
germane to learning. 1706.pdf?
Anyways, I didn't get much from the reading other than to do another
forty-five minutes of reading on the new standard in an undirected way. I
thought of it recently when I was creating arrays to sort. I created two
arrays, one that let itself be selection-sorted and another that was
quicksorted. After I created two arrays that were the size of the
original, I came to suspect that a better solution would combine aspects of
the two, indeed would run in tandem, and that this might be a motivation
for the notion of co-arrays.
>
>> 2) You couldn't hit co-arrays with a baseball but think that it is more on
>> the plates of implementors, who have not achieved a single compiler for
>> standard(n-1).
>
> The sticking point for f03 is PDTs. They're *much* harder
> than their supporters imagined (or the vendors either FTM).
>
> Implementors are implementing coarrays ahead of many f03 features.
> I guess they are responding to their customers rather than being
> fussy about revision numbers.
>
>> Dan advances the notion that f08 improves f95 and has little to do with f03
>> non-implementation.
>
> When some one shows me otherwise, I'll stop making the claim. :-)
Bob hasn't addressed your thesis, as far as I've read. Is he a member of
the axis against co-arrays? His words were "should be optional."