Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia as a CLI Calculator

krasjet.com

Post reply on HN
Print view View original

31–40 of 134 posts

Re: Julia as a CLI Calculator

#31

Post by leephillips »

RivieraKid wrote: post #26

I really wish there was a language based on Swift that would include most of the nice language, REPL and library characteristics of Julia (and perhaps few from Dart). That would get really close to a "perfect language" for me. Overall I like Julia - and use it as a CLI calculator as well - but there are several things that prevent it from being a good general purpose language: - OOP support is "meh". - str.parse(Int)…

“OOP” is an anemic special case of the multiple dispatch that Julia provides. So if you don’t know any better you can program in that style using Julia.

“str.parse(Int).abs is more readable” No, but it makes sense if you also think that OOP makes sense.

You can index based on anything you want.

Re: Julia as a CLI Calculator

#32

Post by nnq »

enriquto wrote: post #6
dunefox wrote: post #5

Earlier quoted context omitted.

Simply loading the REPL takes half a second for me. I use it all the time as a simple calculator.

> Simply loading the REPL takes half a second for me. I juse it all the time as a simple calculator. Half a second is precisely what is meant by "excruciatingly slow". If I need a simple calculator, I expect to be able to use it to compute intermediary results in a shell loop. If my loop has one thousand iterations, you are spending about 10 minutes just initializing the interpreter. This is absurd. Of course, you ca…

> I expect to be able to use it to compute intermediary results in a shell loop

You have a very peculiar use case that most other users don't! ...either you write a shell script, or a Julia script. It's preposterous to want everything to "start instantly", you'll only get stuck with the simplest most primitive tools this way. We'd all be writing C, Bash and PHP by this reasoning.

Re: Julia as a CLI Calculator

#33

Post by dunefox »

RivieraKid wrote: post #26

I really wish there was a language based on Swift that would include most of the nice language, REPL and library characteristics of Julia (and perhaps few from Dart). That would get really close to a "perfect language" for me. Overall I like Julia - and use it as a CLI calculator as well - but there are several things that prevent it from being a good general purpose language: - OOP support is "meh". - str.parse(Int)…

> - OOP support is "meh".

And boy, am I ever glad it is.

Re: Julia as a CLI Calculator

#34

Post by peatmoss »

RivieraKid wrote: post #26

I really wish there was a language based on Swift that would include most of the nice language, REPL and library characteristics of Julia (and perhaps few from Dart). That would get really close to a "perfect language" for me. Overall I like Julia - and use it as a CLI calculator as well - but there are several things that prevent it from being a good general purpose language: - OOP support is "meh". - str.parse(Int)…

> str.parse(Int).abs is more readable than abs(parse(Int, str)).

Oof, beauty is in the eye of the beholder. I appreciate the regularity of abs(parse(Int, str)) rather than remember what to call as a function, and what must be called as a method of some object. Of course my preference would be for a syntax that has the added benefit of getting rid of extraneous commas:

(abs (parse int str))

> 1-based indexing

Again, beauty is in the eye of the beholder. A lot of relevant math is 1-indexed. Also, I guess Julia supports arbitrary indexing, though I understand that defaults matter.

Re: Julia as a CLI Calculator

#35

Post by dTal »

knight17 wrote: post #18

Since this is a calculator topic, I'd like request your input on which calculators you use. I use the Emacs calculator (M-x calc) and XCalc ( http://www.tordivel.no/xcalc/ ) as I like to use RPN calculators. The Windows 10 calculator is painful and slow. XCalc has a mini mode, where it will sit as a small, single line without distracting you too much. I like that feature very much. One thing with Emacs is that I forg…

Qalculate is the best desktop calculator I've used. It has a command line version, qalc.

Qalculate takes unit-aware calculation to the next level by including an algebraic solver. You don't have to rearrange everything to put your unknown on one side - you can just chuck 'x' into your equality somewhere and it'll work it out. For example, to verify the what-if xkcd assertion that an A10's main gun will propel Randall's car up to 7mph in 3 seconds:

(60/s) × (x s) × (395 grams) × (1010 m/s) = (3500 lbs)(70 mph) ≈ x = 2.0754319 s

2 seconds! Maybe Randall's car is heavier than 3500 lbs. How much heavier?

(60/s) × (3 s) × (395 grams) × (1010 m/s) = (x lb)(70 mph) ≈ x = 5059.1879

More like a Dodge Durango. Unless he's accounting for friction.

You see how nice it is to be able to swap around the unknowns in an equality. Other great features are a large number of built-in constants, an astounding variety of built-in functions - it's practically a CAS - and a command history, which is where I pulled the above example from. It also has a plugin for Plasma's krunner, so you can do quick calculations right there in the dropdown. To summarize: Qalculate is the shit.

Re: Julia as a CLI Calculator

#36

Post by sgt101 »

RivieraKid wrote: post #26

I really wish there was a language based on Swift that would include most of the nice language, REPL and library characteristics of Julia (and perhaps few from Dart). That would get really close to a "perfect language" for me. Overall I like Julia - and use it as a CLI calculator as well - but there are several things that prevent it from being a good general purpose language: - OOP support is "meh". - str.parse(Int)…

>OOP support is "meh".

it's not an OO language. It's got a fantastically rich and powerful type system, but the true beauty of it is the way that it allows you to compose functionality. This is having a staggering impact on the evolution of the ecosystem and the progress that Julia libraries are making in creating functionality that now rivals code bases that have been in dev for 10+ years in the Python landscape.

>- str.parse(Int).abs is more readable than abs(parse(Int, str))

I respect your opinion, but mine is different. Perhaps other people find it easier to read asb(parse(Int,str)) as I do?

>- 1-based indexing.

You can change it and choose.

>- Lack of good support for nullability, think of "if let", "guard let", "??", "object?.property".

I don't know anything about this one! Fascinating!

Re: Julia as a CLI Calculator

#37

Post by sgt101 »

dunefox wrote: post #33
RivieraKid wrote: post #26

I really wish there was a language based on Swift that would include most of the nice language, REPL and library characteristics of Julia (and perhaps few from Dart). That would get really close to a "perfect language" for me. Overall I like Julia - and use it as a CLI calculator as well - but there are several things that prevent it from being a good general purpose language: - OOP support is "meh". - str.parse(Int)…

> - OOP support is "meh". And boy, am I ever glad it is.

Having built several OO codebases with 1000+ classes I really really really second this view.

Re: Julia as a CLI Calculator

#38

Post by nsajko »

johnmyleswhite wrote: post #28
nsajko wrote: post #10

A problem with Julia is that it does not parse input numbers with arbitrary precision by default. Example: julia> sin(1.461920290375737576933544899379e+31) -0.9468766486679395 julia> sin(parse(BigFloat, "1.461920290375737576933544899379e+31")) 0.6864670207863400975666631018263839509022548965872940746039593018855528710432756 Fricas is better in this regard, some links: https://en.wikipedia.org/wiki/FriCAS https://fric…

It seems like it would be pretty easy to make a REPL mode that did the big conversions automatically. Not sufficient to protect a naive user, but arbitrary precision floating point is never safe.

> arbitrary precision floating point is never safe

Care to expand on that? Are you advocating for interval arithmetic or maybe decimal floating point?

For what it's worth I think that one would rarely need to interactively deal with so much data at once that using, say, 10000 bit binary floating point would be prohibitive. It is difficult to lose the necessary significant digits with so much "safety margin", and one still has space for about a million of such high-precision floating point numbers.

Re: Julia as a CLI Calculator

#39

Post by boogies »

knight17 wrote: post #18

Since this is a calculator topic, I'd like request your input on which calculators you use. I use the Emacs calculator (M-x calc) and XCalc ( http://www.tordivel.no/xcalc/ ) as I like to use RPN calculators. The Windows 10 calculator is painful and slow. XCalc has a mini mode, where it will sit as a small, single line without distracting you too much. I like that feature very much. One thing with Emacs is that I forg…

Qalculate is great, but often I just use GNU bc. You just have to remember (or make some type of alias) to pass it the -l flag for floating point etc., and I also use -q for quiet. There's also dc(1) for RPN.

Re: Julia as a CLI Calculator

#40

Post by johnmyleswhite »

nsajko wrote: post #38
johnmyleswhite wrote: post #28

Earlier quoted context omitted.

It seems like it would be pretty easy to make a REPL mode that did the big conversions automatically. Not sufficient to protect a naive user, but arbitrary precision floating point is never safe.

> arbitrary precision floating point is never safe Care to expand on that? Are you advocating for interval arithmetic or maybe decimal floating point? For what it's worth I think that one would rarely need to interactively deal with so much data at once that using, say, 10000 bit binary floating point would be prohibitive. It is difficult to lose the necessary significant digits with so much "safety margin", and one…

I agree with your assertion that most users could get away with 10,000 bits. My point is only that there's always going to be somebody who still tries to do something that fails, so you have to pick some set of tradeoffs. Yours seems reasonable.
Post reply on HN