On 4/12/22 00:57, Stephen J. Turnbull wrote:
Ethan Furman writes:
15mpg * 7l == how many miles?
Now it's my turn to not understand the point of this example.
My point is that when an object is instantiated it can normalize its arguments, and that that normalization should
happen with
On Tue, Apr 12, 2022 at 11:27 AM Christopher Barker
wrote:
> > > I guess you could call the associative law of multiplication "dumb
>> > > luck", but most mathematicians will consider that hate speech.
>> >
>> > My apologies for not understanding your example. The counter
>> > example I
>
> > > I guess you could call the associative law of multiplication "dumb
> > > luck", but most mathematicians will consider that hate speech.
> >
> > My apologies for not understanding your example. The counter
> > example I had in my head, and should have written down,
> > was something
Ethan Furman writes:
> On 4/10/22 21:33, Stephen J. Turnbull wrote:
>
> > I guess you could call the associative law of multiplication "dumb
> > luck", but most mathematicians will consider that hate speech.
>
> My apologies for not understanding your example. The counter
> example I had
On Mon, Apr 11, 2022 at 07:32:12AM -0700, Ethan Furman wrote:
> My apologies for not understanding your example. The counter example I had
> in my head, and should have written down, was something like:
>
> 15mpg * 7l == how many miles?
>
> where
>
> mpg = miles per gallons
> l =
On Mon, Apr 11, 2022 at 11:33 AM Ethan Furman wrote:
> On 4/10/22 21:33, Stephen J. Turnbull wrote:
>
> > I guess you could call the associative law of multiplication "dumb
> > luck", but most mathematicians will consider that hate speech.
>
> My apologies for not understanding your example.
On 4/10/22 21:33, Stephen J. Turnbull wrote:
I guess you could call the associative law of multiplication "dumb
luck", but most mathematicians will consider that hate speech.
My apologies for not understanding your example. The counter example I had in my head, and should have written down,
Warning: serious linguistic hacking follows. I tried to be careful in
writing, please be careful in reading. Corrections welcome.
Ethan Furman writes:
> On 4/9/22 21:17, Stephen J. Turnbull wrote:
>
> > if 12*u.mm * 42*u.MFr == 502*u.foo:
> > print('Well done!')
>
> Part of
On 4/9/22 21:17, Stephen J. Turnbull wrote:
if 12*u.mm * 42*u.MFr == 502*u.foo:
print('Well done!')
That would work fine for me. But I can see why somebody who
frequently uses interactive Python as a scientific calculator would
prefer to write
if 12 m/s * 42 s == 502 m:
Steven D'Aprano writes:
> There are many things which are core to science and engineering but
> aren't part of the core Python language. What makes units of
> measurements more special than, say, numpy arrays or dataframes?
Arrays and dataframes are data structures, hidden behind the
wrote:
> This message is for those that would like to "play" with a more natural
> looking syntax for units in Python.
>
This is very cool -- thanks!
-CHB
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web
Greetings,
This message is for those that would like to "play" with a more natural
looking syntax for units in Python.
First, a quick look:
> python -m ideas -t easy_units
Ideas Console version 0.0.23. [Python version: 3.10.2]
~>> import pint
~>> U = pint.UnitRegistry()
~>> walk = 3[km] +
On Sat, Apr 9, 2022 at 5:52 AM Steven D'Aprano wrote:
> > Python is so painful to use for units I've actually avoided it,
What have you tried? and what do you do instead?
MathCAD, maybe?
For my part, there is a bit of a barrier to entry: I need to pick a
library, I need to get over the
On Thu, Apr 07, 2022 at 11:18:57PM -, Brian McCall wrote:
> > What does it *really* matter which of these you write?
>
> > that's just arguing over the colour of the bikeshed.
>
> > you have shown nothing to justify why unit support must be built
> > into the language itself.
>
> I did
On Fri, Apr 08, 2022 at 07:20:35AM -0400, Ricky Teachey wrote:
> Python is so painful to use for units I've actually avoided it, so there
> won't be many examples I can give anyway. Hence my silence in this thread
> the past few days.
Which of the many Python libraries have you tried, and what
On Fri, 8 Apr 2022 at 13:09, Matt del Valle wrote:
>
> My personal preference for adding units to python would be to make instances
> of all numeric classes subscriptable, with the implementation being roughly
> equivalent to:
>
> def __getitem__(self, unit_cls: type[T]) -> T:
> return
My personal preference for adding units to python would be to make
instances of all numeric classes subscriptable, with the implementation
being roughly equivalent to:
def __getitem__(self, unit_cls: type[T]) -> T:
return unit_cls(self)
We could then discuss the possibility of adding some
On Fri, 8 Apr 2022 at 12:22, Ricky Teachey wrote:
> I just get really excited at the idea of it being native to the language and
> am dreaming of being able to use it more often for my every day calculations.
> Right now I just don't feel confident I can.
If you can describe what the Python
On Fri, Apr 8, 2022, 2:40 AM Stephen J. Turnbull
wrote:
> Brian McCall writes:
> Steven d'Aprano writes:
>
> > > you have shown nothing to justify why unit support must be built
> > > into the language itself.
> >
> > I did what I could, but I'm not going to try and justify any more.
>
Brian McCall writes:
Steven d'Aprano writes:
> > you have shown nothing to justify why unit support must be built
> > into the language itself.
>
> I did what I could, but I'm not going to try and justify any more.
That makes me sad, because everybody in the thread acknowledges that
> What does it *really* matter which of these you write?
> that's just arguing over the colour of the bikeshed.
> you have shown nothing to justify why unit support must be built into the
> language itself.
I did what I could, but I'm not going to try and justify any more. At the end
of the
On Wed, Apr 06, 2022 at 03:50:35PM -, Brian McCall wrote:
> Stephen J Turnbull and Paul Moore have asked why the "need" for
> something other than a library (or perhaps a better library). There
> are a number of examples that show simple unit calculations and it's
> easy to argue based on
On Wed, Apr 06, 2022 at 11:48:44PM -0700, Ken Kundert wrote:
> Perhaps a better approach would simply be to build
> a units aware scientific calculator application.
The Python REPL makes an awesome interactive calculator.
Sagemath has done what you suggest: it is a powerful symbolic maths
On Wed, Apr 06, 2022 at 08:36:35PM +0100, Paul Moore wrote:
>
> compactness isn't typically regarded as a significant
> selling point for a proposal.
I would word that differently.
Compactness *alone* isn't typically regarded as a *compelling* selling
point, and *excessive* compactness is
On Wed, Apr 06, 2022 at 04:54:15PM -, Brian McCall wrote:
> Oops, my examples have some other problems:
>
> > # λ = 550e-9nm
>
> should be
>
> > # λ = 550nm
This is an excellent example of why unit tracking, or any other
programming system, is not a panacea. No programming system in
Chris Angelico writes:
> > It's very difficult to get *any* syntax change in. In particular,
> > changing '_' from an identifier component to an operator for
> > combining numeric literals would invalidate *tons* of code
> > (including internationalization code that is the
On Thu, Apr 7, 2022 at 10:51 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:
> NOTE: The big problem I see with this is that I don't see any
> practical way to use syntax for non-numeric types like ndarray.
> The problem is that in, say, economics we use a lot of m x 2
>
On Fri, 8 Apr 2022 at 00:48, Stephen J. Turnbull
wrote:
> 1. Syntax, aka language support (the original suggestion of
> user-defined literals fits here because either the way numbers are
> parsed or the way '_' is parsed would have to change).
>
> It's very difficult to get *any*
After reading this long thread, a few notes:
[preface: I write this as someone whose entire career is based on doing
computation with Python, and with systems where physical units are critical
and complex, and who maintains a fair bit of my own custom unit-oriented
code -- this is not hypothesis]
Brian McCall writes:
> Stephen J Turnbull and Paul Moore have asked why the "need" for
> something other than a library (or perhaps a better library). There
> are a number of examples that show simple unit calculations and
> it's easy to argue based on those that nothing further is needed.
On Thu, 7 Apr 2022 at 01:18, Brian McCall
wrote:
>
>> Please can you explain this to me? I don't know what you mean by "get the
>> final answer", nor do I know how astropy.units is relevant. Units seems to
>> be a perfectly acceptable library without astropy, is that not the case?
>
> Am I
Previously you were adamant that it is important that the units be propagated
into the final result. In my experience this rarely works out as one expects
because the units come out in an overly complicated, confusing form or
unexpected form. For example, you gave the units for Planck's
On Thu, 7 Apr 2022 at 10:19, Brian McCall
wrote:
>
> > Agreed, this is just using Python as a glorified calculator. I understand
> > that this is just an example, but I *am* curious, is the bulk of what you
> > do simply calculations like this, or do your more complicated examples tend
> > to
> Agreed, this is just using Python as a glorified calculator. I understand
> that this is just an example, but I *am* curious, is the bulk of what you do
> simply calculations like this, or do your more complicated examples tend to
> be more like actual programs?
I have never shipped code
Mike and Andre, thanks for the links!
I was indeed planning to take a crack at implementing some ideas. First, for my
part, I need to get approval from the people who own my intellectual property
;-)
I also figured it would take me a while to sift through the Python code, which
I have never
On Wed, Apr 6, 2022 at 7:05 PM Mike Miller
wrote:
>
> On 2022-04-06 12:36, Paul Moore wrote:
>
> > And if new syntax is a clear win even with such a library,
> > then designing a language feature that enables better syntax for that
> > library would still be possible (and there would be a clear
On 2022-04-06 12:36, Paul Moore wrote:
And if new syntax is a clear win even with such a library,
then designing a language feature that enables better syntax for that
library would still be possible (and there would be a clear use case
for it, making the arguments easier to make).
If
On Wed, 6 Apr 2022 at 16:51, Brian McCall
wrote:
> Before I get to this example, though, there is more to arguments for the
> "need" than just counter-examples. I keep using quotes because nothing is
> really a need for anything.
Yes, it's not about "need" in an absolute sense, but more about
Oops, my examples have some other problems:
> # λ = 550e-9nm
should be
> # λ = 550nm
and
> # λ = 550e-9 [nm]
should be
> # λ = 550 [nm]
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
> Thank you for all the examples, that should help a lot. Out of curiosity,
> those are the corrected versions of the code? Where was the mistake in the
> original?
Happy to help! The original was unitless altogether, so that was the first
problem. The particular error was λ. I typically work
On 4/6/22 08:50, Brian McCall wrote:
> Alright, now let's look at an example. Again, it's not my best, let's go with
it. This is just
> a calculation of the expected number of photons to reach a pixel through a
camera of a given
> f-number (F). I mentioned this has bitten me before. All that
Wow, this thread has grown quite a bit in the last two days. And there's some
really good points raised alongside the light trolling here and there. While
the discussion around implementation is important and very interesting, I think
the question around motivation is critical. Since I see some
On Wed, Apr 06, 2022 at 08:34:35PM +1200, Greg Ewing wrote:
> On 6/04/22 10:41 am, Chris Angelico wrote:
> >I don't think anyone would ever say that a
> >parsec (several light years) should be considered equivalent to a
> >second of latitude (a handful of meters) just because they both have
> >an
On 6/04/22 10:41 am, Chris Angelico wrote:
I don't think anyone would ever say that a
parsec (several light years) should be considered equivalent to a
second of latitude (a handful of meters) just because they both have
an angular size of one second!
Although if you're Han Solo then it's a
On Wed, 6 Apr 2022 at 13:33, Christopher Barker wrote:
> (or may favorite: API Gravity [2] as a density)
>
Wow, I have to remember this. I've worked with a lot of APIs in my
time, and some of them definitely are more dense than others.
ChrisA
___
> Length is measured in a variety of units, but the degree ain't one of 'em.
Mostly I was just being silly.
But the relevant part is that people do a lot of useful work using values
that are not in "proper" units, and don't follow the rules as they should.
>From things as simple as using kg as
On Wed, 6 Apr 2022 at 08:35, Greg Ewing wrote:
>
> On 6/04/22 3:47 am, Christopher Barker wrote:
> > And they are -- degrees latitude and degrees longitude are very
> > different units :-)
>
> I'm thinking more of a local Cartesian coordinate system rather
> than lat-long.
>
> Think about this:
On 6/04/22 3:47 am, Christopher Barker wrote:
And they are -- degrees latitude and degrees longitude are very
different units :-)
I'm thinking more of a local Cartesian coordinate system rather
than lat-long.
Think about this: You're driving north in a car that's 3m long.
You turn east. Do
On 6/04/22 3:30 am, Stephen J. Turnbull wrote:
suppose I
wanted to know how many cm there are in an in:
cm_per_in = 1 * in / 1 * cm
Of course that's a silly mistake, but the (sole, IMO) advantage of the
original proposal is that you can't make that silly mistake.
Well, you can make the
On Tue, Apr 5, 2022 at 11:57 AM Steven D'Aprano wrote:
> > And they are -- degrees latitude and degrees longitude are very different
> > units :-)
>
> Greg said *distances*, not coordinates or angles.
People DO sometimes use lat/lon as distances— particularly latitude, where
1 minute is a
On Wed, Apr 06, 2022 at 12:28:49AM +1200, Greg Ewing wrote:
> On 5/04/22 6:05 am, Ethan Furman wrote:
> >It seems to me that these "unitless' units actually have units, even if
> >they *appear* to cancel each other out.
>
> I think it's more that units alone don't capture everything
> that's
On Wed, Apr 06, 2022 at 12:30:47AM +0900, Stephen J. Turnbull wrote:
> Greg Ewing writes:
>
> > With my "no new syntax" suggestion there would be no question here --
> > the only way to write it would be
> >
> > height = 5 * ft + 4.5 * in
>
> I'm very sympathetic to the "no new syntax"
On Tue, Apr 05, 2022 at 08:47:52AM -0700, Christopher Barker wrote:
> On Tue, Apr 5, 2022 at 5:13 AM Greg Ewing
> wrote:
>
> > single 4-dimensional continuum, this makes about as much
> > sense as insisting that north-south and east-west distances
> > are measured in different units.
> >
>
>
I'll start with some opinionated stuff, but possibly helpful attempts
to understand the requirements follows from about the middle of the post.
Ricky Teachey writes:
> [Brian McCall] had it right in his first post that spurred this
> discussion. I'll quote bits of it:
>
> > ...I have spent
On Tue, Apr 5, 2022 at 5:13 AM Greg Ewing
wrote:
> single 4-dimensional continuum, this makes about as much
> sense as insisting that north-south and east-west distances
> are measured in different units.
>
And they are -- degrees latitude and degrees longitude are very different
units :-)
On Tue, 5 Apr 2022 at 14:25, Ricky Teachey wrote:
> units are at THE CORE of that need.
>
> i think python should be the language we reach for. i have made python work
> for me as a civil engineer and been extremely successful with it for all the
> usual reasons: ease of learning and community
Greg Ewing writes:
> With my "no new syntax" suggestion there would be no question here --
> the only way to write it would be
>
> height = 5 * ft + 4.5 * in
I'm very sympathetic to the "no new syntax" suggestion, but suppose I
wanted to know how many cm there are in an in:
On Tue, Apr 5, 2022 at 7:43 AM Steven D'Aprano wrote:
> On Mon, Apr 04, 2022 at 01:53:49PM +1000, Chris Angelico wrote:
>
> > And that's exactly why I think that the *concept* of units could be
> > added to the language, with some syntax and low-level semantics, but
> > the actual units
On 5/04/22 6:36 am, Chris Angelico wrote:
5 L/100km in SI units is 5e-3 m³ / 1e5m. That's 5e-8 m². Or if you
prefer, 50mm².
Fuel economy is a unit of area.
This misses the rather important point that it's not just
litres of empty space, it's litres *of fuel*. You really
need to consider
On 5/04/22 6:05 am, Ethan Furman wrote:
It seems to me that these "unitless' units actually have units, even if
they *appear* to cancel each other out.
I think it's more that units alone don't capture everything
that's important about the physical situation.
Another example: the capacitance
On 5/04/22 6:05 am, Chris Angelico wrote:
In any case: the
speed of light might be 1, but it's still 1 distance divided by 1
time.
If you truly embrace the idea of space and time forming a
single 4-dimensional continuum, this makes about as much
sense as insisting that north-south and
On Tue, Apr 05, 2022 at 04:05:36AM +1000, Chris Angelico wrote:
> Not sure what you mean by "geometrized", but that would be the same
> concept as referring to "natural units", wouldn't it? In any case: the
> speed of light might be 1, but it's still 1 distance divided by 1
> time.
No.
On Mon, Apr 04, 2022 at 07:42:37AM +0200, Luca Baldini wrote:
> I beg to disagree here, here---mass is measured in eV / c^2, and
> momentum in eV / c. (Although, as Brian says, we're all guilty of taking
> shortcuts in conversations.)
I beg to differ. *Real* physicists measure everything in
On Mon, Apr 04, 2022 at 04:47:12AM -, Brian McCall wrote:
> Libraries already exist, and they are not sufficient.
What are they missing?
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
On Mon, Apr 04, 2022 at 01:53:49PM +1000, Chris Angelico wrote:
> And that's exactly why I think that the *concept* of units could be
> added to the language, with some syntax and low-level semantics, but
> the actual units themselves belong in libraries.
+1 on that.
I'm not even sure about the
On 5/04/22 5:17 am, Steven D'Aprano wrote:
However, I suspect that having an array of unit objects rather than
low-level machine ints or floats will reduce the performance of numpy a
lot.
If numpy were to incorporate units, I would expect there to be
just one unit tag for the whole array.
--
On 5/04/22 12:27 am, David Mertz, Ph.D. wrote:
On Mon, Apr 4, 2022, 2:17 AM Brian McCall
> For instance, I don't think there would be much uproar if "teaspoons"
were left out of any kind of implementation.
Apparently someone other than you does the cooking in you household!
Wouldn't
On 4/04/22 7:59 pm, Chris Angelico wrote:
How often do you ACTUALLY need them to be local to a module? When is
this ever a concern?
As long as there are competing *implementations* of units there will
be potential for conflicts, even if the actual units being represented
are the same.
--
Greg
On Tue, 5 Apr 2022 at 11:44, Steven D'Aprano wrote:
>
> On Tue, Apr 05, 2022 at 04:36:24AM +1000, Chris Angelico wrote:
>
> > Some unit cancellations really do result in pure scalars. The ratio of
> > a circle's circumference to its diameter isn't a unit of m/m any more
> > than the ratio of a
On 4/04/22 3:45 pm, David Mertz, Ph.D. wrote:
An electron volt is a unit of energy. Or of mass. Or of momentum.
Well, in relativity they're all really the same thing, or
at least interconvertible.
But there are more glaring examples of this. What do you get
when you multiply a number of
On Mon, Apr 4, 2022 at 7:45 PM Ethan Furman wrote:
> On 4/4/22 13:31, David Mertz, Ph.D. wrote:
>
> > You should probably change the thread subject to "All-and-only 7 SI
> units" if that's what you mean.
>
> While I'm sure SI would be very useful, I suspect that any system will
> have to be
On Mon, Apr 04, 2022 at 11:05:54AM -0700, Ethan Furman wrote:
> On 4/4/22 08:54, Ken Kundert wrote:
> It seems to me that these "unitless' units actually have units, even if
> they *appear* to cancel each other out.
The term is *dimensionless* units.
1 dozen and 1 mole of objects both are
On Mon, Apr 04, 2022 at 04:44:58PM -0700, Ethan Furman wrote:
> Beyond that, do we make Python smart enough to, for example, convert
> `km*km` to `km^2`, or do we let libraries provide their own functions? I'm
> inclined to let libraries provide their own, as they could also implement
> unit
On 4/04/22 2:42 pm, Ricky Teachey wrote:
height = 5ft + 4.5in
Surely we ought to be able to add these values. But what should the
resulting tag be?
One answer might be that the tag only tracks what kind of quantity it
is -- length, mass, time, etc. Internally the number would be
represented
On Tue, Apr 05, 2022 at 04:36:24AM +1000, Chris Angelico wrote:
> Some unit cancellations really do result in pure scalars. The ratio of
> a circle's circumference to its diameter isn't a unit of m/m any more
> than the ratio of a circle's area to that of a circumscribed square is
> a unit of
On 4/04/22 10:47 am, dn wrote:
You wouldn't believe it - have interrupted typing here to receive a
package. However, the clothing delivered is NOT the size ordered...
Let me guess, you ordered it in cm but they delivered it in inches?-)
--
Greg
___
On 4/4/22 13:31, David Mertz, Ph.D. wrote:
> You should probably change the thread subject to "All-and-only 7 SI units" if
that's what you mean.
While I'm sure SI would be very useful, I suspect that any system will have to be useful for a much broader audience to
be accepted; given the vast
You should probably change the thread subject to "All-and-only 7 SI units"
if that's what you mean.
On Mon, Apr 4, 2022 at 1:46 PM Brian McCall
wrote:
> > I drove 20 minutes up the road to by a bushel (US, not British) of U.S.
> No. 1. apples, to make apple cider. On my return trip, I stopped
>
> Units have infinite precision, so grades and tolerances are also
> irrelevant.
>
Not if you believe in Planck lengths (or quantum states) :-).
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from
On Tue, 5 Apr 2022 at 05:47, Steven D'Aprano wrote:
>
> On Mon, Apr 04, 2022 at 03:39:26PM +1000, Chris Angelico wrote:
>
> > I would say that 2.54in/1cm should be equal to 1.
>
> 2.54 inches is not 1 cm. This is how you get a billion dollar spacecraft
> crashing into Mars instead of landing
On Tue, 5 Apr 2022 at 05:44, Steven D'Aprano wrote:
> > Should 2.54 in / 1 cm evaluate to 2.54 in/cm or should
> > it evaluate to 1? I'd much rather it evaluate to 1
>
> There are only two reasonable ways to parse that, depending on
> precedence of units and operators:
>
> * (2.54 inches) / (1
On Mon, Apr 04, 2022 at 03:39:26PM +1000, Chris Angelico wrote:
> I would say that 2.54in/1cm should be equal to 1.
2.54 inches is not 1 cm. This is how you get a billion dollar spacecraft
crashing into Mars instead of landing softly :-)
--
Steve
On Mon, Apr 04, 2022 at 04:22:25AM -, Brian McCall wrote:
[Chris]
> > Part of the problem here is that Python has to be many many things.
> > Which set of units is appropriate? For instance, in a lot of contexts,
> > it's fine to simply attach K to the end of something to mean "a
> >
On Mon, Apr 04, 2022 at 06:16:49AM -, Brian McCall wrote:
> So a comprehensive implementation of units would not require more than
> 160 units, and in reality, a "sufficient" implementation would need
> only 7.
The idea that a system which only supported the seven SI base
quantities, and
On Mon, Apr 04, 2022 at 05:45:52PM -, Brian McCall wrote:
> Anyway, you mentioned you knew of at least 1000 units. I count 7. You have
> another 993?
Will 2451 do?
[steve@ando ~]$ units
2438 units, 71 prefixes, 32 nonlinear units
--
Steve
___
On Tue, 5 Apr 2022 at 04:19, Ethan Furman wrote:
>
> On 4/3/22 22:39, Chris Angelico wrote:
> > On Mon, 4 Apr 2022 at 14:22, Brian McCall wrote:
>
> >> Related to these questions, there is the question of what to do about
> mixed systems?
> > Should 2.54 in / 1 cm evaluate to 2.54 in/cm or
On Mon, Apr 4, 2022 at 2:24 PM Steven D'Aprano wrote:
> On Sun, Apr 03, 2022 at 10:42:16PM -0400, Ricky Teachey wrote:
>
> > I was cheerleading this effort earlier and I still think it would be a
> > massive contribution to needs of the engineering world to solve this
> > problem at the language
> For example, consider currencies. There are currently hundreds of national
> currencies and thousands of cryptocurrencies. They all have the same basic
> fundamental unit of “value”, but value is only loosely defined. Furthermore,
> there is no fixed ratio between the currency and its
On Sun, Apr 03, 2022 at 10:42:16PM -0400, Ricky Teachey wrote:
> I was cheerleading this effort earlier and I still think it would be a
> massive contribution to needs of the engineering world to solve this
> problem at the language level. But boy howdy is it a tough but of a problem
> to crack.
On 4/3/22 22:39, Chris Angelico wrote:
> On Mon, 4 Apr 2022 at 14:22, Brian McCall wrote:
>> Related to these questions, there is the question of what to do about mixed
systems?
> Should 2.54 in / 1 cm evaluate to 2.54 in/cm or should it evaluate to 1?
>
> I would say that 2.54in/1cm should be
On 4/4/22 08:54, Ken Kundert wrote:
> Now consider the issue of “unitless units”. In electrical circuit we often
talk
> about gain, which it the ratio between the signal level at the output of
> a circuit relative to the signal level at the input. But you need to be
> specific about how you
On Tue, 5 Apr 2022 at 03:58, Marco Sulla wrote:
>
> On Mon, 4 Apr 2022 at 07:47, Chris Angelico wrote:
> >
> > Not a particle physicist, so I don't know what the usage actually is,
> > but wouldn't mass actually be eV/c²? If that's frequently written as
> > simply "eV", then that's another
> I drove 20 minutes up the road to by a bushel (US, not British) of U.S. No.
> 1. apples, to make apple cider. On my return trip, I stopped at the hardware
> store to buy a 2 lb box of 1-3/4" ring shank 12 penny nails. I used my 7/8
> hole kitchen planer blade to grate the apples, then
On Mon, Apr 4, 2022 at 11:55 AM Ken Kundert wrote:
> I think there is one more point worth making here. There is a suggestion
> that
> dimensional analysis can underpin a units system. Actually, the idea that
> all
> units can be broken down into a small set of fundamental units is very
>
On Mon, Apr 04, 2022 at 07:46:12AM -, Brian McCall wrote:
> Now do it for NumPy arrays
In response to Greg:
[quoting Greg]
I'm not convinced there's a need for new syntax here.
63*lbs
77*km/hr
With appropriate definitions of lbs, km and hr these
can be made to construct numbers
On Mon, 2022-04-04 at 09:14 -0700, Ken Kundert wrote:
> As why it is naive, see my previous post where I talk about the
> limitations of dimensional analysis.
>
> As a point of reference, I have been developing software for
> electrical engineers for over 40 years. That software uses physical
>
Just to elaborate on units I use, here's a hypothetical (not stuff that
actually happened today, but very commonplace nature):
I drove 20 minutes up the road to by a bushel (US, not British) of U.S. No.
> 1. apples, to make apple cider. On my return trip, I stopped at the
> hardware store to buy
As why it is naive, see my previous post where I talk about the limitations of
dimensional analysis.
As a point of reference, I have been developing software for electrical
engineers for over 40 years. That software uses physical quantities (voltage
current, resistance, capacitance, etc.)
As why it is naive, see my previous post where I talk about the limitations of
dimensional analysis.
As a point of reference, I have been developing software for electrical
engineers for over 40 years. That software uses physical quantities (voltage
current, resistance, capacitance, etc.)
I think there is one more point worth making here. There is a suggestion that
dimensional analysis can underpin a units system. Actually, the idea that all
units can be broken down into a small set of fundamental units is very limiting
and results in many vexing issues.
For example, consider
1 - 100 of 134 matches
Mail list logo
