On 26 August 2016 at 18:35, Steven D'Aprano wrote:
> I think that units are orthogonal to types: I can have a float of unit
> "gram" and a Fraction of unit "gram", and they shouldn't necessarily be
> treated as the same type.
I think you are mixing here what I sometimes call classes (i.e. runtime
On Sun, Aug 28, 2016 at 4:25 AM, Steven D'Aprano wrote:
>
> Sympy (apparently) doesn't warn you if your units are incompatible, it
> just treats them as separate terms in an expression:
>
> py> 2*m + 3*K
> 3*K + 2*m
>
> which probably makes sense from the point of view of a computer algebra
> syst
On Fri, Aug 26, 2016 at 03:23:24PM -0700, Ken Kundert wrote:
> 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 b
It really feels like the OP simply wants Python to become a language for
circuit design, with no consideration of general pulse usability, not of
other domains. Little in the proposal translates well outside his
particular domain, and the differences between domains simply make the
proposed additio
On 27/08/2016 10:44, Ken Kundert wrote:
> SPICE, written by Larry Nagel, introduced the concept in 1972. It is a
> circuit
> simulator, and the language involved was a netlist language: basically a list
> of
> components, the nodes there were connected to, and their values. It looked
> like
>
I've been following this discussion on and off for a while, but
still fail to see how SI units, factors or the like are a use
case which is general enough to warrant changing the language.
There are packages available on PyPI for dealing with this
in a similar way we deal with decimal literals in
MRAB writes:
> When you divide 2 values, they could have the same or different units,
> but must have the same colours. The result will have a combination of
> the units (some might also cancel out), but will have the same colours.
>
> # "amp" is a unit, "current" is a colour.
>
SPICE, written by Larry Nagel, introduced the concept in 1972. It is a circuit
simulator, and the language involved was a netlist language: basically a list of
components, the nodes there were connected to, and their values. It looked like
this:
R1 1 0 1K
C1 1 0 1nF
I1 1 0 1mA
SPICE was an incre
On Fri, Aug 26, 2016 at 03:23:24PM -0700, Ken Kundert wrote:
> 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 th
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 c
On Fri, Aug 26, 2016 at 02:49:51PM +0300, Ivan Levkivskyi wrote:
> 1. By defining __mul__ and __truediv__ on m, s, and other units one can
> achieve the desirable semantics
I'm not entirely sure about that. I'm not even close to an expert on the
theory of types, so I welcome correction, but it d
On 2016-08-26 07:54, Steven D'Aprano wrote:
[snip]
Specialist applications might be able to take shortcuts in
dimensional analysis when "everybody knows" what the suppressed units
must be. General purpose programming languages *cannot*. It is better
NOT to offer the illusion of dimensional analys
On 26 August 2016 at 14:49, Ivan Levkivskyi wrote:
> On 26 August 2016 at 13:01, Steven D'Aprano wrote:
>
>> On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote:
>> > On 8/25/16, Ken Kundert wrote:
>> >
>> > [...]
>> >
>> > > Just allowing the units to be present, even it not
>> > >
>> >
On 26 August 2016 at 13:01, Steven D'Aprano wrote:
> On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote:
> > On 8/25/16, Ken Kundert wrote:
> >
> > [...]
> >
> > > Just allowing the units to be present, even it not
> > >
> > > retained, is a big advantage because it can bring a great dea
On Fri, Aug 26, 2016 at 06:31:30PM +1000, Nick Coghlan wrote:
> On 26 August 2016 at 16:54, Steven D'Aprano wrote:
> > At best, we can choose descriptive variable names that hint what the
> > correct dimensions should be:
> >
> > weight_of_contents + weight_of_container
> >
> >
> > The argumen
On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote:
> On 8/25/16, Ken Kundert 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, eve
On Thu, Aug 25, 2016 at 11:34:23PM -0400, Random832 wrote:
> On Thu, Aug 25, 2016, at 19:50, Steven D'Aprano wrote:
> > Historically, there are *three* different meanings for "MB", only one of
> > which is an official standard:
> >
> > http://physics.nist.gov/cuu/Units/binary.html
>
> The link d
On 26 August 2016 at 16:54, Steven D'Aprano wrote:
> At best, we can choose descriptive variable names that hint what the
> correct dimensions should be:
>
> weight_of_contents + weight_of_container
>
>
> The argument that units would make it easier for the programmer to spot
> errors is, I th
On Fri, Aug 26, 2016 at 4:54 PM, Steven D'Aprano wrote:
> But you're not in the world of circuit design any more, you are dealing
> with a programming language that will be used by people for many,
> many different purposes, for whom "unity" might mean (for example):
>
> 1 foot per second
> 1 foot
On Thu, Aug 25, 2016 at 08:46:54PM -0700, Ken Kundert wrote:
> This idea is new to general purpose languages,
For the record, at least some HP calculators include a "units" data type
as part of the programming language "RPL", e.g. the HP-28 and HP-48
series. I've been using those for 20+ years
On 26 August 2016 at 08:34, Nick Coghlan wrote:
> On 26 August 2016 at 13:46, Ken Kundert
> wrote:
> > On Fri, Aug 26, 2016 at 10:14:53AM +1000, Steven D'Aprano wrote:
> >> On Thu, Aug 25, 2016 at 11:02:11AM -0700, Ken Kundert wrote:
> >>
> >> > Even if the language completely ignores the units,
On 8/25/16, Ken Kundert 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
On 26 August 2016 at 13:46, Ken Kundert wrote:
> On Fri, Aug 26, 2016 at 10:14:53AM +1000, Steven D'Aprano wrote:
>> On Thu, Aug 25, 2016 at 11:02:11AM -0700, Ken Kundert wrote:
>>
>> > Even if the language completely ignores the units, we have still gained by
>> > allowing the units to be there,
On Fri, Aug 26, 2016 at 10:14:53AM +1000, Steven D'Aprano wrote:
> On Thu, Aug 25, 2016 at 11:02:11AM -0700, Ken Kundert wrote:
>
> > Even if the language completely ignores the units, we have still gained by
> > allowing the units to be there, just like we gain when we allow user to add
> > com
On Thu, Aug 25, 2016, at 19:50, Steven D'Aprano wrote:
> Historically, there are *three* different meanings for "MB", only one of
> which is an official standard:
>
> http://physics.nist.gov/cuu/Units/binary.html
The link doesn't work for me... is the third one the 1,024,000 bytes
implicit in de
On 26 August 2016 at 06:06, Ken Kundert wrote:
> Here is a fairly typical example that illustrates the usefulness of supporting
> SI scale factors and units in Python.
Ken,
To build a persuasive case, you'll find it's necessary to stop
comparing Python-with-syntactic-support to
Python-with-no-sy
On Thu, Aug 25, 2016 at 11:02:11AM -0700, Ken Kundert wrote:
> Once you
> allow SI scale factors on numbers, the natural tendency is for people to want
> to
> add units, which is a good thing because it gives important information about
> the number. We should allow it because it improves the
On Thu, Aug 25, 2016 at 09:03:32PM +0100, Paul Moore wrote:
> That's not to say there's no room for debate here - the proposal is
> interesting, and not without precedent (for example Windows Powershell
> supports constants of the form 1MB, 1GB
That's great! I know a few command line tools and s
On 25/08/2016 22:06, Ken Kundert wrote:
> Here is a fairly typical example that illustrates the usefulness of
> supporting
> SI scale factors and units in Python.
>
> This is simple simulation code that is used to test a current mirror driving
> an
> 100kOhm resistor ...
>
> Here is some simu
On Fri, Aug 26, 2016 at 6:06 AM, Ken Kundert
wrote:
> Here is some simulation code that uses SI scale factors
>
> for delta in [-500nA, 0, 500nA]:
> input = 2.75uA + delta
> wait(1us)
> expected = 100kOhm*(2.75uA + delta)
> tolerance = 2.2mV
> fails = ch
Here is a fairly typical example that illustrates the usefulness of supporting
SI scale factors and units in Python.
This is simple simulation code that is used to test a current mirror driving an
100kOhm resistor ...
Here is some simulation code that uses SI scale factors
for delta in [-5
On 25 August 2016 at 19:02, Ken Kundert wrote:
> This proposal basically has two parts. One part is that Python should
> naturally support printing real numbers with SI scale factors. Currently
> there
> are three formats for printing real number: %f, %d, %g. They all become
> difficult to r
All,
This proposal basically has two parts. One part is that Python should
naturally support printing real numbers with SI scale factors. Currently there
are three formats for printing real number: %f, %d, %g. They all become
difficult to read for even moderately large or small numbers. Ex
On Thu, Aug 25, 2016 at 9:24 PM, Steven D'Aprano wrote:
> If I try to add 30 feet to 6 metres and get either 36 feet or 36 metres,
> then your unit system is *worse* than useless, it is actively harmful. I
> don't mind if I get 15.144 metres or 49.685039 feet or even
> 5.0514947e-08 lightseconds,
On Wed, Aug 24, 2016 at 09:28:03PM -0700, Ken Kundert wrote:
> All,
> I propose that support for SI scale factors be added to Python.
I think there's something to be said for these ideas, but you are
combining multiple ideas into one suggestion.
First off, units with quantities: I think that
I have trouble imagining situations in which SI units would help
readability over scientific notation. On the one hand reading it always
involves mental conversion to the exponents, so this is just an extra step.
E.g. this equality is evident at a glance:
1e3 * 1e6 * 1e-9 == 1
This one would take
On Thu, Aug 25, 2016 at 6:19 PM, Ken Kundert
wrote:
>> So you can have 1000mm or 0.001km but not 1m?
>
> If the scale factor is optional, then numbers like 1m are problematic because
> the m can represent either milli or meter. This is resolved by requiring the
> scale factor and defining a unity
On 25 August 2016 at 06:06, Paul Moore wrote:
> On 25 August 2016 at 09:54, Ken Kundert wrote:
>> 1G -> 1e+09
>> 1M -> 1e+06
>> 1k -> 1e+03
>
> While these suffixes are suitable for a scientific context, in a
> computing context, 1k=1024, 1M=1024*1024 and 1G=1024*1024*1024 make
> just
On 25 August 2016 at 09:54, Ken Kundert wrote:
> 1G -> 1e+09
> 1M -> 1e+06
> 1k -> 1e+03
While these suffixes are suitable for a scientific context, in a
computing context, 1k=1024, 1M=1024*1024 and 1G=1024*1024*1024 make
just as much, if not more, sense (and yes, I'm aware of Gigabyt
> Question, though: What happens with exa-? Currently, if the parser
> sees "1E", it'll expect to see another number, eg 1E+1 == 10.0. Will
> this double meaning cause confusion?
Allow me to refine my answer to this question ...
Yes, that is definitely problematic. I see two possible solutions.
1
> So you can have 1000mm or 0.001km but not 1m?
If the scale factor is optional, then numbers like 1m are problematic because
the m can represent either milli or meter. This is resolved by requiring the
scale factor and defining a unity scale factor. I propose '_'. So 1m represents
milli and 1_
On Wed, Aug 24, 2016 at 11:57 PM, Greg Ewing
wrote:
> Chris Angelico wrote:
>>
>> If units are retained, what you have is no longer a simple number, but
>> a value with a unit, and is a quite different beast. (For instance,
>> addition would have to cope with unit mismatches (probably by throwing
On 25/08/2016 06:28, Ken Kundert wrote:
> All,
> I propose that support for SI scale factors be added to Python. This would
> be very helpful for any program that heavily uses real numbers, such as those
> involved with scientific and engineering computation. There would be two
> primary
> c
On Thu, Aug 25, 2016 at 3:57 PM, Greg Ewing wrote:
> Chris Angelico wrote:
>>
>> If units are retained, what you have is no longer a simple number, but
>> a value with a unit, and is a quite different beast. (For instance,
>> addition would have to cope with unit mismatches (probably by throwing
>
Chris Angelico wrote:
If units are retained, what you have is no longer a simple number, but
a value with a unit, and is a quite different beast. (For instance,
addition would have to cope with unit mismatches (probably by throwing
an error), and multiplication would have to combine the units (le
Ian Kelly wrote:
Should 1m be interpreted as 1 meter or 0.001 (unitless)?
I've never seen anyone use a scale factor prefix on
its own with a dimensionless number.
Sometimes informally the unit is omitted when it can
be inferred from context (e.g. "1k" written next to
a resistor symbol obviousl
On Thu, Aug 25, 2016 at 2:28 PM, Ken Kundert
wrote:
> I propose that support for SI scale factors be added to Python. This would
> be very helpful for any program that heavily uses real numbers, such as those
> involved with scientific and engineering computation. There would be two
> primary
On Wed, Aug 24, 2016 at 10:34 PM, Random832 wrote:
> On Thu, Aug 25, 2016, at 00:28, Ken Kundert wrote:
>> Basically a scale factor and units may follow a number, both of which are
>> optional, but if the units are given the scale factor must also be given.
>
> So you can have 1000mm or 0.001km bu
On Thu, Aug 25, 2016, at 00:28, Ken Kundert wrote:
> Basically a scale factor and units may follow a number, both of which are
> optional, but if the units are given the scale factor must also be given.
So you can have 1000mm or 0.001km but not 1m?
___
P
All,
I propose that support for SI scale factors be added to Python. This would
be very helpful for any program that heavily uses real numbers, such as those
involved with scientific and engineering computation. There would be two primary
changes. First, the lexer would be enhanced to take rea
50 matches
Mail list logo
