Why @ symbol for units?

Reading through documentation, it uses R2=2@u_Ω for units, and says this causes operator precedence problems.

Why not just use multiplication for units? That’s what sympy.physics.units, pint, quantities, natu use

I do not understand what you mean exactly by multiplication. Providing an example would be helpful.
For my own part, I simply use floating pointing numbers. So resistors are usually in kiloohms so a 4k7 resistor is simply 4.7e3, a 100K resistor 100e3 and so on. For capacitors, I would put 2.2e-6 for a 2.2 microfarad capacitor. I have not yet found a need for units. They may make the code more pretty though.

I was reading through the examples, which have code like:

circuit.V(‘input’, ‘in’, circuit.gnd, 10@u_V)
circuit.R(1, ‘in’, ‘out’, 9@u_kΩ)
circuit.R(2, ‘out’, circuit.gnd, 1@u_kΩ)

https://pyspice.fabrice-salvaire.fr/examples/resistor/voltage-divider.html

So the units are being added onto the values using the matrix multiplication operator @.

Other Python units-aware packages use the multiplication operator to combine number with units. For example, Pint uses the syntax:

>>> import pint
>>> u = pint.UnitRegistry()
>>> 3*u.meter + 4*u.cm
3.04 meter
>>>  (3*u.A * 5*u.Ω).to(u.V)
15.0 volt

Also it might be cleaner to import a single Units object instead of many separate ones?
import PySpice.Unit as u and u.kΩ, instead of from PySpice.Unit import * and u_kΩ? It would make linters happier to not have an asterisk import, at least.

Or maybe make it use one of these existing libraries that already defines the units and handles the conversions between them?

  • Notice Unit is mandatory and shoud be a package out of PySpice
  • Unit feature was an experimental dev and it was more difficult to implement than expected …
  • At that time I did not found a good Python package to do the job (looked natu and python-quantities) I remember some packages was badly implemented
  • Thus Unit could be flawed and yes I discovered an issue with @ precedence

Some links on Pint

Concerning the @ precedence issue, it will not change until a large group of Python users think it is the right idea and want it …

Such a package like Pint has probably improved over the time. I must find some time to look at it.

I didn’t had the time to promote PySpice.Unit these last years, so it stalled and it is code to maintain … so best would be to have an external package to do the job !

1 Like

I tried to make a comparison of unit packages here:

https://socialcompare.com/en/comparison/python-units-quantities-packages

Pint seems to be the most popular units-only package (scipy is just a list of conversion constant, not actual unit objects)

@endolith I started to write a unit example to document the topic and to show issues with Pint, PySpice Unit has some features that make it works with Spice.

But clearly a unit package is out of scope of PySpice, we just need a small wrapper.