Challenge 4
john
dcl a(10,10) float, diag(10) defined (1sub, 1sub);
put (d); prints the diagonal elements of array a.
David Frank
"john" <jo...@nospam.com> wrote in message
news:cn7Fb.60051$aT.1...@news-server.bigpond.net.au...
> 4. Fortran CAN'T equivalence a vector with the diagonal of a matrix.
>
> dcl a(10,10) float, diag(10) defined (1sub, 1sub);
> put (d); prints the diagonal elements of array a.
>
But above is static not dynamic, and thus has limited functionality.
otoh, you cant fetch a diagonal from a dynamic array
with a executable statement using 1 statement.
forall (i=1:n) diagonal(i) = array(i,i)
Dave Thompson
comp.lang.pl1 as part of a (the?) long-running David Frank flamefest;
comp.lang.fortran added with some trepidation:
> 4. Fortran CAN'T equivalence a vector with the diagonal of a matrix.
>
> dcl a(10,10) float, diag(10) defined (1sub, 1sub);
> put (d); prints the diagonal elements of array a.
For the specific case of diagonal, I *think* this will work:
REAL/whatever Matrix (1:N, 1:N)
TYPE EveryNPlus1; SEQUENCE
REAL/whatever Take, Skip (1:N)
END TYPE EveryNPlus1
TYPE(EveryNPlus1) Overlay (1:N)
EQUIVALENCE (Matrix, Overlay)
and now you can use Overlay%Take as a vector, or I'm pretty sure even
set an "assumed-shape" dummy or POINTER to it (F9x array POINTERs are
full dope vectors). Overlay(N) runs off the end of the last column of
Matrix (Fortran arrays are column-major) though Overlay%Take(N) aka
Overlay(N)%Take doesn't, so I'm not sure this is technically legal.
Similarly for the antidiagonal, and hyper versions; but not more
general isub cases, which you have under a different item number.
With F2k03? "type kind parameters" you might be able to improve the
syntax some, but I haven't looked at it in enough detail to be sure,
and anyway that is neither official nor implemented yet.
- David.Thompson1 at worldnet.att.net
David Frank
"Dave Thompson" <david.t...@worldnet.att.net> wrote in message
news:jqcsuvgoe5ana86ma...@4ax.com...
I dont claim to understand your example.
However I'm happy to have a NON-HOSTILE response from someone.
Perhaps as a observer with obvious Fortran skills you can offer
an opinion whether the summary documented in reverse order 30:1
reflects a accurate assessment of syntax available to Windows
Fortran users and not available to Windows PL/I users.
see: http://home.cfl.rr.com/davegemini/summary.txt
BTW, you do know that [.....] is supported in F2003 (which
becomes the standard in March 2004)
and in several advanced Windows Fortran compilers now as an
extension?
Dan Nagle
At the expense of touching the tar baby,
On Sun, 28 Dec 2003 12:13:56 GMT, "David Frank"
<dave_...@hotmail.com> wrote:
<snip>
>
>
>BTW, you do know that [.....] is supported in F2003 (which
>becomes the standard in March 2004)
Probably more like November 2004. What happens in March?
<snip>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
David Frank
"Dan Nagle" <dna...@erols.com> wrote in message
news:gautuvs1hkul97rm2...@4ax.com...
>
>>BTW, you do know that [.....] is supported in F2003 (which
>>becomes the standard in March 2004)
>Probably more like November 2004. What happens in March?
<snip>
Below story says it likely will be approved in Mar. 2004
http://sdtimes.com/news/092/story9.htm
Dan Nagle
I _knew_ this was touching a tar baby. :-(
The story is wrong. What happens in March?
Dick Hendrickson
Your example looks like it should work to me, but I'm too lazy to try
it. I haven't been following this thread from the beginning, so I'm
not sure what the point of it is. But one observation, in my
>opinion<, all of the interesting and useful work done in real world
Fortran programs of any interesting and useful scope is done on
dummy arguments. And you can't do >any< equivalencing to dummy
arguments, so the answer to the question is more likely "who cares".
But, Fortran 2003 does allow reranking and remapping of arrays
via pointers. Fortran 95 didn't allow any rank changing with
pointers. F03 is limited in that you can only provide higher
rank views of an array. You can't use pointers to change a 2d
array into a 1d array. But the following is abstracted from
the draft 03 standard:
real, target :: MYDATA ( NR*NC ) ! A 1d array
real, pointer :: MATRIX ( :, : ) ! A rank-two array
real, pointer :: DIAG ( : ) ! A one D array
MATRIX( 1:NR, 1:NC ) => MYDATA ! The 2d MATRIX view
DIAG => MYDATA( 1::NR+1 ) ! The 1d diagonal of MATRIX
You have to go through the artifical step of having the original
"matrix" be a 1d array, which is likely to be a pain in the rear for
dummy arguments. But after that, MATRIX acts just like any
2d array and DIAG like any 1d array ( with steps of NR+1 in memory).
Dick Hendrickson
Dan Nagle
Having now actually read the article, it's confused
on a number of points. The "FCD" is standards speak
for Final Committee Draft, but that doesn't make it the standard.
Indeed, several (minor, editorial) changes have been proposed.
At J3's March meeting, the United States position
on these editorial changes will be finalized. And J3 was also
responsible for the f77 and f66 standards, but that's ancient.
John Reid is not a member of J3 (he'd be most welcome
if he had the time), he's the convenor of WG5.
In May, WG5 (the international committee actually responsible
for Fortran) will vote on the edits to the draft.
If that vote carries (WG5's position will be declared,
then national bodies around the world will have some months
to formally vote- it's a large standard everyone needs time
to read it, some folks need time to translate it).
If that vote carries, then ISO will start the process
of publishing the new standard, which is anticipated
to be around November 04.
(I think I've got the process right, I may have slipped somewhere.)
On other points, the import statement doesn't allow access
to "information stored on the server" (whatever that means
in this context), and iso_fortran_env isn't a keyword,
it's the name of an intrinsic module. I wouldn't describe
the volatile attribute as meaning that the compiler "should not
cache that variable in memory", rather, the variable should not be
cached in register, but the memory location should always be used.
There is access to the command line, but it's not through
the import statement nor iso_fortran_env (although some
wanted the procedures providing the access to reside there).
So, ahh, it seems the journalist was close to deadline
when the article was written. The thrust of the story,
that f03 is close to publication is right, and the mention
of J3's web site, John Reid's article, and NAG's web site
(who host WG5's web site), seem appropriate to me.
It's a big standard, if you don't speak standardese,
you may have some difficulty getting the finer points.
robin
> Perhaps as a observer with obvious Fortran skills you can offer
> an opinion whether the summary documented in reverse order 30:1
> reflects a accurate assessment of syntax available to Windows
> Fortran users and not available to Windows PL/I users.
>
> see: http://home.cfl.rr.com/davegemini/summary.txt
> PL/I CANT FAQ (demo'ed by Intel/Compaq Visual Fortran examples)
> ===================================================================
> ASSERTION: Windows PL/I can not translate following Fortran source,
> producing outputs shown, or if no outputs shown, equivalent code that
> meets claims made for Fortran source, (ie. using 1 statement).
Frank knows the statements made above and throughout his "summary"
to be FALSE, for he presented the same in comp.lang.pl1
where equivalent PL/I code was shown to him.
An instance is given here. Others will follow.
> 21. CANT support multi-byte (MB) character sets as there are
> no multi-byte functions, MBINDEX, MBSCAN, MBVERIFY, etc.
FALSE.
The corresponding PL/I multibyte functions are called
INDEX, SEARCH, VERIFY
and so on.
Frank was advised of this a week ago (see appendix I)
He was previously and subsequently explicitly
advised that PL/I functions are generic (Appendix II).
========================Appendix I===========================================
From: "David Frank" <dave_...@hotmail.com>, RoadRunner - Central Florida
Date: Tue, 23 Dec 2003 08:38:41 GMT
>
> If PL/I doesnt support multi-byte (MB) character sets then
> I can re-activate CANT #21 #22 merely by changing the SCAN, VERIFY
> to MBSCAN, MBVERIFY, so does it?
PL/I supports WIDECHAR and GRAPHIC as well as CHARACTER (ASCII) etc
========================Appendix II=============================
From: "David Frank" <dave_...@hotmail.com>, RoadRunner - Central Florida
Date: Wed, 24 Dec 2003 14:05:29 GMT
> But does it have equivalents for:
> MBINDEX, MBSCAN, MBVERIFY, etc. ??
PL/I functions are generic.
No special names are required.
INDEX, SEARCH (=SCAN), and VERIFY etc handle BIT, CHAR, GRAPHIC
and WIDECHAR strings.
Greg Lindahl
Please stop cross-posting this flamewar. Better yet, ignore Dave. He's
a twit.
-- greg
David Frank
"Greg Lindahl" <lin...@pbm.com> wrote in message
news:3ff12309$1...@news.meer.net...
And you are a cross-posting anti-windows Lin(ux)dahl freak.