Use the most appropriate unit to reduce the number of digits when displaying something

[irevoire]

Hey,

It would be nice if numbat could find the most appropriate unit to display stuff.
For example, lately, I was trying to compute how long I could run an esp32 on two AA batteries. Depending on the mode used by the esp32, the duration could simply go from a few hours to 10 years.
If numbat had been able to switch between hours, days, months (weeks?), and years, it would have been way easier to read the results and try stuff out

[sharkdp]

It would be nice if numbat could find the most appropriate unit to display stuff.

See also: #219 (comment)

For example, lately, I was trying to compute how long I could run an esp32 on two AA batteries. Depending on the mode used by the esp32, the duration could simply go from a few hours to 10 years.
If numbat had been able to switch between hours, days, months (weeks?), and years, it would have been way easier to read the results and try stuff out

Not as general as what you're asking, but you can use human for times. Currently only supports "day" as the largest unit, but that will be changed to include months and years in #425

>>> 1e5 s -> human

    = "1 day + 3 hours + 46 minutes + 40 seconds"    [String]

>>> 1e8 s -> human

    = "1157 days"    [String]

[irevoire]

Nice. I didn't know about human for time; that would have been enough for me in the end.

But yes, I guess I want the same thing as #219:

I'm looking for is a -> human for all units

And I believe it should be used by default.

Feel free to close the issue if you think it's already sufficiently tracked somewhere else

[Goju-Ryu]

I'd prefer this to be opt-in and not default. My reasoning is that I often want to keep calculations in the same units I used for consistency. It could also possibly interfere with functions providing specific generic unit guarantees depending on implementation. I’m especially thinking of the generic unit list functions I have been working on recently.

I do find the feature useful though and something like a generic conversion function or keyword to get the best fit would be great. Something like the following would be ideal syntax in my opinion.

>>> 10m * 100m -> auto
1km : Length

This would also make it easy to extend the API with curried functions to allow some control over what the best fit would be as in the example below.

>>> 100m + 1km -> auto_max_decimals(1)
1.1 km : Length

>>> 100m + 1km -> auto_max_decimals(0)
1100 m : Length

[irevoire]

I like the -> human syntax that we already uses for date.
Maybe we could just try to make it work for everything