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-05-30T01:17:13ZPowered by L-Soft's LISTSERV mailing list manager
http://www.lsoft.com/products/listserv-powered.asp
http://www.lsoft.com/images/listserv_small.gifRe: Was implied-shape introduced in f2008?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1397a70f.1705
The Intel Fortran compiler version 2017.0.098 gets this right,<br>but the previous version does not.<br><br>On Mon, 29 May 2017, Malcolm Cohen wrote:<br><br>> Date: Mon, 29 May 2017 18:02:15 +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: Was implied-shape introduced in f2008?<br>><br>> Yes implied-shape is new in F2008, from the Introduction:<br>> "A named constant array's shape can be implied by its value."<br>><br>> Cheers,<br>> --<br>> ..............Malcolm Cohen, NAG Oxford/Tokyo.<br>><br>> -----Original Message-----<br>> From: Fortran 90 List [mailto:COMP-FORTRAN-90@JISCMAIL.AC.UK] On Behalf Of Anton [...]
2017-05-30T13:17:07+12:00John Harperhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1397a70f.1705Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;acbd32cf.1705
Thanks a lot about the clarification!<br><br>Regards,<br><br>Jean<br><br>> Le 29 mai 2017 à 20:14, Malcolm Cohen <malcolm@NAG-J.CO.JP> a écrit :<br>><br>> Jean Vézina writes:<br>> ><br>> >At the next Fortran standards committee meeting that will be held in June 2017, there will be a discussion about planning the next revision:<br>> ><br>> >http://j3-fortran.org/doc/year/17/agenda213.txt <http://j3-fortran.org/doc/year/17/agenda213.txt><br>><br>> Yes, this is a discussion about planning.<br>><br>> >Is there a way for the public to submit a list of features that we would like to be included in the next standard?<br>><br>> No. The discussion is not [...]
2017-05-29T20:21:14-04:00Jean Vézinahttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;acbd32cf.1705Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8b2da81d.1705
Jean Vézina writes:<br><br>><br><br>>At the next Fortran standards committee meeting that will be held in June<br>2017, there will be a discussion about planning the next revision:<br>><br>> <http://j3-fortran.org/doc/year/17/agenda213.txt><br>http://j3-fortran.org/doc/year/17/agenda213.txt<br><br>Yes, this is a discussion about planning.<br><br>>Is there a way for the public to submit a list of features that we would<br>like to be included in the next standard? [...]
2017-05-30T09:14:58+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8b2da81d.1705Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;a58c9fff.1705
On Tue, 2017-05-30 at 11:44 +1200, John Harper wrote:<br>> One feature of Algol 68 that I found useful was that when defining a<br>> new binary operator one could specify its precedence. I tried suggesting<br>> this for Fortran a few years ago but people objected on the ground that<br>> Algol 68 also allowed one to change the precedence of intrinsic<br>> operators, which I agree would be undesirable. However I don't see the<br>> harm in allowing a user-defined operator to be given the same precedence<br>> as an intrinsic one. [...]
2017-05-29T16:58:46-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;a58c9fff.1705Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;140e1095.1705
One feature of Algol 68 that I found useful was that when defining a<br>new binary operator one could specify its precedence. I tried suggesting<br>this for Fortran a few years ago but people objected on the ground that<br>Algol 68 also allowed one to change the precedence of intrinsic<br>operators, which I agree would be undesirable. However I don't see the<br>harm in allowing a user-defined operator to be given the same precedence<br>as an intrinsic one. An example would be .dot. and .cross. for the scalar<br>and vector product of two vectors, the usage of which would be [...]
2017-05-30T11:44:10+12:00John Harperhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;140e1095.1705Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5208f58e.1705
> Le 29 mai 2017 à 17:43, Van Snyder <van.snyder@JPL.NASA.GOV> a écrit :<br>><br>> On Mon, 2017-05-29 at 16:18 -0400, Steve Lionel wrote:<br>>> t would be especially helpful to elaborate if the item is as ambiguous<br>>> (to me, anyway) as "generic programming".<br>><br>> We had parameterized modules on the work plan briefly. [...]
2017-05-29T18:36:20-04:00Jean Vézinahttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5208f58e.1705Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5228d0db.1705
On Mon, 2017-05-29 at 16:18 -0400, Steve Lionel wrote:<br>> t would be especially helpful to elaborate if the item is as ambiguous<br>> (to me, anyway) as "generic programming".<br><br>We had parameterized modules on the work plan briefly.<br><br>Then we had macros on the work plan briefly.<br><br>There are detailed papers about both of them in the j3 archive. [...]
2017-05-29T14:43:43-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5228d0db.1705Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e1c95cbd.1705
Good afternoon Steve,<br><br>Thanks a lot for your reply.<br><br>I will prepare a short list of items that I would like to be added (or at least discussed) and send it to you.<br><br>Regards,<br><br>Jean<br><br>> Le 29 mai 2017 à 16:18, Steve Lionel <00000d9096837217-dmarc-request@JISCMAIL.AC.UK> a écrit :<br>><br>> On Mon, May 29, 2017 at 4:00 PM, Jean Vézina <vezina_jean@sympatico.ca <mailto:vezina_jean@sympatico.ca>> wrote:<br>><br>> Is there a way for the public to submit a list of features that we would like to be included in the next standard?<br>><br>> Perhaps I am wrong, but it looks like that [...]
2017-05-29T16:32:21-04:00Jean Vézinahttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e1c95cbd.1705Re: Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f3dcc238.1705
On Mon, May 29, 2017 at 4:00 PM, Jean Vézina <vezina_jean@sympatico.ca><br>wrote:<br>><br>><br>> Is there a way for the public to submit a list of features that we would<br>> like to be included in the next standard?<br>><br><br>> Perhaps I am wrong, but it looks like that the standard development<br>> process is now less open that before.<br>> [...]
2017-05-29T16:18:22-04:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f3dcc238.1705Features for the next Fortran Standard (following Fortran 2015)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;52b83f44.1705
Good afternoon,<br><br>At the next Fortran standards committee meeting that will be held in June 2017, there will be a discussion about planning the next revision:<br><br>http://j3-fortran.org/doc/year/17/agenda213.txt <http://j3-fortran.org/doc/year/17/agenda213.txt><br><br>Is there a way for the public to submit a list of features that we would like to be included in the next standard?<br><br>For example, generic programming and block based exception handling have been requested a lot of times . [...]
2017-05-29T16:00:07-04:00Jean Vézinahttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;52b83f44.1705Re: Was implied-shape introduced in f2008?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1f430cc2.1705
Yes implied-shape is new in F2008, from the Introduction:<br>"A named constant array's shape can be implied by its value."<br><br>Cheers,<br>--<br>..............Malcolm Cohen, NAG Oxford/Tokyo.<br><br>-----Original Message-----<br>From: Fortran 90 List [mailto:COMP-FORTRAN-90@JISCMAIL.AC.UK] On Behalf Of Anton Shterenlikht<br>Sent: Monday, May 29, 2017 5:45 PM<br>To: COMP-FORTRAN-90@JISCMAIL.AC.UK<br>Subject: [COMP-FORTRAN-90] Was implied-shape introduced in f2008?<br><br>integer, parameter :: j(*) = (/ 3, 4, 7 /) end [...]
2017-05-29T18:02:15+09:00Malcolm Cohenhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;1f430cc2.1705Was implied-shape introduced in f2008?
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4163b964.1705
integer, parameter :: j(*) = (/ 3, 4, 7 /)<br>end<br><br>I think this is a f2008 conforming program,<br>where j is an implied-shape array named<br>constant, 8.5.8.6 of f2015 CD.<br>Is that correct?<br><br>One of my compilers reject this with<br>"Illegal use of symbol j - a named constant array must have constant extents".<br><br>Was this illegal prior to f2008? [...]
2017-05-29T09:44:43+01:00Anton Shterenlikhthttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4163b964.1705Call for Papers: The 2nd Annual PGAS Applications Workshop (PAW17)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b66f46cd.1704
<br>I'm forwarding this on behalf of workshop chair Dr. Karla Morris of Sandia National Laboratories. With coarray Fortran support now in three compilers, I hope that those who are using the parallel features of modern Fortran in applications will consider submitting. <br><br>Damian <br><br>CALL FOR PAPERS <br><br>PAW17: The 2nd Annual PGAS Applications Workshop <br>http://sourceryinstitute.github.io/PAW/ <br><br>Held in conjunction with SC 17: The International Conference for <br>High Performance Computing, Networking, Storage and Analysis <br>http://sc17.supercomputing.org(http://sc17.supercomputing.org/) [...]
2017-04-26T23:09:36-07:00Damian Rousonhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b66f46cd.1704Fortran related information on www.fortran.uk
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2fb80e15.1704
I'd like to draw attention to new and recent Fortran related information<br>at www.fortran.uk<br><br>(1) The compiler comparison charts were updated a couple of months<br>ago. These charts include<br><br>* results on Windows and Linux for 17 Fortran 95 benchamrks using<br>compilers from Absoft, GNU, Intel, Lahey, NAG, Open 64, PGI and Silverfrost.<br>* results of 53 tests which show the ability of compilers to<br>diagnose common run-time error conditions, such as arrays bound errors,<br>uninitialized variable use etc.<br>* results of 34 tests which show the Fortran language features<br>and extensions supported by each compiler. [...]
2017-04-26T13:47:55+01:00John Appleyardhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2fb80e15.1704Re: photos from FORTRAN ROAD
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fdd50909.1704
And of course Apple is located at “1 Infinite Loop” in Cupertino. I never fail to get a chuckle out of that.<br><br>Catherine<br><br>On 4/25/17, 6:20 AM, "Fortran 90 List on behalf of Phillip Helbig" <COMP-FORTRAN-90@JISCMAIL.AC.UK on behalf of helbig@MULTIVAX.DE> wrote:<br><br>> http://coarrays.sourceforge.net/fortran_rd<br>> There's some irony in the names...<br><br>Seagate's address is something-or-other Disk Drive. :-)
2017-04-25T17:03:01+00:00Moroney, Catherine M (398E)https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;fdd50909.1704Re: photos from FORTRAN ROAD
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;6c85d1b5.1704
> http://coarrays.sourceforge.net/fortran_rd<br>> There's some irony in the names...<br><br>Seagate's address is something-or-other Disk Drive. :-)
2017-04-25T15:20:44+02:00Phillip Helbighttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;6c85d1b5.1704Re: photos from FORTRAN ROAD
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b1449c0a.1704
Great pictures, thanks for sharing them.<br><br>Best Regards,<br>Vipul Parekh<br><br>On Sun, Apr 23, 2017 at 4:27 PM, Anton Shterenlikht <mexas@bris.ac.uk><br>wrote:<br><br>> http://coarrays.sourceforge.net/fortran_rd<br>> There's some irony in the names...<br>><br>> Anton<br>>
2017-04-24T08:33:41-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b1449c0a.1704photos from FORTRAN ROAD
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e39185bb.1704
http://coarrays.sourceforge.net/fortran_rd<br>There's some irony in the names...<br><br>Anton
2017-04-23T21:27:09+01:00Anton Shterenlikhthttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e39185bb.1704Re: COMP-FORTRAN-90 Digest - 6 Apr 2017 to 7 Apr 2017 (#2017-8)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;743b2be9.1704
On Fri, 2017-04-07 at 17:42 -0600, Keith Bierman wrote:<br>> The Sun libm used to (and probably still does ) include a conversion<br>> utility so reading in IBM format and producing IEEE should be fairly<br>> straightforward.<br>><br>> I'd expect AIX to have a similar utility<br><br>For portability, and because at the time all I had was the HP-UX F90<br>compiler, I wrote a code that handled 360 format byte-by-byte using<br>ICHAR and arithmetic. [...]
2017-04-07T20:52:07-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;743b2be9.1704Re: COMP-FORTRAN-90 Digest - 6 Apr 2017 to 7 Apr 2017 (#2017-8)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ea6614d6.1704
The Sun libm used to (and probably still does ) include a conversion utility so reading in IBM format and producing IEEE should be fairly straightforward.<br><br>I'd expect AIX to have a similar utility<br><br>khbkhb@gmail.com<br>kbiermank (AIM)<br>303-997-2749<br><br>Sent from my iPhone<br><br>> On Apr 7, 2017, at 5:00 PM, COMP-FORTRAN-90 automatic digest system <LISTSERV@JISCMAIL.AC.UK> wrote:<br>><br>> It was all 360 floating point. I can't imagine that anybody has<br>> converted the data to IEEE, but people are still using it.
2017-04-07T17:42:02-06:00Keith Biermanhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ea6614d6.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;adc6709b.1704
Bill,<br><br>Thank you, yes in fact a prefix of "IEEE_" on the named constants will<br>indeed be preferable.<br><br>Regards,<br>Vipul<br><br>On Fri, Apr 7, 2017 at 6:20 PM, Bill Long <longb@cray.com> wrote:<br><br>> Would more descriptive names, like IEEE_BINARY32_KIND, be OK? Names of<br>> entities in the IEEE modules typically start with IEEE_. Seems like a<br>> straightforward feature for the next standard. And easy to implement in the<br>> module.<br>><br>><br>> On Apr 7, 2017, at 5:07 PM, Vipul Parekh <parekhvs@GMAIL.COM> wrote:<br>><br>> > Tom, Van:<br>> ><br>> > Thanks much for your feedback, very [...]
2017-04-07T18:28:25-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;adc6709b.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8178e561.1704
Would more descriptive names, like IEEE_BINARY32_KIND, be OK? Names of entities in the IEEE modules typically start with IEEE_. Seems like a straightforward feature for the next standard. And easy to implement in the module.<br><br>On Apr 7, 2017, at 5:07 PM, Vipul Parekh <parekhvs@GMAIL.COM> wrote:<br><br>> Tom, Van:<br>><br>> Thanks much for your feedback, very helpful.<br>><br>> This discussion has revealed quite a few options but nothing that seems sufficiently clear for our purposes in industry where the powers-that-be (and the IT departments that serve them) have resolved to do all the computing using IEEE 754 and [...]
2017-04-07T22:20:38+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8178e561.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;57c83fbf.1704
Tom, Van:<br><br>Thanks much for your feedback, very helpful.<br><br>This discussion has revealed quite a few options but nothing that seems<br>sufficiently clear for our purposes in industry where the powers-that-be<br>(and the IT departments that serve them) have resolved to do all the<br>computing using IEEE 754 and the situation will remain so for the<br>foreseeable future. [...]
2017-04-07T18:07:22-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;57c83fbf.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;225de30e.1704
On Fri, 2017-04-07 at 10:43 +1000, Robin Vowels wrote:<br>> The S/360 was delivered at least by 1966, and probably 1965, as I<br>> already said.<br><br>A 360/63 was being installed in the Steele Computing Laboratory at<br>Caltech in the spring of 1965. When they powered it up it caught fire.<br>It was replaced with a 360/67.
2017-04-06T20:23:09-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;225de30e.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c4c7df05.1704
On Thu, 2017-04-06 at 13:36 -0400, Steve Lionel wrote:<br>> Maybe that data file has<br>> VAX G_float or is "opposite-endian". Data formats have additional<br>> constraints not solved even by SELECTED_REAL_KIND.<br><br>I had to reprocess all the SEASAT sea-surface temperature data in 1998.<br>It was all 360 floating point. I can't imagine that anybody has<br>converted the data to IEEE, but people are still using it.
2017-04-06T20:19:24-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c4c7df05.1704Re: COMP-FORTRAN-90 Digest - 5 Apr 2017 to 6 Apr 2017 (#2017-7)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7a683b3a.1704
In my good old days (1963) I used FORTRAN II on an IBM 1620 but after a<br>few months it was replaced by an Elliott 503 machine that used 39-bit<br>words, and stored one floating-point number in each.<br><br>Its floating-point form was x = a*2**b such that -1 <= a <= 1/2 or a = 0<br>or 1/2 <= a < 1, and -25 < b < 256. We used Algol on it; there was said<br>to be FEAT, a Fortran-to-Elliott Algol Translator, but I never got it<br>to work: it was easier to translate my few programs manually to [...]
2017-04-07T14:15:44+12:00John Harperhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7a683b3a.1704Re: COMP-FORTRAN-90 Digest - 5 Apr 2017 to 6 Apr 2017 (#2017-7)
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;75250dc4.1704
On Thu, Apr 6, 2017 at 5:00 PM, COMP-FORTRAN-90 automatic digest system <<br>LISTSERV@jiscmail.ac.uk> wrote:<br><br>> In the good old days before those good old days, DOUBLE PRECISION was 64<br>> bits.<br><br>Actually, in the really good old days, it was 72 (Univac 2x36). Sometimes<br>it was 60 (that might have been a site specific adjustment to the CDC,<br>which logic says ought to have been 120 and I'm sure it was at other<br>sites). 64 was mostly true on the most numerically deplorable (IBM Hex<br>representation). [...]
2017-04-06T18:56:39-06:00Keith Biermanhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;75250dc4.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;cf684caa.1704
From: "Bill Long" <longb@CRAY.COM><br>Sent: Friday, April 07, 2017 12:27 AM<br><br>On Apr 6, 2017, at 4:47 AM, W. J. Metzger <w.metzger@HEF.RU.NL> wrote:<br><br>>> IBM then<br>>> combined their business and scientific lines into one line with the<br>>> introduction of the 360 series (late 70s if I recall well), which<br>>> introduced the 32-bit word. [...]
2017-04-07T10:43:47+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;cf684caa.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ad9343c.1704
Oops - sorry about that. I just assumed given my use in the past and a good hit on a web page.<br><br>I should have consulted the standard, but I “knew” the answer to this one.<br><br>> On Apr 6, 2017, at 1:12 PM, Steve Lionel <00000d9096837217-dmarc-request@JISCMAIL.AC.UK> wrote:<br>><br>> On 4/6/2017 12:34 PM, Clune, Thomas L. (GSFC-6101) wrote:<br>>> Granted “DOUBLE PRECISION COMPLEX” does not exist, but…<br>>><br>>> DOUBLE COMPLEX_does_ exist …<br>><br>> No, it does not, other than as a vendor-specific extension.<br>><br>> Steve
2017-04-06T18:58:18+00:00Clune, Thomas L. (GSFC-6101)https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;ad9343c.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3ac3e7a0.1704
On 4/6/2017 11:28 AM, Vipul Parekh wrote:<br>> More specifically, consider the following from the scenario you<br>> presented involving some generics: the blog in question (the one I<br>> mentioned in the first note) effectively considered 2 of these options<br>> and emphatically states SELECTED_REAL_KIND is what coders should use.<br><br>As the author of the blog in question, I have been glad to see the<br>active discussion. Would that all my blog posts generate such intense<br>debate! [...]
2017-04-06T13:36:31-04:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3ac3e7a0.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;84d9102a.1704
On Thu, 2017-04-06 at 11:28 -0400, Vipul Parekh wrote:<br>> Van,<br>><br>><br>> Is the use of KIND(1.0e0) and KIND(1.0d0) just as 'portable' as<br>> SELECTED_REAL_KIND? My reading and experience suggest otherwise, but<br>> I may be wrong. Can you please share your views?<br><br>I have not encountered a case where this standard-conforming usage does<br>not work. [...]
2017-04-06T10:26:01-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;84d9102a.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;6ed1191c.1704
On Thu, 2017-04-06 at 09:49 +1200, John Harper wrote:<br>> REAL64 is the same as KIND(1D0) in many machines, including<br>> all three that I have access to, but it is apparently the same as<br>> KIND(1E0) in some.<br><br>This is related to the reason that TYPEALIAS, i.e., a new name for an<br>existing type, but not a new type, was a pointless idea. [...]
2017-04-06T10:19:04-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;6ed1191c.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8074959e.1704
On 4/6/2017 12:34 PM, Clune, Thomas L. (GSFC-6101) wrote:<br>> Granted “DOUBLE PRECISION COMPLEX” does not exist, but…<br>><br>> DOUBLE COMPLEX_does_ exist …<br><br>No, it does not, other than as a vendor-specific extension.<br><br>Steve
2017-04-06T13:12:17-04:00Steve Lionelhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8074959e.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d0085378.1704
Well stated question and it raises several thoughts. But let me first add:<br><br>Option 4:<br>function F_s ( X )<br>use iso_c_binding , only :: RK => C_FLOAT<br>…<br>end function F_s<br><br>function F_d ( X )<br>use iso_c_binding , only :: RK => C_DOUBLE<br>…<br>end function F_s<br><br>Presuming that there is an overloaded interface involved somewhere, then I think the following observations hold: [...]
2017-04-06T16:49:25+00:00Clune, Thomas L. (GSFC-6101)https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d0085378.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7d45bb14.1704
Granted “DOUBLE PRECISION COMPLEX” does not exist, but…<br><br>DOUBLE COMPLEX _does_ exist …<br><br>(Not that I recommend its use for the reasons already given.)<br><br>> On Apr 5, 2017, at 5:49 PM, John Harper <harper@MSOR.VUW.AC.NZ> wrote:<br>><br>> DOUBLE PRECISION COMPLEX does not exist but this does: COMPLEX(KIND(1D0)) Z<br>> which ensures that the real and imaginary parts of Z will be double precision. REAL64 is the same as KIND(1D0) in many machines, including<br>> all three that I have access to, but it is apparently the same as<br>> KIND(1E0) in some.<br>><br>> On Wed, 5 Apr 2017, [...]
2017-04-06T16:34:02+00:00Clune, Thomas L. (GSFC-6101)https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7d45bb14.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2b8b695f.1704
DOUBLE PRECISION COMPLEX does not exist but this does:<br>COMPLEX(KIND(1D0)) Z<br>which ensures that the real and imaginary parts of Z will be double<br>precision. REAL64 is the same as KIND(1D0) in many machines, including<br>all three that I have access to, but it is apparently the same as<br>KIND(1E0) in some.<br><br>On Wed, 5 Apr 2017, Vipul Parekh wrote: [...]
2017-04-06T09:49:11+12:00John Harperhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2b8b695f.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;38711700.1704
Van,<br><br>Is the use of KIND(1.0e0) and KIND(1.0d0) just as 'portable' as<br>SELECTED_REAL_KIND? My reading and experience suggest otherwise, but I may<br>be wrong. Can you please share your views?<br><br>More specifically, consider the following from the scenario you presented<br>involving some generics: the blog in question (the one I mentioned in the<br>first note) effectively considered 2 of these options and emphatically<br>states SELECTED_REAL_KIND is what coders should use. What do you say and<br>why? Thanks, [...]
2017-04-06T11:28:35-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;38711700.1704Re: [Fwd: Re: REAL64 what is it good for!]
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3484d70e.1704
On Apr 6, 2017, at 4:47 AM, W. J. Metzger <w.metzger@HEF.RU.NL> wrote:<br><br>> IBM then<br>> combined their business and scientific lines into one line with the<br>> introduction of the 360 series (late 70s if I recall well), which<br>> introduced the 32-bit word.<br><br>Late 60’s. At least when I took intro CS in 1969, it was on a 360/65. It is probably where the 32-bit convention started, but decidedly not IEEE format. [...]
2017-04-06T14:27:24+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;3484d70e.1704Re: REAL64 what is it good for+ACE-
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;74a78cea.1704
From: +ACI-W. J. Metzger+ACI- +ADw-w.metzger+AEA-HEF.RU.NL+AD4-<br>Sent: Thursday, April 06, 2017 7:47 PM<br><br>+AD4- And before it introduced the 6600 with 60 bit words, CDC also had some<br>+AD4- 48-bit models.<br><br>When introduced in 1951, the fastest machine in the world, the Pilot ACE,<br>had 32-bit words, and was used for scientific work.<br><br>+AD4- In Robin's time frame IBM's top 'scientific' machine was the 709, 7090<br>+AD4- with 36-bit words. [...]
2017-04-06T22:34:39+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;74a78cea.1704[Fwd: Re: REAL64 what is it good for!]
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8db6b107.1704
And before it introduced the 6600 with 60 bit words, CDC also had some<br>48-bit models.<br><br>In Robin's time frame IBM's top 'scientific' machine was the 709, 7090<br>with 36-bit words. Their top 'business' machine was the 7070, which was<br>decimal, not binary, with words of 10 decimal digits,an exponent range<br>in floating 10+AF4--49 - 10+AF4-49 and a fraction of 8 decimal digits. IBM then<br>combined their business and scientific lines into one line with the<br>introduction of the 360 series (late 70s if I recall well), which<br>introduced the 32-bit word. [...]
2017-04-06T11:47:40+02:00W. J. Metzgerhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;8db6b107.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;12be90c2.1704
I think, that if one uses the client-server approach, many things become<br>simpler:<br><br>If someone tries to solve a particular problem, he will maybe find, that<br>something like real*6 variables would be enough for his demands. So as a<br>client he would ask for a precision with about 12 decimal places.<br><br>If someone wants to install a set of solvers on a particular system, he<br>might try to install these for all available precisions, so from the<br>server view he would proceed as shown by van Snyder. Now anyone with a<br>reasonable demand could use that package. [...]
2017-04-06T11:25:25+02:00Alois Steindlhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;12be90c2.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d2bad5ec.1704
Am 2017-04-06 um 09:08 schrieb Robin Vowels:<br>> From: alois.steindl@tuwien.ac.at<br>> Sent: Thursday, April 06, 2017 4:34 PM<br>><br>>> I beg to differ: on the CDC, in the late 70s, Real was 60 bit.<br>>> According to my observation the 4-8-16 byte rule appeared later,<br>>> mainly with the PCs.<br>>> Not sure about the VAXes.<br>><br>> The good old days I was referring to were the 1950s and 1960s.<br>><br>The Mailüfterl (see<br>https://web.archive.org/web/20110821021232/http://www.museumonline.at/2000/wien-feuerbach/mailueft/mailueft_en.htm),<br>built in the 50s, an Austrian development, used 48-bit words.<br>>> Best wishes<br>again<br>>> Alois<br>><br>><br>> ------ Originalnachricht------<br>> Von: [...]
2017-04-06T10:52:11+02:00Alois Steindlhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d2bad5ec.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5a8895bc.1704
From: alois.steindl@tuwien.ac.at<br>Sent: Thursday, April 06, 2017 4:34 PM<br><br>>I beg to differ: on the CDC, in the late 70s, Real was 60 bit.<br>> According to my observation the 4-8-16 byte rule appeared later, mainly with the PCs.<br>>Not sure about the VAXes.<br><br>The good old days I was referring to were the 1950s and 1960s. [...]
2017-04-06T17:08:10+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5a8895bc.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c5b4b853.1704
On Wed, 2017-04-05 at 11:29 +0200, Phillip Helbig wrote:<br>> I understand the motivation for KIND. However, many people use<br>> SELECTED_REAL_KIND with 1.0D0 or whatever to find the<br>> "double-precision KIND". Why not just write DOUBLE PRECISION if that<br>> is what you mean?<br><br>I use INCLUDE as a poor-man's substitute for generic programming. [...]
2017-04-05T23:43:29-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c5b4b853.1704AW: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7669debe.1704
I beg to differ: on the CDC, in the late 70s, Real was 60 bit. According to my observation the 4-8-16 byte rule appeared later, mainly with the PCs.Not sure about the VAXes.Best wishesAlois ------ Originalnachricht------Von: Robin VowelsDatum: Do., 6. Apr. 2017 05:15An: COMP-FORTRAN-90@JISCMAIL.AC.UK;Betreff:Re: REAL64 what is it good for! From: Clune, Thomas L. (GSFC-6101)Sent: Thursday, April 06, 2017 6:37 AM> In the good-old-days, DOUBLE PRECISION was often something like 128 bits (and definitely not > IEEE!).In the good old days before those good old days, DOUBLE PRECISION was 64 bits.> But that historic issue aside, using DOUBLE PRECISION is [...]
2017-04-06T06:34:38+00:00alois.steindl@tuwien.ac.athttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;7669debe.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e65e44d.1704
On Apr 5, 2017, at 9:16 PM, Robin Vowels <robin51@DODO.COM.AU> wrote:<br><br>> From: Clune, Thomas L. (GSFC-6101)<br>> Sent: Thursday, April 06, 2017 6:37 AM<br>><br>>> In the good-old-days, DOUBLE PRECISION was often something like 128 bits (and definitely not IEEE!).<br>><br>> In the good old days before those good old days, DOUBLE PRECISION was 64 bits. [...]
2017-04-06T03:53:36+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e65e44d.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c98b3c36.1704
From: Clune, Thomas L. (GSFC-6101)<br>Sent: Thursday, April 06, 2017 6:37 AM<br><br>> In the good-old-days, DOUBLE PRECISION was often something like 128 bits (and definitely not<br>> IEEE!).<br><br>In the good old days before those good old days, DOUBLE PRECISION was 64 bits.<br><br>> But that historic issue aside, using DOUBLE PRECISION is a real pain if you want to change<br>> to a different precision. The KIND mechanism will generally allow us to at least control<br>> the precision in a small number of “well chosen” spots in the code. [...]
2017-04-06T12:16:12+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c98b3c36.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;dfaf5e2f.1704
In the good-old-days, DOUBLE PRECISION was often something like 128 bits (and definitely not IEEE!).<br><br>But that historic issue aside, using DOUBLE PRECISION is a real pain if you want to change to a different precision. The KIND mechanism will generally allow us to at least control the precision in a small number of “well chosen” spots in the code. [...]
2017-04-05T20:37:00+00:00Clune, Thomas L. (GSFC-6101)https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;dfaf5e2f.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4802d645.1704
Phillip,<br><br>You ask, "Why not just write DOUBLE PRECISION if that is what you mean?"<br>Note the standard only states the following about DOUBLE PRECISION:<br><br>1) "The decimal precision of the double precision real approximation method<br>shall be greater than that of the default real method."<br>2) "The decimal precision of double precision real shall be at least 10,<br>and its decimal exponent range shall be at 37. It is recommended that the<br>decimal precision of default real be at least 6, and that its decimal<br>exponent range be at least 37." [...]
2017-04-05T09:21:29-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4802d645.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d8caaee5.1704
> use, intrinsic:: ISO_FORTRAN_ENV, only: REAL32, REAL64<br>><br>> implicit none<br>> private<br>><br>> interface goo<br>> module procedure goo_s<br>> module procedure goo_d<br>> end interface<br>> public :: goo<br>><br>> contains<br>><br>> subroutine goo_s (x)<br>> real(kind=REAL32), intent(..) :: x<br>> include 'goo_source.inc'<br>> end subroutine goo_s<br>> subroutine goo_d (x)<br>> real(kind=REAL64), intent(..) :: x<br>> include 'goo_source.inc'<br>> end subroutine goo_d<br><br>What is the essential difference between this and using REAL and DOUBLE<br>PRECISION? [...]
2017-04-05T11:29:38+02:00Phillip Helbighttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d8caaee5.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;dd248c19.1704
From: "Clive Page" <clive.page@CANTAB.NET><br>Sent: Wednesday, April 05, 2017 1:55 AM<br><br>> On 04/04/2017 13:57, Vipul Parekh wrote:<br>>> You must have considered the possibility where "to specify that your<br>>> variables used in the I/O lists have a specific length in bits", one can<br>>> build on Robin Vowels comment about using CHARACTER variable(s) for IO<br>>> but employ CHARACTER_STORAGE_SIZE named constant from ISO_FORTRAN_ENV to<br>>> get at the desired length(s) in bits (this is as opposed to assuming it<br>>> will be 8 bits). TRANSFER intrinsic then helps with the actual<br>>> variables. Do you anticipate any shortcomings [...]
2017-04-05T10:21:41+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;dd248c19.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;81d6f87e.1704
On Apr 4, 2017, at 10:55 AM, Clive Page <clive.page@CANTAB.NET> wrote:<br><br>> On 04/04/2017 13:57, Vipul Parekh wrote:<br>>> You must have considered the possibility where "to specify that your<br>>> variables used in the I/O lists have a specific length in bits", one can<br>>> build on Robin Vowels comment about using CHARACTER variable(s) for IO<br>>> but employ CHARACTER_STORAGE_SIZE named constant from ISO_FORTRAN_ENV to<br>>> get at the desired length(s) in bits (this is as opposed to assuming it<br>>> will be 8 bits). TRANSFER intrinsic then helps with the actual<br>>> variables. Do you anticipate any shortcomings [...]
2017-04-04T17:48:14+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;81d6f87e.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e09a036b.1704
On 04/04/2017 13:57, Vipul Parekh wrote:<br>> You must have considered the possibility where "to specify that your<br>> variables used in the I/O lists have a specific length in bits", one can<br>> build on Robin Vowels comment about using CHARACTER variable(s) for IO<br>> but employ CHARACTER_STORAGE_SIZE named constant from ISO_FORTRAN_ENV to<br>> get at the desired length(s) in bits (this is as opposed to assuming it<br>> will be 8 bits). TRANSFER intrinsic then helps with the actual<br>> variables. Do you anticipate any shortcomings in this approach relative<br>> to your use cases? [...]
2017-04-04T16:55:47+01:00Clive Pagehttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e09a036b.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c44da420.1704
Tom,<br><br>I greatly appreciate your feedback.<br><br>I'll never be able to understand why "the committee is generally wary of<br>overly constraining properties" yet is reluctant to address the confusion<br>and muddled messaging that has arisen with the current situation and the<br>adverse impact it is having on beginning and casual coders, particularly in<br>industry.<br><br>Regards,<br>Vipul<br><br>On Tue, Apr 4, 2017 at 9:03 AM, Clune, Thomas L. (GSFC-6101) <<br>thomas.l.clune@nasa.gov> wrote: [...]
2017-04-04T10:06:06-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;c44da420.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;13d0e4c1.1704
Gigi,<br><br>You write, "I find handy to use it to (hopefully) a portable way to specify<br>kind number in single/double precision versions". The blog I mentioned in<br>the initial note of this thread says "caveat emptor"<br><br>Regards,<br>Vipul<br><br>On Tue, Apr 4, 2017 at 5:02 AM, GianLuigi Piacentini <ggpiace@tin.it> wrote:<br><br>> Just an hobbyst opinion:<br>><br>> I find handy to use it to (hopefully) a portable way to specify kind<br>> number in<br>> single/double precision versions of procedures to be inserted in object<br>> libraries (think to 'lib.a' file), as in the following snippet:<br>><br>> module foo<br> [...]
2017-04-04T09:15:00-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;13d0e4c1.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d36c25f6.1704
While the standard does not require REAL32/REAL64 to correspond to IEEE, it is the practical reality in modern computing. Yes, many older machines had a more diverse set of FP representations, but there is minimal risk that vendors will back port their compilers to such. The committee is generally wary of overly constraining properties along the lines that you suggest. The standard still has SELECTED_REAL_KIND(), and as of F2003 IEEE_SELECTED_REAL_KIND() that give greater control where such is required. [...]
2017-04-04T13:03:16+00:00Clune, Thomas L. (GSFC-6101)https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;d36c25f6.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5b9c4666.1704
Clive,<br><br>You must have considered the possibility where "to specify that your<br>variables used in the I/O lists have a specific length in bits", one can<br>build on Robin Vowels comment about using CHARACTER variable(s) for IO but<br>employ CHARACTER_STORAGE_SIZE named constant from ISO_FORTRAN_ENV to get at<br>the desired length(s) in bits (this is as opposed to assuming it will be 8<br>bits). TRANSFER intrinsic then helps with the actual variables. Do you<br>anticipate any shortcomings in this approach relative to your use cases? [...]
2017-04-04T08:57:21-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;5b9c4666.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4d075f64.1704
From: "Clive Page" <clive.page@CANTAB.NET><br>Sent: Tuesday, April 04, 2017 6:54 PM<br><br>> Unless I missed it, one important usage case has not been mentioned so far.<br>><br>> If you have an existing binary data file that you want to read in<br>> Fortran, or want to write a binary file for another application to use<br>> then it's necessary to specify that your variables used in the I/O lists<br>> have a specific length in bits. INT32, REAL64 and the rest provide a<br>> good way of specifying this which was hard to do in a portable way before. [...]
2017-04-04T20:09:43+10:00Robin Vowelshttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4d075f64.1704REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;16b1d357.1704
Just an hobbyst opinion:<br><br>I find handy to use it to (hopefully) a portable way to specify kind number in<br>single/double precision versions of procedures to be inserted in object<br>libraries (think to 'lib.a' file), as in the following snippet:<br><br>module foo<br><br>use, intrinsic:: ISO_FORTRAN_ENV, only: REAL32, REAL64<br><br>implicit none<br>private<br><br>interface goo<br>module procedure goo_s<br>module procedure goo_d<br>end interface<br>public :: goo [...]
2017-04-04T11:02:46+02:00GianLuigi Piacentinihttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;16b1d357.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;85375485.1704
Unless I missed it, one important usage case has not been mentioned so far.<br><br>If you have an existing binary data file that you want to read in<br>Fortran, or want to write a binary file for another application to use<br>then it's necessary to specify that your variables used in the I/O lists<br>have a specific length in bits. INT32, REAL64 and the rest provide a<br>good way of specifying this which was hard to do in a portable way before.
2017-04-04T09:54:03+01:00Clive Pagehttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;85375485.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;19be5f01.1704
On Mon, 2017-04-03 at 20:24 +0000, Bill Long wrote:<br>> The REAL32, REAL64, and REAL128 constants, as we as INT8, INT16,<br>> INT32, and INT64 constants for integers, were added as a convenience<br>> for users. "The requirement is to provide a simplified means to select<br>> the most commonly desired real and integer kinds.” It is far better<br>> than the old *n form because these constants can be used in<br>> standard-conforming statements. The constants also provide useful<br>> information in that negative values indicate that the particular KIND<br>> is not supported. [...]
2017-04-03T18:44:11-07:00Van Snyderhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;19be5f01.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;de491bff.1704
For what I most often do (quadrature and solving integral equations)<br>the reasons for not using the highest possible precision are not memory<br>limitations but, most importantly lack of patience (quad precision takes<br>longer than double), and less importantly the desire to try my programs<br>with several different compilers: many selected_real_kind(33) intrinsics<br>are missing from g95, which is otherwise a good compiler. I don't use<br>REAL64 and friends because that's not available in either g95 or our<br>rather old (2014) version of Sun Fortran. [...]
2017-04-04T10:24:55+12:00John Harperhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;de491bff.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e8011947.1704
Thanks much, Bill and Tom, for your replies.<br><br>My apologies if this sounds silly to you all to bring this up, but I'm<br>quite confused: as you can see in the blog, Steve Lionel states, "My advice<br>is to not use those constants ..", he laments the standard only stipulates<br>the storage size and says nothing about the range or precision of the type. [...]
2017-04-03T17:37:29-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;e8011947.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f5df6b97.1704
As someone working with a large model ( O(10^6) sloc ), I have found that using these named constants provides 2 major advantages over the SELECTED_REAL_KIND() approach. First, the intent is much more obvious. Yes, the parameters to the intrinsic let you figure out that on an IEEE machine this expression will give you 32 bits: [...]
2017-04-03T20:41:22+00:00Clune, Thomas L. (GSFC-6101)https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;f5df6b97.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b941cde0.1704
The REAL32, REAL64, and REAL128 constants, as we as INT8, INT16, INT32, and INT64 constants for integers, were added as a convenience for users. "The requirement is to provide a simplified means to select the most commonly desired real and integer kinds.” It is far better than the old *n form because these constants can be used in standard-conforming statements. The constants also provide useful information in that negative values indicate that the particular KIND is not supported. [...]
2017-04-03T20:24:25+00:00Bill Longhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;b941cde0.1704Re: REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2419839a.1704
On a related note (limited connectivity while in hospital, thus not a usual<br>elegant post), is there anything these dazs lige G-Float and D-Float on<br>the VAX (same number of bits, different precision)?<br><br>these days like<br><br>Yes, memory is cheap these days, so there is the temptation of overkill,<br>but I am sure that there are still many memory-limited applications, so<br>if one needs just more precision but not much range, or just more range<br>but not much precision, then the same number of bits but split up<br>differently could be attractive. [...]
2017-04-03T18:24:51+02:00Phillip Helbighttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;2419839a.1704REAL64 what is it good for!
https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4776ded0.1704
Steve Lionel, previously at Intel, pointed out in a recent blogpost at<br>http://intel.ly/2nZSxoE) that "Fortran 2008 extended intrinsic module<br>ISO_FORTRAN_ENV to include named constants .. REAL32, REAL64 and REAL128<br>whose values correspond to the kinds of real .. that occupy the stated<br>number of bits. .. In my view, this is little better than the old *n<br>extension in that it tells you that a type fits in that many bits, but<br>nothing else about it." [...]
2017-04-03T12:00:58-04:00Vipul Parekhhttps://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=COMP-FORTRAN-90;4776ded0.1704