Re: Dealing with ad hominem attacks in comp.programming

In article <a2e2ccb9-b53f-4796-8b5d-466d821d76c8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, kwikius <andy@xxxxxxxxxxxxxxxxxxxxxxxxx> writes
I felt it deserved a thread of its own because, to my knowledge, no major
programming languages come with units as standard.
However I don't have any good ideas, at least as yet.

FWIW physical quantities as programming entities are far from dead.

However they not simple to deal with. People like to discuss problems
that they have solutions to not that seem overwhelming.
[...]
I have previously spent a large amount of time discussing quan (used
to be pqs) in public, but now prefer to spend the time improving the
work offline.

I have read the subthreads on quan and related topics. I found them quite interesting, though not particularly relevant to my day-to-day work.

The matter really divides into two parts. How to represent quantities within the computer, and how to show them in the source code. In other words, whether you write:
3 inches
or
(metres)(3 * 0.0254)
is separate from the internal representation.

The source code bit is actually easier. If you're creating your own language, pick whatever's convenient for you. If you have to live with existing ones, either use their notation or do a preprocessing stage to allow the use of your own.

If I understand you correctly, you're representing quantities as unadorned values in the machine and relying on the compiler to do units analysis. That is, "3 m", "3 s" and "3 kg" would all be represented as an unadorned "3" in the machine, and you rely on the compiler to allow "3 m + 5 m" while forbidding "3 m + 5 s". This is similar to the treatment of imaginary (not complex) types in C99.

An alternative would be to represent quantities as a floating point number and an array of unit exponents. That is, working with the SI units of m, s, kg, K, A, cd, you'd represent:
3 m as { 3.0, 1, 0, 0, 0, 0, 0 }
3 s as { 3.0, 0, 1, 0, 0, 0, 0 }
3 m/s as { 3.0, 1, -1, 0, 0, 0, 0 }
and so on. The + and - operators would check that the units are the same and throw an exception if not, while the * and / operators would manipulate the units accordingly.

The big advantage of this is that it's open-ended: if someone needs to work with kg^2/Acd^3, you don't need another set of overloaded operators to do it. The big disadvantage, of course, is that you lose compile-time checking of consistency.

[I note you treat m and mm as separate types. I don't see the point, but you can extend this approach to that if you want.]

--
Clive D.W. Feather | Home: <clive@xxxxxxxxxx>
Tel: +44 20 8495 6138 (work) | Web: <http://www.davros.org>
Fax: +44 870 051 9937 | Work: <clive@xxxxxxxxx>
Please reply to the Reply-To address, which is: <clive@xxxxxxxxxx>
.

Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... programming languages in common use. ... You can write a proof about an algorithm using the techniques you mention. ... because there is no mathematical guarantee that the C compiler ...
    (sci.crypt)
  • Beginning ANSI - Standard C
    ... computer games for the 8-bit computers and the 16-bit computers such ... I have got the following books: ... Which ANSI C compiler is GOOD, ...
    (comp.lang.c)
  • Re: Beginning ANSI - Standard C
    ... > 1) Which ANSI C compiler is GOOD, ... I feel GCC is a safe bet for your learning and working purpose ...
    (comp.lang.c)
  • Re: f() + g() * h()
    ... of programming languages. ... link-time code generation is to store some intermediate representation ... indication of what compiler back end processes that. ...
    (comp.lang.c)