Velocity Reviews > Re: "Strong typing vs. strong testing"

# Re: "Strong typing vs. strong testing"

Guest
Posts: n/a

 09-28-2010
On 2010-09-28 14:39:27 +0100, Malcolm McLean said:

> he problem is that if you allow expressions rather than terms then
> the experssions can get arbitrarily complex. sqrt(1 inch + 1 Second),
> for instance.

I can't imagine a context where 1 inch + 1 second would not be an
error, so this is a slightly odd example. Indeed I think that in
dimensional analysis summing (or comparing) things with different
dimensions is always an error.

>
> On the other hand sqrt(4 inches^2) is quite well defined. The question
> is whether to allow sqrt(1 inch). It means using rationals rather than
> integers for unit superscripts.

There's a large existing body of knowledge on dimensional analysis
(it's a very important tool for physics, for instance), and obviously
the answer is to do whatever it does. Raising to any power is fine, I
think (but transcendental functions, for instance, are never fine,
because they are equivalent to summing things with different
dimensions, which is obvious if you think about the Taylor expansion of
a transcendental function).

--tim

Niklas Holsti
Guest
Posts: n/a

 09-28-2010
Albert van der Horst wrote:
> In article <(E-Mail Removed)>,

....
>> I would even go further.
>>
>> Types are only part of the story. You may distinguish between integers
>> and floating points, fine. But what about distinguishing between
>> floating points representing lengths and floating points representing
>> volumes? Worse, what about distinguishing and converting floating
>> points representing lengths expressed in feets and floating points
>> representing lengths expressed in meters.

>
> When I was at Shell (late eighties) there were people claiming
> to have done exactly that, statically, in ADA.

It is cumbersome to do it statically, in the current Ada standard. Doing
it by run-time checks in overloaded operators is easier, but of course
has some run-time overhead. There are proposals to extend Ada a bit to
make a static check of physical units ("dimensions") simpler. See
and inparticular the part where Edmond Schonberg explains a suggestion

> A mission failure is a failure of management. The Ariadne crash was.

Just a nit, the launcher is named "Ariane".

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

Thomas A. Russ
Guest
Posts: n/a

 09-28-2010
Malcolm McLean <(E-Mail Removed)> writes:

> I'd like to design a language like this. If you add a quantity in
> inches to a quantity in centimetres you get a quantity in (say)
> metres. If you multiply them together you get an area, if you divide
> them you get a dimeionless scalar. If you divide a quantity in metres
> by a quantity in seconds you get a velocity, if you try to subtract
> them you get an error.

Done in 1992.

See
<http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/measures/0.html>
citation at <http://portal.acm.org/citation.cfm?id=150168>

and my extension to it as part of the Loom system:
<http://www.isi.edu/isd/LOOM/documentation/loom4.0-release-notes.html#Units>

--
Thomas A. Russ, USC/Information Sciences Institute

George Neuner
Guest
Posts: n/a

 09-28-2010
On 28 Sep 2010 12:42:40 GMT, Albert van der Horst
<(E-Mail Removed)4all.nl> wrote:

>I would say the dimensional checking is underrated. It must be
>complemented with a hard and fast rule about only using standard
>(SI) units internally.
>
>Oil output internal : m^3/sec
>Oil output printed: kbarrels/day

"barrel" is not an SI unit. And when speaking about oil there isn't
even a simple conversion.

42 US gallons ? 34.9723 imp gal ? 158.9873 L

[In case those marks don't render, they are meant to be the
double-tilda sign meaning "approximately equal".]

George

Nick
Guest
Posts: n/a

 09-28-2010
http://www.velocityreviews.com/forums/(E-Mail Removed) (Thomas A. Russ) writes:

> Malcolm McLean <(E-Mail Removed)> writes:
>
>> I'd like to design a language like this. If you add a quantity in
>> inches to a quantity in centimetres you get a quantity in (say)
>> metres. If you multiply them together you get an area, if you divide
>> them you get a dimeionless scalar. If you divide a quantity in metres
>> by a quantity in seconds you get a velocity, if you try to subtract
>> them you get an error.

>
> Done in 1992.
>
> See
> <http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/measures/0.html>
> citation at <http://portal.acm.org/citation.cfm?id=150168>
>
> and my extension to it as part of the Loom system:
> <http://www.isi.edu/isd/LOOM/documentation/loom4.0-release-notes.html#Units>

I didn't go as far as that, but:

\$ cat test.can
database input 'canal.sqlite'

for i=link 'Braunston Turn' to '.*'
print 'It is ';i.distance into 'distance:%M';' miles (which is '+i.distance into 'distance:%K'+' km) to ';i.place2 into 'namelace'
end for i
\$ canal test.can
It is 0.10 miles (which is 0.16 km) to London Road Bridge No 90
It is 0.08 miles (which is 0.13 km) to Bridge No 95
It is 0.19 miles (which is 0.30 km) to Braunston A45 Road Bridge No 91
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

Keith Thompson
Guest
Posts: n/a

 09-28-2010
George Neuner <(E-Mail Removed)> writes:
> On 28 Sep 2010 12:42:40 GMT, Albert van der Horst
> <(E-Mail Removed)4all.nl> wrote:
>>I would say the dimensional checking is underrated. It must be
>>complemented with a hard and fast rule about only using standard
>>(SI) units internally.
>>
>>Oil output internal : m^3/sec
>>Oil output printed: kbarrels/day

>
> "barrel" is not an SI unit.

He didn't say it was. Internal calculations are done in SI units (in
this case, m^3/sec); on output, the internal units can be converted to
whatever is convenient.

> And when speaking about oil there isn't
> even a simple conversion.
>
> 42 US gallons ? 34.9723 imp gal ? 158.9873 L
>
> [In case those marks don't render, they are meant to be the
> double-tilda sign meaning "approximately equal".]

There are multiple different kinds of "barrels", but "barrels of oil"
are (consistently, as far as I know) defined as 42 US liquid gallons.
A US liquid gallon is, by definition, 231 cubic inches; an inch
is, by definition, 0.0254 meter. So a barrel of oil is *exactly*
0.158987294928 m^3, and 1 m^3/sec is exactly 13.7365022817792
kbarrels/day. (Please feel free to check my math.) That's
admittedly a lot of digits, but there's no need for approximations
(unless they're imposed by the numeric representation you're using).

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson
Guest
Posts: n/a

 09-28-2010
Erik Max Francis <(E-Mail Removed)> writes:
[...]
> >>> print c # floating point accuracy aside

> 299792458.0 m/s

Actually, the speed of light is exactly 299792458.0 m/s by
definition. (The meter and the second are defined in terms of the
same wavelength of light; this was changed relatively recently.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

George Neuner
Guest
Posts: n/a

 09-29-2010
On Tue, 28 Sep 2010 12:15:07 -0700, Keith Thompson <(E-Mail Removed)>
wrote:

>George Neuner <(E-Mail Removed)> writes:
>> On 28 Sep 2010 12:42:40 GMT, Albert van der Horst
>> <(E-Mail Removed)4all.nl> wrote:
>>>I would say the dimensional checking is underrated. It must be
>>>complemented with a hard and fast rule about only using standard
>>>(SI) units internally.
>>>
>>>Oil output internal : m^3/sec
>>>Oil output printed: kbarrels/day

>>
>> "barrel" is not an SI unit.

>
>He didn't say it was. Internal calculations are done in SI units (in
>this case, m^3/sec); on output, the internal units can be converted to
>whatever is convenient.

That's true. But it is a situation where the conversion to SI units
loses precision and therefore probably shouldn't be done.

>
>> And when speaking about oil there isn't
>> even a simple conversion.
>>
>> 42 US gallons ? 34.9723 imp gal ? 158.9873 L
>>
>> [In case those marks don't render, they are meant to be the
>> double-tilda sign meaning "approximately equal".]

>
>There are multiple different kinds of "barrels", but "barrels of oil"
>are (consistently, as far as I know) defined as 42 US liquid gallons.
>A US liquid gallon is, by definition, 231 cubic inches; an inch
>is, by definition, 0.0254 meter. So a barrel of oil is *exactly*
>0.158987294928 m^3, and 1 m^3/sec is exactly 13.7365022817792
>kbarrels/day. (Please feel free to check my math.) That's
>admittedly a lot of digits, but there's no need for approximations
>(unless they're imposed by the numeric representation you're using).

I don't care to check it ... the fact that the SI unit involves 12
decimal places whereas the imperial unit involves 3 tells me the
conversion probably shouldn't be done in a program that wants
accuracy.

George

Torsten Zühlsdorff
Guest
Posts: n/a

 09-29-2010
Keith Thompson schrieb:

>> >>> print c # floating point accuracy aside

>> 299792458.0 m/s

>
> Actually, the speed of light is exactly 299792458.0 m/s by
> definition.

Yes, but just in vacuum.

Greetings,
Torsten
--
http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8
verschiedenen Datenbanksystemen abstrahiert,
Queries von Applikationen trennt und automatisch die Query-Ergebnisse
auswerten kann.

Pascal J. Bourguignon
Guest
Posts: n/a

 09-29-2010
George Neuner <(E-Mail Removed)> writes:

> On Tue, 28 Sep 2010 12:15:07 -0700, Keith Thompson <(E-Mail Removed)>
> wrote:
>
>>George Neuner <(E-Mail Removed)> writes:
>>> On 28 Sep 2010 12:42:40 GMT, Albert van der Horst
>>> <(E-Mail Removed)4all.nl> wrote:
>>>>I would say the dimensional checking is underrated. It must be
>>>>complemented with a hard and fast rule about only using standard
>>>>(SI) units internally.
>>>>
>>>>Oil output internal : m^3/sec
>>>>Oil output printed: kbarrels/day
>>>
>>> "barrel" is not an SI unit.

>>
>>He didn't say it was. Internal calculations are done in SI units (in
>>this case, m^3/sec); on output, the internal units can be converted to
>>whatever is convenient.

>
> That's true. But it is a situation where the conversion to SI units
> loses precision and therefore probably shouldn't be done.
>
>>
>>> And when speaking about oil there isn't
>>> even a simple conversion.
>>>
>>> 42 US gallons ? 34.9723 imp gal ? 158.9873 L
>>>
>>> [In case those marks don't render, they are meant to be the
>>> double-tilda sign meaning "approximately equal".]

>>
>>There are multiple different kinds of "barrels", but "barrels of oil"
>>are (consistently, as far as I know) defined as 42 US liquid gallons.
>>A US liquid gallon is, by definition, 231 cubic inches; an inch
>>is, by definition, 0.0254 meter. So a barrel of oil is *exactly*
>>0.158987294928 m^3, and 1 m^3/sec is exactly 13.7365022817792
>>kbarrels/day. (Please feel free to check my math.) That's
>>admittedly a lot of digits, but there's no need for approximations
>>(unless they're imposed by the numeric representation you're using).

>
> I don't care to check it ... the fact that the SI unit involves 12
> decimal places whereas the imperial unit involves 3 tells me the
> conversion probably shouldn't be done in a program that wants
> accuracy.

Because perhaps you're thinking that oil is sent over the oceans, and
sold retails in barrils of 42 gallons?

Actually, when I buy oil, it's from a pump that's graduated in liters!

It comes from trucks with citerns containing 24 m³.

And these trucks get it from reservoirs of 23,850 m³.

"Tankers move approximately 2,000,000,000 metric tons" says the English

Now perhaps it all depends on whether you buy your oil from Total or
from Texaco, but in my opinion, you're forgetting something: the last
drop. You never get exactly 42 gallons of oil, there's always a little
drop more or less, so what you get is perhaps 158.987 liter or
41.9999221 US gallons, or even 158.98 liter = 41.9980729 US gallons,
where you need more significant digits.

--
__Pascal Bourguignon__ http://www.informatimago.com/