Brainstorming --

[ChristopherRabotin]

Hi Juan,

As discussed on OpenAstrodynamics, I am interested in a fast unit library. My application would need both Rust and Python support. Anyway, I fed the the video from your readme to ask-claude, and been asking it questions. It recommended the following ideas that I thought might be useful:

Question > Here's what I've been told about unit libraries: "the key idea is to abandon symbolic algebra engines for this, since usually people just want the 7 fundamental units and this number can be hardcoded upfront, saving a ton of complexity". What do you think?

This is an interesting perspective on unit libraries. There are a few arguments on both sides here:

For (abandoning symbolic algebra)

• Simplicity - Hardcoding the set of fundamental units upfront avoids the complexity of implementing full symbolic unit conversion logic. This makes the library easier to develop and maintain.

• Performance - Avoiding the symbolic logic leads to better performance, since you don't have the overhead of the reasoning engine. You have a predefined set of unit ratios to work with.

• Limited use cases - For many basic use cases, the 7 fundamental SI units are sufficient. Only a subset of users will need more complex unit definitions.

Against

• Inflexibility - The library is limited to a fixed set of units. Users can't define their own units or handle non-standard units. Dimensional analysis is limited.

• Incorrectness - Without dimensionality checking, invalid unit operations could be allowed, producing incorrect results.

• Lack of precision - For exact unit conversion between arbitrary units, symbolic logic is needed. Hardcoding a set of conversion factors loses this precision.

• Unrealistic for some domains - Many specialized domains require far more than just the 7 SI units. Anything requiring imperial/US units would not work.

My view

For a basic introductory unit library or limited use cases, hardcoding a set of fundamental units and ratios is a pragmatic approach that avoids a lot of complexity. However, for a fully-featured, correct, and flexible unit library, symbolic logic is ultimately needed.

The ideal solution is probably a hybrid, e.g.:

1. Hardcode a limited set of fundamental units and the logic to handle them. This covers many simple use cases efficiently.

2. Build a symbolic logic/CAS layer to handle arbitrary units, non-standard units, dimensionality checking, etc. for users that need it.

3. Make the symbolic layer optional, and have a simple API so basic users aren't exposed to the complexity.

4. Explore performance optimizations/limitations of the symbolic layer, since speed is a concern.

So in summary, I would not abandoned symbolic algebra altogether for a serious unit library, but would use it judiciously in a way that balances simplicity, correctness, and performance for a wide range of use cases. With some creativity, it is possible to gain most of the pros of both approaches. But clearly defining the scope of your library will help determine whether a purely hardcoding approach would be sufficient or not.

Does this help explain my perspective on the trade-offs here? Let me know if you have any other questions!

[astrojuanlu]

Inflexibility - The library is limited to a fixed set of units. Users can't define their own units or handle non-standard units. Dimensional analysis is limited.

Sorry but, as expected from an "AI" model, this is bullshit 😉

https://github.com/astrojuanlu/fastunits/blob/ae149d0e2cc7e91b3e6024aa22162633cf510402/experiment.py#L10-L18

Maybe I'm not explaining well what "abandon symbolic algebra" means. The 7 fundamental SI dimensions are hardcoded for the default unit system:

https://github.com/astrojuanlu/fastunits/blob/ae149d0e2cc7e91b3e6024aa22162633cf510402/src/fastunits/dimensions.py#L11-L13

But the user can define their own:

https://github.com/astrojuanlu/fastunits/blob/ae149d0e2cc7e91b3e6024aa22162633cf510402/experiment.py#L7-L8

The key is that, within a given unit system, operations are well defined and generic symbolic algebra is not needed:

This means that one can avoid sympy, unlike projects like unyt:

https://github.com/yt-project/unyt/blob/b9c4c21b2e27fd4af9fafa1949dc01296125543c/unyt/unit_object.py#L23-L37

and instead use well defined operations between units:

https://github.com/astrojuanlu/fastunits/blob/ae149d0e2cc7e91b3e6024aa22162633cf510402/src/fastunits/quantities.py#L27-L37

https://github.com/astrojuanlu/fastunits/blob/ae149d0e2cc7e91b3e6024aa22162633cf510402/src/fastunits/units.py#L70-L97

[astrojuanlu]

Lack of precision - For exact unit conversion between arbitrary units, symbolic logic is needed. Hardcoding a set of conversion factors loses this precision.

I think this is a niche use case.

Unrealistic for some domains - Many specialized domains require far more than just the 7 SI units. Anything requiring imperial/US units would not work.

This is another bullshit "AI" answer. There are 7 dimensions regardless of unit system.

Imperial/US units support would be nice, yes. The way to achieve that would be to define conversion factors within a given unit system. It's not difficult with the current system.

[astrojuanlu]

I appreciate your good intention @ChristopherRabotin, but I am not happy with using "AI" to try to reason about difficult engineering tradeoffs. I am happy to do some brainstorming but I would like to ask you to read the code and the resources that are linked in the README.

fastunits is a proof of concept, not even a fully working prototype, but the operation overloading between dimensions, units, and quantities is what makes it unique. This can be extended for floating point and symbolic arithmetic, while saving complexity from overly generic approaches.

[ChristopherRabotin]

Thanks for taking the time to answer. Yup, lots of these answers by the generator aren't great. I'll read through the proof of concept code

On Thu, May 25, 2023, 05:47 Juan Luis Cano Rodríguez < @.***> wrote:

I appreciate your good intention @ChristopherRabotin https://github.com/ChristopherRabotin, but I am not happy with using "AI" to try to reason about difficult engineering tradeoffs. I am happy to do some brainstorming but I would like to ask you to read the code and the resources that are linked in the README.

fastunits is a proof of concept, not even a fully working prototype, but the operation overloading between dimensions, units, and quantities is what makes it unique. This can be extended for floating point and symbolic arithmetic, while saving complexity from overly generic approaches.

— Reply to this email directly, view it on GitHub https://github.com/astrojuanlu/fastunits/issues/6#issuecomment-1562763364, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEZV2GTWFBOTQGQL5G2A4DXH5BGLANCNFSM6AAAAAAYOIXSM4 . You are receiving this because you were mentioned.Message ID: @.***>