6

As an electrical engineer I (we?) use python for helping out with calculation/automation/etc.

When dealing with calculations using some real-world numbers it is VERY common to think in -nano, -pico, -tera, etc. way.

For example: I know what a 1pF capacitor is, but 1e-12 F capacitor is somewhow less friendly. Also, it is 4x more typing (1p vs 1e-12) and more error prone. Not to say that when displaying numbers, having suffixed number is simply easier.

So the question is: is it possible to have this working in python (IPython?):

L = 1n
C = 1p
f = 1/(2*pi*sqrt(L*C))
print(f) gives: 5.033G (or whatever the accuracy should be)

It would be incredibly useful also as just a calculator!

Thanks.

UPDATE: What I look for is not units handling, but just suffixed numbers handling. So don't care whether it's a farad or a kilogram, but DO care about the suffix (-n,-u,-m,-M,-G...)

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
ronszon
  • 2,997
  • 4
  • 19
  • 16
  • More generally, it would be great to have a module for Python that could [deal with units as Frink can](http://futureboy.us/frinkdocs/#SampleCalculations) :) – Mark Longair Mar 19 '11 at 09:02
  • ... although it seems that there are [quite a few options](http://mail.python.org/pipermail/python-ideas/2010-March/006899.html) – Mark Longair Mar 19 '11 at 09:11
  • 1
    Well, maybe the farad made it confusing. I don't look for support of units (or converting between them) but *simply* support for suffixed number parsing. so that 1p is the same as 1e-12 – ronszon Mar 19 '11 at 09:21
  • I know - I was just mentioning them out of interest (or amusement in the case of Frink) - which is why that was just a comment – Mark Longair Mar 19 '11 at 10:08

4 Answers4

3

Sure. Just write your own parser and generate your own AST with Python's language services.

Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
  • 1
    @delnan: CPU is cheap, programmers are expensive. "Practical" is relative. – Ignacio Vazquez-Abrams Mar 19 '11 at 09:02
  • Uii...! This look powerful, but not being _exactly_ a programmer but an engineer I look for something existing :) – ronszon Mar 19 '11 at 09:28
  • @Ignacio: I mean impractical as in "someone needs to write that parser, and that someone will need quite a while and experience with parsing". –  Mar 19 '11 at 09:52
  • Any idea if anybody DID write such parser? It seems like the best idea I got. – ronszon Mar 21 '11 at 06:42
  • Also I wonder why this could not make it to standard python syntax? there are no variable names starting with a number, so 1n, 150M is quite natural way to express a number... Or is there a wall I do not see? – ronszon Mar 21 '11 at 06:43
3

You could create a module with all the necessary units as symbols, say units.py, containing something like

pico = 1*e-12
nano = 1*e-9
micro = 1*e-6
mili = 1*e-3 

Farad = 1

pF = pico*Farad
nF = nano*Farad

then in code, 50pF in Farads is

units
50*units.pF
juanchopanza
  • 223,364
  • 34
  • 402
  • 480
  • Yes, of course, but this does not bring any simplicity does it? – ronszon Mar 19 '11 at 09:19
  • 1
    I guess it depends on your idea of simplicity. To me is seems easier and more scalable than writing a parser. – juanchopanza Mar 19 '11 at 09:28
  • yes, but it does not need to be VERY scalable and extensible, as there are only 21 (http://en.wikipedia.org/wiki/Order_of_magnitude) values necessary... – ronszon Mar 19 '11 at 09:59
  • Sure, but you may want to apply the order of magnitude to dimensions other than Farad. This approach deals with magnitude and dimension, however this may be more than what you need. – juanchopanza Mar 19 '11 at 10:12
  • Indeed. For managing real 'units' there is plenty of packages, but not for managing _just_ the numbers... – ronszon Mar 19 '11 at 10:18
1

Does not make much sense to introduce complexity in the language for something that can be simply be solved with proper naming and functions:

L_nano = unit_nano(1)
C_pico = unit_pico(1)
f = 1/(2*pi*sqrt(L*C))

print(to_Giga(f)) gives: 5.033G
fabrizioM
  • 46,639
  • 15
  • 102
  • 119
  • Yes, of course, but what I am looking for is **simplicity** not complexity. This is more complex then just 1p, isn't it? – ronszon Mar 19 '11 at 09:20
  • Is it? Write the parser code as Ignacio told you and then we can compare – fabrizioM Mar 19 '11 at 09:22
  • Indeed, the extra work here is zero and big there, but afterwards the usability difference is HUGE (again, 1p agains 1e-12 against unit_pico(1)) – ronszon Mar 19 '11 at 10:02
1

The examples that come with pyparsing include a simple expression parser, called fourFn.py. I adapted it to accept your suffixed literals with about 8 lines of additional code, find it here. This change supports the standard suffixes, with the exception of "da" for 1e1, since I was limited to using single characters, I used "D" instead.

If you want to make this into an interactive calculator, you can adapt Steven Siew's submission using the same changes I made to fourFn.py.

PaulMcG
  • 62,419
  • 16
  • 94
  • 130
  • Hm. yes that should work in an application such as a calculator, however, not in "normal" python. Either way thanks, that can actually be useful. I guess the custom parser solution is the closest... – ronszon Mar 21 '11 at 06:41