Steven,
This keeps coming up, so let me address it again.
First, I concede that you are correct that my proposal does not provide
dimensional analysis, so any dimensional errors that exist in this new code
will
not be caught by Python itself, as is currently the case.
However, you should concede that by bringing the units front and center in the
language, they are more likely to be caught by the user themselves. Yes, it is
true that my proposal only addresses units on literals and not variables,
expressions, functions, etc. But my proposal addresses not only real literals
in
the program itself, but also real values in the input and output.
Extending this to address variables, expressions, functions, etc would only
make
sense if the units were checked, which of course is dimensional analysis. It
is
my position that dimensional analysis is so difficult and burdensome that there
is no way it should be in the base Python language. If available, it should be
as an add on. This proposal is more about adding capabilities to be base
language that happen to make dimensional analysis easier and more attractive
than about providing dimensional analysis itself.
Second, I concede that there is some chance that users may be lulled into
a false sense of complacency and that some dimensional errors would get missed
by these otherwise normally very diligent users. But I would point out that
I have been intensively using and supporting languages that provide this
feature
for 40 years and have never seen it.
Finally, lets consider the incident on Mars. The problem occurred because one
software package output numbers in English units (what were they thinking?)
that
were then entered into another program that was expecting metric units. The
only
way this could have been caught in an automated fashion is if the first package
output the units for its numbers, and the second package accessed and checked
those units. And it is precisely this that I am trying to make easier and more
likely with this extension. Of the three steps that must occur, output the
units, input the units, check the units, this proposal addresses the first two.
-Ken
On Fri, Aug 26, 2016 at 08:01:29PM +1000, Steven D'Aprano wrote:
> On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote:
> > On 8/25/16, Ken Kundert <[email protected]> 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
> _______________________________________________
> Python-ideas mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
