Omit fundamental constants in scientific unit conversions? about numbat HOT 4 OPEN

This is a bit annoying since currently there is no difference between Hz and rad/s, which imo there should be a 2*pi.

If you are interested in the background, please see #167 and #91

I would restrict to just fundamental physical constants.

Ok, but this would mean that we would have to hard-code things. Or add a new decorator for this.. something like @fundamental_constant.

I would like it better if we could come up with something more flexible, even if it's not 100% as convenient.

For example, I was recently thinking about some kind of Buckingham-pi-theorem-solver inside Numbat which could look like (syntax up for discussion)

construct<D: Dim>(quantity1, quantity2, …, quantityN)

which would take an arbitrary dimension type D and a list of quantities. It would then search for a solution to the equation

type(quantity1^alpha1 * quantity2^alpha2 * … * quantityN^alphaN) == D

For example: construct<Energy>(mass, velocity) would return mass * velocity^2 (in some way). And construct<Frequency>(energy, ℏ) would return energy * ℏ^-1.

That wouldn't directly help with your use case, but it might be a very useful building block for other features.

from numbat.

How would you design this feature?

If someone types 2meV -> THz, we currently show a type error (lhs: Energy, rhs: Frequency). Numbat can infer that a factor of type Time / (Length² × Mass) = 1 / Action is missing on the left hand side. We can even get it to output that for us using the new typed-hole (?) feature:

>>> 2meV * ? -> THz
error: Found typed hole
  ┌─ <input:11>:1:8
  │
1 │ 2meV * ? -> THz
  │        ^ Time / (Length² × Mass)
  │
  = Found a hole of type 'Time / (Length² × Mass)' in the statement:
  =   2 millielectronvolt × ? ➞ terahertz

We could now go through all defined constants and see if something matches the type of that hole. We actually do that already if we help a bit (see the relevant matches in the last line):

>>> 2meV / ? -> THz
error: Found typed hole
  ┌─ <input:10>:1:8
  │
1 │ 2meV / ? -> THz
  │        ^ Action or AngularMomentum
  │
  = Found a hole of type 'Action or AngularMomentum' in the statement:
  =   2 millielectronvolt / ? ➞ terahertz
  = Relevant matches for this hole include:
  =   planck_constant, ℏ, h_bar, ℎ

But then how do we proceed? Do we take ℏ or ℎ? Show the result for both? And that ambiguity would probably be much bigger for other physical dimensions (speed of light? speed of sound? Escape velocity of planet Earth?).

I would like to avoid having to hard-code any rules, if possible.

from numbat.

Thanks for taking all these considerations! Yeah it needs to be more aware of the physical context, e.g., if it is converting to THz or Hz, it would use h, if it is rad/s, it would use ℏ. (This is a bit annoying since currently there is no difference between Hz and rad/s, which imo there should be a 2*pi.)

For other physical dimensions that might have bigger ambiguity, I would restrict to just fundamental physical constants. Pbb only the following three the majority of times:

• the gravitational constant G
• the speed of light c
• the Planck constant h or ℏ

If e.g. the speed of sound is involved, the user pbb should define it and use in the calculation.

This feature would really be for convertion between historical and research field specific conventions of units, like cm^-1 used for MIR and Raman spectroscopy (and converting it to frequency or wavelength), eV used for high energy physics (and converting it to mass or frequency). Not that many use cases but would save quite some time every now and then.

from numbat.

Thanks for the background!

I do think the fundamental constants are worth having their own decorators, they are the privileged ones (Units are all made-up in a sense that they are convertible by the fundamental constants). There is really no ambiguity on how to convert from eV to rad/s or um.

I also like the general idea of a solver to construct a dimension from other given ones, would be super helpful for dimensional analysis and order-of-magnitude estimations. Can we have both? blush

from numbat.