4 ms·
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
by bananaflag 6mo ago
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 6mo agoYou 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 6mo agoI 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 6mo agoYes. 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