On Monday, August 1, 2016 at 7:29:28 AM UTC-7, FortranFan wrote:
(snip about units and Fortran)
> However the "The criticism" expressed in this thread "about whether
> the .. complexity .. makes it worthwhile" is utterly vacuous unless sound
> technical arguments are put forward which disprove Van Snyder's assertion
> in the original post, "The reasons given by the vendors are (1) it's too hard (it isn't)".
> Thus far, I have not seen any. All that can be seen are the usual naysayer
> kind of comments.
Most features have been well tested, either as actual extensions in previous
compilers, or as popular features of other languages, such that it is obvious
enough how useful, and how to use, them.
> My impression from Van Snyder's original post is that he thinks this is not as
> complex as it seems and that the current Fortran standard specification as
> well as the compiler implementations for the standard have most of the wiring
> in place to implement such a capability. It will be great if Van Snyder can
> elaborate further on his reasoning and his understanding as to why his
> proposal is on the easier side than otherwise.
I do believe that it would be interesting to have a system like I mentioned
previously that uses comments in Fortran programs. Such programs obviously
compile just as they would without comments, and an external processor can
check that the comments describe units correctly.
That doesn't help with I/O, but I believe that is a different problem, and will
need more work to understand.
(snip)
> As stated earlier, I firmly believe a well-designed and easy-to-use standard
> facility for units, if possible, can be a real game-changer for Fortran.
It isn't so obvious to me. In freshman physics, units are important.
One reason is to get students used to thinking about units, but also because
it helps avoid some easy mistakes, such as when one is learning about the
difference between momentum and kinetic energy. Later years don't have
that problem.
> The industries (manufacturing, chemical, process) and the teams I work with
> will indeed make use of such a facility. It will take time and effort,
> but standard capability for units will start to get used if implemented correctly.
If one uses a consistent set of units consistently, much of the problem goes away.
Note that you can always make mistakes that the compiler won't catch.
If, for example, you use the speed of light, when you meant the speed of sound,
it is unlikely that the compiler will notice.
Also, quantities that happen to be dimensionally the same, but physically
different. Torque and energy both have the same units, but don't try to use
one where the other is meant. (In many cases, the integral of torque through
an angle in radians is energy, and radians are dimensionless.)
If one is actually mixing metric and english units in the same problem,
then I suppose it could be a big help. Though doing it all metric might
be a better solution.
(As previously noted, blame Reagan. Conveniently, he can't disagree.)
> As with any new standard feature, use in industry depends on
> implementation in the compilers of choice (usually the commercial ones)
> and prompt resolution of compiler bugs, but that's nothing new.
> Users like me will be among the first to adopt the change and embrace
> it and start to evangelize it if the facility is comprehensive and promotes
> sound use of dimensional analysis and unit-of-measure labels that scientists
> and engineers are used to dealing with in their equations and modeling.
But note that the system I suggest, implemented in Fortran comments with
an external processor, doesn't depend on compiler implementation.
> To me, units (all aspects of it including the dimensionality and the
> unit-of measure labeling) are at the foundation of reliable numerical
> computations.
OK, but they aren't for many people. Not that they don't ever cause
problems, but that there are enough other things to get right, and after
a while one gets better at getting units right.
> Having capabilities that are part of the standard greatly facilitate a key
> ingredient of reliability. Surely reliability is a lot more than units, but
>proper handling of units is where reliability begins in many computations.
> Advances of Fortran in this direction will greatly improve the structural
> underpinnings of how a programming language can facilitate writing good
> software for reliable computations and I think that is what Van Synder
> is implying by the title of this thread.
Could be, but is there any actual evidence? Tests comparing users
programming with units in a language compared to those without?
I suspect double blind testing won't be easy to do.
> So I think the onus is to help and guide Van Snyder and the standards
> committee with the right kind of input for a well-designed and
> easy-to-understand and easy-to-use functionality for units in Fortran.
I think there needs to be some examples and testing before it gets to
the standard committee. They do things like make sure that new syntax
isn't ambiguous. I don't even know that there is a standard way of writing
units that could be used in a new Fortran feature. Anyone want to suggest one?
> The key idea by Van Snyder, it seems to me, is to expand on the attributes
> of floating-point variables in Fortran such as KIND, DIMENSION,
> ALLOCATABLE, etc. Just as
As i noted before, I don't see why INTEGER values can't have units.
That may be less common, but it can happen.
> use, intrinsic :: iso_fortran_env, only : real64
> real(real64), allocatable :: foo(:)
> ..
> leads to a certain glob of information surrounding the floating point
> representation of foo including its precision, range, rank, etc., why would
> it not be to possible to expand on this to include unit information?
Well, note that the kind, precision, and rank systems are not perfect, and in
fact are a big cause of reliability problems in some cases.
> His proposal sets the defaults nicely so that any Fortran coders not
> wanting to avail of such capabilities can continue as they do today,
> no further harm to them simply because of this.
Is it so obvious what notation should be used? It is very confusing to
start with one, standardize it, and then change it, so it should be at least
close to right the first time. That needs some testing.
> I think the proposal has merit and it warrants specific and targeted
> technical discussion on various aspects surrounding it, rather than
> generic, vague estimations oh there will be little benefit compared to
> its complexity or this won't get used, etc.
We have lots of discussion, but about some accurate values for cost
to implement, and benefit to users, in saved time or money?