Dimensions of the World (was: A sample revised prelude)
Mon, 12 Feb 2001 10:56:55 +0000
Ashley Yakeley after Tom Pledger:
> >The main complication is that the type system needs to deal with
> >integer exponents of dimensions, if it's to do the job well.
> Very occasionally non-integer or 'fractal' exponents of dimensions are
> useful. For instance, geographic coastlines can be measured in km ^ n,
> where 1 <= n < 2. This doesn't stop the CIA world factbook listing all
> coastline lengths in straight kilometres, however.
> More unit weirdness occurs with logarithms. For instance, if y and x are
> distances, log (y/x) = log y - log x. Note that 'log x' is some number +
> log (metre). Strange, huh?
When a week ago I mentioned those dollars difficult to multiply
some people spend their lives doing it...), and some dimensional
which should have focalised some people attention on the differences
between (*) and (+), I never thought the discussion would go so far.
Dimensional quantities *are* a can of worms.
From the practical point of view they are very useful in order to avoid
making silly programming errors, I have applied them several times while
coding some computer algebra expressions.
Dimensions were "just symbols", but with "reasonable" mathematical
properties (concerning (*) and (/)), so factorizing this symbolic part
was an easy way to see whether I didn't produce some illegal
Sometimes they are really "dimensionless" scaling factor! In
the units such as mm, cm, in etc. exist and function very nicely as
> If you (or anyone else) could comment on what sorts of units would be
> appropriate for the result type of a logarithm operation, I'd be glad to
> hear it. I don't know what the result type of this example is supposed
> to be if the units of a number are encoded in the type.
Actually, the logarithm example would be consider as spurious by almost
all "practical" mathematicians (e.g., physicists). A formula is sane if
the argument of the logarithm is dimensionless (if in x/y both elements
share the same dimension). Then adding and subtracting the same
log(GHmSmurf) is irrelevant.
But in general mathematical physics (and in geometry which encompasses
major part of the former) there are some delicate issues, which
involve fractality, and sometimes the necessity of "religious acts",
as the renormalization schemes in Quantum Field Theory.
In this case we have the "dimensional transmutation" phenomenon: the
coupling constant which is dimensionless, acquires a dimension, and
conditions the hadronic mass scale, i.e. the masses of elementary
[[[Yes, I know, you, serious comp. scist won't bother about it, but I
try anyway to tell you in two words why. A way of making a singular
finite, is to put in on a discrete lattice which represent the phys.
There is a dimensional object here: the lattice constant. Then you go to
zero with it, in order to retrieve the physical space-time. When you
this zero, you lose this constant, and this is one of the reasons why
theory explodes. So, it must be introduced elsewhere... In another
a physical correlation length L between objects is finite. If the
constant c is finite, L=N*c. But if c goes to zero... Now, programming
all this, Haskell or not, is another issue.]]]
Fractals are seen not only in geography, but everywhere, as Mandelbrot
his followers duly recognized. You will need them doing computations in
colloid physics, in the galaxy statistics, and in the metabolism of
body [[if you think that your energy depenses are proportional to your
volume, you are dead wrong, most interesting processes take place within
membranes. You are much flatter than you think, folks, ladies
Actually, ALL THIS was one of major driving forces behind my interest in
functional programming. I found an approach to programming which did not
target "symbolic manipulations", but "normal computing", so it could be
practically competiting against Fortran etc. Yet, it had a potential to
deal in a serious, formal manner with the mathematical properties of the
That's why I suffer seeing random, ad hoc numerics.
Björn Lisper mentions some approach to dimensions:
> Andrew Kennedy has basically solved this for higher order languages
> with HM type inference. He made an extension of the ML type system
> with dimensional analysis a couple of years back. Sorry I don't have
> the references at hand but he had a paper in ESOP I think.
> I think the real place for dimension and unit inference is in modelling
> languages, where you can specify physical systems through differential
> equations and simulate them numerically. Such languages are being
> increasingly used in the "real world" now.
ESOP '94. Andrew Kennedy: Dimension Types. 348-362.
There are other articles:
Jean Goubault. Inférence d'unités physiques en ML ;
Mitchell Wand and Patrick O'Keefe. Automatic dimensional inference;
and *hundreds* (literally) of papers within the Computer Algebra domain
about dimensionful computations.
I wouldn't say that the issue is "solved".
There is MUCH MORE in modelling physical (or biologic or financial)
world than just the differential equations. There is plenty of algebra
involved, nad *here* the dimensional reasoning may be important. And
such systems as Matlab/Simulink, etc. ignore the dimensions, although
they have now some OO layer permitting to define something like them.