Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metrology module (a different implementation of the units module) #9763

Open
cousteaulecommandant opened this issue Aug 18, 2010 · 8 comments

Comments

@cousteaulecommandant
Copy link

This is a module that implements physical units in a more convenient way than the already existing units module: instead of creating separate variables for each unit, it creates an object containing the value, the dimension (mass, length, time...) as a list, and the units as an expression, plus the conversion factor.

It includes an easy-to-use function to create units from a string, implements SI prefixes and has a nice LaTeX output.

TO DO: Add more units (there are currently only 74, plus 13 constants), review the documentation and code in case it doesn't follow the Sage style, modify sage/symbolic/all.py to include this module (adding "import metrology" causes Sage to throw exceptions when starting).

CC: @kini

Component: symbolics

Keywords: units, SI, metrology

Author: Javier Mora

Reviewer: Burcin Erocal

Issue created by migration from https://trac.sagemath.org/ticket/9763

@cousteaulecommandant
Copy link
Author

Attachment: trac_9763_add_metrology.patch.gz

Creates the metrology.py file, but doesn't edit the corresponding all.py

@cousteaulecommandant
Copy link
Author

The metrology.py file itself, in case it's preferred

@cousteaulecommandant
Copy link
Author

Attachment: metrology.py.gz

Example of usage, Pi theorem

@cousteaulecommandant
Copy link
Author

comment:1

Attachment: example_metrology.sage.gz

@burcin
Copy link

burcin commented May 10, 2011

comment:3

This needs more work as stated in the ticket description and seen by the fact that not all functions included have doctests.

I don't think it makes sense to have 2 different units modules. I suppose the goal here is to replace the existing one at some point. Is the functionality here a clear extension of the existing one? Is there anything that the current module does that this will not be able to do? (I never used the units module.)

Besides the questions of functionality, here are a few things I noticed when I read the patch:

  • The Units class should derive from SageObject.
  • I don't think introducing a function named U to the top level namespace is appropriate. Users which need this functionality so often can define such a shortcut in their initialization file.

@burcin
Copy link

burcin commented May 10, 2011

Reviewer: Burcin Erocal

@cousteaulecommandant
Copy link
Author

comment:4

As burcin said, the idea was to have this as a replacement for the current units module, without removing the old one. (Another idea was to call it units2, but that looked kind of ugly)

Making Units derive from SageObject might be a good idea; however I didn't know much about Sage (nor do I now, actually) so I didn't consider this possibility. Maybe a Units ring could be made too.

The U() function was called this way so one could create units conveniently, like

from metrology import U
length = U("1 m")

However, it's not necessary to have this function on the top level namespace, and Python guidelines usually suggest something like

import metrology
length = metrology.U("1 m")

As for advantages/disadvantages, well, I don't remember them all, but here's a rough list:

Pros

  • Create units from a text string, including multiples and fractions.
  • LaTeX representation of units.
  • Abstraction of units, as (value, unit !SI value, unit dimmensions), which allows to know the mass-length-time decomposition of the magnitude.
  • 0 * 1m = 0 m, not just 0. Also, it's possible to convert from 0 degrees Celsius to Fahrenheit, which is impossible with the current units module.

Cons

  • Units is a class written from scratch, with all operations (__add__(), __mul__()...) coded explicitly.
  • Interoperability with other data types (for example, a matrix of units) might be messy.
  • The units module has a pretty nice documentation for each unit, not present in this module.
  • It's very incomplete, missing a lot of units.

@cousteaulecommandant
Copy link
Author

comment:5

(Apparently I forgot the space before each "*", resulting on a bad formatting. Since comments cannot be edited, I'll put the points again here for better readability)

Pros

  • Create units from a text string, including multiples and fractions.
  • LaTeX representation of units.
  • Abstraction of units, as (value, unit SI value, unit dimmensions), which allows to know the mass-length-time decomposition of the magnitude.
  • 0 * 1m = 0 m, not just 0. Also, it's possible to convert from 0 degrees Celsius to Fahrenheit, which is impossible with the current units module.

Cons

  • Units is a class written from scratch, with all operations (__add__(), __mul__()...) coded explicitly.
  • Interoperability with other data types (for example, a matrix of units) might be messy.
  • The units module has a pretty nice documentation for each unit, not present in this module.
  • It's very incomplete, missing a lot of units.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants