(j3.2006) [Fwd: Fortran 2008 query]
Van Snyder
Van.Snyder
Thu Oct 26 15:58:36 EDT 2017
On Thu, 2017-10-26 at 18:44 +0000, Bill Long wrote:
> I see two possible solutions for this problem (besides writing the
> program differently):
How would you write a program to have 4000 constants represented to 30
dp, just in case you find a processor that will handle quad precision
(which I think is pretty common now)? Processors could in principle
support arbitrary precision, at the expense of using something like
David Bailey's extended precision arithmetic package "under the covers."
Warn users "this will be slow!"
> 1) The option ?length ridiculously large? is too vague.
It was intentionally vague. TBD during requirements development. I
proposed 9999 in 2003. But Stan howled. When systems with one GB per
core were already common. It ought to be unlimited, but....
> We could say that it is a processor-dependent value greater or equal
> to 1023.
Ridiculously small. Why design a language for machines that were
obsolete twenty years ago? We should be designing for the future, not
the past.
I already have a program that would have had a 7670-line parameter
declaration, and a much older one that would have had a 1423-line
declaration. If I had made my spectroscopy catalog a compile-time
constant instead of reading it from a file, it would have been 20,000
lines. And programs will only get bigger and more complicated. With a
newer instrument we might need 200,000 spectroscopy catalog entries.
> That would probably be enough for this program,
Did you miss the part about "nmax = 4000" (should have been "integer,
parameter :: nmax = 4000")? How about "calculated to 30 dp and I don't
want to lose this accuracy"? We allow lines that would fit three 30 dp
values per line (without continuing literal constants -- ugh), so 4000
values wouldn't fit in 1023 lines.
> but making something processor dependent hurts portability and
> whatever value you pick for the lower bound will be seen as too low
> by someone.
The standard has no limit on parentheses or construct nesting depth.
Has any vendor ever gotten a complaint from a customer about their
processor-dependent limit being too small?
The days when a statement length limit made sense are long gone. Some
processors already allow unlimited statement length. Is there another
real language that has a statement length limit?
> 2) Allow array sections in PARAMETER statements, similar to how we
> allow parts of an array in DATA. For example,
>
> program init
> integer,parameter :: n = 9
>
> real :: a(n)
> parameter (a(1:3) = [1.23, 2.34, 3.45])
> parameter (a(4:6) = [4.56, 5.67, 6.78])
> parameter (a(7:9) = [7.89. 8.90. 9.01])
Or just put DATA statements in a module with the PROTECTED attribute.
But then Bill says we should get rid of DATA statements.
I suspect this solution is harder for processor developers than
unlimited statement length. They would need to check that every element
is given a value exactly once. Memory requirements for that are smaller
than unlimited statement length by a constant factor, albeit a large
one.
> print *, a
> end program init
>
> This is currently not allowed, but the standard could be changed to
> allow it. We would want reasonable restrictions, such as requiring
> that all of the elements of the array be defined by PARAMETER
> statements.
>
> Option 2 seems more resilient to future breakage, and is minimally
> invasive since PARAMETER statements are pretty rarely used. Besides,
> this is only an extension - previously conforming programs would
> continue to be conforming.
Longer statements are only an extension. Previously conforming programs
would continue to be conforming.
>
> Cheers,
> Bill
>
> > On Oct 26, 2017, at 1:12 PM, Van Snyder <Van.Snyder at jpl.nasa.gov>
> wrote:
> >
> > I'm not the only one with this problem.
> >
> > Can we make statement length ridiculously large in the next
> revision?
> >
> > I have a Fortran 2008 query I hope that you may help me with.
> I want to
> > have some very long (several thousand element) arrays
> containing data
> > values that are constants (these values are actually accurate
> values
> > that I am using to check the output from various algorithms
> against).
> > The 'obvious' way of doing this is to declare a large
> parameter array. e.g.,
> >
> > nmax = 4000
> > real (kind = kind(0.0d0)), parameter :: accres(nmax) =
> [ &
> > <lots of values> &
> > ]
> >
> > To make this standard conforming the number of continuation
> lines is
> > restricted by the 2008 standard to 255 each with 132
> characters. The
> > data has been calculated to 30 dp and I don't want to lose
> this accuracy.
> >
> > Is there any way, within the standard, that I can split the
> above into
> > several separate statements without using different array
> names?
> >
> > Pre-parameter statements I would have used a sequence of data
> statements
> > and set up values to successive blocks of the array. But
> PARAMETER is
> > better in that it is making the 'constant' nature of the
> array clear
> > which is not the case with DATA.
> >
> >
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
>
> Bill Long
> longb at cray.com
> Principal Engineer, Fortran Technical Support & voice: 651-605-9024
> Bioinformatics Software Development fax:
> 651-605-9143
> Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.j3-fortran.org/pipermail/j3/attachments/20171026/28eec0c2/attachment-0001.html>
More information about the J3
mailing list