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! =)
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.
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
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!
That only, at best, gives you the maximum and minimum values, with no knowledge of the actual distribution.
EDIT: Missed the specific request for interval arithmetic part for representation of numbers. Thought that was a proposal for the error propagation (which requires actual distributions and not simple min and max intervals).
Also, frink does not support accurate interval arithmetic for all operations, and reverts to numerically accurate bounds instead (https://frinklang.org/#IntervalArithmeticStatus). I don't know if Mathematica is any better for those.
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
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.
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...
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.
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.
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.
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.
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.
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!
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].
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
"M" - "Mega" is an official general purpose SI prefix approved in 1960 which always stood for a decimal multiplier. Its common usage as a binary multiplier was limited to counting units of computer memory, and is purely an approximation to allow convenient speaking of, e.g., a megabyte of RAM instead of 1.048576 megabytes of RAM. Because it reflects the natural scale of physical memory.
It is more properly referred to as "MeB" - "mebi", which became an ISO standard prefix in 2008.
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.
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.
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.
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).
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?
Yes. The underlying unit-conversion library is called https://github.com/sharkdp/purescript-quantities
It does not have a (nice) JavaScript API, so far, as it is written in PureScript - like Insect.
Shameless plug for my http://dedo.io/, which is similar to this this, but with less features, more money-oriented and support for any custom units, e.g. if bag_weight = 12 kg / bag, then 10 bags * bag_weight is 120kg
Wouldn't it be great if software evaluated things, and if things didn't made sense, considered what the possible alternatives were, a bit like semantic checkers for spelling and grammar in text?
I think you've missed my point. I'm saying that it would be nice if interactive tools were a bit smarter and could guess that the white space was unwanted. Syntax checking in editors has improved a lot but it should do more than just suggest long variable names as you're typing them.
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.
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.
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.)
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.
Unfortunately that means you will be inundated with requests for further improvements. :-)
I see that you have a built in constant for μ0, mu0.
But it evaluates to
0.00000125664 N/A²
for the ultimate in precision surely it should be expressed as
4π×10−7 N/A²
At least when I use mu0 in spreadsheets, etc., I always define it that way, easier to remember too. And sometimes it lets me see that the pi cancels out.
I'm a little confused as to how this improves on GNU units, which seems to support far more:
$ cat .units
period(len) units=[m;s] 2pi*sqrt(len/gravity) ; (period/2pi)^2 * gravity
$ units
2980 units, 109 prefixes, 97 nonlinear units
You have: period(20cm)
You want:
Definition: 0.89729351 s
You have: period(20cm)
You want: ms
* 897.29351
/ 0.0011144625
You have: period(2ft)
You want: ms
* 1566.5419
/ 0.00063834872
You have: 5 GiB
You want: bytes
* 5.3687091e+09
/ 1.8626451e-10
You have: 5 hundred million
You want:
Definition: 5e+08
You have: tempF(100)
You want: tempC
37.777778
is it supposed to be a competitor? learn how to use a new language? I don't get it.
I like the idea of keeping units, but I'm not sure this makes things easier:
≫ V * A / J
V × (A / J)
= 1 V·A/J
You have: V*A/J
You want:
Definition: 1 / s
Someone wrote something that's similar to X. If you are so well versed in GNU tools, you surely old enough to know that this happens all the time, sometimes intentionally, sometimes not. People like scratching the proverbal itch and creating stuff. What's there to "not get" and what's the point in feigning a surprise and implying OP's ignorance along the way?
If you want to mention that X exists, just say that -"There's X, which is similar. Have you seen it?"
> I'm a little confused as to how this improves on GNU units, which seems to support far more [...]
> is it supposed to be a competitor? learn how to use a new language? I don't get it.
No reason to be confused. GNU units is a great tool. qalculate and speedcrunch are great, too. Insect is just my take at it. Each of these tools has advantages and disadvantages. As for insect, one of the advantages for me is that it is platform-agnostic and can be used from anywhere without installation. The "You have: X; You want: Y" interface is basically replaced by "X -> Y".
There are two differences from GNU Units that I can see straightaway from the GitHub repo:
1. It's written in PureScript.
2. It's MIT licensed. (Actually I had to search the repo to find this - it would be nice if it had a LICENSE file at the top-level that GitHub could pick up.)
Anyway, IMO monocultures suck and competition is good. Kudos to the OP!
{~} % qalc
> c to km s^(-1)
speed_of_light = approx. 299792.46(km / s)
> 10 kg to g
10 * kilogram = 10000 g
> $10 to euro
dollar * 10 = approx. EUR 8.9501477
> 100oF to oC
(((100 * kelvin) + (459.67 * kelvin)) * 5) / 9 = approx. 37.777778 oC
Thank you for the feedback. I should probably consider adding something like "Full documentation and terminal version available here". I hesitated for quite some while before adding "month" and "year" but these (potentially confusing) defaults seemed more useful to me compared to leaving them out.
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.
"9 min/mile -> km/h" fails since they are different dimensions. However in reality we do use both of these units to indicate speed. This might be a stretch but will be good to incorporate if it can be generalized.
I'd be cool to have this as a python script somewhere but I am not quite sure wether I would visit this site whenever I need to calculate some physical units, especially since google already covers most of my needs
dont get me wrong, I think otherwise it looks and feels great and is easy to use but I dont know who will use this.
Thank you for the feedback. Fair point: Google's unit conversion is really good. For me, there's mainly two things that stand out compared to using a Google search:
* The REPL: I wanted an interactive terminal-style calculator where I could press Arrow-Up and easily change a few things. It also lets me define my own variables and use them in my calculations. It saves the history so I can come back and press Ctrl-R to find a recent calculation.
* Combination of Web- and terminal version. I often work in the terminal instead of the browser where I can easily use the CLI version of insect.
There's a good python library to work with units: it's called Pint (named after a certain quantity of beer). Afaik it does everything OP does, and more and better.
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:
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.
In your first example, the result of the calculation is dimensionless (length divided by length), so it does not require any unit. It's a scalar value.
In your second example, the input gets parsed as "1/(2km)" which is equal to "0.5 km⁻¹". If you wanted half a kilometer, you'd have to enter "1/2*km"
They are already supported. There is "B" or "byte" for byte and "bit" for bit. SI-prefixes are case-sensitive, so "G" is for giga, "M" for mega, "m" for milli.
>>> 6 Mbit/s * 1.5 hours to GB
(6 Mbit / s) × 1.5 h -> GB
= 4.05 GB
This is exactly what I've been looking for for years. A fast easy calculator that's as convenient as a physical school calculator but with familiar programming style input since computers don't have scientific calculator keys. I can do sqrt(2) much easier than Windows' calculator and it doesn't have the ridiculous attempt to copy a physical calculator's quirks like pressing equals twice to re-apply the previous operation or having an "inverse"/"2nd function" button.
Units is a bonus but really just the calculator is less frustrating than anything else I've ever seen. Google search is too unpredictable - morphing into a typical confusing 1970's style keypad design after your first calculation. I tried a couple of desktop applications and they were no better either. Come one calculator app designers - stop trying to copy a physical calculator. Those already have a terrible design and computers don't have the same constraints or freedoms as them.
Even better, it can act like a desktop Windows app simply by saving the page in Chrome! Beat that for latency, Google!
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.
Sure, because google isn't a calculator, it's an AI machine. Sometimes it guesses your intent right, sometimes it doesn't. That's fine for many tasks but not a great way to design a bridge or a steam boiler.
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"
$ 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.
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