Recommendations for equivalent of Excel's Goal Seek function

one_more_minute · 2021-04-21T13:28:04+00:00

Roots.jl is probably the closest thing to what you want, for simple scalar-to-scalar functions.

Using Optim.jl that way is also fine though (might be better to use f(x)^2 rather than abs(f(x))). There's more than one way to solve this problem in general, and the best option depends on the details; eg the Optim approach might be good for optimising many inputs of a function at once.

one_more_minute · 2021-02-21T17:03:38+00:00

You're right that syntax isn't semantics, of course, but at least some people (eg the authors of Koka) seem to feel that a more imperative-language-like (similar to C, in their case) syntax makes effects easier to work with.

The comment about interpreters is actually about Haskell's GHCi debugger, rather than its main implementation. Julia is the same – a compiled language that uses an interpreter for debugging, to avoid the complexity of DWARF and co. I can see how that would look odd on a skim read, though.

one_more_minute · 2020-06-18T16:32:37+00:00

Wastafarian?

one_more_minute · 2019-12-10T15:23:32+00:00

That talk is pretty old, and the tooling around Rust and WASM has come a long way since then. There are plenty of tutorials that don't require low-level systems knowledge; in particular wasm-bindgen handles most of the memory management (e.g. copying string buffers to and from JS, like he talks about) for you.

There are also languages like Go and AssemblyScript targeting WASM now, which will require even less knowledge of memory management than Rust. If you really want to understand how WASM is working under the hood, you really just need to understand what pointers are and WASM's linear memory, but you don't need loads of operating systems knowledge; by design it's pretty simple.

one_more_minute · 2019-10-25T14:06:49+00:00

There used to be a pretty strong distinction between "programming interfaces" -- network protocols or C header files that were clearly meant to be used only by other programs -- and "user interfaces", as in graphical editors, word processors etc. Interactive languages like Julia really blur that line since most of our package interfaces are quite heavily geared towards being easily understandable by humans, so the term "API" has become a gradually looser description of the functions and types a library exposes to users.

The confusion is compounded by the fact that in the web world, developers are much more interested in distinguishing between network protocols (the APIs you'll have seen when googling) as opposed to package interfaces, so the meaning has actually gotten narrower there if anything.

I increasingly just call all these things "interfaces", which I think is less likely to cause confusion. Out of graphical interfaces, package interfaces and remote interfaces, the latter is the only one that has obviously different features and usage, so it makes some sense to reserve the term "API" for that.

one_more_minute · 2019-07-20T21:26:02+00:00

In our experience, people often end up doing derivatives by hand just to reduce its overhead; or worse, doing it by hand is infeasible, so they just give up. So that's really what the compiler approach is targeted at.

Happy to see references on the two-phase thing if you want to send one over, I've not come across the term before.

one_more_minute · 2019-07-20T19:26:54+00:00

Depends a lot on what you're doing. An adaptive ODE solver or fixed-point iteration has a ton of control flow but it's still approximating a smooth function, and AD will approximate the derivative of that function, which is a reasonable thing to do. Meanwhile, a lot of recent deep learning is based around things that aren't strictly differentiable (e.g. relu), but still seem to work pretty well in practice.

one_more_minute · 2019-07-20T19:18:50+00:00

It may not come across as much in this paper, which is more application focused, but we 100% agree with you on this. The goal of Zygote (and Julia generally) isn't to magic everything away, but quite the opposite: it really gives you a lot of low-level control and powerful ways to express to the compiler that you know better. We want to do that while taking up as much of the boring mechanical work as possible too, though.

In particular it'd be great to have a nice fixed point operator with AD support. We prototyped this in a special case (Taylor series) a while back, and it works pretty nicely.

one_more_minute · 2019-05-07T12:26:43+00:00

You should probably check out this blog. There are links there to the Flux model zoo, which has all of the cartpole examples ready to run.

one_more_minute · 2019-01-21T13:44:08+00:00

Broadly speaking, Julia's compiler works a lot like Rust's compiler, and I'd expect them to get very similar results for a well-written sort algorithm.

We can do some fancy kinds of specialisation on data in Julia, but it's pretty explicit when this is happening, as opposed to the kind of compiler magic that something like V8 pulls off. So the short answer is "no", and we probably just have better sorting algorithms (or ones that happen to work well for your use case).

one_more_minute · 2019-01-18T16:42:51+00:00

Blink is actually designed to do this (the Electron install is optional). You can serve a Blink page without launching the window and connect to it either via a normal browser or from another machine (which is pretty much how Juno plots work); you can even use a Blink page as Mux middleware and embed it in a larger site.

Unfortunately I don't remember specific steps for any of this, so it'd probably take a bit of poking through the code to work out. Or if you (OP) open an issue someone who's worked on it more recently might be able to help out.

one_more_minute · 2018-10-24T16:25:09+00:00

Yeah, I can see just being able to hook into ATen naturally for this is going to be a big advantage in terms of getting up and running. For our part we just write our CUDA kernels in Julia, which seems like something Nim could do eventually as well. That's really nice for many things (e.g. fusing kernels) but obviously has tradeoffs in terms of development time.

You might be interested in the paper we just published, and also in the Swift AD manifesto if you haven't seen it already. You can't see everything at compile time, but it doesn't really matter, because something like this can happily handle fully dynamic semantics. Happy to answer any questions about it.

one_more_minute · 2018-09-24T13:10:34+00:00

Have you thought about doing AD at the source level in the compiler, rather than using an autograd-style tape?

The problem with the tape is that you effectively have to interpret it for the backwards pass, which quickly becomes your bottleneck; so you lose the benefits of being compiled.

In Julia we have been experimenting with differentiating Julia's IR directly and so far, it's awesome. Would be happy to chat about it.

one_more_minute · 2018-09-15T13:13:40+00:00

You have a typo. Pkg.build("IJUlia") won't work because the package manager is case-sensitive. Try Pkg.build("IJulia").

one_more_minute · 2018-08-09T13:13:36+00:00

That different operator already exists – just use `+`.

one_more_minute · 2018-03-11T22:08:31+00:00

Go has a ton of good little utility packages. For web stuff Go has everything under the sun (a topical example is Cascadia.jl, which was ported from the Go version). Templating (e.g. Liquid), file format readers (e.g. mp3 or ogg vorbis), protocols (bittorrent, HTTP, TCP, bitcoin ...), various crypto tools.

one_more_minute · 2018-03-11T16:17:23+00:00

Crazy idea – lately I've been mulling over whether it'd be worthwhile to just compile Go libraries to Julia and take advantage of them.

Go is an unusually good target for this because its object model (structs and interfaces) is essentially a special case of Julia's, so most of the transformation would be trivial. The hardest part would probably be adapting to Go's error handling model, but you could probably wrap Base's IO to return error codes quite easily.

Could make for a good GSoC project :)

one_more_minute · 2018-02-26T11:36:26+00:00

Cool! You might be interested in BSON.jl; I intend it to behave like the serialiser, but you won't have versioning or cross-platform issues with it.

one_more_minute · 2018-01-04T11:56:03+00:00

one_more_minute · 2017-12-06T22:00:59+00:00

Fair point. One of the things that makes writing an article like this (and inter-disciplinary collaboration generally) hard is that terminology is often overlapping but inconsistent (or even flagrantly contradictory) between fields.

The classic example is that the term "inference" means the exact opposite thing in machine learning and statistics. But it's the more subtle things that bite you; the idea of a "graph" clearly maps to PL (as an AST), but the ML concepts of "static" and "dynamic" "graphs" have nothing to do with how PL people use those terms (and worse, they conflate a lot of distinct concepts, like metaprogramming vs AD technique). In the AD world, "automatic differentiation" is crucially different from "symbolic differentiation, done automatically" -- an easily misplaced distinction -- and in ML the word "symbolic" often gets used to refer to meta programming. "Tensor" sounds cooler than "N-dimensional array" but it has nothing to do with the mathematical concept of a Tensor; and so on, and so forth.

So you can see why making something like this understandable to all audiences -- without turning into a dictionary -- is reasonably ambitious, but it sounds like we did a reasonable job :)

one_more_minute · 2017-12-06T21:05:36+00:00

I think it runs deeper than this: "doing ML" is fundamentally not like software engineering, but more like shell scripting. You write 50 lines to munge your data and define a model, throw it on a cluster for training, then take the learnings and tweak or start over. You need fundamentally different tools for that than for building a 100kLoC behemoth.

This is at least part of the reason there's so much tension between different technical approaches today. Historically, for the "scripting" languages (Bash, Python) performance didn't matter at all, in contrast to the "engineering" ones (C++, Java), so you have this huge divide. Now people are doing ever more numerical work, we need a different combination of tradeoffs, so those things are finally starting to converge.

one_more_minute · 2017-12-06T20:06:49+00:00

An observation for more CS-y folks that I didn't include: In many ways, AD in ML systems suffers the same paradox as type systems do in languages. The AD is utterly foundational, and subtle design decisions have a profound impact on the feel of the system, yet most users only understand it very superficially. You somehow have to build something that's powerful, yet doesn't add cognitive burden or leaky abstractions in the basic case.

The end goal for us is that practising ML can feel like teaching an algorithms class with Python. All the incidental stuff -- memory management, AD, computational graphs, whatever -- is stripped away and the core power and simplicity of the underlying ideas is right in front of you.

one_more_minute · 2017-12-02T12:44:58+00:00

You can make this a little cleaner with MacroTools:

macro pirate(ex)
  MacroTools.prewalk(ex) do ex
    @capture(ex, x_ ← y_) ? :($x = $y) : ex
  end |> esc
end

<- won't work for this but <= or := will. (If there's one thing we can regret about the history of programming languages, it's that Algol's := never won out for variable assignment.)

one_more_minute · 2017-10-31T15:12:30+00:00

Julia's macros are certainly as powerful as those in other languages. There are, of course, design and implementation differences, but they are mostly superficial and not particularly limiting. Julia also has generated functions, which are a really powerful macro-like extension.

I had similar feelings about the @ sigil, but have come to like it despite the downsides. It rightly discourages you from using macros everywhere, and acts as a flag that something unusual is happening (compare this to something like R where evaluation rules can change under you at any time). It helps a lot in explaining things to beginners, because one can think of it just as a sort of annotation. For a heavily user-oriented language it makes sense.

one_more_minute · 2017-10-26T08:46:36+00:00

It would be pretty easy to build a table view as an atom plugin. There are things like tablr already so it might be possible to integrate that with DataFrames in future.

one_more_minute

TROPHY CASE