https://www.jiscmail.ac.uk/cgi-bin/webadmin?RSS&L=COMP-FORTRAN-90&v=1.0COMP-FORTRAN-90 List
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=COMP-FORTRAN-90
COMP-FORTRAN-90 List Archives2017-07-21T00:24:15ZPowered by L-Soft's LISTSERV mailing list manager
http://www.lsoft.com/products/listserv-powered.asp
http://www.lsoft.com/images/listserv_small.gifRe: Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;abbf2282.1707
>> I think that a strong case should be made that the behavior of this<br>>> intrinsic should be consistent with SELECT TYPE which does really end<br>>> up being SELECT TYPE AND KIND.<br><br>No, this would have adverse impacts both on existing program semantics, and on performance.<br><br>>As an ordinary Fortran enthusiast, it is extremely, extremely disconcerting to see a situation where an intrinsic procedure introduced as recently as Fortran 2008 standard revision can end up as "useless". [...]
2017-07-21T09:24:10+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;abbf2282.1707Re: New WG5 web site and Fortran 2020 feature survey!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;bf99f9de.1707
Van,<br><br>The whole idea of a "ranked choice" survey is to make the responder think<br>about the choices. If one could rank everything #1, it would not be that<br>useful. It's not terribly important about how you rank features you don't<br>care about - I could have added a "N/A" checkbox to each one but decided<br>not to do that. After the survey is open for a while I will look to see<br>what people are saying and maybe put it in. [...]
2017-07-20T09:07:04-04:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;bf99f9de.1707Re: New WG5 web site and Fortran 2020 feature survey!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;aa779edf.1707
In the survey, assigning a priority to one category erased the priority<br>in another category if it was the same. In my survey, it erased the<br>priorities for bit strings, automatic allocation, and unsigned integer,<br>for which I wanted to assign "8". Maybe a "not terribly interesting and<br>I don't want to put a relative rank on them" button that can be assigned<br>to more than one would be useful, or just allow leaving it blank without<br>the script sniveling "This question requires an answer" and refusing to<br>submit the survey, along with a button that says "You didn't assign [...]
2017-07-19T19:18:45-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;aa779edf.1707New WG5 web site and Fortran 2020 feature survey!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b4418e46.1707
For many years, the "web home" of ISO/IEC JTC1/SC22/WG5 (the international<br>Fortran standards committee, or WG5 for short) has been graciously hosted<br>by NAG. I am pleased to announce that WG5 now has its own web site:<br>https://wg5-fortran.org/ The site is served over https and is "mobile<br>friendly".<br><br>The WG5 web site is where you'll find news about what's happening with the<br>Fortran standard, and links to all WG5 documents. Information on current<br>and past standards is also available there. [...]
2017-07-19T20:43:48-04:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b4418e46.1707Re: Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fd38efe2.1707
On Tue, Jul 18, 2017 at 4:36 PM, Van Snyder <Van.Snyder@jpl.nasa.gov> wrote:<br>> I agree with Tom that SELECT TYPE and SAME_TYPE_AS ought to be<br>> consistent.<br>><br>> On Tue, 2017-07-18 at 12:51 +0000, Clune, Thomas L. (GSFC-6101) wrote:<br>>> Ouch. Granted that I use this rarely, and mostly in the well-defined<br>>> context of an inheritance tree. But now I need to go and look to see<br>>> if I have any ticking bombs in code that use CLASS(*).<br>>><br>>><br>>> I think that a strong case should be made that the behavior of this<br>>> intrinsic [...]
2017-07-19T10:51:46-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fd38efe2.1707Re: Intrinsic real kinds
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;70f947e6.1707
On Wed, 2017-07-19 at 12:09 +1200, John Harper wrote:<br>> A problem I have with kinds is that the three compilers I use most<br>> offer 4, 4 and 3 different real kinds: gfortran and g95 offer precisions<br>> 6,15,18,33 and ifort offers only 6,15,33. I have not yet discovered how<br>> to write a standard-conforming program, valid with all three compilers,<br>> that has a generic interface block and a specific function for each<br>> real kind. This little example showing what I mean works with gfortran<br>> and g95, but ifort complains, correctly, "Ambiguous generic interface<br>> SQR: [...]
2017-07-18T17:48:49-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;70f947e6.1707Intrinsic real kinds
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4e289751.1707
A problem I have with kinds is that the three compilers I use most<br>offer 4, 4 and 3 different real kinds: gfortran and g95 offer precisions<br>6,15,18,33 and ifort offers only 6,15,33. I have not yet discovered how<br>to write a standard-conforming program, valid with all three compilers,<br>that has a generic interface block and a specific function for each<br>real kind. This little example showing what I mean works with gfortran<br>and g95, but ifort complains, correctly, "Ambiguous generic interface<br>SQR: previously declared specific procedure SQR18 is not distinguishable<br>from this declaration. [SQR33]" [...]
2017-07-19T12:09:16+12:00John Harperhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4e289751.1707Re: Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4874ed8b.1707
To avoid trouble with programs using the present SAME_TYPE_AS, should<br>there also be a new intrinsic, perhaps called SAME_KIND_AS, that checks<br>both type and (if one exists) kind?<br><br>On Tue, 18 Jul 2017, Malcolm Cohen wrote:<br><br>> Date: Tue, 18 Jul 2017 11:08:52 +0900<br>> From: Malcolm Cohen <malcolm@NAG-J.CO.JP><br>> Reply-To: Fortran 90 List <COMP-FORTRAN-90@JISCMAIL.AC.UK><br>> To: COMP-FORTRAN-90@JISCMAIL.AC.UK<br>> Subject: Re: Misuse of same_type_as intrinsic?<br>><br>> Actually this behaviour was already the result of a defect report. Different processors were already giving different answers here, and there was no consensus on what the result should be (and some thought [...]
2017-07-19T12:09:02+12:00John Harperhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4874ed8b.1707Re: Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;44e8e4d2.1707
I agree with Tom that SELECT TYPE and SAME_TYPE_AS ought to be<br>consistent.<br><br>On Tue, 2017-07-18 at 12:51 +0000, Clune, Thomas L. (GSFC-6101) wrote:<br>> Ouch. Granted that I use this rarely, and mostly in the well-defined<br>> context of an inheritance tree. But now I need to go and look to see<br>> if I have any ticking bombs in code that use CLASS(*).<br>><br>><br>> I think that a strong case should be made that the behavior of this<br>> intrinsic should be consistent with SELECT TYPE which does really end<br>> up being SELECT TYPE AND [...]
2017-07-18T13:36:04-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;44e8e4d2.1707Re: Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;66f7e3e2.1707
Thanks for the reply Malcolm. I confess that the issue of type parameter had,<br><br>for the briefest moment, occurred to me, but I immediately dismissed it as<br><br>irrelevant for some reason. I understand better now, and your assessment<br><br>that SAME_TYPE_AS is mostly useless as it currently stands. That's unfortunate.<br><br>I've only ever needed to use this once, and will need to roll my own version for [...]
2017-07-18T16:11:34+00:00Carlson, Neilhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;66f7e3e2.1707Re: Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;76b559aa.1707
Ouch. Granted that I use this rarely, and mostly in the well-defined context of an inheritance tree. But now I need to go and look to see if I have any ticking bombs in code that use CLASS(*).<br><br>I think that a strong case should be made that the behavior of this intrinsic should be consistent with SELECT TYPE which does really end up being SELECT TYPE AND KIND. [...]
2017-07-18T12:51:35+00:00Clune, Thomas L. (GSFC-6101)https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;76b559aa.1707Re: Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;44e27e66.1707
Actually this behaviour was already the result of a defect report. Different processors were already giving different answers here, and there was no consensus on what the result should be (and some thought it should be invalid). So we made it processor-dependent.<br><br>One issue is that with intrinsic types, SAME_TYPE_AS is almost always insufficient as being REAL does not tell you the kind type parameter (most derived types don’t have type parameters so much less of an issue there). So the function is basically useless for intrinsic types anyway. (So some thought that for intrinsic types it should do a [...]
2017-07-18T11:08:52+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;44e27e66.1707Re: Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8708f2d6.1707
On Fri, 2017-07-14 at 12:28 -0600, Neil Carlson wrote:<br>><br>><br>><br>><br>> On Fri, Jul 14, 2017 at 12:23 PM, Van Snyder <Van.Snyder@jpl.nasa.gov><br>> wrote:<br>><br>> On Fri, 2017-07-14 at 12:16 -0600, Neil Carlson wrote:<br>> > [...] that the arguments to same_type_as<br>> > cannot have dynamic types that are intrinsic types<br>> (non-extensible).<br>> > Is that right?<br>><br>><br>><br>> Intrinsic types cannot be extended, but they can be the<br>> dynamic type of<br>> unlimited polymorphic -- class(*) -- variables.<br>><br>><br>><br>> Yes, and I do so. But It is [...]
2017-07-14T13:34:10-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8708f2d6.1707Re: Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d279dc41.1707
On Fri, Jul 14, 2017 at 2:34 PM, Neil Carlson <neil.n.carlson@gmail.com> wrote:<br>> To be completely explicit, is the following use of same_type_as standard<br>> conforming?<br>><br>> program main<br>> class(*), allocatable :: x, y<br>> allocate(x, source=.true.)<br>> allocate(y, source=2.0)<br>> print *, same_type_as(x, y)<br>> end program<br>><br><br>Per the standard blurb you provided, is not the result of the print<br>statement processor-dependent , implying this little program, while<br>standard-conforming, can possibly give different answers with<br>different processors? [...]
2017-07-14T15:12:50-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d279dc41.1707Re: Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;607534fe.1707
To be completely explicit, is the following use of same_type_as standard<br>conforming?<br><br>program main<br>class(*), allocatable :: x, y<br>allocate(x, source=.true.)<br>allocate(y, source=2.0)<br>print *, same_type_as(x, y)<br>end program
2017-07-14T12:34:36-06:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;607534fe.1707Re: Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9e5e7fcf.1707
On Fri, Jul 14, 2017 at 12:23 PM, Van Snyder <Van.Snyder@jpl.nasa.gov><br>wrote:<br><br>> On Fri, 2017-07-14 at 12:16 -0600, Neil Carlson wrote:<br>> > [...] that the arguments to same_type_as<br>> > cannot have dynamic types that are intrinsic types (non-extensible).<br>> > Is that right?<br>><br>> Intrinsic types cannot be extended, but they can be the dynamic type of<br>> unlimited polymorphic -- class(*) -- variables.<br>> [...]
2017-07-14T12:28:54-06:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9e5e7fcf.1707Re: Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;82475e1a.1707
On Fri, 2017-07-14 at 12:16 -0600, Neil Carlson wrote:<br>> I have some parsing code that processes a sequence of values arriving<br>> in class(*) variables and creates an array from them. The type of the<br>> array is established by that of the first value, and is not known<br>> beforehand. The first value is cached as the class(*) variable<br>> "mold", and I am checking that each subsequent "value" has the same<br>> type by using same_type_as(value, mold). This has worked as I<br>> expected for a number of compilers, but in looking at the standard<br>> again, [...]
2017-07-14T11:23:15-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;82475e1a.1707Misuse of same_type_as intrinsic?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;14e18734.1707
I have some parsing code that processes a sequence of values arriving in<br>class(*) variables and creates an array from them. The type of the array is<br>established by that of the first value, and is not known beforehand. The<br>first value is cached as the class(*) variable "mold", and I am checking<br>that each subsequent "value" has the same type by using same_type_as(value,<br>mold). This has worked as I expected for a number of compilers, but in<br>looking at the standard again, I'm thinking this behavior is just a<br>fortunate "extension" (not shared by a new compiler), and that [...]
2017-07-14T12:16:28-06:00Neil Carlsonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;14e18734.1707Re: springer make a range of Turing Award winners papers avaialble
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;dd00a3fe.1707
Only the first two pages are available for a large number of the papers.<br>Perhaps Springer will fix this at some point.<br><br>On 7/4/2017 1:54 AM, Ian Chivers wrote:<br>> Some of These papers may be of interest<br>> To people on the list<br>><br>> Visit<br>><br>> http://www.springer.com/gp/marketing/turing-award-50-years?utm_campaign=CON3<br>> 2079_4&utm_medium=newsletter&utm_source=email&wt_mc=email.newsletter.8.CON32<br>> 079.internal_4<br>><br>> FREE: Read & download proceedings papers by Turing Award winners
2017-07-04T13:04:08-07:00Jeff Rymanhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;dd00a3fe.1707springer make a range of Turing Award winners papers avaialble
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9495e114.1707
Some of These papers may be of interest<br>To people on the list<br><br>Visit<br><br>http://www.springer.com/gp/marketing/turing-award-50-years?utm_campaign=CON3<br>2079_4&utm_medium=newsletter&utm_source=email&wt_mc=email.newsletter.8.CON32<br>079.internal_4<br><br>FREE: Read & download proceedings papers by Turing Award winners
2017-07-04T09:54:00+01:00Ian Chivershttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9495e114.1707Re: elements of array coarray var defined/referenced in unordered segments
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3c640c08.1706
> On Jun 22, 2017, at 5:39 AM, Anton Shterenlikht <mexas@BRIS.AC.UK> wrote:<br>><br>> Is this program conforming?<br><br>Yes.<br><br>><br>> integer :: i(4)[*]<br>> i = this_image()<br>> sync all<br>> if ( this_image() .gt. 1 ) i(1) = i(3)[ this_image() - 1 ]<br>> if ( this_image() .lt. num_images() ) i(4) = i(2)[ this_image() + 1 ]<br>> sync all<br>> write (*,*) this_image(), i<br>> end<br>> [...]
2017-06-22T15:04:13+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3c640c08.1706Re: elements of array coarray var defined/referenced in unordered segments
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;807fa8f4.1706
>Anton,<br>><br>>I don't think there is a problem here either. 19.6.5 of the CD lists all<br>>the events that cause variables to become defined and in each case says<br><br>John, thank you for the pointer.<br>19.6.1p3 and p4 are crystal clear:<br><br>"An array is defined if and only if all of its elements are defined." [...]
2017-06-22T13:06:23+01:00Anton Shterenlikhthttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;807fa8f4.1706Re: elements of array coarray var defined/referenced in unordered segments
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1fde1fc1.1706
Anton,<br><br>I don't think there is a problem here either. 19.6.5 of the CD lists all<br>the events that cause variables to become defined and in each case says<br>which variable is involved. In this case, we are talking about an<br>intrinsic assignment statement and it is the variable that precedes the<br>equals that becomes defined. [...]
2017-06-22T12:43:57+01:00John Reidhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1fde1fc1.1706Re: elements of array coarray var defined/referenced in unordered segments
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5e0644eb.1706
>Anton,<br>><br>>The variables that are being defined here are i(1) and i(4). An array<br>>assignment such as i = this_image() defines the array i.<br><br>But the value of array i, as a whole, would have<br>changed when one or more if its elements are defined,<br>so is it wrong to say that i is being defined too? [...]
2017-06-22T12:13:21+01:00Anton Shterenlikhthttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5e0644eb.1706Re: elements of array coarray var defined/referenced in unordered segments
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;72917edd.1706
Anton,<br><br>The variables that are being defined here are i(1) and i(4). An array<br>assignment such as i = this_image() defines the array i.<br><br>Cheers,<br><br>John.<br><br>Anton Shterenlikht wrote:<br>> Is this program conforming?<br>><br>> integer :: i(4)[*]<br>> i = this_image()<br>> sync all<br>> if ( this_image() .gt. 1 ) i(1) = i(3)[ this_image() - 1 ]<br>> if ( this_image() .lt. num_images() ) i(4) = i(2)[ this_image() + 1 ]<br>> sync all<br>> write (*,*) this_image(), i<br>> end<br>><br>> It seems to violate CD 11.6.2p3 bullet point 1:<br>> "if a variable is [...]
2017-06-22T11:57:17+01:00John Reidhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;72917edd.1706elements of array coarray var defined/referenced in unordered segments
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;31a9ce5d.1706
Is this program conforming?<br><br>integer :: i(4)[*]<br>i = this_image()<br>sync all<br>if ( this_image() .gt. 1 ) i(1) = i(3)[ this_image() - 1 ]<br>if ( this_image() .lt. num_images() ) i(4) = i(2)[ this_image() + 1 ]<br>sync all<br>write (*,*) this_image(), i<br>end<br><br>It seems to violate CD 11.6.2p3 bullet point 1:<br>"if a variable is defined or becomes undefined on an image in<br>a segment, it shall not be referenced, defined, or become<br>undefined in a segment on another image unless the segments are<br>ordered". Variable i is defined and referenced in unordered<br>segments, so this makes [...]
2017-06-22T11:39:47+01:00Anton Shterenlikhthttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;31a9ce5d.1706Re: LITERAL_KINDS, a statement that can help enhance working with literal constants in Fortran?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;da838bcf.1706
From: "Vipul Parekh" <parekhvs@GMAIL.COM><br>Sent: Wednesday, June 14, 2017 2:32 PM<br><br>> On Tue, Jun 13, 2017 at 8:56 PM, Robin Vowels <robin51@dodo.com.au> wrote:<br>>> ..<br>>> This seems to be unnecessary clutter.<br>><br>> To each their own.<br>><br>> The original post makes clear the use case expressed is to code<br>> literal constants without the "_xx" suffix (or prefix) for reasons<br>> stated in the first two paragraphs. [...]
2017-06-14T16:56:17+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;da838bcf.1706Re: LITERAL_KINDS, a statement that can help enhance working with literal constants in Fortran?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d7961d51.1706
On Tue, Jun 13, 2017 at 8:56 PM, Robin Vowels <robin51@dodo.com.au> wrote:<br>> ..<br>> This seems to be unnecessary clutter.<br>><br>> ..<br><br>To each their own.<br><br>The original post makes clear the use case expressed is to code<br>literal constants without the "_xx" suffix (or prefix) for reasons<br>stated in the first two paragraphs.
2017-06-14T00:32:21-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d7961d51.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3968bbf4.1706
From: "Bill Long" <longb@CRAY.COM><br>Sent: Friday, June 09, 2017 2:14 AM<br><br>>> On Jun 7, 2017, at 9:37 PM, Robin Vowels <robin51@DODO.COM.AU> wrote:<br>>><br>>> From: "Bill Long" <longb@CRAY.COM><br>>> Sent: Wednesday, June 07, 2017 1:10 AM<br>>><br>>><br>>>> Yes, these are complications. But I think a simplified version could be specified that would<br>>>> accomplish what is desired. For example<br>>><br>>>> COMPLEX(X,Y)<br>>><br>>>> Require that X and Y be of type REAL or INTEGER, at least one of X or Y be type REAL.<br>>><br>>> Let's not have another exception. Arguments for CMPLX can be [...]
2017-06-14T11:47:17+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3968bbf4.1706Re: LITERAL_KINDS, a statement that can help enhance working with literal constants in Fortran?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7f35ffbd.1706
From: "Vipul Parekh" <parekhvs@GMAIL.COM><br>Sent: Tuesday, June 13, 2017 8:13 AM<br><br>> Those who program using Fortran will be served greatly if, in a future<br>> revision of the standard, some facility is introduced that allows them<br>> to write code that deals with literal constants more expressively and<br>> easily which also improves readability and brings expressions closer<br>> to the principle and ethos of For(mula) Tran(slation). [...]
2017-06-14T10:56:20+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7f35ffbd.1706Re: LITERAL_KINDS, a statement that can help enhance working with literal constants in Fortran?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;6a250f0a.1706
Hi,<br><br>It's very simple. We've not started discussing the procedures yet. So I cannot give any definitive answer. But in the past the committees have always welcomed suggestions from the public, and have frequently solicited them, so I'm sure there will be plenty of opportunities to submit a proposal.<br><br>In the past the submissions have generally been via the national standards bodies (e.g. BSI (UK), JIS (Japan), INCITS (USA)), though to my knowledge both the UK and USA Fortran committees have considered items submitted by others. And this part of the procedure could well be different this time around, so [...]
2017-06-14T08:59:17+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;6a250f0a.1706Re: LITERAL_KINDS, a statement that can help enhance working with literal constants in Fortran?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;228ca99f.1706
On Tue, Jun 13, 2017 at 1:34 AM, Malcolm Cohen <malcolm@nag-j.co.jp> wrote:<br>> This is a bit similar to a proposal made by the UK group for controlling what "default" kinds should be during Fortran 2015 development. ..<br>><br>> The reason for handling type declarations as well as literals was to handle situations that are currently dealt with (somewhat awkwardly, and non-standardly) by compiler options like "-r8".<br>><br>> I think this is an important issue and is worth looking at again in the future.<br>><br>> .. [...]
2017-06-13T16:21:04-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;228ca99f.1706Re: LITERAL_KINDS, a statement that can help enhance working with literal constants in Fortran?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;aa831773.1706
This is a bit similar to a proposal made by the UK group for controlling what "default" kinds should be during Fortran 2015 development. This would have defined the kind type parameter to use not just for literal constants but also for REAL, INTEGER et al declarations with no explicit KIND specification. [...]
2017-06-13T14:34:07+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;aa831773.1706LITERAL_KINDS, a statement that can help enhance working with literal constants in Fortran?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c15a152c.1706
Those who program using Fortran will be served greatly if, in a future<br>revision of the standard, some facility is introduced that allows them<br>to write code that deals with literal constants more expressively and<br>easily which also improves readability and brings expressions closer<br>to the principle and ethos of For(mula) Tran(slation).<br><br>With literal constants treated as having defaults of the corresponding<br>intrinsic types and with the default real being required to only have<br>a decimal precision of 6 and an exponent range of 37, many coders run<br>to errors or make mistakes with their use of literal constants or [...]
2017-06-12T18:13:30-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c15a152c.1706Re: DTIO question
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9989cea1.1706
Just to add, IBM XLF compiler also compiles the code and it runs fine.<br><br>Thanks,<br><br>Daniel<br><br>XL Fortran Development, Fortran Standard Representative<br>IBM Toronto Software Lab<br>Phone: 905-413-3056<br>Tie: 969-3056<br>Email: cdchen@ca.ibm.com<br>http://www.ibm.com/software/awdtools/fortran/xlfortran<br><br>From: Malcolm Cohen <malcolm@NAG-J.CO.JP><br>To: COMP-FORTRAN-90@JISCMAIL.AC.UK<br>Date: 06/11/2017 08:38 PM<br>Subject: Re: DTIO question<br>Sent by: Fortran 90 List <COMP-FORTRAN-90@JISCMAIL.AC.UK><br><br>Hi Walt,<br><br>The words “processed by” must mean that a defined i/o procedure gets<br>invoked, which with an explicit format is if and only if both the next data<br>edit descriptor is DT and there is an accessible interface. An interface<br>being accessible is a static thing [...]
2017-06-12T10:21:39-04:00Daniel C Chenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9989cea1.1706Re: DTIO question
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;39105aee.1706
Thanks for the responses.<br>You all agree with me, but i didn't want to bias your answers :-).<br><br>On Sun, Jun 11, 2017 at 6:38 PM, Malcolm Cohen <malcolm@nag-j.co.jp> wrote:<br><br>> Hi Walt,<br>><br>><br>><br>> The words “processed by” must mean that a defined i/o procedure gets<br>> invoked, which with an explicit format is if and only if both the next data<br>> edit descriptor is DT and there is an accessible interface. An interface<br>> being accessible is a static thing so cannot possibly be what is meant by<br>> “processed by”.<br>><br>><br>><br>> [...]
2017-06-12T08:30:21-06:00Walt Brainerdhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;39105aee.1706Re: DTIO question
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;88e329a.1706
Hi Walt,<br><br>The words “processed by” must mean that a defined i/o procedure gets invoked, which with an explicit format is if and only if both the next data edit descriptor is DT and there is an accessible interface. An interface being accessible is a static thing so cannot possibly be what is meant by “processed by”. [...]
2017-06-12T09:38:24+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;88e329a.1706Re: DTIO question
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ee2592e4.1706
FWIW, the Cray compiler does not complain about your example program:<br><br>> ftn test.f90<br>> srun -n1 ./a.out<br>Salary is 302.00 for 20.0 hours.<br>Salary is 302.00 for 20.0 hours.<br>><br><br>Cheers,<br>Bill<br><br>> On Jun 10, 2017, at 12:19 PM, Walt Brainerd <walt.brainerd@GMAIL.COM> wrote:<br>><br>> Consider the F08 standard, p. 218, 9.6.3, item (7) fourth bullet, just after NOTE 9.35:<br>><br>> If a list item of derived type in a formatted input/output statement is not processed by a defi ned in-<br>> put/output procedure, that list item is treated as if all of the components of the [...]
2017-06-10T21:47:33+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ee2592e4.1706Re: DTIO question
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;6d875541.1706
On Sat, Jun 10, 2017 at 1:19 PM, Walt Brainerd <walt.brainerd@gmail.com><br>wrote:<br><br>> Consider the F08 standard, p. 218, 9.6.3, item (7) fourth bullet, just<br>> after NOTE 9.35:<br>><br>> If a list item of derived type in a formatted input/output statement is<br>> not processed by a defi ned in-<br>> put/output procedure, that list item is treated as if all of the<br>> components of the list item were specifi ed<br>> in the list in component order;<br>><br>> This arises because of a disagreement between Intel and Gfortran.<br>><br>> The question is: what does [...]
2017-06-10T17:24:45-04:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;6d875541.1706DTIO question
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f6dae5e4.1706
Consider the F08 standard, p. 218, 9.6.3, item (7) fourth bullet, just<br>after NOTE 9.35:<br><br>If a list item of derived type in a formatted input/output statement is not<br>processed by a defi ned in-<br>put/output procedure, that list item is treated as if all of the components<br>of the list item were specifi ed<br>in the list in component order; [...]
2017-06-10T11:19:23-06:00Walt Brainerdhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f6dae5e4.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e0cd233.1706
On 6/9/2017 11:31 AM, Van Snyder wrote:<br>> It's possible to run VMS on a VAX simulator from<br>> http://simh.trailing-edge.com/. There are also simulators for PDP-1,<br>> PDP-4, PDP-7, PDP-8, PDP-9, PDP-10, PDP-11, and PDP-15. Or you can run<br>> IBSYS on a 7094. This was developed by a DEC retiree named Bob Supnik.<br>> It might be faster on a 3 GHz pentium than it was on a real VAX. [...]
2017-06-09T11:47:52-04:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e0cd233.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9963d16b.1706
On Fri, 2017-06-09 at 12:36 +0200, Phillip Helbig wrote:<br>> > The folks at VSI are quite competent - I know a number of them<br>> > personally - but I think you're dreaming if you think they will be able<br>> > to quickly bring a F95+ compiler (it had a few F2003 features) up to<br>> > full F2003 much less F2008 or F2015.<br>> ><br>> > > I know one company that will be very glad of the x86 port.<br>> > ><br>> > > They use a lot of DEC features in their Fortran [...]
2017-06-09T08:31:00-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;9963d16b.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;569e98cb.1706
On Thu, Jun 8, 2017 at 3:15 PM, Steve Lionel<br><00000d9096837217-dmarc-request@jiscmail.ac.uk> wrote:<br>> ..<br>><br>> Fortran 2015 already extends IMPLICIT NONE to allow a parenthesized list of<br>> options. Currently the choices are TYPE and EXTERNAL. The latter, which is<br>> new, disables implicit EXTERNAL attribute for procedures. There is not<br>> currently an option to require explicit KIND specifiers, but it would be<br>> easy to add that to the language if that was desirable.<br>> .. [...]
2017-06-09T11:14:24-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;569e98cb.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;479092f4.1706
> The folks at VSI are quite competent - I know a number of them<br>> personally - but I think you're dreaming if you think they will be able<br>> to quickly bring a F95+ compiler (it had a few F2003 features) up to<br>> full F2003 much less F2008 or F2015.<br>><br>> > I know one company that will be very glad of the x86 port.<br>> ><br>> > They use a lot of DEC features in their Fortran code. [...]
2017-06-09T12:36:26+02:00Phillip Helbighttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;479092f4.1706Re: On the matter of an alternate constructor for a COMPLEX type
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d5adc8e0.1706
>In the meantime, the processor of my choice - with its support of<br>>Fortran 2008 revision - allows me to write<br>><br>> ..<br>> complex(kind=..) :: c<br>> ..<br>> c%re = X; c%im = Y<br><br>I think with this processor<br>it's more about a budget than choice...<br><br>Anton
2017-06-09T10:02:48+01:00Anton Shterenlikhthttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d5adc8e0.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;226be498.1706
I know one company that will be very glad of the x86 port.<br><br>They use a lot of DEC features in their Fortran code.<br><br>Good news.<br><br>From: Fortran 90 List [mailto:COMP-FORTRAN-90@JISCMAIL.AC.UK] On Behalf Of Steve Lionel<br>Sent: 08 June 2017 20:42<br>To: COMP-FORTRAN-90@JISCMAIL.AC.UK<br>Subject: Re: Features for the next Fortran Standard (following Fortran 2015)<br><br>On Thu, Jun 8, 2017 at 3:18 PM, Phillip Helbig <helbig@multivax.de> wrote: [...]
2017-06-09T09:14:09+01:00Ian Chivershttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;226be498.1706Re: On the matter of an alternate constructor for a COMPLEX type
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;a24507b7.1706
On Thu, Jun 8, 2017 at 12:35 AM, Malcolm Cohen <malcolm@nag-j.co.jp> wrote:<br><br>> I think it is way too early to be arguing ..<br>><br>>>a complex type can also be viewed as a derived type<br>><br>> Not really, no. It might appear like that at first glance, but the properties of COMPLEX are in fact different from both SEQUENCE derived types and non-SEQUENCE derived types. Changing the type system to accommodate COMPLEX as a derived type would be like building a combine harvester to cut a single blade of grass.<br>><br>> Also imo, introducing special syntax would [...]
2017-06-08T22:27:06-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;a24507b7.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;96543ec1.1706
On Thu, Jun 8, 2017 at 3:18 PM, Phillip Helbig <helbig@multivax.de> wrote:<br>><br>><br>> Unfortunately, I'm still using Fortran95. The reason is that I still<br>> use VMS. VMS compilers, especially the Fortran compiler, used to be the<br>> gold standard. Now that VSI has not only taken over VMS but also<br>> indicated major compiler updates, I hope that I can move to a newer<br>> standard before too long. (So far, I've only run across one thing that<br>> I need in a later standard, and there is a clumsy workaround in F95, but<br>> of course [...]
2017-06-08T15:42:22-04:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;96543ec1.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5be93724.1706
> > >> > Of course, old code should not break. What about expanding IMPLICIT<br>> > >> > NONE? For example: IMPLICIT NOTYPE, NOKIND (NONE being an alias for<br>> > >> > NOTYPE). This could be expanded more later if needed. It would also be<br>> > >> > backwards compatible with old code. [...]
2017-06-08T21:18:22+02:00Phillip Helbighttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5be93724.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;dfd44498.1706
On Thu, Jun 8, 2017 at 2:58 PM, Phillip Helbig <helbig@multivax.de> wrote:<br><br>> > >> > Of course, old code should not break. What about expanding IMPLICIT<br>> > >> > NONE? For example: IMPLICIT NOTYPE, NOKIND (NONE being an alias for<br>> > >> > NOTYPE). This could be expanded more later if needed. It would<br>> also be<br>> > >> > backwards compatible with old code.<br>> [...]
2017-06-08T15:15:29-04:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;dfd44498.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f5e56c6a.1706
> >> > Of course, old code should not break. What about expanding IMPLICIT<br>> >> > NONE? For example: IMPLICIT NOTYPE, NOKIND (NONE being an alias for<br>> >> > NOTYPE). This could be expanded more later if needed. It would also be<br>> >> > backwards compatible with old code.<br>> >><br>> >> Yes and no. Old code would need the insertion of IMPLICIT NOTYPE ...<br>> ><br>> > As now, if there is no IMPLICIT statement at all, the Fortran77 rules<br>> > apply.<br>><br>> In the context of CMPLX, and to be "backwards [...]
2017-06-08T20:58:35+02:00Phillip Helbighttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f5e56c6a.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;63df6fcc.1706
> On Jun 7, 2017, at 9:37 PM, Robin Vowels <robin51@DODO.COM.AU> wrote:<br>><br>> From: "Bill Long" <longb@CRAY.COM><br>> Sent: Wednesday, June 07, 2017 1:10 AM<br>><br>><br>>> Yes, these are complications. But I think a simplified version could be specified that would accomplish what is desired. For example<br>><br>>> COMPLEX(X,Y)<br>><br>>> Require that X and Y be of type REAL or INTEGER, at least one of X or Y be type REAL.<br>><br>> Let's not have another exception. Arguments for CMPLX can be integer. [...]
2017-06-08T16:14:36+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;63df6fcc.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3ec4cab1.1706
Hi,<br><br>> On Jun 8, 2017, at 00:30 , Robin Vowels <robin51@DODO.COM.AU> wrote:<br>><br>> The Fortran Language Committee considers changes to the language.<br>> It is therefore important to bring the problem and proposed change of CMPLX to their attention,<br>> ALONG WITH with the accompanying proposal to handle it with a compiler option,<br>> and therefore it is essential to being compiler options to the committee.<br>> In spite of your uninformed dismissal of the compiler option. [...]
2017-06-08T09:45:01-06:00Dan Naglehttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3ec4cab1.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;dd7efcda.1706
From: "Phillip Helbig" <helbig@MULTIVAX.DE><br>Sent: Thursday, June 08, 2017 6:07 PM<br><br>>> > Of course, old code should not break. What about expanding IMPLICIT<br>>> > NONE? For example: IMPLICIT NOTYPE, NOKIND (NONE being an alias for<br>>> > NOTYPE). This could be expanded more later if needed. It would also be<br>>> > backwards compatible with old code.<br>>><br>>> Yes and no. Old code would need the insertion of IMPLICIT NOTYPE ...<br>><br>> As now, if there is no IMPLICIT statement at all, the Fortran77 rules<br>> apply. [...]
2017-06-08T20:18:01+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;dd7efcda.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fd518be3.1706
> > Of course, old code should not break. What about expanding IMPLICIT<br>> > NONE? For example: IMPLICIT NOTYPE, NOKIND (NONE being an alias for<br>> > NOTYPE). This could be expanded more later if needed. It would also be<br>> > backwards compatible with old code.<br>><br>> Yes and no. Old code would need the indertion of IMPLICIT NOTYOE ... [...]
2017-06-08T10:07:14+02:00Phillip Helbighttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fd518be3.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c2fc08f6.1706
From: +ACI-Malcolm Cohen+ACI- +ADw-malcolm+AEA-NAG-J.CO.JP+AD4-<br>Sent: Thursday, June 08, 2017 3:40 PM<br><br>+AD4-I wrote:<br>+AD4APg- For a start, compiler options are outwith the scope of the standard.<br><br>+AD4-Robin Vowels resorts to insults:<br>+AD4APg- You may not have noticed,<br><br>That's an insult?<br><br>+AD4- That I am a Fortran user +ACo-and+ACo- a Fortran compiler writer (with options) +ACo-and+ACo- one of many Fortran<br>+AD4- standard authors? It seems unlikely. [...]
2017-06-08T16:30:56+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c2fc08f6.1706Re: +AFs-COMP-FORTRAN-90+AF0- +AFs-COMP-FORTRAN-90+AF0- Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e35157b5.1706
I wrote:<br>+AD4- For a start, compiler options are outwith the scope of the standard.<br><br>Robin Vowels resorts to insults:<br>+AD4- You may not have noticed,<br><br>That I am a Fortran user +ACo-and+ACo- a Fortran compiler writer (with options) +ACo-and+ACo- one of many Fortran standard authors? It seems unlikely.<br><br>And then misses the point completely:<br>+AD4- but many compilers offer options that deal with old programs, old extensions, etc. [...]
2017-06-08T14:40:34+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e35157b5.1706Re: +AFs-COMP-FORTRAN-90+AF0- Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e0a56c3c.1706
From: +ACI-Malcolm Cohen+ACI- +ADw-malcolm+AEA-NAG-J.CO.JP+AD4-<br>Sent: Thursday, June 08, 2017 2:22 PM<br><br>+AD4- I said:<br>+AD4APg- Yes we have come full circle. Breaking programs, especially by a<br>+AD4APg- silent change of semantics, is simply a bad idea.<br><br>+AD4- Robin Vowels opined:<br>+AD4APg-A compiler option can trivially deal with it.<br><br>+AD4- Obviously not.<br><br>+AD4- For a start, compiler options are outwith the scope of the standard. [...]
2017-06-08T15:04:20+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e0a56c3c.1706Re: On the matter of an alternate constructor for a COMPLEX type
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;14e17c85.1706
I think it is way too early to be arguing over wording, when we have not decided what the feature should look like, in fact we have not even started discussing when the next standard will be and what procedures we should use, let alone what should go into it, let alone technical details thereof, let alone wording thereof! [...]
2017-06-08T13:35:26+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;14e17c85.1706Re: +AFs-COMP-FORTRAN-90+AF0- Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4b54a947.1706
I said:<br>+AD4- Yes we have come full circle. Breaking programs, especially by a<br>+AD4- silent change of semantics, is simply a bad idea.<br><br>Robin Vowels opined:<br>+AD4-A compiler option can trivially deal with it.<br><br>Obviously not.<br><br>For a start, compiler options are outwith the scope of the standard.<br><br>For a second, no user will know +ACI-which CMPLX+ACI- is being used. It could be that a different one would be used for some files and not others. That is just silly. [...]
2017-06-08T13:22:17+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4b54a947.1706Re: On the matter of an alternate constructor for a COMPLEX type
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3f546b08.1706
On Wed, Jun 7, 2017 at 9:21 PM, Dick Hendrickson<br><dick.hendrickson@att.net> wrote:<br>> ..<br>> Wouldn't it be better to say both real-part and imag-part are expr? Just<br>> follow the template for arguments in CMPLX. I think that covers all the<br>> cases you have and it allows you to write<br>><br>> e_to_the_i_theta = COMPLEX ( SIN(THETA), COS(THETA))<br>><br>> without using temporaries.<br>><br>> Also, I think it would be better to say the result kind is the kind of<br>> "real-part + imag-part" and let the words in section seven define what<br>> happens for different [...]
2017-06-08T00:07:11-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3f546b08.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;296c868b.1706
From: "Clune, Thomas L. (GSFC-6101)" <thomas.l.clune@NASA.GOV><br>Sent: Wednesday, June 07, 2017 9:40 PM<br><br>> Some may want to consider the approach I’ve used for complex number creation. I’ve<br>> inadvertently (and unknowingly) circumvented much of the complexity by following a pattern that I<br>> first learned in an old F77 code I was handed. Namely introduce a parameter reperesenting “i”<br>> (sqrt of negative 1), and use arithmetic to form quantities in the form a + b i just like we do on<br>> paper:<br>><br>> integer, parameter :: SP = kind(1.)<br>> integer, parameter :: DP = kind(1.d0)<br> [...]
2017-06-08T12:57:13+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;296c868b.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;410066fe.1706
From: "Phillip Helbig" <helbig@MULTIVAX.DE><br>Sent: Wednesday, June 07, 2017 6:33 PM<br><br>>> Since the introduction of Fortran 90 it has been my humble practice to<br>>> (the best of my ability) to NEVER rely on type coercion but ALWAYS<br>>> specify what kind the result is to be. That way code is unambiguous and<br>>> self-documenting. The subtlety in the type coercion rules will always,<br>>> unnecessarily, catch some (especially me). Thus, would it be best to<br>>> consider deprecating the type coercion rules in favour of explicit<br>>> specification? Otherwise there is a considerable risk of making an<br>>> [...]
2017-06-08T12:52:49+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;410066fe.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;934b456d.1706
From: Dick Hendrickson<br>Sent: Wednesday, June 07, 2017 11:06 AM<br><br>>>On Tue, Jun 6, 2017 at 10:10 AM, Bill Long <longb@cray.com> wrote:<br><br>>>Yes, these are complications. But I think a simplified version could be specified that would<br>>>accomplish what is desired. For example<br><br>>>COMPLEX(X,Y)<br><br>>>Require that X and Y be of type REAL or INTEGER, at least one of X or Y be type REAL. The KIND<br>>>of the result would be KIND(X+Y). [...]
2017-06-08T12:51:17+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;934b456d.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e94c24ee.1706
From: "David Vowles" <david.vowles@ADELAIDE.EDU.AU><br>Sent: Wednesday, June 07, 2017 10:04 AM<br><br>> Since the introduction of Fortran 90 it has been my humble practice to (the best of my ability)<br>> to NEVER rely on type coercion but ALWAYS specify what kind the result is to be.<br><br>Useful, but does not address the problem.<br>Expliciting including KIND is helpful in making it easy to change precision globally. [...]
2017-06-08T12:45:33+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e94c24ee.1706Re: A question on CMPLX function
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3d1ba34.1706
From: "Vipul Parekh" <parekhvs@GMAIL.COM><br>Sent: Wednesday, June 07, 2017 4:26 AM<br><br>> On Tue, Jun 6, 2017 at 1:14 PM, Anton Shterenlikht <mexas@bris.ac.uk> wrote:<br>>>..<br>>><br>>> I think the first 3 assignments to c1<br>>> use default real kind.<br>>> The 4th assignment uses the highest kind<br>>> of FOO and PI, which is R16.<br><br>> Yes and that's because the KIND argument is missing in the CMPLX<br>> function invocations. So the point that I deliberately excluded in<br>> the first post, but will now bring up is that<br>><br>> c1 = ( PI, FOO )<br>><br> [...]
2017-06-08T12:42:00+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3d1ba34.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;229254dc.1706
From: "Bill Long" <longb@CRAY.COM><br>Sent: Wednesday, June 07, 2017 1:10 AM<br><br>> Yes, these are complications. But I think a simplified version could be specified that would<br>> accomplish what is desired. For example<br><br>> COMPLEX(X,Y)<br><br>> Require that X and Y be of type REAL or INTEGER, at least one of X or Y be type REAL. [...]
2017-06-08T12:37:19+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;229254dc.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;40159384.1706
From: +ACI-Malcolm Cohen+ACI- +ADw-malcolm+AEA-NAG-J.CO.JP+AD4-<br>Sent: Tuesday, June 06, 2017 6:12 PM<br><br>+AD4APg- Admittedly, this might break some programs.<br><br>+AD4- Yes we have come full circle. Breaking programs, especially by a silent change of semantics, is<br>+AD4- simply a bad idea.<br><br>A compiler option can trivially deal with it.<br>The case of CMPLX(C) +AFs-where C is DOUBLE COMPLEX+AF0- to single precision is rare,<br>could have been used to convert to single precision. Likewise CMPLX(R1, R2) for douible precision<br>arguments, [...]
2017-06-08T12:32:03+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;40159384.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;28463439.1706
On Thu, 2017-06-08 at 12:07 +1000, Robin Vowels wrote:<br>> Have you looked at REAL?<br>> REAL returns a result of the same kind as its argument.<br>> Give it a double-precision complex argument and it returns a<br>> double-precision<br>> result.<br>> All it needs is for CMPLX to be consistent with REAL.<br><br>REAL is actually two rather different functions that have the same name,<br>a concept that isn't that unusual in Fortran. [...]
2017-06-07T19:25:28-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;28463439.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b2078d58.1706
From: +ACI-W. J. Metzger+ACI- +ADw-w.metzger+AEA-HEF.RU.NL+AD4-<br>Sent: Tuesday, June 06, 2017 5:41 PM<br><br>+AD4- However, REAL(c) with c complex returns the real value of c with the<br>+AD4- kind of c. Thus if c is double precision complex, real returns a double<br>+AD4- precision real. Thus it seems not unreasonable to expect CMPLX(x, y) to<br>+AD4- return a complex with the kind of x. [...]
2017-06-08T12:23:37+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b2078d58.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;971145ed.1706
From: "John Harper" <harper@MSOR.VUW.AC.NZ><br>Sent: Tuesday, June 06, 2017 10:12 AM<br><br>> When I suggested CMPLEX earlier this morning I forgot that among the<br>> possibilities for CMPLX(X,Y) are X of any real or integer kind and Y<br>> of any real or integer kind, perhaps different from that of X, and<br>> that BOZ literal constants are also allowed. What complex kind would<br>> Robin want if X and Y are not of the same type, or of the same type but<br>> different kinds? [...]
2017-06-08T12:21:37+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;971145ed.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fbd4fa8a.1706
From: "John Harper" <harper@MSOR.VUW.AC.NZ><br>Sent: Tuesday, June 06, 2017 8:06 AM<br><br>> Could we solve the problem by having a new intrinsic perhaps called CMPLEX<br>> that is fully generic, as well as the existing CMPLX, which isn't?<br><br>It would be better to have a single complex function to do the job.<br><br>---<br>This email has been checked for viruses by Avast antivirus software.<br>https://www.avast.com/antivirus
2017-06-08T12:08:49+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fbd4fa8a.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;a9e48c84.1706
----- Original Message -----<br>From: "Bill Long" <longb@CRAY.COM><br>To: <COMP-FORTRAN-90@JISCMAIL.AC.UK><br>Sent: Monday, June 05, 2017 9:25 AM<br>Subject: Re: Features for the next Fortran Standard (following Fortran 2015)<br><br>><br>>> On Jun 2, 2017, at 10:15 PM, Robin Vowels <robin51@DODO.COM.AU> wrote:<br>>><br>>> From: "Bill Long" <longb@CRAY.COM><br>>> Sent: Saturday, June 03, 2017 1:48 AM<br>>><br>>><br>>>> Maybe I missed something in the noise here, but I’m having trouble seeing the issue.<br>>>><br>>>> The desire to make CMPLX generic is moot. CMPLX is already generic.<br>>><br>>> Yes and no.<br>>><br>>>> It will accept arguments that are [...]
2017-06-08T12:07:00+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;a9e48c84.1706Re: On the matter of an alternate constructor for a COMPLEX type
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;478cadae.1706
On Wed, Jun 7, 2017 at 2:50 PM, Vipul Parekh <parekhvs@gmail.com> wrote:<br><br>> There is some indication from a recent thread on this mailing list the<br>> Fortran standards committee might be open to the idea of an alternate<br>> constructor for a COMPLEX type in a future revision and that it will<br>> require further careful work:<br>><br>> On Tue, Jun 6, 2017 at 4:12 AM, Malcolm Cohen<br>> <mailto:malcolm@nag-j.co.jp> wrote:<br>> >> ..<br>> ><br>> > It would be better to have an alternative constructor that can be used<br>> instead of CMPLX. It will require [...]
2017-06-07T20:21:31-05:00Dick Hendricksonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;478cadae.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e9a756ca.1706
Aye aye sir.<br><br>On Wed, 7 Jun 2017, Bill Long wrote:<br><br>> Date: Wed, 7 Jun 2017 14:40:20 +0000<br>> From: Bill Long <longb@CRAY.COM><br>> Reply-To: Fortran 90 List <COMP-FORTRAN-90@JISCMAIL.AC.UK><br>> To: COMP-FORTRAN-90@JISCMAIL.AC.UK<br>> Subject: Re: Features for the next Fortran Standard (following Fortran 2015)<br>><br>> A colleague in college came up with a solution to the “i” problem - he defined the constant EYE to be sqrt(-1.0). Hardly any conflicts, and yet everyone “got it” easily.<br>><br>> Cheers,<br>> Bill<br>><br>><br>>> On Jun 7, 2017, at 6:40 AM, Clune, Thomas L. (GSFC-6101) <thomas.l.clune@NASA.GOV> wrote:<br>>><br> [...]
2017-06-08T09:46:45+12:00John Harperhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e9a756ca.1706On the matter of an alternate constructor for a COMPLEX type
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;aa452d86.1706
There is some indication from a recent thread on this mailing list the<br>Fortran standards committee might be open to the idea of an alternate<br>constructor for a COMPLEX type in a future revision and that it will<br>require further careful work:<br><br>On Tue, Jun 6, 2017 at 4:12 AM, Malcolm Cohen<br><mailto:malcolm@nag-j.co.jp> wrote:<br>>> ..<br>><br>> It would be better to have an alternative constructor that can be used instead of CMPLX. It will require some careful work to achieve, .. [...]
2017-06-07T15:50:45-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;aa452d86.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;262b9e02.1706
A colleague in college came up with a solution to the “i” problem - he defined the constant EYE to be sqrt(-1.0). Hardly any conflicts, and yet everyone “got it” easily.<br><br>Cheers,<br>Bill<br><br>> On Jun 7, 2017, at 6:40 AM, Clune, Thomas L. (GSFC-6101) <thomas.l.clune@NASA.GOV> wrote:<br>><br>><br>> z = a + b * I_dp<br>><br>> Then all my usual intuition about precision in Fortran arithmetic expressions can be reasonably relied upon.<br>><br>> The only thing I don’t like about this, is that part of me really wants to call the constant “i”, but that is [...]
2017-06-07T14:40:20+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;262b9e02.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d788f395.1706
Some may want to consider the approach I’ve used for complex number creation. I’ve inadvertently (and unknowingly) circumvented much of the complexity by following a pattern that I first learned in an old F77 code I was handed. Namely introduce a parameter reperesenting “i” (sqrt of negative 1), and use arithmetic to form quantities in the form a + b i just like we do on paper: [...]
2017-06-07T11:40:12+00:00Clune, Thomas L. (GSFC-6101)https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d788f395.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2ec6f141.1706
But in c +AD0 (x,y), x and y have to be constants, not variables. At least<br>the two compilers I have available think so.<br>So that doesn't give the functionality of the proposed COMPLEX(x,y)
2017-06-07T11:02:32+02:00W. J. Metzgerhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2ec6f141.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;56c525bd.1706
> Since the introduction of Fortran 90 it has been my humble practice to<br>> (the best of my ability) to NEVER rely on type coercion but ALWAYS<br>> specify what kind the result is to be. That way code is unambiguous and<br>> self-documenting. The subtlety in the type coercion rules will always,<br>> unnecessarily, catch some (especially me). Thus, would it be best to<br>> consider deprecating the type coercion rules in favour of explicit<br>> specification? Otherwise there is a considerable risk of making an<br>> already COMPLEX situation INTRACTABLE. [...]
2017-06-07T10:33:37+02:00Phillip Helbighttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;56c525bd.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7e16d928.1706
On Tue, Jun 6, 2017 at 10:10 AM, Bill Long <longb@cray.com> wrote:<br><br>> Yes, these are complications. But I think a simplified version could be<br>> specified that would accomplish what is desired. For example<br>><br>> COMPLEX(X,Y)<br>><br>> Require that X and Y be of type REAL or INTEGER, at least one of X or Y<br>> be type REAL. The KIND of the result would be KIND(X+Y).<br>> [...]
2017-06-06T20:06:40-05:00Dick Hendricksonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7e16d928.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3de44ab5.1706
Since the introduction of Fortran 90 it has been my humble practice to (the best of my ability) to NEVER rely on type coercion but ALWAYS specify what kind the result is to be. That way code is unambiguous and self-documenting. The subtlety in the type coercion rules will always, unnecessarily, catch some (especially me). Thus, would it be best to consider deprecating the type coercion rules in favour of explicit specification? Otherwise there is a considerable risk of making an already COMPLEX situation INTRACTABLE. [...]
2017-06-07T00:04:12+00:00David Vowleshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3de44ab5.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c4979fdd.1706
> > Could we solve the problem by having a new intrinsic perhaps called CMPLEX<br>> > that is fully generic, as well as the existing CMPLX, which isn't?<br>><br>> This certainly has had some support in the past, and some people attempted<br>> to draft concrete proposals for it (it was a public comment on Fortran<br>> 2008). However, as you note in your later message there are some<br>> complications, [...]
2017-06-06T23:10:55+02:00Phillip Helbighttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c4979fdd.1706Re: A question on CMPLX function
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;13ae6b41.1706
On Tue, Jun 6, 2017 at 1:14 PM, Anton Shterenlikht <mexas@bris.ac.uk> wrote:<br>>..<br>><br>> I think the first 3 assignments to c1<br>> use default real kind.<br>> The 4th assignment uses the highest kind<br>> of FOO and PI, which is R16.<br>> ..<br><br>Yes and that's because the KIND argument is missing in the CMPLX<br>function invocations. So the point that I deliberately excluded in<br>the first post, but will now bring up is that [...]
2017-06-06T14:26:16-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;13ae6b41.1706Re: A question on CMPLX function
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4bb82eb3.1706
><br>>Consider the following simple example involving the CMPLX function:<br>><br>>-- begin code --<br>> implicit none<br>><br>> integer, parameter :: R4 = selected_real_kind( p=6, r=37, radix=2 )<br>> integer, parameter :: R16 = selected_real_kind( p=33, r=4931, radix=2 )<br>> real(kind=R16), parameter :: PI =<br>>3.1415926535897932384626433832795028841971_r16<br>> real(kind=R4), parameter :: FOO = 0.12345678901234567890_r4<br>><br>> complex(kind=kind(0d0)) :: c1<br>><br>> print *, "complex(kind=kind(0d0)) :: c1"<br>><br>> print *, new_line(""), "With c1 = cmplx( X=PI, Y=FOO ):"<br>> c1 = cmplx( X=PI, Y=FOO )<br>> print "(*(g0,z0))", "c1%re = ", c1%re, ", kind(c1%re) = ", kind(c1%re)<br>> print [...]
2017-06-06T18:14:07+01:00Anton Shterenlikhthttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4bb82eb3.1706A question on CMPLX function
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1553cf44.1706
Consider the following simple example involving the CMPLX function:<br><br>-- begin code --<br>implicit none<br><br>integer, parameter :: R4 = selected_real_kind( p=6, r=37, radix=2 )<br>integer, parameter :: R16 = selected_real_kind( p=33, r=4931, radix=2 )<br>real(kind=R16), parameter :: PI =<br>3.1415926535897932384626433832795028841971_r16<br>real(kind=R4), parameter :: FOO = 0.12345678901234567890_r4<br><br>complex(kind=kind(0d0)) :: c1<br><br>print *, "complex(kind=kind(0d0)) :: c1"<br><br>print *, new_line(""), "With c1 = cmplx( X=PI, Y=FOO ):"<br>c1 = cmplx( X=PI, Y=FOO )<br>print "(*(g0,z0))", "c1%re = ", c1%re, ", kind(c1%re) = ", kind(c1%re)<br>print "(*(g0,z0))", "c1%im = ", c1%im, ", kind(c1%im) = ", kind(c1%im) [...]
2017-06-06T12:32:02-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1553cf44.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;a4381ace.1706
Yes, these are complications. But I think a simplified version could be specified that would accomplish what is desired. For example<br><br>COMPLEX(X,Y)<br><br>Require that X and Y be of type REAL or INTEGER, at least one of X or Y be type REAL. The KIND of the result would be KIND(X+Y).<br><br>Cheers,<br>Bill<br><br>> On Jun 5, 2017, at 7:12 PM, John Harper <harper@MSOR.VUW.AC.NZ> wrote:<br>><br>> When I suggested CMPLEX earlier this morning I forgot that among the<br>> possibilities for CMPLX(X,Y) are X of any real or integer kind and Y of any real or integer kind, perhaps [...]
2017-06-06T15:10:38+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;a4381ace.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8a66c2b5.1706
On Tue, Jun 6, 2017 at 3:41 AM, W. J. Metzger <w.metzger@hef.ru.nl> wrote:<br>> However, REAL(c) with c complex returns the real value of c with the<br>> kind of c. Thus if c is double precision complex, real returns a double<br>> precision real. Thus it seems not unreasonable to expect CMPLX(x, y) to<br>> return a complex with the kind of x.<br>><br>> Admittedly, this might break some programs.<br>><br>> Cheers, Wes<br>> .. [...]
2017-06-06T09:09:55-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8a66c2b5.1706Re: +AFs-COMP-FORTRAN-90+AF0- Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f37e4c41.1706
+AD4- Admittedly, this might break some programs.<br><br>Yes we have come full circle. Breaking programs, especially by a silent change of semantics, is simply a bad idea.<br><br>It would be better to have an alternative constructor that can be used instead of CMPLX. It will require some careful work to achieve, but should be possible at some point in the future. [...]
2017-06-06T17:12:00+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f37e4c41.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;204b5909.1706
However, REAL(c) with c complex returns the real value of c with the<br>kind of c. Thus if c is double precision complex, real returns a double<br>precision real. Thus it seems not unreasonable to expect CMPLX(x, y) to<br>return a complex with the kind of x.<br><br>Admittedly, this might break some programs.<br><br>Cheers, Wes [...]
2017-06-06T09:41:30+02:00W. J. Metzgerhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;204b5909.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5de91d00.1706
John Harper suggested:<br>> Could we solve the problem by having a new intrinsic perhaps called CMPLEX<br>that is fully generic, as well as the existing CMPLX, which isn't?<br><br>This certainly has had some support in the past, and some people attempted<br>to draft concrete proposals for it (it was a public comment on Fortran<br>2008). However, as you note in your later message there are some<br>complications, and these resulted in the proposal being dropped at that<br>time. And not revived later. I think it is possible to design a better<br>COMPLEX constructor, so it is worth looking at [...]
2017-06-06T10:00:16+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5de91d00.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;439d4c0a.1706
When I suggested CMPLEX earlier this morning I forgot that among the<br>possibilities for CMPLX(X,Y) are X of any real or integer kind and Y<br>of any real or integer kind, perhaps different from that of X, and<br>that BOZ literal constants are also allowed. What complex kind would<br>Robin want if X and Y are not of the same type, or of the same type but<br>different kinds? [...]
2017-06-06T12:12:22+12:00John Harperhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;439d4c0a.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;eba21af7.1706
Could we solve the problem by having a new intrinsic perhaps called CMPLEX<br>that is fully generic, as well as the existing CMPLX, which isn't?<br><br>On Fri, 2 Jun 2017, Malcolm Cohen wrote:<br><br>> Date: Fri, 2 Jun 2017 17:30:08 +0900<br>> From: Malcolm Cohen <malcolm@NAG-J.CO.JP><br>> Reply-To: Fortran 90 List <COMP-FORTRAN-90@JISCMAIL.AC.UK><br>> To: COMP-FORTRAN-90@JISCMAIL.AC.UK<br>> Subject: Re: Features for the next Fortran Standard (following Fortran 2015)<br>><br>>> The proposal does not invalidate any old programs.<br>><br>> Unfortunately it does, it invalidates programs going all the way back to<br>> Fortran 77.<br>><br>>> And some users could [...]
2017-06-06T10:06:47+12:00John Harperhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;eba21af7.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f0679906.1706
> On Jun 2, 2017, at 10:15 PM, Robin Vowels <robin51@DODO.COM.AU> wrote:<br>><br>> From: "Bill Long" <longb@CRAY.COM><br>> Sent: Saturday, June 03, 2017 1:48 AM<br>><br>><br>>> Maybe I missed something in the noise here, but I’m having trouble seeing the issue.<br>>><br>>> The desire to make CMPLX generic is moot. CMPLX is already generic.<br>><br>> Yes and no.<br>><br>>> It will accept arguments that are complex, real, integer, or even boz constants.<br>><br>> But it does not return a result that is of the same kind as its principal argument.<br>><br>> Think [...]
2017-06-04T23:25:16+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f0679906.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;725c59b9.1706
On Sat, 2017-06-03 at 13:15 +1000, Robin Vowels wrote:<br>> > The desire to make CMPLX generic is moot. CMPLX is already generic.<br>><br>> Yes and no.<br>><br>> > It will accept arguments that are complex, real, integer, or even boz constants.<br>><br>> But it does not return a result that is of the same kind as its principal argument.<br>><br>> Think of SIN. It returns a result of the same kind as its argument.<br>> Give it double precision argument, and it returns a double precision result.<br>> Give it a default precision argument and [...]
2017-06-02T22:51:01-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;725c59b9.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8f7b54d.1706
From: "Bill Long" <longb@CRAY.COM><br>Sent: Saturday, June 03, 2017 1:48 AM<br><br>> Maybe I missed something in the noise here, but I’m having trouble seeing the issue.<br>><br>> The desire to make CMPLX generic is moot. CMPLX is already generic.<br><br>Yes and no.<br><br>> It will accept arguments that are complex, real, integer, or even boz constants. [...]
2017-06-03T13:15:41+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8f7b54d.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;82d769f7.1706
Maybe I missed something in the noise here, but I’m having trouble seeing the issue.<br><br>The desire to make CMPLX generic is moot. CMPLX is already generic. It will accept arguments that are complex, real, integer, or even boz constants.<br><br>The KEY point is that CMPLX is a type conversion function. Just like REAL. If I code REAL(x) I expect the result to be default REAL with the value of x, as close as conversion allows. In other words, convert X to type default REAL. If I code REAL(x, 8) then I expect the result to be REAL with KIND=8. [...]
2017-06-02T15:48:30+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;82d769f7.1706Re: A question on the feature 'recursive components of allocatable type' from Fortran 2008
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ba42f6b2.1706
On Fri, Jun 2, 2017 at 12:12 AM, Malcolm Cohen <malcolm@nag-j.co.jp> wrote:<br><br>> .. There is no need for any "request for interpretation", rather it would appear you should be making a bug report to the vendor who got it wrong.<br>> ..<br>><br>> BTW looking back I see I have written rather a lot. That is because there is a severe time zone lag, so I'm just trying to cover every aspect I can think of, my apologies if it appears to be overly detailed and complicated. [...]
2017-06-02T09:32:03-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ba42f6b2.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;74532098.1706
From: "Malcolm Cohen" <malcolm@NAG-J.CO.JP><br>Sent: Friday, June 02, 2017 6:30 PM<br><br>> >The proposal does not invalidate any old programs.<br>><br>> Unfortunately it does, it invalidates programs going all the way back to<br>> Fortran 77.<br><br>You didn't read my proposal.<br><br>I wrote :--<br>Compatabilty with the old non-generic form, dating from the 1960s,<br>can be provided by a compiler option. [...]
2017-06-02T18:43:27+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;74532098.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;56236b69.1706
>The proposal does not invalidate any old programs.<br><br>Unfortunately it does, it invalidates programs going all the way back to<br>Fortran 77.<br><br>>And some users could well find that their programs begin giving<br>more-accurate results !! because they did not use CMPLX correctly (and<br>inadvertently had their double-precision values quietly converted to single<br>precision).<br><br>And other users could well find their programs failing to compile, giving<br>incorrect results, or crashing at runtime because they are now passing<br>things twice as big as before, but the receiver is not expecting that. [...]
2017-06-02T17:30:08+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;56236b69.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;20b73d25.1706
From: "Malcolm Cohen" <malcolm@NAG-J.CO.JP><br>Sent: Friday, June 02, 2017 4:55 PM<br><br>> The chance of everyone agreeing to invalidate many Fortran programs all the<br>> way back to Fortran 77 is somewhat remote.<br><br>The proposal does not invalidate any old programs.<br><br>As it is, some compilers provide a dusty option.<br><br>And some users could well find that their programs<br>begin giving more-accurate results !! because they did<br>not use CMPLX correctly (and inadvertently had their double-precision<br>values quietly converted to single precision). [...]
2017-06-02T17:51:42+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;20b73d25.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;86b5b877.1706
From: "Jean Vézina" <vezina_jean@SYMPATICO.CA><br>Sent: Tuesday, May 30, 2017 8:36 AM<br><br>> The parameterized module facility would be fine for me (J3/05-195). Also, the exception handling<br>> facilities you describe<br>> in Fortran Forum would provide exactly what is needed for the second item I mentioned.<br><br>> Unsigned integers would be really convenient for doing image and signal processing.<br>> It is annoying to have to use the character data type to<br>> store pixels and then convert to integer to do the processing and back to character to save the<br>> output. [...]
2017-06-02T17:40:03+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;86b5b877.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;a373e31a.1706
The chance of everyone agreeing to invalidate many Fortran programs all the<br>way back to Fortran 77 is somewhat remote.<br><br>You might find it easier to use a compiler that warns you when you've<br>apparently forgotten to use the KIND argument of CMPLX.<br><br>Cheers,
2017-06-02T15:55:09+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;a373e31a.1706Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ce020cdd.1706
The CMPLX builtin needs to be made generic,<br>so that it accepts arguments of default precision, double precision, and<br>whatever extra precisions are available, and to return a result of the<br>same precision, namely, default, double, or extra precisions, respectively.<br><br>Compatabilty with the old non-generic form, dating from the 1960s,<br>can be provided by a compiler option. [...]
2017-06-02T16:22:05+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ce020cdd.1706Re: A question on the feature 'recursive components of allocatable type' from Fortran 2008
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;df160a63.1706
I wrote:<br><br>ALLOCATE(temp)<br>temp%data = newdata<br>CALL move_alloc(x,temp)<br>CALL move_alloc(temp,x)<br><br>There is an obvious typo in the third line of that sequence, which ought to be:<br><br>CALL move_alloc(x,temp%next)<br><br>Thus making the whole sequence:<br><br>ALLOCATE(temp)<br>temp%data = newdata<br>CALL move_alloc(x,temp%next)<br>CALL move_alloc(temp,x)<br><br>Sorry about that.<br><br>Cheers,<br>--<br>.......................Malcolm Cohen, NAG Oxford/Tokyo.
2017-06-02T14:32:41+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;df160a63.1706Re: A question on the feature 'recursive components of allocatable type' from Fortran 2008
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fbc36dd4.1706
I do not see any reason to ask any interp question here. The standard has got perfectly clear semantics here!<br><br>"T(newdata,X)" is already well-defined in what it does.<br><br>"X = something" is already well-defined in what it does.<br><br>The semantics of "X = T(newdata,X)" are simply the evaluation of T(newdata,X), which is well-defined, followed by the assignment of the resulting value to X, and this is also well-defined. [...]
2017-06-02T13:12:35+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fbc36dd4.1706Re: A question on the feature 'recursive components of allocatable type' from Fortran 2008
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;180bc109.1706
On Thu, 2017-06-01 at 11:56 -0400, Vipul Parekh wrote:<br>> On Wed, May 31, 2017 at 9:47 PM, Malcolm Cohen <malcolm@nag-j.co.jp> wrote:<br>> ><br>> > I think that this is not a very interesting example, .. This is<br>> especially true since a number of compilers do *not* do the<br>> auto-reallocation required by the standard by default, you need to<br>> pass a special option to make that happen; for such a compiler without<br>> its special option, “X = T(newdata,X)” is highly likely to crash and<br>> burn.<br>><br>> Malcolm, thanks much for your response. Unfortunately [...]
2017-06-01T11:38:05-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;180bc109.1706Re: A question on the feature 'recursive components of allocatable type' from Fortran 2008
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1a530a40.1706
On Wed, May 31, 2017 at 9:47 PM, Malcolm Cohen <malcolm@nag-j.co.jp> wrote:<br>><br>> I think that this is not a very interesting example, .. This is especially true since a number of compilers do *not* do the auto-reallocation required by the standard by default, you need to pass a special option to make that happen; for such a compiler without its special option, “X = T(newdata,X)” is highly likely to crash and burn. [...]
2017-06-01T11:56:51-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1a530a40.1706Re: A question on the feature 'recursive components of allocatable type' from Fortran 2008
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5cf870a8.1706
I think that this is not a very interesting example, as type T does not have any data in it. If T has any other components, you are not going to be doing “X = T(X)” any more, but rather “X = T(newdata,X)”.<br><br>Anyway, thinking of the structure constructor T(newdata,X) as being a sequence of MOVE_ALLOCs is not a good way to think. The semantics of the constructor is that it constructs a new value, with deep copying of allocatable components. Whether some of the copying can be elided in some use cases is a matter of optimisation, not of [...]
2017-06-01T10:47:36+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5cf870a8.1706