203 comments

[ 2.6 ms ] story [ 233 ms ] thread
Hi HN! This has been posted a few months ago (by someone else), but it wasn't really finished back then. The feedback I got here last time has helped a lot to improve all sorts of things. Looking forward to your comments!

Old discussion: https://news.ycombinator.com/item?id=13909631

Very well polished. Congrats on finishing it!

I have only one minor issue: the REPL scrolling conflicts with the default scrolling acceleration on macOS. So just a very small movement on the trackpad and it scrolls all the way up or down. I believe this is due the "jquery-mousewheel" plugin [1].

[1]: https://github.com/jquery/jquery-mousewheel/issues/36

Thank you very much.

I'll look into this. Thank you for the reference.

This is pretty cool, it's one of the rare applications I've used where the things I've tried "just work". For example "10 kg to g", "c", "c to km s^(-1)", "c to km/s" all work intuitively. It's great it works at the command line too.

Something I wish I'd had when I was studying Physics.

All of these things work in Google, btw. Google has one of the best unit conversion tools, and it's built into the search.
I've always been frustrated by how Google's unit conversion doesn't integrate well with its calculator.
That's why 99% of the time there's no need to use the calculator, just type your formula straight into the search.
And use a remote server with at least 1RTT of delay to do basic arithmetic. Big Data indeed.
It's not so basic though. Google knows the current value of most currencies, for instance. It's actually more efficient for the central servers to pull that data and the clients to query once in a while, rather than every single client (local calculator) to constantly keep all that data up to date. And that's just the currencies.
How many times in you lifetime does the inches-meters conversion rate will change?

Currencies I can understand hitting a remote server, but general unit conversion and basic arithmetic?

Also, how that statistic goes? Each Google search costs burns them about $1 in electricity costs? ;).
How is wolfram alpha? I always use it for more complicated pure math, but I don't think I ever used it for unit conversion.
It's great at unit conversions. You can do things like "number of milliseconds between amsterdam and paris at speed of sound". I use it all the time.
Your query doesn't exactly work though, it's interpreted as "paris at speed of sound". However "time between amsterdam and paris at the speed of sound in milliseconds" does work, returning 1.26*10^6 ms.
(shame smiley) I could've tested the query, but I wrote it on mobile.
Hahah, I was also on mobile. The mobile website of Wolfram Alpha works pretty good, they also have an app but haven't tried it yet.
You can convert 100m to femtoparsecs, for example.
Oh wow, even microparsec/kilofortnight in m/s works now. This did not work for many years, and prompted me to write my only ever e-mail to Google with a complaint about 5 years ago.

Unfortunaetly, the conversion 30 miles per gallon in liter/100 km still displays an equal sign, which is technically wrong. However, this conversion is so useful, that I won't complain about it.

Plus exchange rates

10EUR + 11 USD + 1500 USD + 500CAD in ZAR

I always used my HP48; it had great unit support.
Thank you very much for the feedback!
GNU units(1)
Included on OS X, too! (though apparently a BSD version). Wow, I did not know this.
That's very much the BSD version, which is far more limited in capabilities.

GNU Units is available under homebrew (as "gunits" IIRC).

(comment deleted)
Looks nice! are you relying on mathjs? I think it has some of the same functionality.

If not, is the conversion logic in an npm package?

package.json and bower.json does not include mathjs, so it doesn't seem like it does rely on mathjs.
Hi Sharkdp, wonderful product. I think that unit and command autocompletion would be super useful!
Hi, thank you very much for the feedback. Actually, autocompletion should work already?
(comment deleted)
I like this, but would really like a convert-to-base-units function.

  ≫ sqrt(1/(eps0 mu0)) ->m/s
    sqrt(1 / (eps0 × mu0)) -> m / s
     = 299833000 m/s
  ≫ sqrt(mu0/eps0) ->ohm
    sqrt(mu0 / eps0) -> Ω
     = 377.031 Ω
Fun fact: Converting to a unit is exactly the same as dividing by it (temperatures are the exception), so this works too:

    ≫ sqrt(mu0/eps0) / ohm
      sqrt(mu0 / eps0) / Ω
       = 376.73
Also seems like the constants (!) got changed a bit since you executed this
Thank you for the feedback! I'm open for any syntax suggestions.
Maybe something like SI(sqrt(1/(eps0 mu0))) = 299792458 m/s factor(sqrt(mu0/eps0),ohm) = SI(sqrt(mu0/eps0)/ohm)*ohm = 376.730 Ω
I tried to enter

  3 5
which was interpreted as 3 * 5. Seems a bit risky to me :) Otherwise looks neat.
Thank you for the feedback. That is intentional. Whitespace (or even lack thereof, as in "2x") is implicit multiplication. Otherwise, you'd have to write multiplication signs everywhere:

  2*sin(5*cm/(2*m))
Yes, whitespace as multiplication between number and unit or variable will be expected as multiplication but you can consider warning users about whitespace between two number literals because that could be just a typo.
Looks pretty nice, but no light years? No attoparsecs? You don't even have hogsheads or fortnights!!!!!1!

Still, it's pretty good.

(comment deleted)
Thank you for the feedback. I'm always open for suggestions on new units (https://github.com/sharkdp/purescript-quantities)!
Yes, please add light years, parsecs. Perhaps weight of planets in our solar system, and the sun?
lightyears and parsecs are here, now.
lightyears, (atto)parsecs and fortnights are now supported.
Hmm, I find the auto-associativity to be a bit weird for example:

≫ 1/12 c

  1 / (12 × c)
   = 2.7797e-10 s/m
Thank you very much for the feedback!

This is on purpose (see operator precedence rules: https://github.com/sharkdp/insect#reference). Implicit multiplication (without an explicit multiplication operator) has a higher precedence than division in order for something like this to work:

  tan(15cm/3m)

  = tan(15cm/(3m))
On the other hand, explicit multiplication has a lower precedence than division, so you would have to write "1/12*c". I agree that it can be confusing at times (that's why there is a pretty printer), but I don't want the language/parser to be whitespace-aware.
See how GNU units resolves this:

  1/10 m -> 0.1 / m
  1|10 m -> 0.1 m
  27 ^ 2/3 -> 243
  27 ^ 2|3 -> 9
You get the gist of it - a division operator with insane precedence.
Ha! That's a really neat idea. Thank you for sharing this. I'll consider adding it.
Apparently unit-less constants should bind stronger:

1/4 s - > (1/4) s

1 m / 4 s - > (1 m) / (4 s)

Looks really nice!

≫ exp(2*kg/s)

  exp(2 × (kg / s))

  Conversion error:
    Cannot convert quantity of unit kg/s to a scalar
Excellent!

Is there any way I can save a list of variables to file and then reload them?

I also would like to vote for supporting imaginary numbers (Issue #47).

Thank you for the feedback!

> Is there any way I can save a list of variables to file and then reload hem?

Not yet, no - thank you for the suggestion. The command-line version can read from a file, though (https://github.com/sharkdp/insect/issues/40)

Great work indeed. I'd also love to see support for complex numbers. A big differentiator over other calculators.
It unfortunately fails my go-to test for these calculators:

    ≫ 7.8L/100km -> miles/gallon
      7.8 L / 100 km -> mi / gal
      Conversion error:
        Cannot convert unit L/km (base units: m²)
                    to unit mi/gal (base units: m⁻²)
That's because your unit conversion is invalid. It's entirely possible to construct an equation that computes mi/gal from L/km (or from gal/mi for that matter), but the dimmensionalty of the two numbers clearly disagree. Yes, you can introduce scenarios like yours where "any human" would know what the intended meaning of the question is, but mathematically speaking it's incorrect and encouraging a calculator to perform mathematically incorrect operations is a recipie for both disaster and the introduction of student/user misunderstandings.
Yes, 100% agree with your comment. I'd rather have a calculator application that is maybe a little less "smart" in exchange for mathematical correctness and predictability.
I don't remember which calculator did this (I think GNU units), but I've seen this handled automatically with a warning saying "Warning: reciprocal conversion"
Yes, that's what GNU units does:

  $ units
  Currency exchange rates from www.timegenie.com on 2016-06-21 
  2926 units, 109 prefixes, 88 nonlinear units
  
  You have: 7.8L/10km
  You want: miles/gallon
  	reciprocal conversion
  	* 3.0155716
  	/ 0.33161209
I think it's fine for a calculator to make guesses as long as it makes it very clear that it's doing so.
The dimensionality for your query is wrong. If you fix that it works just fine:

    ≫ 100km/7.8L -> miles / gal
      100 km / 7.8 L -> mi / gal
       = 30.1557 mi/gal
Nice. This is a lot like (in looks and some functionality) the macOs app, 'Numi' (which I love) : https://numi.io/
Numi looks nice! I like the syntax

I use the similar Soulver on my Mac and iOS devices.

Nice.

I probably mostly use Numi for unit conversions, but asked for in a 'human' way. eg "68 square meters in square feet"

Damn, that looks sweet. Is there a similar app out there for Android and Ubuntu/Debian?
Too bad it doesn't support complex numbers

    2**100+1-2**100
Equals 0?
It seems it uses approximate floating point arithmetics, with 30 digit precision.
Correct. "2^99 + 1 - 2^99" still works because 2^99 < 10^30
A confusing thing is that the program seems to be using the purescript-quantity library which uses the purescript-decimals library which is arbitrary precision numbers, if I followed the dependencies correctly.

The readme also advertises it can deal with 10^(10^10), which it can (doubles can't deal with this, so it's definitely not just using Javascript doubles). The part which prints out numbers rounds to 6 places, but I don't see any place which rounds intermediate results.

Edit: Found where 30 digits comes in. https://github.com/sharkdp/purescript-decimals/blob/ad719fc7...

That's nice test but to fair their tagline says high precision not arbitrary precision.
Very nice on first try -- added to my quick toolbar. Great to be able to intermix metric and SAE units, as there is (very unfortunate) constant use of both in my field of work.

Any hope of an Android app version soon?

Fails at the first fundamental test:

  Meaning of life

      Meaning × of × life

      Unknown identifier: Meaning
Oh no :-)

Quick workaround:

≫ Meaning = 6

≫ of = 1

≫ life = 7

Hmmm, I now wish Douglas Adams had chosen 56.

Meaning = 7

of = 2

Life = 4

Very nice! Any plans to add decibel/log-scale units? That would make this even handier.
Thank you! "bel" is already supported ("decibel" also, due to the handling of SI prefixes). Unfortunately, "dB" is parsed as "deci-byte". While this is not really a useful unit, this is on purpose (see https://github.com/sharkdp/insect/issues/67) in order to support "kB", "MB", etc. for "kilobyte", "megabyte", etc.
This is worthy of fixing in my opinion. I do see this as a nuance, but if this is what the common usage of dB is, it should be supported.
Looks nice, but is there a reason it interprets m^2 * Pa correctly

  ≫ 1 Pa * 2 m^2 / N
    1 Pa × (2 × m^2 / N)
     = 2
but doesn't automatically convert a result to N?

  ≫ 1 Pa * 2 m^2
    1 Pa × 2 × m^2
     = 2 m²·Pa
Same with W, J, s and all their relations.
Thank you for the feedback!

Automatic simplification (as opposed to explicit conversion) is a complex topic. There are a few simplifications that are already applied, for example:

  20 L / m^2
   = 0.02 m
You are absolutely right, it'd be nice to have "Pa·m²" be converted to "N" automatically. I've been thinking about simply going through a list of simple, standardized units (SI units like Newton) while trying to convert the result into these simple units. However, notice that this is not always what you want. If someone likes to compute in imperial units, we would rather leave all quantities in imperial units.
you could only apply simplifications that minimised the sum of the absolute value of all the unit exponents. that would be intuitively satisfying, and not require converting imperial to metric (which would leave the exponents unchanged)
Good suggestion, thank you! I was already thinking about some way to measure "perceived complexity" of a physical unit - this sounds like a very good try for such a heuristic.
Sorry to be the party stopper for a really awesome tool, just wanted to let you know that you have a dead butterfly as a logo: http://emilydamstra.com/news/please-enough-dead-butterflies/
Oh, I didn't know that :-)... that's interesting. I'm very much open for suggestions on how to improve the logo. I already went through a couple of iterations...

https://github.com/sharkdp/insect/blob/master/media/insect.s...

Actually it was just a "did you know?" comment, 99.99% of people don't know/care about it. I'd throw a SVG modification but I won't have my laptop around/time until Monday, when I'd just lower the upper wing a bit.
Seriously? Not to be negative but this is even more pedantic than I would expect from hacker news, and thats saying alot.
It's not a critical comment, he's just making the author aware that his logo represents something he might not be aware of.
Ah it was meant to be a fun fact/"were you aware of?" kind of comment, not even criticism (;
It has the ring of a know it all type of pedantic comment. I can safely assume that butterflys are deformed when they are pinned, I dont have to have a big expose revealing it as some hidden secret. Hackernews has the habbit of making disability level OCD seem like some grand hidden nugget that will make everyone think you are nerding better than everyone else.
Come on. This was an obvious reference to the article that was hot on HN recently.

Also while you "can safely assume that butterflys are deformed when they are pinned", you can also safely assume vast majority of the world doesn't know that, and you can also assume many people might want to reconsider using a dead butterfly as a symbol once they learn the image doesn't show what they thought it shows.

AKA regular, friendly, and completely warranted pedantry.

i'd argue it's more of an hn in joke

if you look at the previous thread(o) i think gp is either directly of indirectly referencing most of the comments therein are of the "now you've watched it you can't unwatch it" variety(i)

now, should a meta joke be the top comment about this tool? i suppose that is for the forum to decide..

but the op may find it useful information.. perhaps thae missed the previous thread

op: awesome tool

(o) https://news.ycombinator.com/item?id=14460013

(i) https://www.youtube.com/watch?v=JeIJ8l3PZ88

But the butterfly in the logo is pictured side-on..
The wing is still in the wrong position. The tip shouldn't be the farthest forward bit.
That's cute. Are there any phone apps which do that?

Remember Graphing Calculator? That could use such features.

Autodesk Inventor understands units in formulas, but mostly for length and angle. Everything becomes meters internally.

Soulver does it (Mac/iPhone), it just uses 'as' instead of '->'

E.g. "6Mbit/s * 1.5h as GB"

I've been using it for a while now and I can't imagine going back to a traditional calculator

It's not working on my Android, Dolphin browser. I am unable to type anything on the prompt.
I really like the UI and seeming wealth of different units. It doesn't look like it supports fluid ounces though.

I tried "4 tbsp to oz" and it interprets oz as mass instead of volume. Google correctly gives me 2 as the answer.

It doesn't support "stones" (st?) either. I tried "20 st -> kg" (Game of Thrones uses stones as units of mass) but it didn't work.
Thank you for the feedback. I'm not sure how to support this. I would probably have to call it "fluid_ounce" / "fl_oz" or "fl.oz." in order to distinguish it from the unit of mass.
You could try to go the complicated route to disambiguate based on whether the other units present are liquid volume or mass.
Well, the way /usr/bin/units solves it is to allow "floz", "usfloz", "fluidounce", or "usfluidounce".

Having to learn that you can type "floz" is better than not being able to do it at all.

(You could also allow "fl oz", "fluid ounce", "fl ounce", etc. if you tweak your parser a little bit, but that's the deluxe version, and any functionality at all would be a big improvement.)

Thank you. I'll add one of those.
floz and fluidounce are now supported.
(comment deleted)