[bananaflag]

I think your interface is a bit inconsistent, this is why people ask that question.

If you have

65mi in 12mi/h -> 19500s

then instead of

12h in s -> 43200s

you should have

12h in s -> 43200

Then a unit at the end should mean that not all dimensions have been reduced.

In the same vein, in the README, the "weird results" section should come after the "dimension removal" section. The way it is now, the apparent "bug" comes before the feature.

[bjoli]

You are right about this being confusing. I have thought about whether to adopt in as strict division or whether to be strict about in UNIT to have to produce UNIT. The first one will not resolve the issue of Umits selecting becquerel or Hz to represent N/s, but the second is not as much fun.

[bananaflag]

I think the behaviour is good as it is, it is just the output display that should be consistent (as I suggested in my example).

[bjoli]

Yes. But treating in a strict division isn't really what people expect. Then 12mi/h in km/h becomes "19.3xyz" not "19.3xyz km/h".

The least surprising thing would be to enforce unit output. If I say I want "in km/h" the output should be in km/h or show an error. It is however less fun. Getting becquerel when you forget a unit along the way is the kind of spice that makes life fun.

Treating "in" as strict division also doesnt solve the surprise of getting Bq or Hz when you accidentally end up with something that is N/s