Live data from Hacker News

Julia as a CLI Calculator

krasjet.com

111–120 of 134 posts

Re: Julia as a CLI Calculator

#111

Earlier quoted context omitted.

crop(resize(first(images), 100, 100), 25, 25, 75, 75) this will likely get better when julia implements proper pipes, IIRC coming soon in the plans (like elixir does): images |> first |> resize(100,100) |> crop(25, 25, 75, 75) If the language bothers to implement an inspect method (again, like elixir) this is vastly superior to . chaining because you can do this: images |> inspect |> first |> inspect |> resize(100,10…

I'm not sure what `inspect` does, but can you clarify what you mean by proper pipes? julia> x = [3,2,4,5] 4-element Array{Int64,1}: 3 2 4 5 julia> x |> sort |> x->reshape(x,(2,2)) 2×2 Array{Int64,2}: 2 4 3 5 works. It gives a syntax error if the pipes are on the newline. Is that your gripe? Or is it that it doesn't automatically partially apply the function, requiring you to use an anonymous function, like `x->reshap…

Yes, by "proper pipes" I mean partial application. (I used to code julia but now I'm mostly living in elixir because that pays the bills) Yes, the explicitness of what you wrote is a marginal gain in preferability from an idealized point of view, but I promise you your eyes and brain will be more tired from that explcit form than if you just learn to read pipelines as passing into the first value (in elixirland we have lambdas that you can pipe into, too. Nobody does this.)

You don't know what you're missing by not having an inspect function. In elixir it's styled "IO.inspect", and it pretty-prints the value as a side-effect, and returns the value unchanged. You can pass a "label" option as your second parameter, and that will add a label to the pretty print. For example, assume I have a module M with the expected functions:

    value = 10
    |> M.add_3 |> IO.inspect(label: "A")
    |> M.times(4) |> IO.inspect(label: "B")
    |> M.minus_2 |> IO.inspect(label: "C")
will print:

    A: 13
    B: 52
    C: 50
and value will be assigned 50.

Now, the great thing about that is that you can blat a bunch of IO.inspects simultaneously using multiline cursors. That low friction 1) causes you to actually use it, and 2) cause you to also set your code up so that it's easy to IO.inspect, which typically also means cleaner, and easier to read code. It is IMO the most powerful debugging tool that I've ever used.

Example: https://github.com/ityonemo/ex_dhcp/blob/master/lib/ex_dhcp....

That small pipeline does a pretty complex set of actions - deserialize a raw binary to a structured datatype, then call a handler, then process a handler return result. There are four datatypes that run through that pipeline. Nonetheless, I can inject IO.inspects into that with six keystrokes (I have a vscode snippet), run the code, and watch as the data are transformed, and immediately identify what corner case I missed and write a proper test for it.

And yes, it is far less powerful if the pipes can't tolerate the newline. (though you usually can still multicursor on a single line).

Anyways, I'm not saying this to rag on Julia. I'm just saying I think julia can and SHOULD have this, and it would be awesome. Also, elixir needs to learn a thing or two from julia's repl.

Re: Julia as a CLI Calculator

#112

Earlier quoted context omitted.

crop(resize(first(images), 100, 100), 25, 25, 75, 75) this will likely get better when julia implements proper pipes, IIRC coming soon in the plans (like elixir does): images |> first |> resize(100,100) |> crop(25, 25, 75, 75) If the language bothers to implement an inspect method (again, like elixir) this is vastly superior to . chaining because you can do this: images |> inspect |> first |> inspect |> resize(100,10…

> This is impossible in oo languages It's possible in languages which support extensions, such as Swift, Dart or Kotlin.

no it's not, because a key part of OO is encapsulation. You really do need a functional language with naked, fully introspectable types everywhere, for this to work effectively.

Re: Julia as a CLI Calculator

#113
post #55

Earlier quoted context omitted.

I use a function "ev" that wraps bc. It's crude, but handy: $ ev() { echo "scale=3; $*" | bc -l; } $ ev 22/7 3.142

I do something similar, with a couple of convenience substitutions for commas and multiplication: $ math() { echo "scale=2 ; $ " | sed -e "s:x: :g" | sed -e "s:,::g" | bc; } $ math 5,382 x 48,927.3 263326728.6

You should put this into a codeblock by indenting by 2 spaces. The formatting converts asterisk-delimited text into italics.

  $ math() { echo "scale=2 ; $*" | sed -e "s:x:*:g" | sed -e "s:,::g" | bc; }
  
  $ math 5,382 x 48,927.3
  
  263326728.6

Re: Julia as a CLI Calculator

#114
post #105

Earlier quoted context omitted.

Most dynamic OOP languages don't have interfaces either, so that is kind of a poor argument. You cannot compare Julia to something like Java. You got to compare it to Ruby, Python etc. Also I have no idea what an interface definition would look like in Julia. A function in Julia isn't bound to one specific type like in an OOP language.

I think interfaces in Julia might go something like interface AnimalActions function walk(x::Animal) end function call(x::Animal, y::Animal) end function eat(x::Animal, z::Food) end end struct Dog and then I guess using it like using AnimalActions d = Dog("rufus") walk(d)

The below package implements something like that, but better imo: https://tk3369.github.io/BinaryTraits.jl/dev/

Re: Julia as a CLI Calculator

#115

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…

For an RPN calculator, I find orpie really great.

Otherwise I use WolframAlpha a lot.

Re: Julia as a CLI Calculator

#116
One thing I miss is RPN-string input. Unlike normal RPN where you load the "stack," for RPN string you can enter

> 2 3 + 4 *

as one line, press enter, and get 20. This lets you take advantage of the no-parens nature of RPN while viewing the expression on one line rather than flipping through the stack. Only Windows PowerToy scientific calculator had this mode, that I know of.

Re: Julia as a CLI Calculator

#117

Earlier quoted context omitted.

> This is impossible in oo languages It's possible in languages which support extensions, such as Swift, Dart or Kotlin.

no it's not, because a key part of OO is encapsulation. You really do need a functional language with naked, fully introspectable types everywhere, for this to work effectively.

[deleted]

Re: Julia as a CLI Calculator

#118

One thing I miss is RPN-string input. Unlike normal RPN where you load the "stack," for RPN string you can enter > 2 3 + 4 * as one line, press enter, and get 20. This lets you take advantage of the no-parens nature of RPN while viewing the expression on one line rather than flipping through the stack. Only Windows PowerToy scientific calculator had this mode, that I know of.

this sounds like "dc" except with dc you'd need to add a "p" at the end to print the top of the stack

Re: Julia as a CLI Calculator

#119

Earlier quoted context omitted.

> This is impossible in oo languages It's possible in languages which support extensions, such as Swift, Dart or Kotlin.

no it's not, because a key part of OO is encapsulation. You really do need a functional language with naked, fully introspectable types everywhere, for this to work effectively.

I tried it in Dart and it worked, so it's possible.

But maybe I don't understand your point, if so, tell me what exactly would be impossible to implement in a language like Swift, Dart, Kotlin.

Re: Julia as a CLI Calculator

#120
One of my main gripes about matlab and that Julia unfortunately adopted is the dot syntax. Any other symbol would have worked, but the dot is just way too easy to overlook.

I think it is because it was initially developed for people primarily working with matrices.

Most of the things I do is actually based around multidimensional arrays so when I do operations I almost always want element-wise operations. Unfortunately you often don't even realise you do the wrong operation, just the result is wrong. So I have spend lots of time debugging, until I realised I had a missing dot somewhere, and then spending again significant time trying to find where the dot is missing.

I therefore always found the complaint about np.dot(x,y) being too verbose interesting, because I like that, it makes it explicit and is difficult to overlook.

Post reply on HN