3 ms·

Hah! I wrote a unit converter for Android recently and that is one of the criticism I get. "Why does my conversion end up in becquerel?" It is usually because p

by bjoli 6mo ago

Hah! I wrote a unit converter for Android recently and that is one of the criticism I get. "Why does my conversion end up in becquerel?" It is usually because people forgot to divide by time, where they write something like "(31l/m2)/1min in mm" when they should have have written something like "(31l/m2)/1min in mm/h". Anyway, check it out here: https://github.com/bjoli/Umits https://github.com/bjoli/Umits I am about 6 days away from publishing and open beta (currently in mandatory closed testing). If you want to join the closed test, you can do so by mailing me at the email at the top of the readme.

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 ago
  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 6mo ago
    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 6mo ago
      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

by bjoli 6mo ago

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 ago
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 6mo ago
  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 6mo ago
    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