[Python-ideas] SI scale factors in Python

[Steven D'Aprano]

On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote:
> On 8/25/16, Ken Kundert <python-ideas at shalmirane.com> wrote:
> 
> [...]
> 
> > Just allowing the units to be present, even it not
> >
> > retained, is a big advantage because it can bring a great deal of clarity to
> > the
> > meaning of the number. For example, even if the language does not flag an
> > error
> > when a user writes:
> >
> >     vdiff = 1mV - 30uA
> 
> It reminds me: "Metric mishap caused loss of NASA's Mars Climate
> orbiter. It could be nice to have language support helping to avoid
> something similar.

This proposal won't help to avoid this sort of disasterous misuse of 
units. It will make that sort of mistake *easier*, not harder, by giving 
the user the false sense of security.

A good description of the Mars Orbiter mishape can be found here, with 
a link to the NASA report:

http://pint.readthedocs.io/en/0.7.2/

Suppose I am programming the Mars lander. I read in some thruster data, 
in pound-force seconds:

    thrust = sm_forces(arg)  # say, it returns 100 lbf·s

I don't expect to see the tag "lbf·s" anywhere unless I explicitly print 
the value out or view it in a debugger. So the tag gives me no visual 
assistence in avoiding unit conversion bugs. It is worse than having no 
unit attached at all, because now I have the false sense of security 
that it is tagged with a unit.

Much later on I pass that to a function that expects the thrust to be in 
Newton seconds:

    result = fire_engines(thrust)

There's no dimensional analysis, so I could just as easily pass 100 
kilograms per second cubed, or 100 volts. I have no protection from 
passing wrong units. But let's ignore that possibility, and trust that I 
do actually pass a thrust rather than something completely different.
 
The original poster Ken has said that he doesn't want to do unit 
conversions. So I pass a measurement in pound force seconds, which is 
compatible with Newton seconds, and quite happily use 100 lbf·s as if it 
were 100 N·s.

End result: a repeat of the original Mars lander debacle, when my lander 
crashes directly into the surface of Mars, due to a failure to convert 
units. This could have been avoided if I had used a real units package 
that applied the conversion factor 1 lbf·s = 44.5 N·s, but Kevin's 
suggestion won't prevent that.

You can't avoid bugs caused by using the wrong units by just labelling 
values with a unit. You actually have to convert from the wrong units to 
the right units, something this proposal avoids.

I think that Ken is misled by his experience in one narrow field, 
circuit design, where everyone uses precisely the same SI units and 
there are no conversions needed. This is a field where people can drop 
dimensions because everyone understands what you mean to say that a 
current equals a voltage. But in the wider world, that's disasterous.

Take v = s/t (velocity equals distance over time). If I write v = s 
because it is implicitly understood that the time t is "one": 

    s = 100 miles
    v = s

Should v be understood as 100 miles per hour or 100 miles per second or 
100 miles per year? That sort of ambiguity doesn't come up in circuit 
design, but it is common elsewhere.



-- 
Steve