Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

“Physical” or “Engineering” Units of Measure #50

Open
certik opened this issue Oct 27, 2019 · 32 comments
Open

“Physical” or “Engineering” Units of Measure #50

certik opened this issue Oct 27, 2019 · 32 comments
Labels
Clause 8 Standard Clause 8: Attribute declarations and specifications

Comments

@certik
Copy link
Member

certik commented Oct 27, 2019 •
edited

Extracted from #49. Author: Van Snyder

Introduction

The proposal for which authorization to proceed as an ISO Technical Specification was requested
in June 2016 was N2113.

Incorrect use of physical units is a common error in scientific or engineering software. Other
common errors are mismatching the types of actual and dummy arguments, and subscript
bound violations. Explicit interfaces largely solve the latter problems, but do nothing directly
for the former. (One can use derived types to provide a physical units system, at the expense
of redefining intrinsic functions, operations, and assignment, for all combinations of units – a
tremendous job for mechanics, saying nothing about thermodynamics, electronics, ... – and then
you hope for inlining. If done using type parameters or integer components, it can distinguish
length from time, but not kilograms from pounds.) A particularly expensive and embarrassing
example was the loss of the Mars Climate Orbiter. The loss resulted because the NASA contract
required small forces, e.g. from attitude-control maneuvers, to be reported in Newton-Seconds,
but Lockheed nonetheless reported them in Pound-Seconds. (This was quite inscrutable, as
Lockheed had had NASA contracts for over thirty years, and they always specified SI units.)

Proposal

Define a new UNIT or MEASURE attribute or type parameter (call it what you will) that
can be specified for any numeric variable or named constant. Literal constants are unitless.

Define multiplication and division operations on units. Exponentiation by an integer constant
could be defined to be equivalent to multiplication or division. Square root, or maybe even
exponentiation of a unit by a rational number, would be useful. In the context of a unit
definition, the integer literal constant 1 is considered to be the unitless unit.

Each unit declaration creates one or more generic units conversion functions having the same
name as the unit, that takes an argument with any related unit, and converts it to have units
specified by the name of the function. It also creates a function that casts unitless values to
have the specified unit. There is an intrinsic UNITLESS conversion function.

Quantities can be added, subtracted, assigned, compared by relational operators, or argument
associated only if they have equivalent units. Atomic units, i.e. units that are not defined in
terms of other units, are equivalent by name. Other units are equivalent by structure.

When quantities are added or subtracted, the units of the result are the same as the units of
the operands. When quantities are multiplied or divided, the units of the result are the units
that result from applying the operation to the operands’ units. Multiplication or division by a
unitless operand produces a result having the same units as the other operand.

Units participate in generic resolution.

Procedure arguments and function results can have abstract units. This allows enforcing a
particular relationship between the units, without requiring particular units. For example, the
SQRT intrinsic function result has abstract units A, and its argument has abstract units A*A.
Abstract units do not participate in generic resolution.

Define an intrinsic RADIAN unit, and a parallel set of generic intrinsic trigonometric functions
that take RADIAN arguments and produce unitless results. All of the remaining intrinsic
procedures have arguments with abstract units and results that are unitless (e.g. SELECTED -
INT KIND) or have the same units as their argument (e.g. TINY). Because function results do
not participate in generic resolution, it is not possible to have a parallel set of generic intrinsic
inverse trigonometric functions that return RADIAN results. It may be useful to provide an
intrinsic module that has some public units and procedures, e.g. units TICK and SECOND and
a SYSTEM CLOCK module procedure that has arguments with units TICK, TICK/SECOND
and SECOND.

Variables are declared to have units by specifying UNIT(unit-name) as an attribute in their
declarations, or alternatively by separate UNIT declaration statements.

Examples:

UNIT :: INCH, SECOND
UNIT :: CM, INCH = 2.54 * CM
UNIT :: CM_PER_INCH = CM / INCH
REAL, PARAMETER, UNIT(CM_PER_INCH) :: CONVERT = 2.54
UNIT :: SQINCH = INCH * INCH ! or INCH ** 2
UNIT :: IPS = INCH / SECOND, FREQUENCY = 1 / SECOND ! or SECOND ** (-1)
REAL, UNIT(SQINCH) :: A
REAL, UNIT(FREQUENCY) :: F
REAL, UNIT(INCH) :: L, L2
REAL, UNIT(CM) :: C
REAL, UNIT(SECOND) :: T
REAL, UNIT(IPS) :: V

V = A + L              ! INVALID -- SQINCH cannot be added to INCH,
                       ! and neither one can be assigned to IPS
V = IPS(A + SQINCH(L)) ! VALID -- I’m screwing this up intentionally
V = (A / L + L2) / T   ! VALID -- IPS is compatible with INCH / SECOND
A = L * L2             ! VALID -- SQINCH is compatible with INCH * INCH
F = V / L              ! VALID -- units of RHS are 1/SECOND
C = CONVERT * L        ! VALID -- CM / INCH * INCH = CM
C = CM(L)              ! VALID -- Clearer than the previous statement
L = SQRT(A) * 5.0e-3   ! VALID -- exercise for reader

Full Proposal

A full proposal, cast as a TS, by Van Snyder: Units-TR-19.pdf
@certik certik mentioned this issue Oct 27, 2019
Open
@jacobwilliams
Copy link

I haven't studied the details of this proposal, but I know that built-in units would be an amazing feature for engineering applications.

As an aside, I think the only software I've ever used that had this was Mathcad, which in school was incredible for doing engineering homework problems. I do think the committee should certainly be thinking about how to get students to want to use Fortran, rather than only focusing on HPC people. This could certainly be one feature that could do that.

@sblionel
Copy link
Member

Van's proposal has been repeatedly and thoroughly considered by WG5 and found wanting. It didn't help that "units" would not have avoided the problem that Van kept offering as an example of why it would be useful.

I would have to say that this proposal has been poisoned, and is unlikely to gain any traction. At the very least, WG5 (and not just J3) wanted to see a trial implementation using derived types and defined operators to see how it would work in real life. That never happened despite multiple requests over years.

@jacobwilliams
Copy link

See also from @szaghi: https://github.com/szaghi/FURY

@certik
Copy link
Member Author

certik commented Nov 30, 2019

@sblionel this proposal is a prime example why we need to discuss things publicly (for example here). The committee has rejected this repeatedly before my time on the committee, and I can't find any technical discussion why it was rejected. That is very inefficient. Let's use this opportunity to document the arguments.

It didn't help that "units" would not have avoided the problem that Van kept offering as an example of why it would be useful.

It looks like based on the article you sent that a lot more went wrong, but it did start with the wrong units. Given that this example is given in the motivation of this proposal, I would like to know the answer to these questions:

Was the navigation system written in Fortran?

If Fortran had units support and units were used in the navigation system, would it actually catch this particular error?

(I can easily imagine that it wouldn't, if the two modules communicated in some way that the units, as proposed in this proposal, would not actually catch it.)

At the very least, WG5 (and not just J3) wanted to see a trial implementation using derived types and defined operators to see how it would work in real life.

It looks like that's been done: https://github.com/szaghi/FURY, as @jacobwilliams mentioned.

However, I would prefer this to be part of the language, determined at compile time (with no runtime overhead), not implemented using derived types, checked at runtime.

@certik
Copy link
Member Author

certik commented Nov 30, 2019 •
edited

I would have to say that this proposal has been poisoned, and is unlikely to gain any traction.

I believe very strongly that no Fortran feature should be "poisoned" (by a single person?) that we cannot even discuss it. I strongly suggest we discuss features on their technical merits and document arguments for and against. Being "poisoned" is not a technical argument.

However, tt is useful to know that the committee repeatedly discussed this and that they might be "allergic" to seeing this again. And so if we are going to bring this up again, we better have solid arguments and address every single objection that the committee had. (It does not help that the committee did not write down the objections, but let's fix that from now on by documenting all objections to a given proposal.)

@everythingfunctional
Copy link
Member

I actually have an implementation of this here.

@acferrad
Copy link

acferrad commented Dec 27, 2019 via email

@everythingfunctional
Copy link
Member

Thanks @acferrad . I had trouble choosing what to use as the base for mass, because it seemed when I looked that both conversion factors were published by NIST and were inconsistent. Similar thing with calories and BTU, multiple, inconsistent conversion factors.

@klausler
Copy link

I think that the important aspect of this feature is the language support for having a concept of units as an attribute of types (just REAL?), having the compiler combine units correctly on multiplication and division and (some) powers, and check them on addition, subtraction, assignment, argument association, &c. The actual names of the units and their conversion factors could come from intrinsic or library modules, and in the latter case, the Fortran language would not be responsible for determining their values.

@nncarlson
Copy link

The actual names of the units and their conversion factors could come from intrinsic or library modules, and in the latter case, the Fortran language would not be responsible for determining their values.

Definitely should be the latter. The standard has no business mandating a set of names or conversion factors. Simply providing an abstract unit capability should be the goal.

@acferrad
Copy link

Definitely should be the latter. The standard has no business mandating a set of names or conversion factors. Simply providing an abstract unit capability should be the goal.

Totally agree. Therefore, in this implementation of what would become a Fortran standard, the names and constants should be removed from the project, and stored in an external file or project. The Fortran standard would then need to have some way of accessing it.

@everythingfunctional
Copy link
Member

I don't think this is something that should be part of the language. I agree that it is something that should be done and used in new code wherever possible, just not as part of the language. I've seen several libraries trying to deal with units, and they all take different approaches to dealing with what are not entirely orthogonal or entirely compatible problems. Those being:

  • keeping track of the units associated with a value
  • prevent passing values of one quantity where a value of a different quantity is expected
  • keeping conversions between units consistent throughout a code base
  • formatting output to include units
  • allowing math to be done while keeping track of units
  • allowing SI prefixes to be used and understood when dealing with units
  • allowing user inputs to specify units

I've taken what I think is a pretty good shot at creating a library, as I mentioned above, but I think even that reveals some bugs, inconsistencies or missing features that would likely show up in trying to put something like this in to the standard. Not the least of which being that conversion factors between units aren't always simple. Think Celsius to Fahrenheit.

I don't think I've seen a sufficiently self consistent, bug free, feature complete way of dealing with units in any language. And so I would not recommend trying to make it part of the Fortran standard.

@klausler
Copy link

I don't think I've seen a sufficiently self consistent, bug free, feature complete way of dealing with units in any language. And so I would not recommend trying to make it part of the Fortran standard.

The implementation of units on the HP-48 programmable calculator is worth studying.

@certik
Copy link
Member Author

certik commented Dec 30, 2019 •
edited

@everythingfunctional I agree that something like this requires a complete implementation first, and real usage before even thinking of putting this into the standard. I looked at your implementation and it seems that creating values with units is as easy as 1.0d0.unit.METERS. But how do you actually use it, say an array of quantities? Can you add some documentation and post here? Does it require to define the array of derived types? Or just reals. I read through your tests, but it is still not clear. Looking at one such test: https://gitlab.com/everythingfunctional/quaff/blob/b515ae79fa0d68d44d25aefdc103234a760a5d54/tests/speed_test.f90#L31, it seems it requires to define density and density_?

The advantage of figuring out how to put this into the language itself is that one might define just regular arrays of real numbers (i.e., no derived types) and assign units to it with some syntax, and the compiler will check the units at compile time with no runtime overhead, and the natural already familiar syntax.

I agree this would require a prior compiler implementation and usage in real codes to see if this is worth putting into the language.

@everythingfunctional
Copy link
Member

@certik , each quantity is it's own type. So the expression 1.0d0.unit.METERS is of type Length_t. And thus, if you wanted an array of densities, you would define one like type(Density_t) :: densities(5). It's possible add and subtract quantities of the same type, multiple and divide a quantity by a scalar, and dividing quantities of the same type returns a double precision. Quantities of the same type can also be compared with the normal operators. Additionally, each of the functions to divide or multiply different quantities is implemented specifically to return the correct resulting quantity. I.e. (1.0d0.unit.METERS) / (1.0d0.unit.SECONDS) == (1.0d0.unit.METERS_PER_SECOND) is valid and true. Additionally, all of the procedures are elemental, so you can do matrix math as well.

There is clearly some run time cost associated with this approach (about 3x cost to multiply 2 numbers as shown by my tests). But I find that to be acceptable in most instances given the added safety and convenience it brings. And if you're doing really performance sensitive stuff, the internal values are stored in SI units and are public so you can mitigate the slow down even further if need be.

With full compile time checking I'm not sure you could make this valid and extensible with new units.

lengths(1:3) = [1.0d0.units.METERS, 1.0d0.units.FEET, 1.0d0.units.MICROMETERS]

But it works perfectly with my library. And it's possible to add new units and even quantities without actually needing to make any changes to the original library. If you want to use furlongs per fortnite for speed in your code, you just need to define a conversion factor from meters and a symbol somewhere in your code and it will work just fine.

@epagone epagone mentioned this issue Jan 4, 2020
Open
@magicmouse
Copy link

Mr. Snyder's specification has proved very useful, as of 2021 i am aware of various languages that fully support physical units of measure. At compile time only there is F# and Cambridge FORTRAN. For a full implementation, including user defined units of measure, and carrying the exponents of the fundamental quantities at runtime, you have Frink language (www.frinklang.org), and Beads (www.beadslang.org). Frink is the supreme king of Units. Beads is a general purpose graphical interactive language that emits web apps, etc., and includes a layout model and event management in the language.

@urbanjost
Copy link

pre-f90 working with a large number of projects scattered around the world we found almost all the unit issues were bound with input and output of values (including graphics) and basically make the Unix units(1) command into a subroutine and created a standard portable self-describing file format that required a unit code, and a routine called relate(3f) that would do y=mx+b conversions along with labels for each defined unit that was used as a default for labeling, particularly on plots. So a user could specify the units he wanted a plot in and everything would be automatically converted, for example. There was a built-in relate default table of a few thousand entries, and a "blessed" file with several thousand more relationships. We found in our case most unit-related issues were not in the codes doing computation so much as the routines delivering the data between programs from different departments and labs. We often wished there was something built into the language (almost all Fortran, some Ada PL/1, pascal,...) What we found in our particular case more of an issue at the coding level was uncertainty and accumlated floating point error issues; I remember the consensus was that would still be solved by hardware support at the processor level -- what ever happened to that? Think it would be great if Fortran supported units whether by types or casting or ... but that does not necessarily solve the primary issues we saw that involved input and output. Would these solutions provide some kind of labeling of data? I am glad XML was not around in the scientific world at the time or we might have tried that.

@vansnyder
Copy link

I disagree with Steve (@sblionel) that the units proposal has been "repeatedly and thoroughly considered." I gave a brief presentation at the 2005 Delft meeting. Malcolm and Lawrie made some comments that resulted in changes. The consensus was that this was a reasonable idea but couldn't be fit into the development schedule. I tried to bring it up for discussion at later meetings but there was no discussion. I tried to elicit discussion in e-mail but that also did not happen. I proposed to develop a non-binding TS, but WG5 voted against submitting an essentially-completed document for publication, and refused to discuss reasons for that rejection. No one has provided concrete technical objections to the proposal. No one has pointed to a section or paragraph and remarked "this cannot work" or "this cannot be done." The objections have been the difficulty to fit it into the development schedule, or the effort required by vendors to implement it. I believe the effort, on either score, would be significantly less than coarrays or interop.

At meeting 167, where proposals for 2008 were initially discussed, it was proposal 04-122. In 04-265r1.xls, the "hate dislike like love" score was 0-3-7-1. There was no technical discussion in plenary or subgroup. Nobody who cast a "dislike" vote offered a reason.

Another objection was "nobody has asked us for it." Of course, this was in response to me asking for it. I wasn't just asking for myself. I was representing more than 600 Fortran users at JPL, many of whom had admitted to having had mistakes in their codes that the proposed units system would have caught. The average cost estimate was two to three work weeks per year, but only one catastrophically expensive loss.

To answer some of Ondrej's questions:

The navigation software was in Fortran -- roughly six million lines spanning about 65 programs, being maintained at a cost of 6.5 work-years per year. People who didn't know anything about Fortran insisted in about 1996 that the entire suite of navigation and trajectory planning software had to be re-written in C++ and Python, which was done at great expense -- more than 240 work years. As late as the Mars Phoenix landing in 2008, it still didn't work.

For Mars Climate Orbiter, small-force data from Lockheed was ingested from text files. Contrary to Steve's assertion that the proposal would not have caught the problem that resulted in that catastrophic $300 million loss, that is precisely the reason that the proposal includes units in formatted I/O. It's possible that if units had been supported in the language, and used in the software, Lockheed software engineers could have "lied" in their output, claiming the units were Newton seconds when they were in fact pound seconds. But they would have had to make a conscious (or boneheadedly stupid) effort to do so. It's true that a compiler could not have caught the inconsistency because it wouldn't see both codes. But within a single code, the proposal is designed so that a processor can verify units consistency, including across procedure interfaces and between modules, and convert between related measurements based upon the same fundamental units.

A scheme using derived types, such as Grant Petty's scheme, has high runtime overhead, and requires significantly more labor than the method I proposed.

Fortran's niche for decades has been engineering and scientific applications, with a significant financial community thrown in. All these domains would benefit from units support. I don't see cell-phone apps or video games or OS kernels or MySQL or web pages getting any benefit from it. So the argument "other languages don't offer it" doesn't carry much weight.

@certik
Copy link
Member Author

certik commented Jul 7, 2021

@vansnyder thanks for this excellent comment.

The big problem as I saw was that the committee and community was not archiving any kind of feedback and discussion of the proposals. As such, for somebody like me joining the committee in 2019, I can't see any discussion about your units proposal.

But, I think we have greatly improved the process since then. Your "units" proposal is getting all kinds of discussion now, in this very issue and also in this Discourse thread:

and at least @klausler and I are both interested in implementing this in a compiler, so that people can test this out. Yes, it should be in the language and checked by the compiler at compile time. (The IO would have to be checked at runtime, but I think it could be a quick check, depending on how it is read in, and presumably the IO is usually not the performance bottleneck -- we can brainstorm this later.)

So far I like the idea a lot and I think it should be pursued by prototyping in a compiler and the community should play with that. And actually discuss the pros and cons of including this.

I reserve the right to change my mind as more details are developed. As we should all --- after prototyping and user experience, if we find this is not a good idea after all, that the pros do not outweigh the cost of this feature, then let's not do that.

Here are the costs that every feature to Fortran (including this one) should be considered against:

@magicmouse
Copy link

magicmouse commented Jul 7, 2021 •
edited

One of the problems with established languages is that it is almost impossible to get agreement on sensible extensions to the language, and vast amounts of time pass by while it is laboriously discussed. We now have 2 languages (Frink and Beads) with physical units of measure both at compile time and run-time. The advantage of runtime units is that you can store a quantity the HD and read it in and still know the exponents. One can also verify both at compile time and run time that you are mixing proper units and not combining exponents inappropriately.

Interestingly, when I announced the feature of units of measure on Reddit in the scientific subgroup, it was met with almost sadistic levels of scorn, by scientists who snarled that they don't make units mistakes. The engineers were similarly displeased. I concluded from this that there is a fair amount of professional snobbery and arrogance about dumb mistakes that they don't want to admit making. We all know about the errors people make in spreadsheets costing millions. As far as i can tell human beings get up in the morning and make a lot of mistakes.

My point is that there are human emotional reasons for blocking this very sensible proposal to add Units of Measure.

Even in Mobile Apps which i have quite a bit of experience (over 100 apps), there is fairly regular use of time which has units of months, days, weeks, hours, etc. and in commerce one sees "dozen" and "gross" a fair amount. And angular measurements are also super common (degrees / radians). Avoiding units errors is just one of many protections against human error, and people should be more open to reducing the total volume of the envelope of possible errors.

And by the way, Mr. Snyder, you can run Beads under Linux by using Wine, the freeware windows EXE runner.

@sblionel
Copy link
Member

sblionel commented Jul 7, 2021

My observations on the history of Van's proposal... J3 and WG5 repeatedly discussed the UNITS proposal over the years. The most recent was the 2013 Delft meeting where we spent an hour or more reviewing the proposal. My notes say:
"Straw vote on whether to ask SC22 to authorize work item for units TS. 3/7/1 abstain
US abstain, UK No, JP No, NL abstain, Canada No, Germany abstain  Not going to do it."

A big problem with a TS is the presumption that it will be part of the next standard revision. I and others did not like the specific proposal, which to me was very "F77-like". I suggested to Van that he should create a trial implementation using derived types and then see how it works when used in an application. He didn't want to do that. Another suggestion was to fork gfortran and add the feature, but that has a steep learning barrier even for an experienced compiler developer, which Van is not.

Personally, I don't have an objection to the concept, but as a former compiler developer I can see how this would be a lot of work for something I expect few programmers would use. You can do almost everything desired with derived types and defined operators, and I would really like to see someone model this as such before asking WG5 to add it to the language. If one of the OSS compilers wants to try it, great!

@fluidnumerics-joe
Copy link

I'm curious to understand what the objection is to implementing units handling and file IO in a library rather than implementing at the compiler level. Why doesn't a cross-organization group form to make something viable that doesn't require a change in the Fortran standard. IMO, this seems to be the path of least resistance, unless there are other barriers to getting something like this done and well supported (e.g. funding).

From this conversation, the "units as a standard" request is coming from and supported by NASA and DoD contractors but doesn't appear to have support beyond these kinds of groups. While I recognize tracking units correctly in code and in file IO is important and currently error prone, perhaps its time we rethink our software development strategy, rather than modifying a standard that impacts a broader community.

@certik
Copy link
Member Author

certik commented Jul 7, 2021 •
edited

and I would really like to see someone model this as such before asking WG5 to add it to the language. If one of the OSS compilers wants to try it, great!

Yes, we are in agreement on that. I think this should be prototyped first before bringing it to WG5 or J3. (Note that I would go beyond that and I think every significant feature should be prototyped first.)

@vansnyder
Copy link

vansnyder commented Jul 7, 2021 via email

@vansnyder
Copy link

vansnyder commented Jul 7, 2021 via email

@certik
Copy link
Member Author

certik commented Jul 7, 2021 •
edited

@vansnyder my understanding is that the main feedback from WG5 is to implement this in a Fortran compiler as a prototype (which has never been done yet).

What has been done is to prototype this using derived types and operators, e.g., by Grant Petty. I have found the following references to his work:

@vansnyder
Copy link

vansnyder commented Jul 7, 2021 via email

@certik
Copy link
Member Author

certik commented Jul 7, 2021

I realize that the proposal in N2113 would require more development work within the compiler. I suspect that at least some of it would be handled by an extension of the work that was required to allow more than one kind type parameter for a variable. In many ways, the UNIT specification acts like a kind type parameter. Tests for structural compatibility would be entirely new. Calculating units by combining factors within a term would be entirely new. Creating conversion functions would be entirely new. I/O would be entirely new. Even with all this entirely new work, I suspect the effort would be substantially less than the work required for coarrays or C interop.

Yes. It is my understanding that WG5 recommends to implement it in the compiler as the next step.

Yes I think it would not be that difficult, and I know at least @klausler and myself would be interested in attempting it. Hopefully more people would help.

@magicmouse
Copy link

Using Van Snyder's proposal as a starting point, i added Units of Measure to my Beads language. In the syntax, i allow a new datatype that of meas, which has the normal engineering unit families of angle, mass, length, area, pressure, energy, etc. In each unit family there are various units, with either constant scaling factors that relate a unit like kilometer to the meter, or specifies a function to go to and from the base unit. The user can create their own unit families, with a unique set of fundamental primitives like mass/length/ etc, and is limited to ratio of integer exponents. During compile time and runtime the measurement internally consists of a record consisting of a magnitude, the unit family it belongs to, and the current array of exponents in a canonical form. As you multiply quantities the exponents add. The user can thus conveniently write 3 kg + 2 lb + 3 g, and it will automatically do the units conversions. 3 kg * 4 m / 2 sec would remember the exponents. As there are only a few operators, it is not a big effort to carry these units around, and one can always uses scalars in large matrics so as to not burden the system.

Anyone claiming that we can't tolerate any extra overhead in calculations to ensure they are correct has not been paying attention to the over 1 million to 1 reduction in the cost of computation, since i was using the Univac 1108 at JPL in 1971. And let's not forget that stupid BitCoin used terawatt-hours of electricity doing useless calculations in a proof-of-waste scheme that is the greatest peacetime waste of resources in modern times.

The complexity to implement physical of units is fairly small. You have to handle meas * meas, scalar *meas, and one needs a few conversion functions so you can get a value to and from the preferred unit. The compiler has to track quite a bit more information (the array of exponents, the unit family, etc.) as it does its type calculations, but it isn't that hard, and compared to the fancy code optimizations that exist in the back-ends of compilers, this front end work is not a difficult task.

That the FORTRAN committee ignores the brilliant work of Van Snyder, whose long tenure at one of the crown jewels of the US high tech industry, and ignores the pioneering work of Fermat who invented the technique of checking units to proofread formulae in the 1800's is inexcusable inertia.

It is faster to write a whole new language (it took me 4 years so far) than to get a committee off its rear ends. C. Northcote Parkinson wrote extensively about how committees function, and perhaps the committee is too large; i think he set the limit at 8 or 12 i can't remember.

@magicmouse
Copy link

And with regards to proposal such as adding refinement types: by the time you have added sufficient abstraction power to have families of related units, and tracking exponents, you have built a more complex type system than Haskell or any other Category-theory laden language. The point is not to turn FORTRAN into a super-Haskell, but to gracefully and minimally extend FORTRAN to support his vital function.

Addition of this new data type is slightly more work than adding COMPLEX numbers was; you convert a single scalar value into 2 values in complex numbers, for a unit of measurement it is a record of a few fields. Since there are only 5 operations: addition, subtraction, multiplication, division, and exponentiation to fractional powers, that is only 5 runtime functions to invoke. It's just not that hard.

@certik
Copy link
Member Author

certik commented Jul 8, 2021 •
edited

@magicmouse thank you for your comments. Just a reminder that we have a Code of Conduct: let's criticize the committee if you think they have not done a good job sometimes, but let's not be demeaning about it.

Regarding performance:

Anyone claiming that we can't tolerate any extra overhead in calculations to ensure they are correct has not been paying attention to the over 1 million to 1 reduction in the cost of computation, since i was using the Univac 1108 at JPL in 1971.

It is my understanding that unit would not have any runtime overhead, except perhaps a very small overhead in IO (if you use them). Is that not the case?

Runtime overhead would be unacceptable for me. Yes, computers got faster, but that's besides the point: if Fortran suddenly intrinsically becomes slower for array operations, then somebody else will write a language that is faster. The way Fortran is designed is that it allows the compiler to (in theory) extract high percentage of the available performance, there are no intrinsic features that prevent performance. Well, there is the new reallocate LHS feature that possibly slows things down (and I am against it for the same reason, but that's another discussion). The point us: just the fact that hardware is fast compared to the past does not mean that we can waste cycles: if that was true, then everybody would be using Python for HPC. I love Python, and use it precisely because it is easy. It's often at least 200 times slower than Fortran, and yet computers have got 200 faster since the first time I used Python: one can definitely use Python now and be faster than any Fortran code 30 years ago --- and yet people including myself still want to use Fortran today, not Python, for high performance computing. As possibly the single core performance will stop getting faster in the next 10 years or so, I think performance of compilers will become even more important.

@vansnyder
Copy link

vansnyder commented Jul 8, 2021 via email

@certik certik added the Clause 8 Standard Clause 8: Attribute declarations and specifications label Apr 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Clause 8 Standard Clause 8: Attribute declarations and specifications
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests