Insect: a fast, repl-style scientific calculator
shark.fish
shark.fish
But, while we're all posting wishlists, one thing that'd be nice is if it simplified unnecessarily complex compound units in the result. In the simplest case, it's able to do this, canceling out literally identical units that appear in both a numerator and denominator:
> 2m/s * 2s
4m
Obviously that is a better result than this hypothetical example would be: > 2m/s * 2s
4 m·s/s
But if you use two different units of time, you get essentially a result like that worse one: > 2m/s * 2min
4m·min/s
The unit m·min/s is not exactly wrong as a result here, but is unwieldy and a bit unusual as a unit of length. Since a "min/s" is just a scalar quantity, the scalar 60 (1 min/s = 60 s/s = 60), this simplifies to 240m.You do get that result if you explicitly ask for it,
> 2m/s * 2min -> m
240m
But it'd be convenient to automatically get these kinds of simplifications, especially when dealing with more complex expressions.Absolutely agreed. This is on my priority list and there is already an open issue which is tracked here: https://github.com/sharkdp/insect/issues/37
https://gist.github.com/msutherl/b2ab6d5ae7454ea1a987ee85385...
> 5+20
> = 25
> +10
> = 35
> 5+20
25
> ans+10
35On Linux, set up a `Compose key`[0]. That makes `°` become `Compose o o`. If you're on Windows, a useful thing to do is enable the US-International keyboard so that you can more easily type characters with accents, so you can type Pokémon properly. US-International also respects the AltGR/Right alt to compose many characters [1]. For example, I can type ² by pressing AltGr+2 which really is quite easy. I can also type ° by pressing AltGr+Shift+;
However, everything the examples inspired me to try fails. 2² works but 2⁴ fails. 30° works but 30°25′8″ fails. 10×3÷4 fails. ‘pi’ and ‘hbar’ are predefined but ‘π’ and ‘ℏ’ aren't.
Edit: should be fixed now.
> 1920/16*9
1080
> Sin[30 Degree]
1/2
> Quantity[2, "Minutes"] + Quantity[30, "Seconds"]
Quantity[150, "Seconds"]
> UnitConvert[Quantity[6, "Megabits"/"Seconds"] *Quantity[1.5, "Hours"], "Gigabits"]
Quantity[32.4, "Gigabits"]
> r = Quantity[80, "Centimeters"]
Quantity[80, "Centimeters"]
> UnitConvert[Pi r^2, ("Meters")^2]
Quantity[(16 \[Pi])/25, ("Meters")^2]
> UnitConvert[Quantity[40000., "Kilometers"/"SpeedOfLight"], "Milliseconds"]
Quantity[133.426, "Milliseconds"]
It's more verbose to type out the units unless you use the integrated WolframAlpha query with Control-Equal. > ln(-1)
NaN
> sqrt(-1)
NaN
Hmmm... > sqrt(2)
1.41421
> sqrt(2)-1.41421
0.00000356237
> 1.00000356237 + 0.0000001
1
What are the rules you apply when truncating results? number of digits displayed? > 3e6 + 0.1
3000000
> 3e7 + 1
30000001
> 3e7 + 1.1
30000000
> 3e7 + 42.9
30000000
There might be a bug, 42.9 < 1 ?This is not really a bug, but I agree that it looks quite weird right now. Explanation in this comment: https://news.ycombinator.com/item?id=13918393
One small annoyance is that it captures common browser shortcuts: e.g. Cmd-L on Mac (iirc Ctrl-L on Win/Linux) is a shortcut for the URL which is what I usually use when I want to go to another page. In insect, it just prints an "l" on screen, so I need to use the mouse to navigate elsewhere.
Ctrl-L is used to clear the screen (same as in terminals, apparently it does not work for you?), but I agree... I also use Ctrl-L to change the URL. I'll see if I can change it (this is not really part of insect, but jquery.terminal).
Just to clarify: Ctrl-L does clear the screen -- this would have been a problem on Windows, but does not bother me on a Mac; on the other hand, Cmd-L (which is the Mac shortcut for the URL) simply prints an "l".
(And I agree this is very cool, especially the way it handles physical units.)
Oddly enough, the reason I eventually stumbled Calca was trying to find a replacement for qalculate[1].
[0]: http://calca.io/ [1]: https://qalculate.github.io/
Anyway, nice project.
> 6Mbit/s * 1.5h
9Mbit·h/s
It seems as though the "h/s" should be resolved and that the result should instead be "4.05Gb", without needing to explicitly specify that the resulting unit should be Gb: > 6Mbit/s * 1.5h -> Gb
4.05Gb
It would also be nice if "month" and "year" were added. WolframAlpha uses "30 days 10 hours" for a month and 365 days for a year.Yes, thank you. This is already tracked here:
https://github.com/sharkdp/insect/issues/37
> It would also be nice if "month" and "year" were added. WolframAlpha uses "30 days 10 hours" for a month and 365 days for a year.
I thought about it and didn't add it at first, due to the ambiguity. But I guess these values seem like reasonable defaults.
For conversions, why use GNU Units over, say, Google in your browser? I find that most of my unit conversions happen in my browser, while I'm online. Anecdotal evidence, obviously, but is this not the case for others? Where do most people use unit conversions?
I'm also not an engineer, so I can't take that into account from experience alone. Wouldn't your tooling provide automated conversions into "correct" units?
250 lbf * 1 m/s -> kW
You can put hp or other desired units you require in the answer. It will hint on balancing the equation to make the units physically similar.
[1] https://frinklang.org > sin(pi)
-3.73566e-20
Needs some more work... > sin(pi)
-3.73566e-20
> sin(2*pi)
7.47132e-20
> sin(3*pi)
-1.1207e-19
> sin(4*pi)
1.49426e-19
So abs(sin(n*pi))
is proportional to n, and sin(n*pi)
alternates in sign. This is because your "pi" is really a floating-point number which is slightly more than pi...Is there a way around this without doing all computation symbolically?
A hacky solution could be to round the output of sin(x) to a given internal precision. This would only hide the real internal numerical problem, though.
It seems that other calculators suffer from the same issue: https://www.google.de/search?q=sin(1e10*pi)
For now, I have increased the internal precision to 30 significant digits and updated the value of Pi to be more precise than that. Of course, this doesn't really solve the problem... just shifts it by a few orders of magnitude :-)
Edit: Also, note that everything is fine if the answer is not zero (due to the rounding in the output):
> sin(pi)+1
11
> I would say that six sign. digits are more than enough for most applications
A better solution would be to not use a fixed number of significant digits, but to display the result with the precision of the least precise number the user entered. If you could follow the propagation of uncertainty through the calculations, that would be even better.
https://en.wikipedia.org/wiki/Propagation_of_uncertainty
PS: Great job anyway, bookmarked, thanks!
> It's great that you use significant digits, but then you have to be explicit about it, and display exactly that many digits, in this case all the zeros (1,00000).
Yes, I completely agree from a statistics/physics viewpoint. The reason I display it as `1` right now is that I only have a fixed number of sign. digits (and not the sophisticated solution that you propose - which would be great!). If I always displayed all six digits, one would get `3 - 2 = 1.00000`...
> A better solution would be to not use a fixed number of significant digits, but to display the result with the precision of the least precise number the user entered. If you could follow the propagation of uncertainty through the calculations, that would be even better.
That would be fantastic. I'll look into it.
> PS: Great job anyway, bookmarked, thanks!
I'm glad you like it!
First impressions are everything. Please see in "The Psychology of Human Misjudgment" the excellent description of humans' "Influence-from-Mere-Association Tendency." The technical merits of a product will not matter if people can't get past their initial feelings. This is highly inconsiderate.
Until the name is swapped out for a more sensible one, I will not be downloading this software.