From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sun Jul 10 01:06:43 2016 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 8FCC335877F; Sun, 10 Jul 2016 01:06:43 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id E1EF6356F40 for ; Sun, 10 Jul 2016 01:06:40 +0200 (CEST) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u69N6ZWP015532 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits) verified NO) for ; Sat, 9 Jul 2016 16:06:38 -0700 Subject: Other languages with unit support From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 Content-Type: multipart/alternative; boundary="=-Hn1rqXkeyNEdNEnlCvpz" Organization: Yes Date: Sat, 09 Jul 2016 16:06:35 -0700 Message-ID: <1468105595.25709.317.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-36.el6) X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk --=-Hn1rqXkeyNEdNEnlCvpz Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit According to Orchard, Rice and Oshmyan, these languages have units support: F# (functional) Haskell (functional) ML (functional) Fortress (abandoned in 2012) Others have reported choosing Mathcad instead of Matlab because it has unit support. Does anybody use any of these languages for serious scientific and engineering programming? I.e., for something other than prototypes, toys, or small problems? There is a C++ library at http://tuoml.sourceforge.net/. From the first page: The purpose of this library is to try to make it more difficult to make coding mistakes that incorrectly mix units of measure. This is done with a set of C++ classes that provide type-safe manipulation of units of measure for various properties. The classes provide compile-time units checking as opposed to run-time checking. Compile-time checking is far less difficult and expensive to track down errors. For example, if the developer tries to mix feet and meters, a compile-time error will result. Without the type-safe classes, this error would not be found until run-time (if at all!). Extreme care was taken in designing this library so that the run-time execution using the classes does not suffer any penalty versus using native double precision types. For instance, the classes have no virtual functions, so the compiler does not generate a virtual table. The resulting memory footprint of the class is therefore the same as a double. And since the type checking is done at compile time, there is no run-time performance hit when using the classes. Grant Petty provided a module for units computing in Fortran. It imposes significant runtime overhead. It doesn't support conversion, which would make it bigger and more expensive to use. Osprey is a units checker for C programs. I suspect it doesn't provide conversion, or input checking. SimCheck is a units checker for Simulink programs. I suspect it doesn't provide conversion, or input checking. But I guess nobody wants support for units. --=-Hn1rqXkeyNEdNEnlCvpz Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit According to Orchard, Rice and Oshmyan, these languages have units support:

F# (functional)
Haskell (functional)
ML (functional)
Fortress (abandoned in 2012)

Others have reported choosing Mathcad instead of Matlab because it has unit support.

Does anybody use any of these languages for serious scientific and engineering programming? I.e., for something other than prototypes, toys, or small problems?

There is a C++ library at http://tuoml.sourceforge.net/. From the first page:

The purpose of this library is to try to make it more difficult to make coding mistakes that incorrectly mix units of measure. This is done with a set of C++ classes that provide type-safe manipulation of units of measure for various properties. The classes provide compile-time units checking as opposed to run-time checking.

Compile-time checking is far less difficult and expensive to track down errors. For example, if the developer tries to mix feet and meters, a compile-time error will result. Without the type-safe classes, this error would not be found until run-time (if at all!).

Extreme care was taken in designing this library so that the run-time execution using the classes does not suffer any penalty versus using native double precision types. For instance, the classes have no virtual functions, so the compiler does not generate a virtual table. The resulting memory footprint of the class is therefore the same as a double. And since the type checking is done at compile time, there is no run-time performance hit when using the classes.

Grant Petty provided a module for units computing in Fortran. It imposes significant runtime overhead. It doesn't support conversion, which would make it bigger and more expensive to use.

Osprey is a units checker for C programs. I suspect it doesn't provide conversion, or input checking.

SimCheck is a units checker for Simulink programs. I suspect it doesn't provide conversion, or input checking.

But I guess nobody wants support for units.

--=-Hn1rqXkeyNEdNEnlCvpz--