Does anybody else care about reliability?

[Van Snyder]

In 1976, my group was asked by DoD to review the five levels of requirements for what became Ada. We recommended that the language provide facilities for real variables to have units of measure, and that the compiler check for consistency. Col. Whittaker essentially answered "Huh? Why would a language intended explicitly for high-reliability programming need that?"

In 1986 I proposed it informally for Fortran. I couldn't get funding to join X3J3, so it went nowhere.

In 2004, I proposed a work item for what became Fortran 2008. Within the US ANSI/INCITS committee (J3), it was favorably received, with 2 disliking it, eight liking it, and three loving it. It was inscrutably assigned a difficulty commensurate with coarrays, and was eventually dropped from consideration in favor of projects that were considered to be easier.

Starting in 2006, and several times thereafter, I proposed a work item called a "Technical Specification" (TS) as an ISO/IEC JTC1/SC22/WG5 project. A TS has a separate schedule from a standard revision. The project was rejected. I proposed it several times again, and it has been repeatedly rejected.

The reasons given by the vendors are

(1) it's too hard (it isn't), and

(2) nobody's asked us for it directly (but the standards committees have been asked).

Nobody has had the courage to say why they didn't like it, perhaps because they're afraid that would allow me to address the objections.

We lost a $300 million project (Mars Climate Orbiter) because of a mistake involving units, that would have been caught and automatically corrected if the facilities I propose had been available and used.

I spend in aggregate about two weeks per year -- a day here, a day there -- hunting for and correcting mistakes involving units, usually when somebody gives me a subprogram to incorporate into my code, with arguments identified as something like "height," "latitude," and "pressure." Is the height geocentric or geodetic? Is it meters, kilometers, miles, average Earth radii, ...? Is the latitude geocentric or geodetic? Radians or degrees? Is the pressure PSIA, PSIG, mmHg, hectopascals, bars, ...?

I don't think I'm alone. Does anybody else have this problem? Does anybody else care about software reliability? Would anybody else like to have assistance from the programming language? Maybe if you spoke up, the "nobody asked us for it" excuse wouldn't carry much weight.

[herrman...@gmail.com]

On Wednesday, July 6, 2016 at 7:08:18 PM UTC-7, Van Snyder wrote:

(snip on Ada)

> We recommended that the language provide facilities for real variables to
> have units of measure, and that the compiler check for consistency.

Why do INTEGER variables not need units?

> Col. Whittaker essentially answered "Huh? Why would a language intended
> explicitly for high-reliability programming need that?"

> In 1986 I proposed it informally for Fortran. I couldn't get funding to join
> X3J3, so it went nowhere.

> In 2004, I proposed a work item for what became Fortran 2008.
> Within the US ANSI/INCITS committee (J3), it was favorably received,
> with 2 disliking it, eight liking it, and three loving it. It was inscrutably
> assigned a difficulty commensurate with coarrays, and was eventually
> dropped from consideration in favor of projects that were considered
> to be easier.

It would be interesting to do some tests, to see how well it worked in
actual practice.

While I might understand how it works internally, how to do I/O is
less obvious. Do input files now need units for each value? What happens
to all the old files that don't have them.

> Starting in 2006, and several times thereafter, I proposed a work item
> called a "Technical Specification" (TS) as an ISO/IEC JTC1/SC22/WG5
> project. A TS has a separate schedule from a standard revision.
> The project was rejected. I proposed it several times again, and it has
> been repeatedly rejected.

> The reasons given by the vendors are

> (1) it's too hard (it isn't), and

> (2) nobody's asked us for it directly (but the standards committees have been asked).

> Nobody has had the courage to say why they didn't like it, perhaps
> because they're afraid that would allow me to address the objections.

> We lost a $300 million project (Mars Climate Orbiter) because of a mistake
> involving units, that would have been caught and automatically corrected
> if the facilities I propose had been available and used.

I remember this one, but I don't know the details well enough. As above,
do the input files have units? Do units propagate at run time through all expressions?

> I spend in aggregate about two weeks per year -- a day here, a day
> there -- hunting for and correcting mistakes involving units, usually
> when somebody gives me a subprogram to incorporate into my code,
> with arguments identified as something like "height," "latitude," and
> "pressure." Is the height geocentric or geodetic? Is it meters, kilometers,
> miles, average Earth radii, ...? Is the latitude geocentric or geodetic?
> Radians or degrees? Is the pressure PSIA, PSIG, mmHg, hectopascals, bars, ...?

Some seem easy, some not so easy. PSIA and PSIG are interesting. What happens
when you add, subtract, multiply, or divide, values with PSIA and PSIG?

What happens when you multiply PSIG by length or area?

> I don't think I'm alone. Does anybody else have this problem?
> Does anybody else care about software reliability? Would anybody else like
> to have assistance from the programming language?
> Maybe if you spoke up, the "nobody asked us for it" excuse wouldn't
> carry much weight.

One that I have noticed some time ago, is that in physics books variables tend
to have units, but in engineering books the units are factored out.

That is, in physics you will see F=ma, where you can use appropriate units for
any two, and the units for the third will then be defined.

In engineering:

F (Newtons) = m (kg) * a (m/s**2),

or even

F (Pounds) = m (slugs) * a *(ft/s**2)

(They do it different in ChE, but I forget how.)

Did you mean like the physics example, or one of the engineering examples?

It is interesting, but I think you have to go all the way though, and consider
how it could be used. Then, if it is too inconvenient, realize that it won't be
used.

-- glen

[Van Snyder]

On Wednesday, July 6, 2016 at 9:36:44 PM UTC-7, herrman...@gmail.com wrote:
> On Wednesday, July 6, 2016 at 7:08:18 PM UTC-7, Van Snyder wrote:

> > We recommended that the language provide facilities for real variables to
> > have units of measure, and that the compiler check for consistency.
>
> Why do INTEGER variables not need units?

The requirement for that never came up in my work. I can image it might come up in, for example, finance or economics. Are units expressions consistent with Fortran rules for integer division?

> It would be interesting to do some tests, to see how well it worked in
> actual practice.

Grant Petty has a package based upon derived types. It supports up to eight atomic units, with exponents. Arithmetic is provided by procedures, so unlike my proposal it imposes significant runtime overhead.

> While I might understand how it works internally, how to do I/O is
> less obvious. Do input files now need units for each value? What happens
> to all the old files that don't have them.

In my proposal, units in explicitly formatted input are checked, and converted if necessary, if there's a "U" format descriptor. Units are produced in explicitly formatted output if there's a "U" format descriptor. Units are not produced or checked in unformatted I/O, list-directed I/O, or namelist I/O.

> > We lost a $300 million project (Mars Climate Orbiter) because of a mistake
> > involving units, that would have been caught and automatically corrected
> > if the facilities I propose had been available and used.
>
> I remember this one, but I don't know the details well enough. As above,
> do the input files have units? Do units propagate at run time through all expressions?

If a units facility had been available, and its use required, input files would have been read with formats having "U" format descriptors. Units propagate through expressions, but this calculation takes place at compile time, so there is no performance penalty. If conversion is necessary, say between Celsius and Fahrenheit, it's explicit. The conversion is never more complicated than a*X+b, where a and b are constants and a is not zero, so the conversion functions are slightly more trivial than statement functions.

The story of the loss of Mars Climate Orbiter is a bit deeper than is admitted in the official NASA report. The ultimate cause is the same: Lockkeed used Imperial units in reporting the results of its small-force model (for the attitude thrusters, which are impossible to position, aim, and use perfectly symmetrically). After that, some obfuscation enters the report, to mask the effects of the Golden age of Goldin. A navigator (user of the navigation software, as opposed to a developer) noticed that there appeared to be a discrepancy that would be accounted for if there were a factor of about 4.4 applied to the small-force results. Of "faster better cheaper" you can only have two, so navigator training was skimped. The navigator didn't know that 4.4 is approximately the conversion between pound-seconds and Newton-seconds. He was told "That's not your job; get back to work!". Later a navigator (I don't know whether it was the same one) noticed that there was a 67 km discrepancy between the predicted aim point, based upon integrating the equations of motion including the small-force model, and tracking data. He was told the same thing. Eventually, enough people became convinced that something ought to be investigate. A meeting was convened of the navigation software developers, navigators, propulsion engineers, and managers. They argued for five hours, and ultimately decided to do the fifth trajectory correction maneuver, which was in the schedule. Then the managers went to dinner by themselves and canceled it. That's not in the report, for obvious reasons.

> > I spend in aggregate about two weeks per year -- a day here, a day
> > there -- hunting for and correcting mistakes involving units, usually
> > when somebody gives me a subprogram to incorporate into my code,
> > with arguments identified as something like "height," "latitude," and
> > "pressure." Is the height geocentric or geodetic? Is it meters, kilometers,
> > miles, average Earth radii, ...? Is the latitude geocentric or geodetic?
> > Radians or degrees? Is the pressure PSIA, PSIG, mmHg, hectopascals, bars, ...?
>
> Some seem easy, some not so easy. PSIA and PSIG are interesting. What happens
> when you add, subtract, multiply, or divide, values with PSIA and PSIG?
>
> What happens when you multiply PSIG by length or area?

The only intrinsic units in the proposal are Unitless and Radian. The relationships between all other units are your responsibility.

> > I don't think I'm alone. Does anybody else have this problem?
> > Does anybody else care about software reliability? Would anybody else like
> > to have assistance from the programming language?
> > Maybe if you spoke up, the "nobody asked us for it" excuse wouldn't
> > carry much weight.
>
> One that I have noticed some time ago, is that in physics books variables tend
> to have units, but in engineering books the units are factored out.
>
> That is, in physics you will see F=ma, where you can use appropriate units for
> any two, and the units for the third will then be defined.
>
> In engineering:
>
> F (Newtons) = m (kg) * a (m/s**2),
>
> or even
>
> F (Pounds) = m (slugs) * a *(ft/s**2)
>
> (They do it different in ChE, but I forget how.)
>
> Did you mean like the physics example, or one of the engineering examples?

The definitions of units and their relationships are your responsibility.

> It is interesting, but I think you have to go all the way though, and consider
> how it could be used.

I believe I have gone all the way through, except perhaps for units for integers, which would be a trivial addition. Different units for real and imaginary parts of complex numbers don't make sense, unless you want to prohibit multiplication and division, so I didn't propose that.

> Then, if it is too inconvenient, realize that it won't be
> used.

That is exactly why schemes based upon preprocessors and derived types are not used. I believe what I propose in ftp://ftp.nag.co.uk/sc22wg5/N1951-N2000/N1969.pdf is both easy to use and easy to implement. There is at least one project underway to develop a preprocessor, but I view it as a proof of concept and a data point on the "how much will it cost" axis, but I don't have great hopes it will be widely used.

[herrman...@gmail.com]

On Wednesday, July 6, 2016 at 10:30:23 PM UTC-7, Van Snyder wrote:

(snip regarding keeping units with variables)

(where I wrote)

> > While I might understand how it works internally, how to do I/O is
> > less obvious. Do input files now need units for each value? What happens
> > to all the old files that don't have them.

> In my proposal, units in explicitly formatted input are checked, and converted if
> necessary, if there's a "U" format descriptor. Units are produced in explicitly
> formatted output if there's a "U" format descriptor.
> Units are not produced or checked in unformatted I/O, list-directed I/O, or namelist I/O.

So you convert whatever input units to a fixed internal set, such as SI?

Then on output, you specify the units you want?

Seems that there are still enough ways to go wrong. When one converts files without
units to files with units, one can obviously use the wrong ones.

Do units propagate through intrinsic functions?

What happens to units with SQRT?

I do remember a computerized physics teaching system that I used some years
ago that required students to put units with their answers. I do remember once trying
it out, where for a velocity I put in J^0.5 kg^-0.5 and it worked. (I later found out that
there are numerical constants for all units. As it only has to compare for (close to) the
correct answer, The constants are different enough that one isn't likely to get close
if one uses the wrong units, but it is possible.

What about different units that have the same dimensions. Torques in Newton-meters, and not Joules, for example. Transformer rating in Volt-Amps that are not Watts. (For non-unity
power factor.)

[Wolfgang Kilian]

Yes, I do care about reliability.

I agree that for science applications, being able to work with units
makes sense and could be a great asset. Using units must not reduce
runtime performance in any way. Errors must be detectable at compile
time, i.e., we need constraints. It looks like that those requirements
cannot be resolved within the current language.

(Most of the functionality can be implemented in form of derived-type
operations, as mentioned in the paper -- derived-type I/O could be
finally useful -- but if the type algebra is to be open, unit
calculations would be deferred to run time.)

It looks like you have considered and resolved the typical objections
that a physisict should raise when thinking about the problem. You are
extending Fortran by a computer algebra system. This sounds a bit
scary, but as long as unit resolution is guaranteed to terminate, don't
worry ...

Assigning the task of defining all units and their relations to the user
is probably a good decision.

A few issues come to my mind. I guess that you have considered most of
this:

- Literals with units are a bit awkward, if I understand the proposal
correctly: the quantity '1 meter' has to be specified as METER(1._dp).
For the quantity '1 m/s', you would define first a new unit like M_PER_S
and then write M_PER_S (1._dp), right? Or rather METER (1._dp) / SECOND
(1._dp) ...?

I guess that a convenient shorthand syntax for literals with units (in
particular, composite units) in expressions would encourage the
acceptance of units for programmers. Maybe I'm overlooking something.
Probably it is too difficult to fiddle such a thing into Fortran syntax.

- Conversion could be available for integer arguments, say METER (1) or
METER (N) instead of METER (1._dp) or METER (REAL (N, KIND=dp)). This
would have require a KIND argument, i.e., METER (1, KIND=dp) ... so maybe.

Integer numbers with units don't make sense, if physics is to be taken
seriously, integers should be always converted to reals when units are
applied.

- Allowing units for reals but not for complex is a no-go for me. One
of Fortran's greatest advantages is that any calculation can be extended
to work with complex numbers by merely modifying the declarations, as
long as the expressions make sense. In my field (particle physics),
while user input/output is mostly reals, a large fraction of the actual
calculations is done entirely with complex numbers. If units are
available, they should not reside just at the surface.

In complex numbers, real and imaginary part always have a common unit,
of course.

- I don't see any benefit in a RADIAN intrinsic unit. It makes sense if
the coefficient is integer, because then SIN (RADIAN (360)) can be
evaluated exactly. But this is not in the proposal. In mathematics,
RADIAN is merely a fixed number. I'd rather drop it, or preferably
introduce PI or RADIAN as intrinsic real parameters (maybe via an
intrinsic module).

As noted, RADIAN numbers can be arguments to SIN, but not the result of
ASIN. (Or LOG, for that matter.)

In exponentials, you have to mix unitless numbers with numbers in
radians - if complex numbers with units are allowed. But that is
essential for the proposal to be useful, IMHO.

- In the notes (7.3a, for instance), I spot declarations such as

unit :: A, B, SQRTA=A**(1/2)

I don't find at first glance where the normative text allows the '(1/2)'
(I assume it's written somewhere.) Now, I have learned to accept the
fact that in Fortran, (1/2) evaluates to zero. But not here. Opening
another Pandora's box ...

(Actual rational numbers in Fortran would be another welcome addition.
But a completely different issue.)

- As it is also noted, the units system should work together with
parameterized derived types. That might be difficult if there are no
parameterized procedures ... It looks like units should better be
introduced in combination with a more decent system of parameterization.
Back to the discussion in the other threads.

-- Wolfgang

[Gary Scott]

Yes, I've mentioned this desire for improved support for units and
scaling several times here. It was sometimes derided as something that
a programming language shouldn't do.

[Gary Scott]

On 7/7/2016 12:30 AM, Van Snyder wrote:
> On Wednesday, July 6, 2016 at 9:36:44 PM UTC-7, herrman...@gmail.com wrote:
>> On Wednesday, July 6, 2016 at 7:08:18 PM UTC-7, Van Snyder wrote:
>
>>> We recommended that the language provide facilities for real variables to
>>> have units of measure, and that the compiler check for consistency.
>>
>> Why do INTEGER variables not need units?
>
> The requirement for that never came up in my work. I can image it might come up in, for example, finance or economics. Are units expressions consistent with Fortran rules for integer division?
>

Quite common for integers to require units/scaling, I see no difference
as to the intrinsic (numeric) type requiring this. In avionics modeling
and data processing, you're constantly having to convert from all manner
of different formats (e.g. 16 bit serial bus, perhaps 11-bit, 2-bit, any
other length sub-fields, usually big endian) to native internal
integers, with scale factors applied to achieve the correct units.

[Stefano Zaghi]

Dear Van Snyder,

Il giorno giovedì 7 luglio 2016 04:08:18 UTC+2, Van Snyder ha scritto:
> ... I don't think I'm alone. Does anybody else have this problem? Does anybody else care about software reliability? Would anybody else like to have assistance from the programming language? Maybe if you spoke up, the "nobody asked us for it" excuse wouldn't carry much weight.

You are not alone, reliability counts also for me. Indeed, in my computations (CFD) I am used to think to the non dimensional form of equations: a length is not "meters" or "feets", is just a (non dimensional) length, it obtains "dimensions" after (post-processing) the computations are done for preserving as much as possible the limited (finite precision machine) resources. Nevertheless, such a feature is very nice.

Can I add my voice to your? :-)

My best regards.

[herrman...@gmail.com]

On Thursday, July 7, 2016 at 6:33:19 AM UTC-7, Stefano Zaghi wrote:

(snip on units and software reliability)

> You are not alone, reliability counts also for me.

Seems to me that there are many causes for problems with software
other than units. I still find this strange calling it reliability, but ...

> Indeed, in my computations (CFD) I am used to think to the non dimensional
> form of equations: a length is not "meters" or "feets", is just a
> (non dimensional) length, it obtains "dimensions" after (post-processing)
> the computations are done for preserving as much as possible the limited
> (finite precision machine) resources.

There are a fair number of problems where the output comes out in units
related to the input, such that the program doesn't care.

Non-relativistic electrostatics is scale independent. The paths of electrons
scale with units, such that the results are the same. If you add magnetic fields,
they are no longer scale independent, but the scale factor only changes the
magnetic field units.

As far as reliability of software, I usually try simple problems with known
solutions. That uncovers both algorithm errors and units problems.
If you have enough, and good enough, test cases, you find most problems.

Is I noted in a previous post, it seems to me that engineering books tend
to factor out units, while physics books tend to keep them with variables.
(Not counting engineering books written by physicists, and physics books
written by engineers.)

I suspect that engineers factor out units, so they can use programming
languages (or calculators or slide rules) that don't propagate units.

Once you have all the equations with units factored out, you don't need
(or find use for) a programming language that propagates them.

Consider the ability to select between SI and Gaussian units for
electrodynamics. Some constants change, and some units change,
but you don't want to have to write two different programs for the
two cases.

I suspect physicists will want programs to be able to read in units, and
output in appropriate units. That is, dynamically propagate units though
the calculation. The OP seems to suggest static unit propagation.

> Nevertheless, such a feature is very nice.

-- glen

[jfh]

On Thursday, July 7, 2016 at 5:30:23 PM UTC+12, Van Snyder wrote:
> The conversion is never more complicated than a*X+b, where a and b are constants and a is not zero, so the conversion functions are slightly more trivial than statement functions.

There are conversions worse than a*X+b: pH = -log10([H+])

where [H+] = (hydrogen-ion concentration)/(mol/L)

I have seen many books leaving out that mol/L : log(x) and log10(x) are defined only for dimensionless x. I can do log10(1e-7) but not log10(mol/L). Similarly when teaching first-year calculus I tried, usually unsuccessfully, to get the students to say integral(1/x)dx = log(x/C) where C has the same units as x and the same sign as x. They usually wrote log(|x|)+c, which is of course wrong if x is complex, as they were surprised to find in their complex analysis course
a year or two later.

[herrman...@gmail.com]

On Thursday, July 7, 2016 at 7:05:28 PM UTC-7, jfh wrote:

(snip on pH and molarity)

> I have seen many books leaving out that mol/L : log(x) and log10(x) are
> defined only for dimensionless x. I can do log10(1e-7) but not log10(mol/L).
> Similarly when teaching first-year calculus I tried, usually unsuccessfully,
> to get the students to say integral(1/x)dx = log(x/C) where C has the same
> units as x and the same sign as x.

Calculus books are well known for getting things dimensionally wrong.

Chemists are also good at leaving out the mol/L, and, even more, that
should be gram moles (g-mol/L), but they also leave that out.

Chemical Engineers use pound-moles, that is, the amount of something
such that its mass in pounds (don't ask) equals its molecular mass in Daltons.

Some years ago, I made a spectral plot with units of BTU/pound mole
for a ChE joke.

[Stefano Zaghi]

Dear Herrman,

Il giorno giovedì 7 luglio 2016 23:19:43 UTC+2, herrman...@gmail.com ha scritto:
> Is I noted in a previous post, it seems to me that engineering books tend
> to factor out units, while physics books tend to keep them with variables.
> (Not counting engineering books written by physicists, and physics books
> written by engineers.)
>
> I suspect that engineers factor out units, so they can use programming
> languages (or calculators or slide rules) that don't propagate units.
>
> Once you have all the equations with units factored out, you don't need
> (or find use for) a programming language that propagates them.

Thank you for exposing your experience, I learned new things. In fluid dynamics we learn very soon the Buckingham theorem that is a pillar of dimensional analysis: using non dimensional form of equations has many pros, among them non dimensional numbers help to highlight the main phenomena involved and the "normalization" helps to avoid to deal with very small/high numbers in computations (that for a finite-precision calculation is important).

What I learned from your comments is that Physicists does not adopt this approach (at least widely). This is surprising for me: we that are Engineers are used (at least I am used to) to think to Physicists to (the super heros) who tell us what is better to do... we are the "oompa loompa" of Physicists, so I was sure that the practice to think into non dimensional form in Engineer was borrowed from Physics.

My best regards.

[Wolfgang Kilian]

In high-energy physics, nontrivial computations involve dimensionless
quantities (arguments of logs, hypergeometric functions, etc.), but
plain integration (of extremely complicated but rational functions)
takes dimensionful masses, momenta, energy as input and produces
dimensionful cross sections as output. Since in modern applications,
all masses are in GeV (not writing factors of c) and all cross sections
in femtobarns, there is no ambiguity. Some ambiguities arise as soon as
distances and times come into play - there, having units available in
the program might eliminate some trivial errors.

I guess that in applications such as atmosphere physics, where various
incompatible units arise, one might want to keep the units because also
the computation resembles the real world at all stages. In other
fields, unit mismatch is only a minor source of error, other problems
are more important.

-- Wolfgang

[@Stefano: accidentally sent first to PM, sorry]
--
E-mail: firstnameini...@domain.de
Domain: yahoo

[Arjen Markus]

Op vrijdag 8 juli 2016 04:05:28 UTC+2 schreef jfh:

What about a temperature correction factor of the form alpha**(T-20), where T is supposed to be in degrees Celsius and the factor itself is dimensionless? Can't think of a sensible unit for alpha (usually its _value_ is something around 1.03)

Regards,

Arjen

[Gary Scott]

i was hoping also for value range check, ability to specify MSB or LSB
value, ability to specify which subfield of bits to use, all part of a
"bit string" extended definition. I would make this all apart of an
advanced bit string definition capability, not muck up existing native
types. We can build something really useful for advanced system
programming that is broadly useful...but nothing can ever be foolproof.

[Thomas Koenig]

herrman...@gmail.com <herrman...@gmail.com> schrieb:

> Chemical Engineers use pound-moles, that is, the amount of something
> such that its mass in pounds (don't ask) equals its molecular mass in Daltons.

Not the ones in Europe (I am one), thank God.

> Some years ago, I made a spectral plot with units of BTU/pound mole
> for a ChE joke.

See https://what-if.xkcd.com/4/ .

[herrman...@gmail.com]

On Friday, July 8, 2016 at 1:02:06 AM UTC-7, Stefano Zaghi wrote:

(snip, I wrote)

> > Is I noted in a previous post, it seems to me that engineering books tend
> > to factor out units, while physics books tend to keep them with variables.
> > (Not counting engineering books written by physicists, and physics books
> > written by engineers.)

(snip)

> > Once you have all the equations with units factored out, you don't need
> > (or find use for) a programming language that propagates them.

> Thank you for exposing your experience, I learned new things. In fluid dynamics
> we learn very soon the Buckingham theorem that is a pillar of dimensional analysis:
> using non dimensional form of equations has many pros, among them non
> dimensional numbers help to highlight the main phenomena involved and
> the "normalization" helps to avoid to deal with very small/high numbers in
> computations (that for a finite-precision calculation is important).

Yes, but this is a different question.

> What I learned from your comments is that Physicists does not adopt this
> approach (at least widely). This is surprising for me: we that are Engineers
> are used (at least I am used to) to think to Physicists to (the super heros)
> who tell us what is better to do... we are the "oompa loompa" of Physicists,
> so I was sure that the practice to think into non dimensional form in
> Engineer was borrowed from Physics.

The one I wrote is about how books seem to be written.

Physics books will write the equation, and leave it up to the reader
to supply units. That might be good or bad.

If the book says: F=ma

and your mass is in kg, and acceleration in ft/s**2, you get your
force in kg ft/s**2, which is an unusual unit, but the equation
doesn't care.

If the book says F (Newtons) = m (kg) * a (m/s**2),
then you are expected to convert m and a to the specified
units before using the formula, and the result is always Newtons.

The equation might have constants, which tend to be combined.

You might have one like:

d (feet) = 16 * (t (seconds) ) **2

for objects falling due to gravity.

Note that written this way, the variables d and t don't have units.

The value of d is the distance divided by the unit (feet), and
s is the time divided by the unit (s). The units of 16 are conveniently
hidden from view.

I should find some examples from actual books.

[herrman...@gmail.com]

(snip, I wrote)

> I should find some examples from actual books.

It is probably cheating, as I found this example in a chapter on dimensional
analysis in a Fluid Mechanics book. Specifically, they tell you not to do it this
way, and don't even give the units, so as to discourage its use.

It is the Hazen-Williams formula, given in this book as:

Q = 61.9*D**2.63*(dp/dx)**0.054

where D is the pipe diameter, and (dp/dx) the pressure gradient,
and Q is the volume flow of water through the pipe.

Looking at:

https://en.wikipedia.org/wiki/Hazen–Williams_equation

they give it as D**0.63, but in that case they calculate the velocity
of water in the pipe, so you need another D**2 to get the volume.

The book calls the a "dimensionally inhomogeneous" formula, and
indicates that they are rampant in hydraulics literature.

You can see that those exponents will complicate the dimensional
analysis of this equation.

-- glen

[herrman...@gmail.com]

On Friday, July 8, 2016 at 2:51:16 AM UTC-7, Wolfgang Kilian wrote:

(snip)

> In high-energy physics, nontrivial computations involve dimensionless
> quantities (arguments of logs, hypergeometric functions, etc.), but
> plain integration (of extremely complicated but rational functions)
> takes dimensionful masses, momenta, energy as input and produces
> dimensionful cross sections as output. Since in modern applications,
> all masses are in GeV (not writing factors of c)

c=1 units, where time and length have the same dimension, are common
in special relativity. In this case, energy (GeV), momentum (GeV/c) and
mass (GeV/c**2) are all expressed as GeV.

> and all cross sections
> in femtobarns, there is no ambiguity. Some ambiguities arise as soon as
> distances and times come into play - there, having units available in
> the program might eliminate some trivial errors.

OK, so not hbar=1 units.

(snip)

-- glen

[dpb]

On 07/08/2016 12:23 PM, Thomas Koenig wrote:
> herrman...@gmail.com<herrman...@gmail.com> schrieb:
>
>> Chemical Engineers use pound-moles, that is, the amount of something
>> such that its mass in pounds (don't ask) equals its molecular mass in Daltons.
>
> Not the ones in Europe (I am one), thank God.
>

...

OTOH, being of the '60s vintage in uni, the first Intro to Chem E course
indoctrinated us on the difference between lb(m) and lb(f) and g(sub)c
to get between...while a NucE major, ChE minor and there was rarely if
ever a reference to metric all the way thru altho NucE was almost purely
so excepting for balance-of-plant, where hydraulics and thermodynamics
were still English units. I found this same convention in practice at
the reactor vendor and utilities and it remained so at least until I
migrated elsewhere by the 90s...there's precious little new plant
construction where a new convention could have arisen so I strongly
suspect it's still common practice on all existing units...

--

[herrman...@gmail.com]

On Friday, July 8, 2016 at 4:53:47 PM UTC-7, dpb wrote:

(snip, I wrote)

> >> Chemical Engineers use pound-moles, that is, the amount of something
> >> such that its mass in pounds (don't ask) equals its molecular mass in Daltons.

(Thomas wrote)

> > Not the ones in Europe (I am one), thank God.

> OTOH, being of the '60s vintage in uni, the first Intro to Chem E course
> indoctrinated us on the difference between lb(m) and lb(f) and g(sub)c
> to get between...while a NucE major, ChE minor and there was rarely if
> ever a reference to metric all the way thru

Yes, that is why the (don't ask) above.

I was in a lab with ChE people and physics people, mostly doing
physics problems. I remember discussion about g(sub)c in group
seminars, but never tried to actually figure out how to use it.

Previously, spectral absorption and emission plots used kK (kilo Keyser) for
the x axis, but I did mine in eV. Since I had to add the unit conversion anyway,
I also added kCal/mole and then BTU/pound mole. My advisor (joint appointment
between ChE and physics) thought it was pretty funny.

I believe that BTU/pound mole is often used for chemical reactions,
but not normally for absorption spectra. That is, hc/wavelength converted
to appropriate units.

> altho NucE was almost purely
> so excepting for balance-of-plant, where hydraulics and thermodynamics
> were still English units. I found this same convention in practice at
> the reactor vendor and utilities and it remained so at least until I
> migrated elsewhere by the 90s...there's precious little new plant
> construction where a new convention could have arisen so I strongly
> suspect it's still common practice on all existing units...

-- glen

[herrman...@gmail.com]

(snip, I wrote)

> I believe that BTU/pound mole is often used for chemical reactions,
> but not normally for absorption spectra. That is, hc/wavelength converted
> to appropriate units.

Interesting, if you put:

"btu per pound mole" "absorption spectrum"

into Google, one hit comes up, but the two phases aren't used together.

It seems to be from the "Professional Thermographers Association",
which presumably does some spectral analysis.

BTU per pound more is in a discussion on units.

-- glen

[herrman...@gmail.com]

On Friday, July 8, 2016 at 10:23:17 AM UTC-7, Thomas Koenig wrote:

(snip, I wrote)

> > Some years ago, I made a spectral plot with units of BTU/pound mole
> > for a ChE joke.

> See https://what-if.xkcd.com/4/ .

Pretty funny!

As for the barn unit that someone else mentioned, I always knew that it was related to
the "His aim is so bad, he couldn't hit the side of a barn" quote, but didn't actually know
where it came from.

Seems that at the beginning of research on Uranium and bombs, someone wanted a unit
that didn't make it so obvious what they were doing. The barn is about the geometric
cross section of the Uranium nucleus.

(The cross section is much bigger when you shoot a slow neutron at U235.)

So, you should be able to calculate the area of the side of a barn in barns.

-- glen

[Thomas Koenig]

herrman...@gmail.com <herrman...@gmail.com> schrieb:

> c=1 units, where time and length have the same dimension, are common
> in special relativity. In this case, energy (GeV), momentum (GeV/c) and
> mass (GeV/c**2) are all expressed as GeV.

Looks like an incomplete case of dimensional analysis to me :-)

My doctoral supervisor (a physicist) complained about engineers
who were calculating a Reynolds number to determine pressure drop
in a pipe even for laminar flow.

[Wolfgang Kilian]

The hbar=1 units (and c=1, etc., of course) are for theorists. Lengths
and times come into play when a detector is being simulated. They
better be computed in real-life units (well, in metric units, actually).

One might argue that actual detector simulation software could benefit a
lot from units integrated in the language. Many different physical
effects are involved at different stages. However, this part nowadays
is usually written in C++.

-- Wolfgang

[Jos Bergervoet]

On 7/8/2016 11:54 PM, herrman...@gmail.com wrote:
> (snip, I wrote)
>
>> I should find some examples from actual books.
>
> It is probably cheating, as I found this example in a chapter on dimensional
> analysis in a Fluid Mechanics book. Specifically, they tell you not to do it this
> way, and don't even give the units, so as to discourage its use.
>
> It is the Hazen-Williams formula, given in this book as:
>
> Q = 61.9*D**2.63*(dp/dx)**0.054
>
> where D is the pipe diameter, and (dp/dx) the pressure gradient,
> and Q is the volume flow of water through the pipe.
>
> Looking at:
>
> https://en.wikipedia.org/wiki/Hazen–Williams_equation
>
> they give it as D**0.63, but in that case they calculate the velocity
> of water in the pipe, so you need another D**2 to get the volume.
>
> The book calls the a "dimensionally inhomogeneous" formula, and
> indicates that they are rampant in hydraulics literature.

The same happens in electronics. For instance the
current in some non-linear device might be modeled
as a fitted function of the voltage:
I = V**0.347,
but that would *not* mean that the quantity I now
should have dimension Volt to the power 0.347. We
still want I simply to be Amps and V to be Volts.

So the dimensional analysis of the equations is often
not what the user wants. Things become even worse if
there is also an interactive interface, which refuses
to plot curves if it thinks (based on dimensional
analysis) that the units do not meet those at the axes.

If you're lucky you then can find the command to strip
the units from the quantities and forget about the
whole stuff.

(NB: I'm definitely not looking forward to having it
built in in any standardized programming language!)

--
Jos

[herrman...@gmail.com]

On Saturday, July 9, 2016 at 1:59:05 PM UTC-7, Jos Bergervoet wrote:

(snip, I wrote)

> > It is probably cheating, as I found this example in a chapter on dimensional
> > analysis in a Fluid Mechanics book. Specifically, they tell you not to do it this
> > way, and don't even give the units, so as to discourage its use.

> > It is the Hazen-Williams formula, given in this book as:

> > Q = 61.9*D**2.63*(dp/dx)**0.054

> > where D is the pipe diameter, and (dp/dx) the pressure gradient,
> > and Q is the volume flow of water through the pipe.

(snip)

> > https://en.wikipedia.org/wiki/Hazen–Williams_equation

(snip)

> The same happens in electronics. For instance the
> current in some non-linear device might be modeled
> as a fitted function of the voltage:
> I = V**0.347,
> but that would *not* mean that the quantity I now
> should have dimension Volt to the power 0.347. We
> still want I simply to be Amps and V to be Volts.

Yes, I believe the case above is a fitted function over the
range normally used in real systems.

> So the dimensional analysis of the equations is often
> not what the user wants. Things become even worse if
> there is also an interactive interface, which refuses
> to plot curves if it thinks (based on dimensional
> analysis) that the units do not meet those at the axes.

OK, but for another case, the current as a function of
cathode to anode voltage in a space charge limited
diode is proportional to the voltage to the 3/2 power.

The constant, called perveance, is geometry dependent.

Electrostatic are scale independent, so you can scale all
electrode by a constant factor for the same perveance.

Unlike the case above, this can be shown in theory,
with appropriate boundary conditions and Poisson's
equation. Also, it works pretty well in actual devices.

There is even a unit, Pervs, amp/volt**1.5, or more
often micropervs.

> If you're lucky you then can find the command to strip
> the units from the quantities and forget about the
> whole stuff.

> (NB: I'm definitely not looking forward to having it
> built in in any standardized programming language!)

-- glen

[herrman...@gmail.com]

On Saturday, July 9, 2016 at 1:59:05 PM UTC-7, Jos Bergervoet wrote:

(snip on units in programming)

> If you're lucky you then can find the command to strip
> the units from the quantities and forget about the
> whole stuff.

> (NB: I'm definitely not looking forward to having it
> built in in any standardized programming language!)

How about a system that is not part of the standard, and uses special comments
that give the units for appropriate variables, and are then validated just before
compile time.

REAL :: F, m, a
! **UNITS** F=Newtons
! **UNITS** a=m*s**-2
! **UNITS** m=kg

F=m*a

Then run through an external (other than the compiler) processor which parses the
Fortran statements and **UNITS** comments, verifies the units, and writes appropriate
output. Call it from a Makefile, such that it is all automatic.

This doesn't allow for I/O with units in the file, though.

Numerical (physical) constants would have to be in PARAMETER to get a name and
units attached to the name, which is always a good idea. I am not so sure how you
avoid putting in constants with the wrong units.

REAL, PARAMETER :: g
! **UNITS** g=9.8 cm*s**-2 ! comment goes here

For this to work, you have to at least be able to parse assignment statements,
not necessarily other statements.

If it worked well, and got popular, one might then propose adding it to the standard,
possibly with a different syntax.

-- glen

[FortranFan]

On Saturday, July 9, 2016 at 7:19:37 PM UTC-4, herrman...@gmail.com wrote:

> ..

>
> How about a system that is not part of the standard, and uses special comments
> that give the units for appropriate variables, and are then validated just before
> compile time.
>
> REAL :: F, m, a
> ! **UNITS** F=Newtons
> ! **UNITS** a=m*s**-2
> ! **UNITS** m=kg
>
> F=m*a
>
> Then run through an external (other than the compiler) processor which parses the
> Fortran statements and **UNITS** comments, verifies the units, and writes appropriate
> output. Call it from a Makefile, such that it is all automatic.
>

> ..

@glen,

You must be talking about CamFort: see https://github.com/camfort/camfort

and papers such as

http://www.sciencedirect.com/science/article/pii/S1877750315000563

and

http://scitation.aip.org/content/aip/journal/cise/18/1/10.1109/MCSE.2016.17

[FortranFan]

On Friday, July 8, 2016 at 5:54:18 PM UTC-4, herrman...@gmail.com wrote:

> .. I found this example in a chapter on dimensional

> analysis in a Fluid Mechanics book. Specifically, they tell you not to do it this
> way, and don't even give the units, so as to discourage its use.
>
> It is the Hazen-Williams formula, given in this book as:
>
> Q = 61.9*D**2.63*(dp/dx)**0.054
>
> where D is the pipe diameter, and (dp/dx) the pressure gradient,

> ..

>
> The book calls the a "dimensionally inhomogeneous" formula, and
> indicates that they are rampant in hydraulics literature.
>

> ..

Usually such formulae are expressed as

f = k * (x/x0)**n * (y/y0)**m * (z/z0)**o ..

where f is some fluid flow related quantity such as velocity; k has the same dimensions as f and typically has a fixed (constant) value; n, m, o are dimensionless constants fitted to some observations, and x0, y0, z0 are *characteristic* variables attaining values of unity for a given unit of measure system, usually the one used by developers of the empirical relationship involving fluid flow.

Nonetheless, what connection with "dimensionally inhomogeneous" formula do the relationships explained at the Wikipedia link on Hazen-Williams equation have? I fail to see any; my hunch is either the point made by the authors of the fluid mechanics book was something different or they got it wrong.

Anyways, I don't see any relevance of all this to the proposal by OP.

[FortranFan]

On Saturday, July 9, 2016 at 4:59:05 PM UTC-4, Jos Bergervoet wrote:

> ..

> The same happens in electronics. For instance the
> current in some non-linear device might be modeled
> as a fitted function of the voltage:
> I = V**0.347,

> ..

Would you have an example and a reference for this? What I have come across have relationships of the form:

I = I_0 * f(V/Vb)

and there are no issues with dimensional homogeneity or a lack of it. Developments in Electronics are relatively modern, meaning they have mostly come about since the practical invention of the transistor in 1947 with sufficient awareness of dimensional analysis. I'll be quite curious to learn of a "dimensionally inhomogeneous" correlation being actually used in Electronics.

[Jos Bergervoet]

On 7/10/2016 6:05 AM, FortranFan wrote:
> On Saturday, July 9, 2016 at 4:59:05 PM UTC-4, Jos Bergervoet wrote:
>
>> ..
>> The same happens in electronics. For instance the
>> current in some non-linear device might be modeled
>> as a fitted function of the voltage:
>> I = V**0.347,
>> ..
>
> Would you have an example and a reference for this?

Of course Glen already gave an example of a relation
I = c * V**p
where in theory p=1.5, which means that in practice it is
slightly different and dependent on lots of details. Which
rules out fixing it with a fixed choice of the dimension
of c. You would have to construct special objects 'c' with
different fractal dimensions for every case you encounter,
i.e. doing a lot of effort merely to satisfy a bureaucratic
system of restricting rules.

But since you prefer more modern electronics...

> ... Developments in Electronics are relatively modern,

> meaning they have mostly come about since the practical
> invention of the transistor in 1947

I suggest you skip that era as well, since the early point
contact transistors *did not even have* a mathematical
description! It was not understood why after 'formation'
the emitter-to-collector current transfer became greater
than one (whereas in a vacuum tube or FET it is exactly
one, and in a junction transistor slightly less than one).

> .. with sufficient awareness of dimensional analysis.

Awareness is not the point. Usefulness[1] is the question!

> I'll be quite curious to learn of a "dimensionally
> inhomogeneous" correlation being actually used in
> Electronics.

OK then (sorry for beating around the bushes a little.
It is good practice in this group). We will look at a
PN junction. We could look at the forward current, where
apparently you know the basic equation and we will run
in the same practical deviations from it as for the
vacuum tube. But even more interesting is the reverse
operation. We then have to describe a voltage-dependent
capacitor, e.g. by specifying its charge
Q = f(V)
The simplest step junction would give
Q = sqrt(V-Vx)
where, as you see, the function does not have a nice
dimensionless argument (as e.g. the forward current in
I=I0*exp(V/Vt)). And again, the square root will in
practice be a slightly different function, depending
on the doping profile of the junction.

Dimensional analysis will no longer give any useful
insight in such cases.

[1] Even in pure theoretical physics, the mainstream
approach is to omit the units (euphemistically denoted
as 'natural units'.) This means, as you can read:
https://en.wikipedia.org/wiki/Natural_units
that the units
"... are then typically omitted from mathematical
expressions of physical laws, and while this has
the apparent advantage of simplicity, it may entail
a loss of clarity due to the loss of information for
dimensional analysis."
So clarity is preferred over cluttering things with
some unnecessary error-correction mechanism.

--
Jos

[Thomas Koenig]

Van Snyder <w.van....@gmail.com> schrieb:

[Units in Fortran]

> I don't think I'm alone. Does anybody else have this problem?
> Does anybody else care about software reliability? Would anybody
> else like to have assistance from the programming language?
> Maybe if you spoke up, the "nobody asked us for it" excuse wouldn't
> carry much weight.

I'm late in joining this thread, but anyway...

I would very much like this kind of thing. But then, I like
MathCad very much and use it extensively, also for preparation
of Excel spreadsheets or Fortran programs when I want to get the
conversions of units right, which can be a challenge even with
SI units if people (including me :-) tend to think in quanities
like kg/h.

I have also toyed with proposing such a feature for inclusion in
gfortran, but I would have been stuck writing it myself, so... :-)

What I would prefer is something non-intrusive - for example,
you can declare a variable of dimension "length" and unit of
"centimeters", and have the compiler warn about mismatches, such
as adding centimeters and meters or centimeters and seconds.

Conversion between different units for the same dimension would
be done via functions, for example from an intrinsic module.

[fj]

I use conversion tools but they are available only during data reading.

For instance, a user may enter velocities in inch by millisecond just in joining the unit just after the number : 3.5in/ms

Our data reader translates this in SI (88.9m/s) automatically. Many units are foreseen and most combinations, including exponents are authorized.

Notice that our data reader is written in Fortran !

[robin....@gmail.com]

On Thursday, July 7, 2016 at 12:08:18 PM UTC+10, Van Snyder wrote:
> In 1976, my group was asked by DoD to review the five levels of requirements for what became Ada. We recommended that the language provide facilities for real variables to have units of measure, and that the compiler check for consistency. Col. Whittaker essentially answered "Huh? Why would a language intended explicitly for high-reliability programming need that?"
>
> In 1986 I proposed it informally for Fortran. I couldn't get funding to join X3J3, so it went nowhere.
>
> In 2004, I proposed a work item for what became Fortran 2008. Within the US ANSI/INCITS committee (J3), it was favorably received, with 2 disliking it, eight liking it, and three loving it. It was inscrutably assigned a difficulty commensurate with coarrays, and was eventually dropped from consideration in favor of projects that were considered to be easier.
>
> Starting in 2006, and several times thereafter, I proposed a work item called a "Technical Specification" (TS) as an ISO/IEC JTC1/SC22/WG5 project. A TS has a separate schedule from a standard revision. The project was rejected. I proposed it several times again, and it has been repeatedly rejected.
>
> The reasons given by the vendors are
>
> (1) it's too hard (it isn't), and
>
> (2) nobody's asked us for it directly (but the standards committees have been asked).

What about language clutter?

> Nobody has had the courage to say why they didn't like it, perhaps because they're afraid that would allow me to address the objections.
>
> We lost a $300 million project (Mars Climate Orbiter) because of a mistake involving units, that would have been caught and automatically corrected if the facilities I propose had been available and used.

There are things called code reviews for validating software.

> I spend in aggregate about two weeks per year -- a day here, a day there -- hunting for and correcting mistakes involving units, usually when somebody gives me a subprogram to incorporate into my code, with arguments identified as something like "height," "latitude," and "pressure." Is the height geocentric or geodetic? Is it meters, kilometers, miles, average Earth radii, ...? Is the latitude geocentric or geodetic? Radians or degrees? Is the pressure PSIA, PSIG, mmHg, hectopascals, bars, ...?

That should be provided as documentation in the code.
There are probably other errors in the code besides conversion of
units.

Conversion of units are topics given to beginning programmers.

> I don't think I'm alone. Does anybody else have this problem? Does anybody else care about software reliability? Would anybody else like to have assistance from the programming language? Maybe if you spoke up, the "nobody asked us for it" excuse wouldn't carry much weight.

It sounds like your problem is one of inadequate documentation
and inadequate code reviews.

Anyhow, if software reliability is the aim, Fortran is the last language
that anyone would use.

[Jos Bergervoet]

On 7/14/2016 3:03 PM, robin....@gmail.com wrote:
> On Thursday, July 7, 2016 at 12:08:18 PM UTC+10, Van Snyder wrote:

..
...

>> The reasons given by the vendors are
>>
>> (1) it's too hard (it isn't), and
>>
>> (2) nobody's asked us for it directly (but the standards committees have been asked).
>
> What about language clutter?

Very good point. Reliability is not served by featurism
in programming languages.

>> Nobody has had the courage to say why they didn't like it, perhaps because they're afraid that would allow me to address the objections.
>>
>> We lost a $300 million project (Mars Climate Orbiter) because of a mistake involving units, that would have been caught and automatically corrected if the facilities I propose had been available and used.
>
> There are things called code reviews for validating software.

In addition, there is no proof that a more complicated
language would reduce the number of errors. With this one
caught, three others might have slipped in.

This is similar to the rhetorical trick of using a loaded
question in this threads topic (using 'reliability' without
any existing proof that this would actually be the result).

--
Jos

[Richard Maine]

Jos Bergervoet <jos.ber...@xs4all.nl> wrote:

> This is similar to the rhetorical trick of using a loaded
> question in this threads topic (using 'reliability' without
> any existing proof that this would actually be the result).

Yes. I've stayed out of this discussion partly because of exactly that.
The "question" statement presumes on its surface that you don't care
about reliability if you aren't in favor of adding this particular
feature to the language. That just doesn't seem like a good starting
point for a reasoned discussion.

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[Stefano Zaghi]

Il giorno giovedì 14 luglio 2016 22:42:51 UTC+2, Richard Maine ha scritto:

Dear Richards,

the Van Snyder post did not seemed to presume nothing to me: he/she think that adding this feature to the language improves its reliability, I do not read "if if you aren't in favor of adding this particular feature to the language you do not care about reliability", this sounds like your interpretation.

For a "reasoned discussion" it could be helpful if you add your reasons in favor or not to the feature proposed by Van Snyder. As I stated above, I think that is more reliable to perform computation in non dimensional form, but my view is limited (as you know) so it could probably happen that non dimensional computations are not "viable". In such a situation the Van Snyder's proposal could help (I guess, but I cannot completely figured out how).

Anyhow, I think that learning your opinions on why this feature is bad or not can help me to change my mind. On the contrary, your interpretation of Van Snyder's "preconception" does not add any "reasons". The "rhetorical" trick claimed by Jos sounds like a "rhetorical" trick of Jos to avoid to provide the "proof" that the Van Snyder's proposal is bad. Van Snyder provided some reasons (on which I partially disagree) why he/she think this is a good feature: you do not add your reasons.

On the contrary, Robin's harsh comment is more documented. His reason about "code/syntax cluttering" is a good point that could change my mind... On the contrary, the reference to "code reviews" sounds more weak to me.

My best regards.

[Wolfgang Kilian]

On 14.07.2016 22:42, Richard Maine wrote:
> Jos Bergervoet <jos.ber...@xs4all.nl> wrote:
>
>> This is similar to the rhetorical trick of using a loaded
>> question in this threads topic (using 'reliability' without
>> any existing proof that this would actually be the result).
>
> Yes. I've stayed out of this discussion partly because of exactly that.
> The "question" statement presumes on its surface that you don't care
> about reliability if you aren't in favor of adding this particular
> feature to the language. That just doesn't seem like a good starting
> point for a reasoned discussion.
>

Point taken. Some of this seems to refer to debates that have been
going on over a long time.

I think that reliability by ('compile-time'!) redundancy should stay on
the agenda for Fortran. This doesn't imply that there is a unique
direction to take. Physical units address a particular level of
redundancy in science and engineering. One might follow a more generic
route (assertions, interfaces, contracts, ...), or a combination.
Priorities have to be set, so others may argue that the amount of
reliability by redundancy in Fortran (as available via the type and
module systems) is already sufficient.

-- Wolfgang


--
E-mail: firstnameini...@domain.de
Domain: yahoo

[FortranFan]

On Friday, July 15, 2016 at 3:31:38 AM UTC-4, Stefano Zaghi wrote:

> ..
>
> the Van Snyder post did not seemed to presume nothing to me: he/she think that adding this feature to the language improves its reliability.... Van Snyder provided some reasons (on which I partially disagree) why he/she think this is a good feature: you do not add your reasons.
>
> ..

Dear Stefano Zaghi,

A suggestion: added weight should be given to views by those who are actively coding and reduced weight to opinions of those who are not (and who are mainly indulging in barbershop noise - you may have seen the movie, Coming to America, by Ed Murphy, if not you should when you have some free time for a well-caricatured example of this.

Van Snyder has developed his proposal very well and my read is he offers full backward compatibility. Take the following simple case:

-- begin code --
real m, v, a, F
m = 1.0 ! mass
v = 1.0 ! velocity
a = 1.0 ! acceleration
F = m*v ! Force
print *, "Force = ", F
end
-- end code --

The above correct program but wrong computation is something Fortranners will ALWAYS be able to do, even if his proposal is fully implemented.

What he is after is to introduce a facility that can catch the error. It will be a great advancement for Fortran if this can be achieved comprehensively and reliably.

Now simply imagine if the following were possible (please note it is all pseudocode):

-- begin code --
module my_units_m

use, intrinsic :: ISO_FORTRAN_UNITS, only : M => MASS, L => LENGTH, T => TIME

implicit none

private

unit, public :: VELOCITY = M/T (or [ M = 1, T = -1 ] )
unit, public :: ACCELERATION :: M/T**2 (or [ M = 1, T = -2 ] )
!.. That is, specify dimensionality of new unit types from 7 foundational units described in SI system, as available in new ISO_FORTRAN_UNITS intrinsic module
!.. Note all integer exponents

..

end my_units_m
..
program p

use, intrinsic :: ISO_FORTRAN_UNITS, only : M => MASS
use my_units_m, only : V => VELOCITY, A => ACCELERATION, ..
..
implicit none

..
real(kind=xx,udim=M) :: m
real(kind=xx,udim=V) :: v
real(kind=xx,udim=A) :: a
real(kind=xx,udim=F) :: F1
real(kind=xx,udim=F) :: F2

..
F1 = m*v ! results in compiler error because it can detect the unit *dimension* mismatch

..
F2 = m*a ! Ok, compiler validates the unit *dimensionality* of the expression

..
end program p
-- end code --

The above is just pseudocode as I said. Plus it *DEPARTS* from Van Snyder's proposal; my point is the basic concept of unit of measure facility in Fortran. So I ask you to put on your imagination hat on and wonder if capabilities along such lines were possible, how profound a step forward will it be for Fortran!

And for someone who works in industry in scientific and engineering development and who finds managers and bean-counters hesitant to continue supporting Fortran due to long-term reliability and maintenance concerns, I think such a capability, if implemented correctly, will be a game changer. It will make it so much easier for folks like me to advance the use of modern Fortran further in industry.

My simple-minded read of Van Snyder's concept is that unit dimensionality of floating point variables can be handled similar to REAL KIND in Fortran. I admit I do NOT know the details. But the default is UNITLESS, so nothing needs to change for existing code. It's only for those who want to refactor existing code or write new code using such features. Sounds great to me, assuming it to be true.

Van Snyder is a brilliant computer scientist, by the way, very imaginative and forward-thinking (unlike the Luddites who frequent this forum) and the world of Fortran is lucky to have him in the camp - think of all the computer scientists who have served other languages, especially C++, and all the Fortran code base that eroded thanks to their advancement of those other languages while FORTRAN remained stagnant.

I am extremely supportive of Van Snyder's proposal, all I seek is further details and for the unit facility to be COMPREHENSIVE and EFFICIENT. The details I leave up to the standards committee.

Best Regards,

[FortranFan]

On Friday, July 15, 2016 at 7:31:28 AM UTC-4, FortranFan wrote:

> ..

>
> Now simply imagine if the following were possible (please note it is all pseudocode):
>

> ..


Oops! In my hurry, I accidentally made some basic ERRORs and omitted certain details: here's a revised version of the pseudocode which will, hopefully, be more descriptive:

-- begin code --
module my_units_m

use, intrinsic :: ISO_FORTRAN_UNITS, only : M => MASS, L => LENGTH, T => TIME

implicit none

private

unit, public :: VELOCITY = L/T (or [ L = 1, T = -1 ] )
unit, public :: ACCELERATION = L/T**2 (or [ L = 1, T = -2 ] )
unit, public :: FORCE = M*L/T**2 (or [ M = 1, L = 1, T = -2 ] )

!.. That is, specify dimensionality of new unit types from 7 foundational units described in SI system, as available in new ISO_FORTRAN_UNITS intrinsic module
!.. Note all integer exponents

..

end my_units_m
..
program p

use my_kinds_m, only : xx

use, intrinsic :: ISO_FORTRAN_UNITS, only : M => MASS

use my_units_m, only : V => VELOCITY, A => ACCELERATION, F => FORCE, ..
..
implicit none

..
real(kind=xx,udim=M) :: SomeMass
real(kind=xx,udim=V) :: SomeVel
real(kind=xx,udim=A) :: SomeAccel

real(kind=xx,udim=F) :: F1
real(kind=xx,udim=F) :: F2

..

F1 = SomeMass*SomeVel ! results in compiler error because it can detect the unit *dimension* mismatch

..
F2 = SomeMass*SomeAccel ! Ok, compiler validates the unit *dimensionality* of the expression

[Stefano Zaghi]

Dear FortranFan

> A suggestion: added weight should be given to views by those who are actively coding and reduced weight to opinions of those who are not (and who are mainly indulging in barbershop noise - you may have seen the movie, Coming to America, by Ed Murphy, if not you should when you have some free time for a well-caricatured example of this.

I viewed this film, very funny that scene, you catch me a smile :-) However, my "weights" here are all normalized to the top, I try to forget all my "preferences" because it is happened that I can learn a lot from whom I do not like very much... Your suggestion has been gotten anyway :-)

> Van Snyder ...

Very "intriguing", I was not able to figure out a Van Snyder "pseudo-implementation": yours seems very low-cluttering syntax...

> The above is just pseudocode as I said. Plus it *DEPARTS* from Van Snyder's proposal; my point is the basic concept of unit of measure facility in Fortran. So I ask you to put on your imagination hat on and wonder if capabilities along such lines were possible, how profound a step forward will it be for Fortran!

Sure, one of the weakness of the Robin's suggestion about "external code reviews" is, in my opinion, that humans are not "so good reviewers" as "compilers". If the compilers can catch such an error this could be very useful.

> My simple-minded read of Van Snyder's concept is that unit dimensionality of floating point variables can be handled similar to REAL KIND in Fortran. I admit I do NOT know the details. But the default is UNITLESS, so nothing needs to change for existing code. It's only for those who want to refactor existing code or write new code using such features. Sounds great to me, assuming it to be true.

This is a very important thing and the opinion/suggestion/implementation of Van Snyder could be very helpful here: your "kind-similarity" makes units-feature less intrusive/cluttered than what I was figuring out...

> Van Snyder is a brilliant computer scientist...

I can only give to he/she my best thanks for giving us Fortran, as well as I do with Richard and all other committee members.

> I am extremely supportive of Van Snyder's proposal, all I seek is further details and for the unit facility to be COMPREHENSIVE and EFFICIENT. The details I leave up to the standards committee.

I was skeptical about this feature, my main concerns were about cluttering the syntax for a very specific-not-so-important feature, but your pseudo code is very impressive.

My best regards.

[Anton Shterenlikht]

FortranFan <pare...@gmail.com> writes:

>On Friday, July 15, 2016 at 3:31:38 AM UTC-4, Stefano Zaghi wrote:

>module my_units_m

> use, intrinsic :: ISO_FORTRAN_UNITS, only : M =3D> MASS, L =3D> LENGTH, =
>T =3D> TIME
> implicit none
> private
> unit, public :: VELOCITY =3D M/T (or [ M =3D 1, T =3D -1 ] )
> unit, public :: ACCELERATION :: M/T**2 (or [ M =3D 1, T =3D -2 ] )

You just shot yourself in the foot.
As others have suggested, by adding units,
one adds the opportunity for making new
kinds of errors - unit errors, just as you have done.
Units might solve some problems, but will
immediately create others.
And because you made 2 errors,
you will get correct dimensionality in
some expressions, so, depending on
the rest of the code, you might not
be able to catch these errors.

Anton

[Wolfgang Kilian]

... and, please, don't confuse dimension with unit of measure.

[Ghost]

Em 06/07/2016 23:08, Van Snyder escreveu:
> In 1976, my group was asked by DoD to review the five levels of requirements for what became Ada. We recommended that the language provide facilities for real variables to have units of measure, and that the compiler check for consistency. Col. Whittaker essentially answered "Huh? Why would a language intended explicitly for high-reliability programming need that?"
>
> In 1986 I proposed it informally for Fortran. I couldn't get funding to join X3J3, so it went nowhere.
>
> In 2004, I proposed a work item for what became Fortran 2008. Within the US ANSI/INCITS committee (J3), it was favorably received, with 2 disliking it, eight liking it, and three loving it. It was inscrutably assigned a difficulty commensurate with coarrays, and was eventually dropped from consideration in favor of projects that were considered to be easier.
>

> Starting in 2006, and several times thereafter, I proposed a work item called a "Technical Specification" ( S) as an ISO/IEC JTC1/SC22/WG5 project. A TS has a separate schedule from a standard revision. The project was rejected. I proposed it several times again, and it has been repeatedly rejected.

>
> The reasons given by the vendors are
>
> (1) it's too hard (it isn't), and
>
> (2) nobody's asked us for it directly (but the standards committees have been asked).
>

> Nobody has had the courage to say why they didn't like it, perhaps because they're afraid that would allow me to address the objections.
>
> We lost a $300 million project (Mars Climate Orbiter) because of a mistake involving units, that would have been caught and automatically corrected if the facilities I propose had been available and used.
>

> I spend in aggregate about two weeks per year -- a day here, a day there -- hunting for and correcting mistakes involving units, usually when somebody gives me a subprogram to incorporate into my code, with arguments identified as something like "height," "latitude," and "pressure." Is the height geocentric or geodetic? Is it meters, kilometers, miles, average Earth radii, ...? Is the latitude geocentric or geodetic? Radians or degrees? Is the pressure PSIA, PSIG, mmHg, hectopascals, bars, ...?
>

> I don't think I'm alone. Does anybody else have this problem? Does anybody else care about software reliability? Would anybody else like to have assistance from the programming language? Maybe if you spoke up, the "nobody asked us for it" excuse wouldn't carry much weight.
>

In my work this is a nightmare. From my background, I'm used to
geometrical units, but the people from field theory like natural
units and the guys who work equations of state don't like kb=1.
Finally, the units people like to see in papers have nothing to
do with any of these. So, putting together a simulation of the
cooling of neutron stars and getting all units right is occupational
hazard. For some time I actually thought a little bit about this
in my programs. Good to hear that professional programmers contemplate
the idea as well.

[Stefano Zaghi]

Dear Anton,

Il giorno venerdì 15 luglio 2016 14:10:27 UTC+2, Anton Shterenlikht ha scritto:
> You just shot yourself in the foot.
> As others have suggested, by adding units,
> one adds the opportunity for making new
> kinds of errors - unit errors, just as you have done.

This is always true, but you should compare also the "kind" of errors: reviewing the "units API definition" could/should be more easy than review all the computations...

The reason "this feature is bad because it introduces other sources of errors" is weak for me if no further arguments are added. The introduction of "intent(out)" feature has introduced the possibility of subtle mistakes... but this was not a valid reason to avoid "intents".

The 2 errors FortranFan pseudo-code do not prove (for me) that Van Snyder's unit is so bad...

My best regards.

[FortranFan]

On Friday, July 15, 2016 at 8:10:27 AM UTC-4, Anton Shterenlikht wrote:

> ..

>
> You just shot yourself in the foot.
> As others have suggested, by adding units,
> one adds the opportunity for making new
> kinds of errors - unit errors, just as you have done.
> Units might solve some problems, but will
> immediately create others.
> And because you made 2 errors,

> ..


Wow!

Pseudocode submission on an online forum, where one is under the gun to the minimize the time one can devote while trying to also hold on to a full-time job, is not a measure of anything, OK. Even then it occurred to me something was amiss and about 20 min later, as I reached my work desk after making the post from home computer, I corrected myself - see the timeline of my posts.

And make note: unit errors are not new by any means, they have happened before and occur today too. So in the worst of circumstances, the unit facility will only work if users of such a facility ensure correct usage i.e., "dot all their i's and cross their t's" - and that's not new either. So what then, language shouldn't evolve?

Yours is a ridiculous argument, utterly baseless.

[Gary Scott]

On 7/15/2016 6:31 AM, FortranFan wrote:
snip

>
> My simple-minded read of Van Snyder's concept is that unit dimensionality of floating point variables can be handled similar to REAL KIND in Fortran. I admit I do NOT know the details. But the default is UNITLESS, so nothing needs to change for existing code. It's only for those who want to refactor existing code or write new code using such features. Sounds great to me, assuming it to be true.
>
> Van Snyder is a brilliant computer scientist, by the way, very imaginative and forward-thinking (unlike the Luddites who frequent this forum) and the world of Fortran is lucky to have him in the camp - think of all the computer scientists who have served other languages, especially C++, and all the Fortran code base that eroded thanks to their advancement of those other languages while FORTRAN remained stagnant.
>
> I am extremely supportive of Van Snyder's proposal, all I seek is further details and for the unit facility to be COMPREHENSIVE and EFFICIENT. The details I leave up to the standards committee.
>

Well, I'd prefer to not muck existing features. I'd merge this with an
advanced "design your own type" within a bit string definition (compound
definitions) feature. Much more powerful and flexible and if you're
going to do something like this, make it the most flexible feature you can.

[herrman...@gmail.com]

On Friday, July 15, 2016 at 5:10:27 AM UTC-7, Anton Shterenlikht wrote:
> FortranFan <parek...s@gmail.com> writes:

(snip)

> >module my_units_m
> > use, intrinsic :: ISO_FORTRAN_UNITS, only : M =3D> MASS, L =3D> LENGTH, =
> >T =3D> TIME
> > implicit none
> > private
> > unit, public :: VELOCITY =3D M/T (or [ M =3D 1, T =3D -1 ] )
> > unit, public :: ACCELERATION :: M/T**2 (or [ M =3D 1, T =3D -2 ] )

> You just shot yourself in the foot.
> As others have suggested, by adding units,
> one adds the opportunity for making new
> kinds of errors - unit errors, just as you have done.
> Units might solve some problems, but will
> immediately create others.

Besides the fact that there are many ways to make unreliable programs other
than units mistakes, this seems to me to be a real problem.

Having the system verify units will, unless the system is extremely good, allow
for some kinds of mistakes to get through, such that people will not be looking
for those mistakes.

That is, when people believe in a safety system, they rely on it and reduce
their otherwise cautious ways.

Anti-lock brakes are a great idea, but they don't help if they allow you to
get into unsafe situations that you would otherwise avoid if you didn't have ABS.

Reviewing a program for unit consistency also allows one to review for other
mistakes that unit check won't find. (Note, for example, that it won't catch
using the wrong variable that happens to have the right units.)

> And because you made 2 errors,
> you will get correct dimensionality in
> some expressions, so, depending on
> the rest of the code, you might not
> be able to catch these errors.

-- glen

[Gary Scott]

uh, Tesla "autopilot"
> -- glen
>

[FortranFan]

On Friday, July 15, 2016 at 9:22:41 AM UTC-4, herrman...@gmail.com wrote:

> .. when people believe in a safety system, they rely on it and reduce
their otherwise cautious ways. ..

>
> Anti-lock brakes are a great idea, but they don't help if they allow you to
> get into unsafe situations that you would otherwise avoid if you didn't have ABS.
>

> ..

@glen,

It is questionable, "when people believe in a safety system, they rely on it and reduce their otherwise cautious ways." My own experience is there are individuals, teams, etc. who are cautious and have mechanisms/work processes to make good use of whatever safety systems they have at their disposal. And there are folks and groups who are inclined not to be all that cautious. And there are some in between. The former will continue with their approach no matter what extra safety systems are provided, especially as they take on more complex tasks. The latter tend to ignore the safety nets. It doesn't mean society shouldn't build safety systems. Moreover with enough focus and investment, one can move more of the latter folks into the former. I work in chemical industry and I know; things changed dramatically post-Bhopal tragedy (https://en.wikipedia.org/wiki/Bhopal_disaster) in 1984. US chemical industry changed completely within a decade following this tragedy. And a big component of the shift was to build safety systems that everyone can rely on, in addition to change in culture and so forth. But the latter aspects rely integrally on the safety systems.

Re: anti-lock brakes (ABS), if I recall correctly 2012 Federal Law in US mandated all vehicles to have a stability control system that relies on ABS. I doubt one can even have buy a car in US now without ABS; I have not checked, but even if one could find one on the market today it won't be long before they disappear (also no one I know will even try to procure a car without ABS). ABS are thus a de facto standard feature in vehicles.

But most importantly, there is no accepted evidence the presence of ABS is causing drivers to be so reckless in driving that ABS feature should NOT be made available in cars. I simply can't imagine NHTSA in US, equivalent body in EU, etc. will be so supportive of ABS if it were to "reduce their otherwise cautious ways" of driving.

So whatever analogy you are trying to draw using ABS in the context of this thread is bogus.

[FortranFan]

On Friday, July 15, 2016 at 8:49:29 AM UTC-4, Gary Scott wrote:

> ..

> Well, I'd prefer to not muck existing features. I'd merge this with an
> advanced "design your own type" within a bit string definition (compound
> definitions) feature. Much more powerful and flexible and if you're
> going to do something like this, make it the most flexible feature you can.

Re: revision of the Fortran standard in general, I'm completely open-minded about Van Snyder's proposal on units as well as your suggestion on bit strings (and by others on generics and refinement of OO, etc). It is up to the Fortran community and the standard body to move Fortran forward for the general benefit of users.

But, immediately, on the unit-of-measure aspect, I have no idea how bit strings would help.

If you can collaborate with Van Snyder and other interested parties, especially the standard committee, on your idea about bit strings, then it will be very useful. Right now, I simply fail to see the connection with bit strings. Whereas with Van Snyder's proposal, as I said, with my limited knowledge and understanding, I can see how he's building on the KIND concept to provide compile-time checking for units.

Hence it will help if you can elaborate further on your idea.

Cheers,

[herrman...@gmail.com]

On Friday, July 15, 2016 at 7:45:27 AM UTC-7, FortranFan wrote:

(snip, I wrote)

> > Anti-lock brakes are a great idea, but they don't help if they allow you to
> > get into unsafe situations that you would otherwise avoid if you didn't have ABS.

> It is questionable, "when people believe in a safety system, they rely on it and
> reduce their otherwise cautious ways."
> My own experience is there are individuals, teams, etc. who are cautious and have
> mechanisms/work processes to make good use of whatever safety systems they
> have at their disposal. And there are folks and groups who are inclined not
> to be all that cautious. And there are some in between.
> The former will continue with their approach no matter what extra safety
> systems are provided, especially as they take on more complex tasks.
> The latter tend to ignore the safety nets.

True, but the cautious people will be extra cautious when they know that
there is no safety system. They will check five times for mistakes instead of three.

> It doesn't mean society shouldn't build safety systems.

Yes, but you figure out the real cost of the safety system, and the reduced
costs of accidents when using the system.

(I was recently reading the book "The Big Short". A big part of the story is
that people are not good at figuring out cost/benefit for very expensive event
that occur at an extremely low rate. There is a movie if you don't want to read
the book. I don't know if this explanation is in the movie, though.)

In many cases, the optimum point comes when the cost of the
safety feature equals the reduction in cost of the accidents it reduces.

If airbags cost $1 million/car, we wouldn't have them in our cars. There are
better ways to save lives at lower cost.

> Moreover with enough focus and investment, one can move more of the latter
> folks into the former. I work in chemical industry and I know; things changed
> dramatically post-Bhopal tragedy
> (https://en.wikipedia.org/wiki/Bhopal_disaster) in 1984. US chemical
> industry changed completely within a decade following this tragedy.
> And a big component of the shift was to build safety systems that everyone
> can rely on, in addition to change in culture and so forth.
> But the latter aspects rely integrally on the safety systems.

As well as I remember the story, the plant was run, including safety features,
by the Indian owned group. But with the US companies' name on it, you
can see who gets the blame.

> Re: anti-lock brakes (ABS), if I recall correctly 2012 Federal Law in US mandated
> all vehicles to have a stability control system that relies on ABS. I doubt one can
> even have buy a car in US now without ABS; I have not checked, but even if
> one could find one on the market today it won't be long before they disappear
> (also no one I know will even try to procure a car without ABS).
> ABS are thus a de facto standard feature in vehicles.

Many cars last to 20 years or more, so I suspect that there are still enough
out there. But mostly I picked it because it is an easy to see example.

For another that is currently under controversy, consider the question of
helmets for kids (say before high school) playing soccer (futbol for those in
other countries.)

https://sites.psu.edu/siowfa15/2015/11/16/soccer-concussion-helmets-beneficial-or-bogus/

http://www.kpbs.org/news/2010/feb/24/should-soccer-players-wear-head-protection/

(The articles might be for other ages, but there is at least a controversy for kids.)

Some studies show that when they have helmets, their coaches teach them, and
expect from them, more dangerous moves.

> But most importantly, there is no accepted evidence the presence of ABS is
> causing drivers to be so reckless in driving that ABS feature should NOT be
> made available in cars. I simply can't imagine NHTSA in US, equivalent body
> in EU, etc. will be so supportive of ABS if it were to "reduce their otherwise
> cautious ways" of driving.

It was many years after they became available, and they were very expensive
in the beginning, until they were on a majority of cars. As I remember, the
early ones used compressed gas, pipes to get it to the air bag, and appropriate
valves and such. All pretty expensive. Now, with sodium azide, it is much
easier to make an affordable one that works, though with the current recalls,
not quite as easy as it should be.

> So whatever analogy you are trying to draw using ABS in the context of this
> thread is bogus.

With the addition of any safety system, the optimal point moves, not to complete
reliance on the system, but not as cautious as without the system.

OK, how about something that is a bigger cause of unreliable programs,
and that most of us know well: going outside of array bounds.

In the Fortran 66 days, when compilers with bounds checking were rare,
we were good at checking each statement that referenced an array to see
if it could possibly exceed the bounds. Add IF statements where we couldn't
be sure, and where there wasn't another way to be sure. We balanced
the time spent looking over programs with the time wasted when a program
failed (especially hours into a long computation).

I suspect that compilers implementing run-time array bounds checks
improve program reliability much more than units checks do.

The OP seemed 100% sure that units checks would have saved the
spacecraft headed for mars. I am less than 100% sure.

-- glen

[Gary Scott]

I have attempted to many times over the last 20 years. Absolutely zero
interest was expressed, so it is obvious that I'm ill-equipped to market
it. Just trying to keep hope alive, keep hope alive :) units is merely
one tiny little "attribute" of many that I'd like to be able to specify
about my built up type. Yes I know that certain specifications will
have performance issues and must be accomplished in software. That's
precisely the idea.

>
> Cheers,
>

[Thomas Koenig]

herrman...@gmail.com <herrman...@gmail.com> schrieb:

> Having the system verify units will, unless the system is extremely good, allow
> for some kinds of mistakes to get through, such that people will not be looking
> for those mistakes.

You could make the same argument about bounds checking, or about using
undeclared variables. Do you recommend not using the compiler
facilities for catching those mistakes? Do you use IMPLICIT NONE?

> Reviewing a program for unit consistency also allows one to review for other
> mistakes that unit check won't find. (Note, for example, that it won't catch
> using the wrong variable that happens to have the right units.)

Reviewing a program for misspelled variables also allows one to
review for other mistakes that IMPLICIT NONE won't find. (Note,
for example, that it won't catch using wrong variables that happen
to have been declared).

[mecej4]

As others have remarked, units amount to just one minor item that affects reliability. Although units can be troublesome to some students, a properly educated scientist/mathematician/engineer ought to be able to manage units accurately and efficiently. However, if a software feature can help in reducing unit-related errors, use of the feature should certainly be encouraged.

However, I have not yet seen reasons to be enthusiastic about Van Snyder's proposal. The proposal in N1969 is about 40 pages of standard-speak, and I skimmed through it but found it tiresome. Then, I noticed that much of the same content is given in abridged form as slides in N1970. Two features created a strong negative impression:

a) In his second post in this thread, Van Snyder says "The definitions of units and their relationships are your responsibility." Does this mean, then, that each user has to develop, implement and check the definitions and relationships needed for a particular project? Would that not be a significant hurdle?

b) Slide 16 of N1970 says under "Unit Definition Statement Examples":

UNIT :: CM = 100 * METER

which can be puzzling when I look up my engineering handbook, which says "100 cm = 1 m".

I understand the train of thought that may have produced the statement: "..if L is some length, L / (1 cm) = 100 * L / (1 m)". However, I think that Van Snyder should give some advice on how to avoid such confusion.

If Van Snyder can cite a plain-scientific-English (i.e., not StandardSpeak) position paper on this topic, I should like to read it.

-- mecej4

[Dan Nagle]

Hi,

On 2016-07-16 12:06:24 +0000, Gary Scott said:

> I have attempted to many times over the last 20 years. Absolutely zero
> interest was expressed, so it is obvious that I'm ill-equipped to
> market it. Just trying to keep hope alive, keep hope alive :) units
> is merely one tiny little "attribute" of many that I'd like to be able
> to specify about my built up type. Yes I know that certain
> specifications will have performance issues and must be accomplished in
> software. That's precisely the idea.

The problem is that a units feature is not one tiny little attribute.

Every time units is proposed, the vendors rejoin that:

1. Vendors are not hearing requests for units from anyone
willing to pay for it, and

2. Implementation of units will require large amounts of resources,
said resources being taken from implementing other features,
improving efficiency, and fixing bugs.

If you think the vendors are protesting too much, ask what their motive is.
(The point being that if units really were going to make Fortran products
significantly more valuable, it would be recognizably in the vendors' interest
to implement it, thereby giving the first implementor a market advantage,
and forcing the rest to follow suit quickly.)

TTFN

--
Cheers!

Dan Nagle

[Richard Maine]

Dan Nagle <danl...@mac.com> wrote:

> Every time units is proposed, the vendors rejoin that:
>
> 1. Vendors are not hearing requests for units from anyone
> willing to pay for it, and

That's related to why I don't think much of the proposal. I don't think
it would actually do much for reliability. Part of that is because for
various reasons, I just don't see it as something that wouldl actually
get used a lot. The lack of people pushing on vendors is one indication
of that, but I'd have figured that even beforehand.

I doubt I'd have used it in any of my codes. It just doesn't reasonably
apply to an awful lot of them, and getting units wrong has just never
been a significant fraction of the errors in my code. Yes, I've heard of
one widely-publicised example of units; and there are probably a few
others that I'm not thinking of. But I just don't see it as something
that causes lots of errors in practice. And even for those cases where
it has caused errors, would having this in the language have really
helped? For a start, would it even have been used in the codes in
question? How about retrofitted into existing libraries? I'll note that
the proposal wouldn't address several of the issues that Van mentioned
as being related to units (such as having the right units, but relative
to the wrong origin or with the wrong sign - I've seen those).

In general, the default answer for new feature proposals is "no". One
doesn't actually need to justify a "no" vote. The burden of
justification lies with proposing a new feature. In this case, the cost
is pretty high, so the burden of justification is correspondingly high
and I don't see that it has been met. Citing the abstract importance of
units and some cases where units errors were made in actual code doesn't
suffice. One would also have to argue convincingly that having the
feature in the language would result in people actually using it and
consequently improving reliability in reality.

In my opinion, the lack of people pushing on vendors for such features
is a hint about how much they would actually get used.

I'll not post any more on this subject. There's already been one comment
that I am a ludite indulging in barbershop noise and that my opinions
should be discounted because I'm curently retired, so my 45 years of
experience with the language (and others) don't count for much. Yes, I
get that message. Not interested in debating it.

I will note that, although I've often found myself disagreeing with
Van's proposals (not always - I quite liked his proposal on submodules,
for example), I have always been impressed by his diligence and hard
work. He was probably one of the committee members to put the most work
into the job. (I also put a lot as editor, which took enough time that I
didn't end up with a lot left over to do much about developing many of
my own proposals). I mention that in this context just to explain that
arguing against him at length on this would take a *LOT* of work (which
I'm not prepared to do).

[herrman...@gmail.com]

On Saturday, July 9, 2016 at 8:05:44 PM UTC-7, FortranFan wrote:

(snip, I wrote)

> > How about a system that is not part of the standard, and uses special comments
> > that give the units for appropriate variables, and are then validated just before
> > compile time.

> > REAL :: F, m, a
> > ! **UNITS** F=Newtons
> > ! **UNITS** a=m*s**-2
> > ! **UNITS** m=kg

> > F=m*a

> > Then run through an external (other than the compiler) processor which parses the
> > Fortran statements and **UNITS** comments, verifies the units, and writes appropriate
> > output. Call it from a Makefile, such that it is all automatic.

(snip)

> You must be talking about CamFort: see https://github.com/camfort/camfort

No, I just made that up while writing it. But I should look at comfort.

> and papers such as

> http://www.sciencedirect.com/science/article/pii/S1877750315000563

> http://scitation.aip.org/content/aip/journal/cise/18/1/10.1109/MCSE.2016.17

I was thinking a little more about how this might work in actual problems.

Seems to me that you need a way to call a subroutine or function and explain
the results of that function.

Say you call a numerical integration routine. First, it might be a library routine
that doesn't know about units, but even more you might call it more than once.

It is easy to see that the units of the result of an integral are the product of the
units of the integrand and of the variable of integration. There needs to be
a way to tell the compiler/units processor that one is calling a function, and
this is what will happen when I call that function.

Even simpler, when you call sqrt(), the units are the square root of the units
of the argument.

One really needs to try out any proposals on real programs to see what actually
happens.

[Gary Scott]

On 7/16/2016 12:36 PM, Dan Nagle wrote:
> Hi,
>
> On 2016-07-16 12:06:24 +0000, Gary Scott said:
>
>> I have attempted to many times over the last 20 years. Absolutely
>> zero interest was expressed, so it is obvious that I'm ill-equipped to
>> market it. Just trying to keep hope alive, keep hope alive :) units
>> is merely one tiny little "attribute" of many that I'd like to be able
>> to specify about my built up type. Yes I know that certain
>> specifications will have performance issues and must be accomplished
>> in software. That's precisely the idea.
>
> The problem is that a units feature is not one tiny little attribute.

It is only one of the many that I'd like to be able to specify.
However, I didn't see it particularly useful for reliability, but
perhaps more for code clarity, self documenting code, precise and
detailed specification of the behavior of the defined/built up type.

[Dan Nagle]

Hi,

On 2016-07-16 18:12:38 +0000, Richard Maine said:

> I'll not post any more on this subject. There's already been one comment
> that I am a ludite indulging in barbershop noise and that my opinions
> should be discounted because I'm curently retired, so my 45 years of
> experience with the language (and others) don't count for much. Yes, I
> get that message. Not interested in debating it.

Sagacious experience will defeat youthful enthusiasm every time.

Your views are much appreciated (and not only when we agree).

>
> I will note that, although I've often found myself disagreeing with
> Van's proposals (not always - I quite liked his proposal on submodules,
> for example), I have always been impressed by his diligence and hard
> work. He was probably one of the committee members to put the most work
> into the job.

Second.

--
Cheers!

Dan Nagle

[herrman...@gmail.com]

On Saturday, July 16, 2016 at 1:26:53 PM UTC-7, Gary Scott wrote:
> On 7/16/2016 12:36 PM, Dan Nagle wrote:

(snip)

> > The problem is that a units feature is not one tiny little attribute.

> It is only one of the many that I'd like to be able to specify.
> However, I didn't see it particularly useful for reliability, but
> perhaps more for code clarity, self documenting code, precise and
> detailed specification of the behavior of the defined/built up type.

Without the feature, we should put a comment on each assignment
explaining the units used in that statement. Many of us aren't quite that
good, but still put them in when it isn't as obvious as it should be.

As above, comments that would allow for an automated checking pass seems
about as useful as a language feature. If it is good, people will use it.

[Jos Bergervoet]

On 7/17/2016 1:47 AM, herrman...@gmail.com wrote:
> On Saturday, July 16, 2016 at 1:26:53 PM UTC-7, Gary Scott wrote:
>> On 7/16/2016 12:36 PM, Dan Nagle wrote:
>
> (snip)
>>> The problem is that a units feature is not one tiny little attribute.
>
>> It is only one of the many that I'd like to be able to specify.
>> However, I didn't see it particularly useful for reliability, but
>> perhaps more for code clarity, self documenting code, precise and
>> detailed specification of the behavior of the defined/built up type.
>
> Without the feature, we should put a comment on each assignment
> explaining the units used in that statement.

It is easier to comment once for the programming unit:
! These routines all use natural units
or
! These routines all use SI units
or another system you want, and then for the inevitable
exceptions to use a name to clarify things, e.g.:
read *, f_MHz
after which you could use f_MHz for further work and it
still would be reasonably safe, or convert it directly:
f = f_MHz*1d6
after which the name f needs no explanation about units
at all, since it adheres to the blanket statement.

...

> As above, comments that would allow for an automated checking pass seems
> about as useful as a language feature.

Automatic checking is not possible (and the idea of
a language feature is a bad one) because the units
depend on the semantics of the code. This is way
beyound the capabilities of any automatic system.
Even the simple example given above:

f = f_MHz*1d6

Should the automatic system deduce that if f_MHz is
in Mega-Hertz, that then f is in Hertz? And then if

f_10th_harmonic = 10*f

by the same rule, f_10th_harmonic would be deduced
to be in deci-Hertz? But that is almost certainly
not the intention of the user (while the first
deduction probably is reasonable). These things
can get even more complicated if radians/second
and Hertz are both used. And for quantities where
decibels are used some more ambiguities exist.

If you only want to keep track of the dimensions
(physics meaning intended here) instead of the
exact units, you still will end up with lots of
ambiguities, as examples given in this thread have
already indicated.

The whole idea of having these things automatically
checked is impossible. It is too close to "check
for any errors, semantic or syntactic". Only the
programmers or orthers who understand the meaning
of the program can do this.

Therefore, those who care about reliability should
be against this feature.

--
Jos







Are they the same unit?
And if so, what sa

[herrman...@gmail.com]

On Sunday, July 17, 2016 at 8:58:08 AM UTC-7, Jos Bergervoet wrote:

(snip, I wrote)

> > As above, comments that would allow for an automated checking pass seems
> > about as useful as a language feature.

Maybe I didn't explain it well enough.

> Automatic checking is not possible (and the idea of
> a language feature is a bad one) because the units
> depend on the semantics of the code. This is way
> beyound the capabilities of any automatic system.
> Even the simple example given above:

> f = f_MHz*1d6

! **UNIT** f_MHz=M s**-1
! **UNIT** f=s**-1

> Should the automatic system deduce that if f_MHz is
> in Mega-Hertz, that then f is in Hertz? And then if

An automatic system could check that the expression is consistent with
the units specified for each variable.

> f_10th_harmonic = 10*f

So far, I believe the automated system should ignore variables
without a specified **UNIT**, but of course that allows for undetected
problems.

> by the same rule, f_10th_harmonic would be deduced
> to be in deci-Hertz? But that is almost certainly
> not the intention of the user (while the first
> deduction probably is reasonable). These things
> can get even more complicated if radians/second
> and Hertz are both used. And for quantities where
> decibels are used some more ambiguities exist.

> If you only want to keep track of the dimensions
> (physics meaning intended here) instead of the
> exact units, you still will end up with lots of
> ambiguities, as examples given in this thread have
> already indicated.

The OP was expecting to detect failures between metric
and English units. That won't happen if you only check
dimensions.

> The whole idea of having these things automatically
> checked is impossible. It is too close to "check
> for any errors, semantic or syntactic". Only the
> programmers or orthers who understand the meaning
> of the program can do this.

I was trying to give the OP some benefit of the doubt and see how
far it would go. There are complications, and the only way to find them
is to actually try.

> Therefore, those who care about reliability should
> be against this feature.

I have worked over the years to find and fix array bounds problems
in physics programs. Mostly units haven't been a problem
in those programs, but you never know.

If you get the units wrong by a factor such that some quantity doesn't
affect the result, it is hard to know. That is, you might not notice with
tests matching expected results.

[Gary Scott]

What is the proposed syntax for specifying the units (sorry if I missed it).

[Jos Bergervoet]

On 7/17/2016 6:15 PM, herrman...@gmail.com wrote:
> On Sunday, July 17, 2016 at 8:58:08 AM UTC-7, Jos Bergervoet wrote:
>
> (snip, I wrote)
>>> As above, comments that would allow for an automated checking pass seems
>>> about as useful as a language feature.
>
> Maybe I didn't explain it well enough.
>
>> Automatic checking is not possible (and the idea of
>> a language feature is a bad one) because the units
>> depend on the semantics of the code. This is way
>> beyound the capabilities of any automatic system.
>> Even the simple example given above:
>
>> f = f_MHz*1d6
>
> ! **UNIT** f_MHz=M s**-1
> ! **UNIT** f=s**-1

OK, your assertions in comments convey about the same
information as my naming. But I'm always worried about
comments getting out of sync with evolving code, which is
less likely for variable names (although still possible..)

>> Should the automatic system deduce that if f_MHz is
>> in Mega-Hertz, that then f is in Hertz? And then if
>
> An automatic system could check that the expression is consistent with
> the units specified for each variable.

Is the expression f = f_MHz*1d6 consistent with it?

>> f_10th_harmonic = 10*f
>
> So far, I believe the automated system should ignore variables
> without a specified **UNIT**, but of course that allows for undetected
> problems.

The programmer would intend in this case:
! **UNIT** f_10th_harmonic=s**-1
! **UNIT** f=s**-1

So if, as you write, the automatic system is to
"check that the expression is consistent" as with
the f_MHz expression, then it will disagree with
the programmer's intention.

Coders who do not really understand what a 10th
harmonic means will then be forced by their managers
to correct this "error" and thereby create a broken
code.

...

>> If you only want to keep track of the dimensions
>> (physics meaning intended here) instead of the
>> exact units, you still will end up with lots of
>> ambiguities, as examples given in this thread have
>> already indicated.
>
> The OP was expecting to detect failures between metric
> and English units. That won't happen if you only check
> dimensions.

Exactly, the proponents of checks like this will
certainly not be satisfied before everything is
checked by rules. And as proven by the example here
this is not possible.

..

> I have worked over the years to find and fix array bounds problems
> in physics programs. Mostly units haven't been a problem
> in those programs, but you never know.

It might happen, perhaps even quite often. But
those problems cannot be solved by rule checking,
whether it is built into the language or not.

Therefore, those who care about reliability should

be against such a feature.

--
Jos

[Gordon Sande]

On 2016-07-17 17:16:22 +0000, Jos Bergervoet said:

>
> ..
>> I have worked over the years to find and fix array bounds problems
>> in physics programs. Mostly units haven't been a problem
>> in those programs, but you never know.
>
> It might happen, perhaps even quite often. But
> those problems cannot be solved by rule checking,
> whether it is built into the language or not.
>
> Therefore, those who care about reliability should
> be against such a feature.

I have had the experience of using two different modelling systems that
had unit checking. (Units in the common english usage rather than the
technical dimensional analysis.) Both systems had text descriptions of
the variables, with the addition of units information. These would be
called High Level Languages rather than procedural languages like
Fortran (or C).

The first system was specified by a physicist to use SI units. By the
time it was in use it had become obvious that everything of interest for
the problem was what SI called a pure number. As such the author decided
that the effort was useless and a waste of time. There are various small
systems that solve/aid "freshman physics" problems by following the SI
specifications. With such a limited domain of use it would be quite
reasonable to think of these systems as "toy" systems intended to
explore the issues with the notions.

The second system was one which I specified for a similar problem
domain. (No surprise on either of those.) The units were just symbolic
names. The types of units that came into use was much wider than I would
have expected. There were the chemical names for the feedstocks to the
plants being modelling. There were the currencies for the differing
locations of the plants including both current and corrected for
inflation. There were differing types employee hours. There were also
the scaling units for pounds or metric tonnes. And on and on. There was
a nuisance in that one needed various conversion constants with their
curious forms as one set up the variables for the actual computations.
Since this was an add-on to to go from passive documentation to active
checking it became very useful to have a "universal" unit that would
match anything during the conversion process. Although there had been
repeated reviews of the old code there were quite a few errors found. A
common error was the use of the wrong duration in computing an interest
cost. Once the system became active there was much less effort spent on
rechecking code for mismatched units. It was necessary to have "formal"
units for the procedures that did averaging or accumulation of product
flows up to reporting periods. It would have been nice to have had the
ability to have arrays with differing units for each element of the
array but there were limits on how much effort was to be spent on
developing the units checking system. Another source of trouble were the
so called "production functions" that resulted in inhomogeneous
(dimensional) functions. They were "solved" by making them operate on
pure numbers.

A second set of issues turned out to be the order of the subscripts of
arrays. Range checking would catch some but Pascal-like ranges were just
another form of units checking and useful.

The small tidy units checking systems were of little use for the social/
physical/financial modelling that we were doing. The large untidy unit
checking systems were helpful for the problem domains that we were
doing. An obvious point is that it would have been impossible to have
given special names for the the various combinations of unit that arose.
So no "mph" shortcut for "miles/hour".

[William Clodius]

Richard Maine <nos...@see.signature> wrote:

> Jos Bergervoet <jos.ber...@xs4all.nl> wrote:
>
> > This is similar to the rhetorical trick of using a loaded
> > question in this threads topic (using 'reliability' without
> > any existing proof that this would actually be the result).
>
> Yes. I've stayed out of this discussion partly because of exactly that.
> The "question" statement presumes on its surface that you don't care
> about reliability if you aren't in favor of adding this particular
> feature to the language. That just doesn't seem like a good starting
> point for a reasoned discussion.

I had several problems with Van's posting. First was the tone you and
Jos bring up that I think is exemplified by the subject line. It easily
puts someone that does not have a "fundamental units" data type as a
priority on the defensive, and I think makes the proposal less likely to
be accepted. It disregardes language changes by the committees that
improved safety: explicit interfaces, modules, intent, requiring the
reporting of syntactic and semantic errors, improving the usefullness of
alloctables, the ISO_FORTRAN_ENV, IEE 754 compatibility, etc.

Any change in a software spec, and that is what a programming language
standard is, requires a cost benefit analysis. Van handwaves on both the
costs and the benefits.


As to the costs of not having the ficility.

He gives one example where his proposal would help, an example with such
a large upper management screw up that it comes across as likely that
there were other problems hidden by this one. An argument based on a
single outlier, however extreme, is not persuasive.

He gives unquantified anecdotes from his personal experience, indicating
that he frequently sees this problem. Anecdotes are not statistics. His
experience in a small part of NASA is very unlikely to be typical of the
"average" Fortran programer. The lack of quantification also undercuts
his argument. I know from experience that memory is verry error prone.
It tends to reinforce existing beliefs, and not overturn them. He would
help his argument if he could say that in working with N programmers he
seees this problem on average M times a year, but he doen't do that.

He notes that a Fortan module exitss that provides the facility that has
large runtime costs. In one sense that doesn't surprise me. The obvious
way to do this is to have runtime type checking, where the conversion to
keep track of different powers of uints has a runtime overhead. But I
can think of at least one way of avoiding the cost. Have two modules
with the same interfaces: one with the runtime checking for validating
the code; another where the units type is simply a wrapper for a scalar
float/double. If intermodule optimization is not sufficient to reduce
the runtime costs, put the type definitions into an include file.


As to the costs of providing the facility

He asserts without proof that it will be low cost assuming that static
analysis is always easy to implement. That is highly debatable. The type
of checking is very unusual, involving what are product types. I suspect
the runtime checking of Ada and Fortran implementations will map
straight forwardly to the static checking. NOte for example that C++
templates can provide this facility at low runtime cost, but templates
are a Turing complete language so they can do at compile time what other
facilities do at run time. He gives several examples of implementations.
It would hep his case if he had contacted the implementors of those
facilities to find out the development times and tradeoffs. Even a
summary of the number of lines used to implement them would be useful
for cost estimates.

It is a feature that strikes me as very prone to bikeshedding. It is an
easy to describe facility in its simplest form that has LOTs of possible
extensions: multiple precisions, units in IO, imperial units, cgs,
physical constants, non-linear relations, unitless units such as radians
and cycles, special units such as torr, TECU, etc. Keeping the proposal
under control so it remains low cost requires excellent management.


As to the benefits

He overstates the security this will provide. There will be times when
such a facility will have to be by passed: non-linear relations that are
often found in electronics or interfacing to non-Fortran code.

It can induce overconfidence in the face of simple errors


Cost benefit analysis by others

Note that the development teams for the language with the most public
emphasis on safety, Ada, have consistently rejected this proposal.


some implementations
Ada
<https://sourceforge.net/p/unitsofmeasurementforada/wiki/Home/>

Python
<https://www.python.org/dev/peps/pep-0484/>

C++ boost
<http://www.boost.org/doc/libs/1_55_0/doc/html/boost_units.html>

F#
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.538.964&rep=rep1&type=pdf>

Fortress
<https://www.eecis.udel.edu/~cavazos/cisc879-spring2008/papers/fortress.pdf>
(Note David Chase <https://dr2chase.wordpress.com/> worked on Fortress
and I have found him very communicative on several language issues.)

[GianLuigi Piacentini]

Van Snyder wrote:

> In 1976, my group was asked by DoD to review the five levels of
> requirements for what became Ada. We recommended that the language
> provide facilities for real variables to have units of measure, and that
> the compiler check for consistency. Col. Whittaker essentially answered
> "Huh? Why would a language intended explicitly for high-reliability
> programming need that?"
>
> In 1986 I proposed it informally for Fortran. I couldn't get funding to
> join X3J3, so it went nowhere.
>
> In 2004, I proposed a work item for what became Fortran 2008. Within the
> US ANSI/INCITS committee (J3), it was favorably received, with 2 disliking
> it, eight liking it, and three loving it. It was inscrutably assigned a
> difficulty commensurate with coarrays, and was eventually dropped from
> consideration in favor of projects that were considered to be easier.
>
> Starting in 2006, and several times thereafter, I proposed a work item

> called a "Technical Specification" (TS) as an ISO/IEC JTC1/SC22/WG5

> project. A TS has a separate schedule from a standard revision. The
> project was rejected. I proposed it several times again, and it has been
> repeatedly rejected.
>
> The reasons given by the vendors are
>
> (1) it's too hard (it isn't), and
>
> (2) nobody's asked us for it directly (but the standards committees have
> been asked).
>
> Nobody has had the courage to say why they didn't like it, perhaps because
> they're afraid that would allow me to address the objections.
>
> We lost a $300 million project (Mars Climate Orbiter) because of a mistake
> involving units, that would have been caught and automatically corrected
> if the facilities I propose had been available and used.
>
> I spend in aggregate about two weeks per year -- a day here, a day there
> -- hunting for and correcting mistakes involving units, usually when
> somebody gives me a subprogram to incorporate into my code, with arguments
> identified as something like "height," "latitude," and "pressure." Is the
> height geocentric or geodetic? Is it meters, kilometers, miles, average
> Earth radii, ...? Is the latitude geocentric or geodetic? Radians or
> degrees? Is the pressure PSIA, PSIG, mmHg, hectopascals, bars, ...?
>
> I don't think I'm alone. Does anybody else have this problem? Does
> anybody else care about software reliability? Would anybody else like to
> have assistance from the programming language? Maybe if you spoke up, the
> "nobody asked us for it" excuse wouldn't carry much weight.

Please take a look to the following post in comp.lang.ada

AICWL, GtkAda contributions, Fuzzy sets, Units GtkAda 3.14 update

and specifically to

http://www.dmitry-kazakov.de/ada/units.htm

may be someone more knowledgeable than me can chime in and pehaps be
inspired for a Fortran 'translation'.

Gigi

[campbel...@gmail.com]

I find this discussion of equating reliability to units of measure to be misplaced and futile. Is it suggested that Fortran merge with SI units or will it also include Imperial units ? This is never going to happen !
I was reading the previous link provided by Gigi, which reminded me of "t" for "ton, tonne, tons, tonnes" plus the rest of the mass mess. As if Fortran could address these problems.
Then there are all the weighting/conversion factors, such as in most engineering design standards. How could we use them in a unit conforming code ?

Lets not mix the general issue of coding reliability with a consistent system of units, which is a risk factor way down the list of significance, relating more to the formulae being used than the coding approach being adopted.

This discussion does highlight the problem of where to put boundaries on what should be included in a standard.

John

[Wolfgang Kilian]

While your points are valid, the proposal by Van Snyder does not do it
like that. If I understand it correctly, its intention is to address
precisely these points: it does not impose any system of units but
leaves this completely to the programmer or library writer. This
includes all I/O issues. What it does is to prohibit adding
incommensurate quantities (like length and weight) if commanded to do
so, and for commensurate but different units (like units of weight) it
allows you to shift all conversion to behind-the-scenes, requiring the
client code of a library to be explicit about the chosen unit whenever a
specific value enters. The use of units is never enforced by the
language. It may be enforced by the programmer himself, or by a library
writer.

Finally, all this is written thus that the compiler can do the algebra
at compile time; the only runtime operations are implicit conversions
that would have been there anyway in the code (as explicit conversions).

I think that the proposal, in form of the draft presented to the
committee, is very well worked out and does address all these problems.
The criticism is more about whether the relation between its complexity
and the benefit for the end user makes it worthwhile. Whether it
introduces more new pitfalls than it removes. It is also not obvious
that it would actually be adopted by end users. In some fields maybe,
in some fields maybe not. Various reservations in this context have
been raised elsethread.

-- Wolfgang

[Gordon Sande]

On 2016-07-26 00:00:54 +0000, campbel...@gmail.com said:

> I find this discussion of equating reliability to units of measure to
> be misplaced and futile. Is it suggested that Fortran merge with SI
> units or will it also include Imperial units ? This is never going to
> happen !
> I was reading the previous link provided by Gigi, which reminded me of
> "t" for "ton, tonne, tons, tonnes" plus the rest of the mass mess. As
> if Fortran could address these problems.
> Then there are all the weighting/conversion factors, such as in most
> engineering design standards. How could we use them in a unit
> conforming code ?

If you use a High Level Language for some application you will also
discover that
most of the interesting unit-like attributes are what the physical unit systems
consider to be pure numbers. In finance these are currencies with messy
issues like
inflation. In epidemiology and human resources these are exposure to disease or
training levels. In chemistry these are which chemical is the feedstock
or one of various
co-products. It is a help to have something proofread expressions and
"certify" that
at least one part of the subject matter is correct. Units are used for
more that
(freshman) physics although that is one of the few places where the
notion is so well
formalized with precise terminology. Another issue is that in economics
and engineering
you run into "production functions" which are not homogeous which make
unit checking
very awkward. There is also the problem of the order of subscripts on
various arrays
which sure looks likes a units problem that range checking only helps a
little bit.

[Jos Bergervoet]

On 7/15/2016 2:28 PM, Ghost wrote:

> Em 06/07/2016 23:08, Van Snyder escreveu:
>> In 1976, my group was asked by DoD to review the five levels of
>> requirements for what became Ada. We recommended that the language
>> provide facilities for real variables to have units of measure, and
>> that the compiler check for consistency. Col. Whittaker essentially
>> answered "Huh? Why would a language intended explicitly for
>> high-reliability programming need that?"
>>
>> In 1986 I proposed it informally for Fortran. I couldn't get funding
>> to join X3J3, so it went nowhere.
>>
>> In 2004, I proposed a work item for what became Fortran 2008. Within
>> the US ANSI/INCITS committee (J3), it was favorably received, with 2
>> disliking it, eight liking it, and three loving it. It was
>> inscrutably assigned a difficulty commensurate with coarrays, and was
>> eventually dropped from consideration in favor of projects that were
>> considered to be easier.
>>
>> Starting in 2006, and several times thereafter, I proposed a work item

>> called a "Technical Specification" ( S) as an ISO/IEC JTC1/SC22/WG5

>> project. A TS has a separate schedule from a standard revision. The
>> project was rejected. I proposed it several times again, and it has
>> been repeatedly rejected.
>>
>> The reasons given by the vendors are
>>
>> (1) it's too hard (it isn't), and
>>
>> (2) nobody's asked us for it directly (but the standards committees
>> have been asked).
>>
>> Nobody has had the courage to say why they didn't like it, perhaps
>> because they're afraid that would allow me to address the objections.
>>
>> We lost a $300 million project (Mars Climate Orbiter) because of a
>> mistake involving units, that would have been caught and automatically
>> corrected if the facilities I propose had been available and used.
>>
>> I spend in aggregate about two weeks per year -- a day here, a day
>> there -- hunting for and correcting mistakes involving units, usually
>> when somebody gives me a subprogram to incorporate into my code, with
>> arguments identified as something like "height," "latitude," and
>> "pressure." Is the height geocentric or geodetic? Is it meters,
>> kilometers, miles, average Earth radii, ...? Is the latitude
>> geocentric or geodetic? Radians or degrees? Is the pressure PSIA,
>> PSIG, mmHg, hectopascals, bars, ...?
>>
>> I don't think I'm alone. Does anybody else have this problem? Does
>> anybody else care about software reliability? Would anybody else like
>> to have assistance from the programming language? Maybe if you spoke
>> up, the "nobody asked us for it" excuse wouldn't carry much weight.
>>
>

> In my work this is a nightmare. From my background, I'm used to
> geometrical units, but the people from field theory like natural
> units and the guys who work equations of state don't like kb=1.
> Finally, the units people like to see in papers have nothing to
> do with any of these. So, putting together a simulation of the
> cooling of neutron stars and getting all units right is occupational
> hazard.

But isn't that purely a specification issue?

It seems to me that for the coding we must use a single
(consistent) system of units and it should be the system
that leads to the clearest readable code (as for anything
in coding, aiming at clarity is the first rule).

After that choice has been made, you can look at what the
input and output uses and encapsulate the interfacing into
some read and write routines.

In messy cases (as you describe) the code will actually
make things much clearer for all involved! Good Fortran
code is of course poetry to read, as we all know, but it
can in this case also serve the purpose of clarifying how
the equations are meant.

--
Jos

[herrman...@gmail.com]

On Tuesday, July 26, 2016 at 7:57:35 AM UTC-7, Jos Bergervoet wrote:
> On 7/15/2016 2:28 PM, Ghost wrote:

(snip on units, and using them in programming languages)

> > In my work this is a nightmare. From my background, I'm used to
> > geometrical units, but the people from field theory like natural
> > units and the guys who work equations of state don't like kb=1.
> > Finally, the units people like to see in papers have nothing to
> > do with any of these. So, putting together a simulation of the
> > cooling of neutron stars and getting all units right is occupational
> > hazard.

> But isn't that purely a specification issue?

I suppose, but it is just about always there.

People who use SI units consistently everywhere else, commonly measure
magnetic fields in gauss. The tesla is just too big for convenience.

If each problem has just one funny unit in it, then it is a lot more
work throughout the whole program to get right.

As I said a few times by now, I wouldn't mind a system that used
special forms of comments, and a separate processor. It such a
system was popular enough, that would be a reason to add it to
the standard.

> It seems to me that for the coding we must use a single
> (consistent) system of units and it should be the system
> that leads to the clearest readable code (as for anything
> in coding, aiming at clarity is the first rule).

Well, yes, but often enough that doesn't happen.

It is especially bad when a program is at the intersection
of two different scientific fields, where different units are
commonly used.

As I noted earlier, it gets interesting when US ChE units and
physics units get together, which isn't all that uncommon.

Or as someone else noted, in rocket science, which I suppose
again is a mix of ChE and physics. (I used to know people from
JPL with shirts "Well, actually I am a rocket scientist.")

Blame it on Reagan and the GOP.

Carter started a program to convert the US
to metric units. Reagan canceled that program.

It almost happened when gasoline went over $1/gallon, and it
was easier to convert pumps to liters, than to allow for more
than $1/gal in the mechanical calculator used.

> After that choice has been made, you can look at what the
> input and output uses and encapsulate the interfacing into
> some read and write routines.

And yes. Input files commonly don't have units, and when adding
them, you could easily get it wrong. Unit conversion errors could
happen before data gets anywhere near a computer.
(Well, that gets harder as there are more and more computers.)

> In messy cases (as you describe) the code will actually
> make things much clearer for all involved! Good Fortran
> code is of course poetry to read, as we all know, but it
> can in this case also serve the purpose of clarifying how
> the equations are meant.

But well commented code should normally be enough to get
it right. If not, then it could use more comments!

-- glen

[herrman...@gmail.com]

On Tuesday, July 26, 2016 at 7:03:32 AM UTC-7, Gordon Sande wrote:

(snip)

> If you use a High Level Language for some application you will also
> discover that
> most of the interesting unit-like attributes are what the physical unit systems
> consider to be pure numbers. In finance these are currencies with messy
> issues like
> inflation. In epidemiology and human resources these are exposure to disease or
> training levels. In chemistry these are which chemical is the feedstock
> or one of various
> co-products. It is a help to have something proofread expressions and
> "certify" that
> at least one part of the subject matter is correct. Units are used for
> more that

In the new movie "Ghostbusters" there are some scenes with physics
equations on a white board. One is alpha=1/137. That is about as much
as I could follow in the short time it was shown.

> (freshman) physics although that is one of the few places where the
> notion is so well formalized with precise terminology.

In undergraduate physics in general, there is much emphasis on units.

> Another issue is that in economics and engineering
> you run into "production functions" which are not homogeous which
> make unit checking very awkward.

I remember once I had some equation with units of sqrt($).

It had to do with how the cost scales with the size of some other
quantity, and happened to come out that way.

> There is also the problem of the order of subscripts on
> various arrays which sure looks likes a units problem that range
> checking only helps a little bit.

Certainly for way for programs to go wrong, units tends to be
one of the less common ways.


(snip)

-- glen

[jfh]

On Wednesday, July 27, 2016 at 2:03:32 AM UTC+12, Gordon Sande wrote:
>
> If you use a High Level Language for some application you will also
> discover that
> most of the interesting unit-like attributes are what the physical unit systems
> consider to be pure numbers. In finance these are currencies with messy
> issues like
> inflation.

True, and then there's the constantly changing exchange rates between currencies,
and the fact that the rate is different for buying or selling a given currency.

[Richard Maine]

<herrman...@gmail.com> wrote:

> (I used to know people from
> JPL with shirts "Well, actually I am a rocket scientist.")

I can sort of claim to be one. I worked more with aircraft than rockets,
but I did do enough with rockets to at least defend a plausible claim...

Except that the biggest problem is that "rocket science" is a bit of a
misnomer in the first place. To the extent that I might almost say that
seriously claiming to be one counts as proof that you aren't because
that shows you don't know what the term implies. :-)

The hard parts of building rockets that work instead of blow up are more
engineering than science. I'd say the actual science parts are pretty
easy. f=ma gets you most of the physics. Add some basic chemistry and it
seems to me like you are mostly there in terms of the science. The rest
is just a "small matter of engineering."

Unless perhaps one is talking about "advanced propulsion" concepts that
are currently closer to science fiction than reality. But when people
say "rocket scientists" they are usually talking about those who make
today's rockets rather than theorize about tomorrow's.

[herrman...@gmail.com]

On Tuesday, July 26, 2016 at 3:03:12 PM UTC-7, Richard Maine wrote:

(snip, I wrote)

> > (I used to know people from
> > JPL with shirts "Well, actually I am a rocket scientist.")

> I can sort of claim to be one. I worked more with aircraft than rockets,
> but I did do enough with rockets to at least defend a plausible claim...

Yes, I suppose that anyone who does science for NASA should qualify.

> Except that the biggest problem is that "rocket science" is a bit of a
> misnomer in the first place. To the extent that I might almost say that
> seriously claiming to be one counts as proof that you aren't because
> that shows you don't know what the term implies. :-)

> The hard parts of building rockets that work instead of blow up are more
> engineering than science. I'd say the actual science parts are pretty
> easy. f=ma gets you most of the physics. Add some basic chemistry and it
> seems to me like you are mostly there in terms of the science. The rest
> is just a "small matter of engineering."

About the same way that what most people call "Computer Science"
is actually engineering. More and more departments are renaming to
CSE, Computer Science and Engineering, and if you actually want to
do computer science, it might be in the math department.


As far as I know, the public idea of "it takes a rocket scientist"
traces back to the beginning of NASA, or the and of NACA, when many
of the test rockets exploded just after launch. (See the beginning
of "The Right Stuff".) Yes, more engineering than science.

[Stefano Zaghi]

Dear Richard and Herman,

you are obviously wrong. I am an aerospace engineer, my Ph.D. concerned research and design of Solid Rocket Motors (SRM). The multiphase, multifluid, compressible Javier-Stokes equations constitute probably one of the most complex PDE system, it involves a lot of physics. You are confusing the building of a rocket with respect its research and design activity.

My best regards.

[Jos Bergervoet]

On 7/27/2016 11:03 AM, Stefano Zaghi wrote:
> Dear Richard and Herman,
>
> you are obviously wrong. I am an aerospace engineer, my Ph.D.
> concerned research and design of Solid Rocket Motors (SRM).

Richard is just too modest! I think both you and
he are fine examples of rocket scientists.

> The multiphase, multifluid, compressible Javier-Stokes equations
> constitute probably one of the most complex PDE system, it
> involves a lot of physics.

And a million-dollar millennium problem in Mathematics
as well:
<http://www.claymath.org/millennium-problems>

Do you think it will soon be solved? (Of course
I don't expect you to give away any hints..)

--
Jos

[Stefano Zaghi]

Dear Jos,

>>Richard is just too modest! I think both you and
he are fine examples of rocket scientists.

Probably Richard is a good example, I am only an engineer.

>>>And a million-dollar millennium problem in Mathematics

as well: ...

>>>Do you think it will soon be solved? (Of course
I don't expect you to give away any hints..)

You are right, I am not up to the aim. Whenever you solve it, I will happy to do my oompa loompa work and implement your solution for you :-).

There is still not proofs of unicity and existence, but the NS laws do not know this and they work very well :-)

My best regards.

[Gary Scott]

On 7/27/2016 4:40 AM, Jos Bergervoet wrote:
> On 7/27/2016 11:03 AM, Stefano Zaghi wrote:
>> Dear Richard and Herman,
>>
>> you are obviously wrong. I am an aerospace engineer, my Ph.D.
>> concerned research and design of Solid Rocket Motors (SRM).
>
> Richard is just too modest! I think both you and
> he are fine examples of rocket scientists.

Well, there are a great many that would claim that we're all just
fossils because we still use Fortran/FORTRAN...
>

[Richard Maine]

To me, that's all enginering work. Sort of thing that was covered in the
Engineering department more than the physics department in the schools I
went to. Yes, it involves a lot of physics, but so does most
engineering. I was somewhat exagerating is describing it as all reducing
to f=ma. (Hmm. Maybe that's what you meant by saying I was wrong; in
that case, I'll buy your corection). Just like cooking involves
chemistry - sometimes moderately complicated chemistry. But it is just
using those physics principles - not so much discovering them.

Design is a major part of engineering - one of the biggest parts. In a
sense, an engineer could be thought of as doing applied science - taking
the scientific principles and making something that works based on them.
Whereas a scientist would be someone who discovered those principles.

[Dan Nagle]

Hi,

Issues such as these are why I have long considered currency conversion,
as a use-case for a units feature, to be a sure sign that
a wannabe solution is in desperate search of a big problem.

--
Cheers!

Dan Nagle

[Stefano Zaghi]

Dear Richard,

>>To me, that's all enginering work. Sort of thing that was covered in the
Engineering department more than the physics department in the schools I
went to. Yes, it involves a lot of physics, but so does most
engineering. I was somewhat exagerating is describing it as all reducing
to f=ma.

Yes, you are wrong, I suppose that this is your way to say "I was wrong", in that case I'll buy your correction :-)

>>>.. Just like cooking involves

chemistry - sometimes moderately complicated chemistry. But it is just
using those physics principles - not so much discovering them.

The usage of word like "cooking" is dismissive or even offensive. Yes, we are involved into applied science, our research field is not surely devoted to find maximum principles, but writing a list of priorities could be "dangerous", I always viewed physicists as superheroes, but chemistriers could disagree...

>>>In a
sense, an engineer could be thought of as doing applied science - taking
the scientific principles and making something that works based on them.
Whereas a scientist would be someone who discovered those principles.

In general I agree, but this is a limited view, e.g. numerics is a field where engineers add a lot of new knowledge similar to mathematichans. Obvsiously, I cannot represent the category, I am the engineer you are talking about, but such a generalization is what can be heard in a barbershop.

My best regards.

[FortranFan]

On Tuesday, July 26, 2016 at 9:51:23 AM UTC-4, Wolfgang Kilian wrote:

> ..

>
> I think that the proposal, in form of the draft presented to the
> committee, is very well worked out and does address all these problems.
> The criticism is more about whether the relation between its complexity
> and the benefit for the end user makes it worthwhile. Whether it
> introduces more new pitfalls than it removes. It is also not obvious
> that it would actually be adopted by end users. In some fields maybe,
> in some fields maybe not. Various reservations in this context have
> been raised elsethread.
>
> -- Wolfgang

A great summary.

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.

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.

But based on what I have learned of Van Snyder, his deep expertise, his long service of working on the Fortran standards and with various committees and his vision and commitment to advancing Fortran, I am highly inclined and motivated to trust his judgment on this.

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.

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. 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.

To me, units (all aspects of it including the dimensionality and the unit-of measure labeling) are at the foundation of reliable numerical computations. 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.

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.

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

..
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? 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.

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.

[Richard Maine]

FortranFan <pare...@gmail.com> wrote:

> However the "The criticism" expressed in this thread "about whether the ..

> complexity .. makes it worthwhile" is utterly vacuous...

Criticising those you disagree with as being "Ludites" and "naysayers"
engaging in "utterly vacuous" "barbershop noise" with no "technical"
content is not likely to go far in making your points. (All the quoted
terms directly from your posts on this).

Yes, as I noted before, Van has a lot of experience and long service on
the committee. As do I and several others posting here. I hesitate to
guess age, but some here at least give a contrasting impression - one of
the enthusiasm of youth untemperred by experience. There's a quote,
arguably attrbuted to Twain, which I used in my signature for many
years. In fact, it was Van who first pointed this quote out to me as
being a wittier version of a point I had made. "Good judgement comes
from experience; experience comes from bad judgement."

Estimating cost versus benefit is *ALWAYS* a fundamental part of
deciding whether to add something to the language. And there are always
more features proposed than can possibly make it in - usually by
literally orders of magnitude. I recall a list of something like a
hundred or so new features proposed for f2003, and that counted only
those that had gone far enough for someone to write up a formal
proposal. The onus of proof is always on the proposer. One doesn't
actually need justification for voting "no". If justification were
required to downvote a feature, then nothing would ever get done because
the committee's entire time would be devoted to crafting justifications
for the things it didn't do.

I'm not sure why I bother with this, as I doubt the advice will be
heeded. I just comment that the style of argumentation you are
exhibiting is not likely to be constructive. There have been cases where
I'm suspicious that the main reason for rejecting something was that
the proponent was viewed as too dificult to work with. Not that this has
been explicitly cited as a reason. One doesn't have to cite reasons; see
above. But there are times I've been suspicious of it.

Whine and castigate if you like, but my experience says that's not the
way to get things accomplished.

[herrman...@gmail.com]

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?

[herrman...@gmail.com]

On Monday, August 1, 2016 at 9:32:39 AM UTC-7, Richard Maine wrote:

> FortranFan <parek..s@gmail.com> wrote:

> > However the "The criticism" expressed in this thread "about whether the ..
> > complexity .. makes it worthwhile" is utterly vacuous...

(snip)

> Estimating cost versus benefit is *ALWAYS* a fundamental part of
> deciding whether to add something to the language. And there are always
> more features proposed than can possibly make it in - usually by
> literally orders of magnitude. I recall a list of something like a
> hundred or so new features proposed for f2003, and that counted only
> those that had gone far enough for someone to write up a formal
> proposal. The onus of proof is always on the proposer. One doesn't
> actually need justification for voting "no". If justification were
> required to downvote a feature, then nothing would ever get done because
> the committee's entire time would be devoted to crafting justifications
> for the things it didn't do.

I wonder why it is so similar in politics, with candidates making claims
that don't make any sense, and expecting them to be accepted.

Yes. And the favorite ways to get justification are to show something
working as a popular extension in some compiler, or as a feature in
another language, either one with sufficient use.

(Though I always wondered if there was really enough use for either
NAMELIST or alternate returns from subroutines to add them.)

Even after you have sufficient justification to add a feature, you need
an appropriate syntax for the feature that fits with the existing language,
and, even more, is not ambiguous.

I have suggested a form of machine readable comments, I haven't seen
much else written in a form that could be easily added directly.

I suppose it could be done with a new attribute for variables:

REAL, UNITS(kg) :: mass1, mass2

but then you need a way to add units to constants.

Only allow using PARAMETERs for constants with units?
Some might say that is always the best way.

REAL, PARAMETER, UNITS(m*s**-2) :: g=9.8

Seems to me that this could also lead to using a separate processor,
though in this case it would remove them before passing it along
to the compiler.

[nsch...@gmail.com]

On Monday, August 1, 2016 at 9:29:28 AM UTC-5, FortranFan wrote:
> To me, units (all aspects of it including the dimensionality
> and the unit-of measure labeling) are at the foundation of
> reliable numerical computations.

Perhaps, but here is another point of view: The notion of number is the foundation of all numerical computations.

Consider these examples:

a) 2 + 3 = 5

b) two apples + three apples = five apples

c) two men + three women = five people

Does c) have correct units? Would your unit-enabled Fortran program handle such a calculation?

After a child grasps the abstract notion of number, further developments in arithmetic, then the move to algebra, then calculus -- all these can be studied without any mention of physical objects such as apples, and that is one of the ways in which mathematics exhibits power and beauty.

Once a computation has been completed in terms of pure numbers, it may be useful to interpret the result in terms of physical or other concrete objects, but this need not be done every time and in every conversation or computer program.

-- NSC

[Steve Lionel]

On 8/1/2016 7:50 PM, herrman...@gmail.com wrote:
> (Though I always wondered if there was really enough use for either
> NAMELIST or alternate returns from subroutines to add them.)

NAMELIST was a popular feature introduced by IBM in the 1970s and widely
copied. (I implemented it in VAX Fortran in 1979.) I still see a lot of
use of it today.

I'm pretty sure that alternate returns were a F66 thing that were
considered bad form even by the time of F77.

--
Steve Lionel
Developer Products Division
Intel Corporation
Merrimack, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran

Refer to http://software.intel.com/en-us/articles/optimization-notice
for more information regarding performance and optimization choices in
Intel software products.

[Tim Prince]

On 8/2/2016 9:06 AM, Steve Lionel wrote:
> On 8/1/2016 7:50 PM, herrman...@gmail.com wrote:
>> (Though I always wondered if there was really enough use for either
>> NAMELIST or alternate returns from subroutines to add them.)
>
> NAMELIST was a popular feature introduced by IBM in the 1970s and widely
> copied. (I implemented it in VAX Fortran in 1979.) I still see a lot of
> use of it today.
>
> I'm pretty sure that alternate returns were a F66 thing that were
> considered bad form even by the time of F77.
>

Alternate returns were implemented in several incompatible ways in F66
compilers (which of necessity included many more useful non-standard
features). I agree with Steve, we discussed alternatives to alternate
returns back in the 66 days. I never had to try to cover them in my f66
to 77/90 semi-automatic translation schemes.
F77 introduced standardized versions of NAMELIST and alternate returns
to which programs using the previous versions of these could be
reconciled. I never saw much usage of programs which were originally
f66 and followed this reconciliation path.

[FortranFan]

On Monday, August 1, 2016 at 10:36:40 PM UTC-4, nsch...@gmail.com wrote:

> ..

>
> c) two men + three women = five people
>
> Does c) have correct units? Would your unit-enabled Fortran program handle such a calculation?
>

> ..


@NSC,

Not sure what you're getting at. The proposal by OP allows a Fortran program to continue as today if one does NOT want to do anything with UNITs. But if UNIT checking is desired by the programmer, it allows appropriate checking for consistent numerical operations in terms of units by the compiler at compile-time, giving all the flexibility to the programmer to set it up.

[Ron Shepard]

On 8/2/16 8:06 AM, Steve Lionel wrote:
> On 8/1/2016 7:50 PM, herrman...@gmail.com wrote:
>> (Though I always wondered if there was really enough use for either
>> NAMELIST or alternate returns from subroutines to add them.)
>
> NAMELIST was a popular feature introduced by IBM in the 1970s and widely
> copied. (I implemented it in VAX Fortran in 1979.) I still see a lot of
> use of it today.

Yes, of course namelist is still useful. I have used it in various
programs since the 70's, and, although it was not standardized until
f90, it was reasonably portable provided you stuck to just simple
features that were common. For example, some compilers only allowed
common and local variables, while others might also have allowed dummy
arguments.

> I'm pretty sure that alternate returns were a F66 thing that were
> considered bad form even by the time of F77.

I also have code that still uses these, and when I get around to
replacing these codes, it is going to be more verbose than it is now. In
my case, I have a set of input routines that do a common set of
operations (prompt for input, validity checks for ranges, etc.). They
all have an "error" return, an "end of input" return, a "back to
previous question" return, a "skip forward" return in addition to the
standard return where the input was acceptable. I implemented all of
those possibilities with alternate returns. When I get around to
replacing them, I will return an integer return code followed by a
select case construct in the calling routine. The existing alternate
return structure is more compact than the repeated select case
constructs, so that is why the replacement will be more verbose.

In more general situations, alternate returns are useful for writing
compact finite state machines. My input routines are an example of that
kind of programming. I would have preferred to have extended and
enhanced this capability within the language rather than making it
obsolete. For example, if you combine alternate returns with the ability
to specify the return branch with ASSIGNed statement labels, then you
can write code that is almost self documenting. But alas, ASSIGN
statements are obsolete too.

$.02 -Ron Shepard

[FortranFan]

On Monday, August 1, 2016 at 12:32:39 PM UTC-4, Richard Maine wrote:

> ..
>

> Criticising those you disagree with .. is not likely to go far in making your points. ..
> .. it was Van who first pointed.. "Good judgement comes
from experience; experience comes from bad judgement." ..

>
> Estimating cost versus benefit is *ALWAYS* a fundamental part of

> deciding whether to add something to the language. ..

>
> Whine and castigate if you like, but my experience says that's not the
> way to get things accomplished.
>

> ..



If Van Snyder's proposal (which I've nothing to do with and I have no other vested interest other than that of a coder who would use the capability if it makes it into the standard) "is not likely to go far" simply because I, just another reader of the forum, states things exactly as they are, well so be it.

What I see is Van Snyder give more public disclosure on cost-benefit analysis of his proposal than anything I can get my hands on regarding any other feature that has actually made it into the Fortran standard - due credit to him on this. He indicates costs will be low and benefits will be high; he has experience, he is highly knowledgeable, and I see no basis for anyone to question his judgment, directly or indirectly. I only decided to comment as I did on this thread until I noticed a *LOT* of the latter.

This is not about how Van Snyder titled the thread. This is clearly not about me. Nothing will be better than me being totally absent in this thread while all the other readers are actively and positively engaged in the details of the proposal and are going back and forth with creative and supportive comments to improve upon the idea.

This is all about advancing Fortran and providing "constructive" feedback on the technical aspects of the proposal to Van Snyder so he can improve/refine it by the time it is tabled for the standards committee.

[Stefano Zaghi]

Dear Richard,

Il giorno lunedì 1 agosto 2016 18:32:39 UTC+2, Richard Maine ha scritto:
>
> Criticising those you disagree with as being "Ludites" and "naysayers"
> engaging in "utterly vacuous" "barbershop noise" with no "technical"
> content is not likely to go far in making your points. (All the quoted
> terms directly from your posts on this).

In case you consider also my tone not kind, please accept my apologize.

> Yes, as I noted before, Van has a lot of experience and long service on
> the committee. As do I and several others posting here. I hesitate to
> guess age, but some here at least give a contrasting impression - one of
> the enthusiasm of youth untemperred by experience. There's a quote,
> arguably attrbuted to Twain, which I used in my signature for many
> years. In fact, it was Van who first pointed this quote out to me as
> being a wittier version of a point I had made. "Good judgement comes
> from experience; experience comes from bad judgement."

I agree, it is a good quote, but the age is not "certainty" of good judgment :-)

> Estimating cost versus benefit is *ALWAYS* a fundamental part of
> deciding whether to add something to the language. And there are always
> more features proposed than can possibly make it in - usually by
> literally orders of magnitude. I recall a list of something like a
> hundred or so new features proposed for f2003, and that counted only
> those that had gone far enough for someone to write up a formal
> proposal. The onus of proof is always on the proposer. One doesn't
> actually need justification for voting "no". If justification were
> required to downvote a feature, then nothing would ever get done because
> the committee's entire time would be devoted to crafting justifications
> for the things it didn't do.

I think this is a good workflow for the standard committee, the Fortran we have is great, thus the workflow seems to work, but here we are not there...

I think that Van Snyder have already such a detailed analysis, costs/benefits included. Here we are just in place to share our "feelings" about his proposal.

It could be very useful to learn your reasons to vote "no", e.g. I am in a "limbo": I think the more sane approach is to do perform computation in non dimensional form (using a proper set of non dimensional numbers to normalize magnitudes also), thus Van Snyder proposal has low attractive for me, but the examples of pseudo-code shown by FortraFan is very nice and a unit check could be useful. Moreover, the Hermann "comments" trick could be even less invasive. Your motivations for "no thanks" could help me to discover the other side of the moon and to learn new things... Please, do not say "no" without reasons as you could have done in the committee. Let Van Snyder and the others to critic your reasons.

> I'm not sure why I bother with this, as I doubt the advice will be
> heeded.

I stay tuned, your advice is always captured.

> I just comment that the style of argumentation you are
> exhibiting is not likely to be constructive.

On the contrary, I found FortranFan comments really constructive and helpful, e.g. he/she showed me that a unit check syntax could be not so cluttering.

> There have been cases where
> I'm suspicious that the main reason for rejecting something was that
> the proponent was viewed as too dificult to work with. Not that this has
> been explicitly cited as a reason. One doesn't have to cite reasons; see
> above. But there are times I've been suspicious of it.

I hope that the time is changing: separate the idea from who proposed it is fundamental. For example I learned a lot from Robin (Robin, please forgive me, indeed I like your "concise" style), that often uses not so kind tone. New committee members like Damian Rouson (just for citing one that I have talked with) are surely able to separate "the message from the messenger" and even a good idea coming from a troll will be considered.

> Whine and castigate if you like, but my experience says that's not the
> way to get things accomplished.

This is a bad new, your experience is great, thus even the next time(s) Van Snyder proposal will not be considered...

My best regards.

[Richard Maine]

Stefano Zaghi <stefan...@gmail.com> wrote:

> I hope that the time is changing: separate the idea from who proposed it
> is fundamental.

Ain't gonna happen when resources are finite, as they always are.
There has to be a filter and sometimes it is going to be based on the
person. Only in pretty severe cases, but it is going to happen.
(And to reiterate what I said several times before, Van is *NOT* an
example of that, at least not in the negative sense; he is well
respected to the extent that proposals from him are if anything given
extra weight.)

> For example I learned a lot from Robin.

Wow. Talk about an excellent example. If you find Robin a
plausible source, then your judgement has almost nothing in
common with mine. The short version is...

Combine

1. Often being obviously factualy wrong. I hope you didn't "learn" too
much from him and assume that what you learned was all correct.

2. Refusing to admit to even the most trivial and obvious of errors,
leading to long and pointless debates unless the opposition just shuts
up.

3. Various rhetorical games too numerous to list. Answering a completely
different question than the one asked. Inventing his own definitions of
common terms..........

4. Weren't you talking about good citations? Or maybe that was someone
else here. Robin's most common citation style is one of "because I said
so and I'm smarter than you", "you ought to be able to fine one
yourself", and other simillar variants. Reminds me of Trump. :-(
I'll grant they do tend to be concise, but "Is so" or "is not" doesn't
make for much of a convincing point outside of a playground.

Sorry, but no, I don't consider Robin to be a plausible source for
anything, and I've devoted *FAR* more of my life to reading his posts
than they deserve. Including, no, I didn't bother to read his posts in
this thread. Maybe he actually said something useful. It does happen.
But nope, he doesn't get any more of my time to sort out what might be
useful. Quota exceeded. And before you ask, no, third party requests for
me to comment in detail on his posts aren't going to make it happen
either.

P.S. I'm far from the only one.

[Gary Scott]

I mostly tune in to read you, including the occasional dustups...

[herrman...@gmail.com]

On Tuesday, August 2, 2016 at 12:24:59 PM UTC-7, Stefano Zaghi wrote:

(snip)

> This is a bad new, your experience is great, thus even the next time(s) Van Snyder
> proposal will not be considered...

I have made two suggestions about ways to implement a unit checking system,
which pretty much got no responses.

If someone really is interested, they should start implementing one.

As well as I know, pretty much all new features added to the standard have
been tested in some way before adding them. The best way is implemented as
an extension in a compiler, better if it gets a lot of use.

The two suggestions I made could be implemented separate from a compiler,
making it all easier. (Note that the first C++ compiler was a preprocessor for
a C compiler, generating compilable C code.)

It always seems suspicious to me when someone suggests something is
easy to implement, should be added to the standard, but doesn't do any
of the work of actually implementing anything.

-- glen

[Ian Harvey]

On 2016-08-03 11:13, herrman...@gmail.com wrote:
...

> As well as I know, pretty much all new features added to the standard have
> been tested in some way before adding them. The best way is implemented as
> an extension in a compiler, better if it gets a lot of use.

To the contrary, I can only think of a select few cases (coarrays and
internal procedures as actual arguments), where features added via
technical reports or changes to the base standard were preceded by
implementation.

I don't have access to every Fortran compiler that ever existed, so
there will be others I've missed, but I think a far more accurate
statement is that "most features introduced via technical report or
change to the base standard since Fortran 95 have not been tested via
implementation, prior to publication".

Features introduced via technical report are a useful half way house.
If you exclude those from the statement above, then there are a few more
cases - support for the stuff introduced in the two TS's that are going
into F2015 is leading the standard, and historically I think the
implementation of the allocatable TR lead F2003.

But even if you excluded TR's from the statement above, for Fortran 2003
in particular the statement above would still be rather accurate.
Fortran 2003 brought huge changes.

It would be "nice" if both testable implementations of proposals were
available, and those implementations got lots of testing, but some
perspective is required around the motivation for a "vendor" to provide
an experimental implementation, and the motivation for lots of
programmers to write non-conforming code that uses those extensions.

A testable implementation would certainly help reduce the uncertainty
around the true costs and benefits of a proposal.