(j3.2006) (SC22WG5.5456) User observations on PDTs

[Lionel, Steve]

At the recent J3 meeting I mentioned that Intel had several customers very
interested in PDTs and who were looking for better support of them as well
as further features. A couple of members asked me for more details, so I
posed the question and got this response which is a good summary. (Also
follow the link for more.)

 

I think IanH's (Ian Harvey) comments in this topic
(https://software.intel.com/en-us/forums/topic/542336) summarize nicely many
of our motivations for using PDTs, especially what he says in Quote #12.
One can say the solutions we're currently offering to our consumers are very
close to his PositionAlloc example, but the typical use cases by our
customers are such we can be in PositionLen situation i.e., most of the data
dimensions of objects are fixed states and one often does not need the
flexibility offered by allocatable objects.  As mentioned by IanH, "length
type parameters are just awesome."   So we're considering a rewrite of some
of our code to transition from "PositionAlloc" to "PositionLen".  Note if
PDTs had become available much earlier in the Fortran 2003 implementation
cycle in Intel Fortran, then we would have started considering it for our
code design much sooner and a lot of our code would have been developed
using PDTs in the first place, especially with use of the length parameter.


 

In addition, one other area where we're looking PDTs is to use kind
parameters in the implementation of "abstract calculus" (example reference:
Scientific Software Design book by Rouson et al. you mention in your Dr
Fortran blog) in some of our core numerical libraries with both double
precision (real64 and c_double from iso_fortran_env, iso_c_binding
intrinsics) and quadruple precision (real132 from  iso_fortran_env)
arithmetic in mind.  We hope to start investigating  how we might benefit
from quadruple precision computations in certain "numerically sensitive"
sections of our simulations without having to rewrite much code.  Albeit
this is in very early stages and there are a lot of compiler improvements
we're waiting for, but we're excited at the prospect of using kind parameter
facility too.

 

So the belief that PDTs are not all that useful is incorrect.  Once robust
implementations of PDTs become widespread in compilers, it can become very
useful and if the standard can be further improved to facilitate generic
programming (e.g., not requiring include files to handle kind parameter
scenarios or being able to specify some limits on the type parameters, etc),
PDTs can become even more powerful.  So I feel the standard-bearers should
be looking to further improve this feature rather than leaving it as-is.

 

 

Steve Lionel

Intel Developer Support

Merrimack, NH

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20150305/91be51b9/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6616 bytes
Desc: not available
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20150305/91be51b9/attachment.bin