Show HN: Insect – a high-precision scientific calculator with physical units

[boramalper]

Kudos!

I would love to see two more things:

1. Propagation of uncertainty.[1] I often yearned for a calculator that automatically propagated uncertainties for me while writing my (high-school) lab reports. I think it would be life-saver functionality for many students at the very least.

2. True high-precision. I don't know how Insect works under the hood (so maybe you are already doing it this way) but instead of using high-precision results of the operations, store the operations themselves and calculate the final result at the end with the desired amount of precision.

I am aware that both requests requires a tremendous amount of change so you might as well think of them for the next major version! =)

[1]: https://en.wikipedia.org/wiki/Propagation_of_uncertainty

[schiffern]

Frink is a "napkin math" language that supports units, uncertainty propagation (keeping track of middle/lower/upper), and exact rational numbers. Named after Professor Frink from The Simpsons, of course. Also it has an insanely comprehensive file of units and constants (derived from GNU units and greatly expanded), so it includes handy things like earthmass, stefanboltzmann, etc.

http://frinklang.org

https://frinklang.org/frinkdata/units.txt

[sharkdp]

Thank you very much for the feedback. That would be great, yes. I believe that both points are somehow already included in the issue that I'm tracking here: https://github.com/sharkdp/insect/issues/54

Unfortunately, it is not a simple change, no :-/

[maho]

I absolutely agree with these requests! I am so desperate for an uncertainty-aware/unit-aware calculator that I tried implementing one myself, even though it is quite beyond my skill-set. I gave up and used Mathematica (more on that below). Two comments on the requests:

- Most existing calculators that offer propagation of uncertainty use a simplified formula -- the one with the square root and the partial derivatives. That's OK for lab courses. But in real life, the distributions of the input parameters are non-Gaussian, the formulas depend on each other in subtle ways that are easy to miss, and you have to deal with systematic and statistic errors (precision vs. accuracy). Most researches I know, myself included, sort-of fudge this with pen-and-paper and Excel, and end up underestimating their errors... In my view, the best solution is a Monte-Carlo type calculation, where you draw the input parameters from their respective distributions, then do the calculation, and repeat 10000 times. The mean and the std deviation gives you final result.

- Arbitrary precision is doable, but often unnecessary. To me, it was always more important to know when the result is numerical garbage (in which case I rearrange the equations to make them more computer-friendly), than to choose some precision up-front, hoping it would be enough. For me, interval arithmetic [1] is the best solution. All numbers are represented by the next higher and next lower floating point number, and each calculation results in a new interval, where the result is guaranteed to be in the interval. Often, the intervals blow up unnecessarily, but are still much smaller than the desired accuracy or precision. These days, whenever I get an unexpected result, I repeat the calculation with interval arithmetic in Mathematica or Matlab to exclude numerical errors. Interval arithmetic is not very costly in terms of run-time, and there are great libraries out there.

The unit-aware, uncertainty aware calculator that I ended up using for my PhD-thesis was Mathematica. Mathematica deals with units somewhat well and iterates over lists natively. You can write standard formulas and feed them lists for the Monte-Carlo calculation. However, unit calculations are extremely slow. My workaround split the calculation into one unit-calculation and 10000 unit-less calculations. However, I ran into so many Mathematica bugs and quirks that hosed the calculation ("transparent" Mathematica-updates that changed the result, file corruption (!), swalled minus-signs (!!)) that I cannot possibly recommend Mathematica for anything but toy projects.

Great work! I will keep a close eye on this awesom project!

[1]: http://subs.emis.de/LNI/Seminar/Seminar07/148.pdf

[franciscop]

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/

[nautilus12]

Seriously? Not to be negative but this is even more pedantic than I would expect from hacker news, and thats saying alot.

[sharkdp]

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...

[alok-g]

Wow! The article is eye-opening; worthy of submitting to HN as a news link in my opinion to create more awareness. If you agree, please submit.

[johtso]

But the butterfly in the logo is pictured side-on..

[xyzzy_plugh]

That looks like a living butterfly.

[lol768]

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.

[olegkikin]

All of these things work in Google, btw. Google has one of the best unit conversion tools, and it's built into the search.

[db48x]

I always used my HP48; it had great unit support.

[dom0]

GNU units(1)

[sharkdp]

Thank you very much for the feedback!

[sharkdp]

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

[slig]

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

[jclulow]

So "megabytes" appears to be the power-of-ten unit, which is generally not that helpful in practice.

   ≫ 6 megabytes to bytes
     6 MB -> B
      = 6000000 B

Assuming you're sticking with the power-of-ten unit, that means you should really grow support for the (sigh) "mebibytes" family of units; i.e., what some folks are retro-actively calling the power-of-two byte unit.

   ≫ 6 mebibytes to bytes
     6 × mebibytes -> B
     Unknown identifier: mebibytes

[sharkdp]

Thanks! It has already been requested: https://github.com/sharkdp/insect/issues/81

[bo1024]

I'd call them "MB (megabytes)" and "MMB" (marketing megabytes). Pretty clear.

[btown]

> high precision

    ≫ e*1e15
      e × 1000000000000000
       = 2718280000000000

Needs a bit of work, I think.

[navane]

I use Python with pint [0] for this. It integrates with numpy. It has support for uncertainty. You can do all calculations Python can, Python math reads like ascii math. It also can output to latex.

This can easily run local. If you prefer online repl, it's available on repl.it [1]. There you can keep your scripts in the cloud for later, with rudimentary versioning.

[0] https://github.com/hgrecco/pint [1] https://repl.it

[raketenolli]

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.

[sharkdp]

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.

[kwhitefoot]

Please everyone in the US (and everywhere else) stop using the word imperial to describe the US Customary system of units.

The Imperial system uses the same names for many units but the sizes of several important ones are different.

For instance Insect says:

≫ 1 gal/1litre 1 gal / 1 L = 3.78541

If this gallon were really Imperial then it would say.

≫ 1 gal/1litre 1 gal / 1 L = 4.54609

This is mostly because 1 pint US is 16 fluid ounce US but 1 pint imperial is 20 fluid ounce imperial.

But be careful because 1 fluid ounce imperial is 28.4131 ml, whereas 1 fluid ounce US is 29.5735 ml.

[semi-extrinsic]

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).

[hdivider]

Great work indeed. I'd also love to see support for complex numbers. A big differentiator over other calculators.

[gvkv]

Well done!

Plain and easy to understand interface and excellent use of colour and space. Two suggestions:

1. While I doubt it'll be used very much, consider adding calories for completeness if nothing else:

  1000 kcal -> joules

or

  1000 Cal -> joules

You might also throw in cal for just for fun[1]!

2. Change Variables to Constants. I think this is more in keeping with standard jargon.

[1]: cal is based on the gram while Cal or kcal is based on the kilogram.

[forgotpwtomain]

Hmm, I find the auto-associativity to be a bit weird for example:

≫ 1/12 c

  1 / (12 × c)
   = 2.7797e-10 s/m

[sharkdp]

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.

[nine_k]

Apparently unit-less constants should bind stronger:

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

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

[rnhmjoj]

I use this tool also: http://pythonhosted.org/uncertainties It comes in pretty handy for a quick calculation with error propagation.

[eps]

If it could deduce density from the material name, it'd useful for volume-to-mass conversions., e.g.

   1 cup of butter -> g

Not sure if it's quite scientific though... :)

[6502nerdface]

Wolfram Alpha can do this:

  (density of gold) * (average volume of human)

  -> 1282 kg

And if you do:

  (density of gold) * (average volume of human) * (price of gold)

It will even show you a plot of the time series of its value since the early 20th century.

[dredmorbius]

GNU Units is extensible in this regard. You can add your own dimensions.

I'm trying to think of how you'd specify density of butter, perhaps "butterdensity", cognate, "earthmass".

I've got a number of geographic areas specified, so I can give you, say, paper size in milli manhattanarea.

[db48x]

Looks pretty nice, but no light years? No attoparsecs? You don't even have hogsheads or fortnights!!!!!1!

Still, it's pretty good.

[sharkdp]

Thank you for the feedback. I'm always open for suggestions on new units (https://github.com/sharkdp/purescript-quantities)!

[sharkdp]

lightyears, (atto)parsecs and fortnights are now supported.

[scentoni]

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 Ω

[infinisil]

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

[sharkdp]

Thank you for the feedback! I'm open for any syntax suggestions.

[DINKDINK]

Needs more temperature scales than just kelvin.

US Engineering units of energy would also be help certain people: such as BTUs British Thermal Units etc.

[sharkdp]

I thought about it for some time and decided not to add Celsius and Fahrenheit: https://github.com/sharkdp/insect/issues/68

They are useful, of course, when it comes to simple unit conversions. But they lead to all kinds of problems if you start using them in calculations (which is what Insect is mostly for).

[sharkdp]

calories are supported now

[eggy]

I have been using Frink for over 7 years. Aside from a calculator with a gazillion units, Frink lets you program in a less verbose Java for other tasks. Graphics are easy too. I write small apps for calculations I often need at work with GUIs and input prompts. What makes Insect different? Can you program apps in it?

[oskbor]

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?

[arve0]

package.json and bower.json does not include mathjs, so it doesn't seem like it does rely on mathjs.

[F_r_k]

For those interested on a CLI counterpart, GNU units is more or less the same. The units definitions file is enormous