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

adding units #20

Open
maadcoen opened this issue Dec 11, 2024 · 3 comments
Open

adding units #20

maadcoen opened this issue Dec 11, 2024 · 3 comments

Comments

@maadcoen
Copy link

Hi!

I was wondering whether it wouldn't make sense to add unit support to the Number class, so that you can do something like this:

distance = Number(1, 0.1, unit="m")
distance.str() # -> "1 +-0.1 m"
distance.unit # -> "m"

This is in any case useful to make the numbers more meaningful and might also be used to throw errors when trying to add / subtract numbers with different units from one another.

cheers

Maarten

@riga
Copy link
Owner

riga commented Dec 12, 2024

Hi @maadcoen !

Thanks for the suggestion. While I like the general idea, and tbh I had this on my list a couple years ago, the implications this comes with are pretty complicated.

Some examples

a = Number(1, 2, unit="m")
b = Number(3, 4, unit="s")
c = a + b

What is the unit of c?

a = Number(1, 2, unit="m")
b = Number(3, 4, unit="mm")
c = a + b

Should b be interpreted as 0.003 ± 0.004 due to the mili m? Should the leading m be parsed as 0.001 in the first place?

a = Number(1, 2, unit="m")
c = 2 ** a

Unit of c?


I guess you can see that it's really highly non-trivial to implement units consistently and correctly for generic use cases, and imho this is why most libraries just don't.

@maadcoen
Copy link
Author

maadcoen commented Dec 12, 2024

Yeah, I can see that is an issue. Maybe it would be a solution to just avoiding interpreting the unit at all, and dropping it as soon as an operation is performed? the main reason I would be interested in it, is anyway not for the unit algebra, but just for documentation purposes. I.e. when I have a list of cross sections, I can access the exact units I have inserted the numbers with.

A bit more advanced might be to just copy the operation to the units so that at least a history is conserved I.e.

a = Number(1, 2, unit="m")
b = Number(1, 1, unit="s")
a ** 2 -> Number(1, 4, unit="m ** 2")
a / b-> Number(1, ..., unit="m / s")
a * b-> Number(1, ..., unit="m * s")

Regarding the examples you give, they should throw an error, since adding different units doesn't make any sense. It does, maybe, if only the SI prefix differs but then one might opt not to implement this at all and treat them just as different units. Conversion is then left to the user (which is now anyway also the case). Also taking powers of dimension full numbers is senseless. I don't know, furthermore, what scinum does to more advance operations (like np.sqrt, np.log ...) but those could potentially be made illegal as well if there is no easy way to account for them too.

So, in summary, I'd suggest to implement units partially, and in case things get problematic to throw an error, or a warning and drop the units.

@riga
Copy link
Owner

riga commented Dec 12, 2024

I agree with you regarding the benefit for documentation, but I'm opposed to introducing a feature that is meant to work only in edge cases but at the same time requires a variety of core changes. If you manage to find a lightweight solution I'm open for PRs though :)

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

No branches or pull requests

2 participants