idunning

It is Julia running in a browser, allowing you to try it with no installs. Its not meant for public use yet.

And yes, you shouldn't sign into something you know nothing about - no one is asking you too :)

Yes this wasn't meant to publicly available yet - was up for our own testing and internal use. The maintainer is working on scaling it a bit, but its not really ready to take on the full load of the internet.

It is essentially Julia running in the browser, primarily as an IJulia notebook. Its a way to try Julia, and is good for teaching as students don't need to install anything to get started with technical computing.

Its actually functional, but wasn't meant to be released yet and can't scale to this kind of demand. When it is released, I'm sure you'll see it here!

This is not meant for public consumption yet, so alternatives will be provided later. Before then, using Google to authenticate is much simpler than making a robust password system, and the tool also can store files on Google Drive - requiring auth anyway.

This isn't ready for public consumption, it was posted to HN by someone unrelated to JuliaBox.

See also the fantastic Color.jl, a Julia package with similar functionality. Makes very pretty IJulia notebooks! More info at https://github.com/JuliaLang/Color.jl or just run Pkg.add("Color") at your Julia REPL.

The critical points are the left and right sides of the rectangles.

There was a talk at JuliaCon about this exact topic, and they weren't using it for something I'd describe as "scientific programming". Hope it gets released eventually!

Is https://github.com/JuliaLang/julia/issues/265 the issue you are referring to? If so, not fixed.

Not sure about the second part, but `workspace()` was added in 0.3 (https://github.com/JuliaLang/julia/blob/release-0.3/NEWS.md, https://github.com/JuliaLang/julia/issues/1195)

Sorry for self-reply, but ran out of edit time: a very valid concern about Julia is the lack of packages because it is new - a catch-22 situation that all new languages. This has been recognized by developers and Julia has now got some great inter-language interop packages and functionality, allowing it to harness a world of packages in other languages.

* Very efficient interaction with C and Fortran libraries is a core Julia feature, with the ability to pass arrays and structs directly between C and Julia.

Calling C: http://docs.julialang.org/en/latest/manual/calling-c-and-for...

* Python libraries can be used through PyCall.jl, which is used most famously to call matplotlib (PyPlot.jl) but also other libraries like pandas (Pandas.jl).

PyCall.jl: https://github.com/stevengj/PyCall.jl

PyPlot.jl: https://github.com/stevengj/PyPlot.jl

Pandas.jl: https://github.com/malmaud/Pandas.jl

* Java libraries can be used through JavaCall.jl, which is used in Taro.jl to call Apache Tika and Apache POI

JavaCall.jl: https://github.com/aviks/JavaCall.jl

Taro.jl: https://github.com/aviks/Taro.jl

* R libraries can be called through Rif.jl

Rif.jl: https://github.com/lgautier/Rif.jl

You can call Python packages from Julia, so not entirely starting from scratch! For example here is pandas: https://github.com/malmaud/Pandas.jl

For anyone curious about the packages available in Julia 0.3, please check out http://pkg.julialang.org/. We hope to add keywords and such in the near-term to make package discovery easier. Until then you can check out some of the "organizations" (http://julialang.org/community/) such as JuliaStats (http://juliastats.github.io/) and JuliaOpt (http://juliaopt.org). Finally, we have a blog aggregator that you can follow at http://www.juliabloggers.com/

Julia 0.3 is a solid release and many Julia users have been using the master Github version for the past few months for production use, academic work, and just messing around quite happily. There are relatively few breaking changes from 0.2 to 0.3, with much better package support - so upgrade as soon as you can.

Julia 0.4 is likely to be a more "unstable" release in the tick-tock style that Linux used to have. Already been some great new things merged in, many more to come. I'd recommend not using the master branch of Julia at this time, and instead stay on release-0.3 if you like to build from source.

Or, with a view to Occams Razor, alternatives:

- a large percentage of those health-care workers were infected before full protection was widespread

- they have many chances for infection and mistakes happen

- healthcare workers in regions where Ebola was not known to have reached yet did not take necessary precautions.

I wouldn't say its "misleading", it is a correct usage of the word online (especially contrasted with offline learning) and is the name of the sub-area. You won't find many (most?) papers in the area with those search terms unfortunately.

A benefit of git, for which I can forgive a lot of git's flaws, that was not mentioned in the conclusion is the light-weight branching. The ability to quickly make a branch, experiment, branch off that, merge back, cherrypick commits from another branch, etc. makes me more efficient by spending less time worrying about affecting stable code with experimental changes.

I guess what I'm getting at is a GA with 100% mutation is basically randomly generating solutions and evaluating them. Now, no one does that, but if your GA eventually explores a large amount of the search space in order to get a good solution then it suggests that its not the right approach. So yes, some sort of "global optimization" where you acknowledge you are basically going to look at the whole domain but avoid the silly cases/provably worse cases would be the alternative.

And yes it is, thanks!

One thing to watch out with these sorts of approaches is you are actually improving on an exhaustive search of all possibilities (perhaps with some smart pruning).

Comprehensive! Covers the Lisp-y influences of Julia in great depth.

My perspective on Julia is that it has 3 ingredients:

1. A principled design that derives from the experiences of past programming language and particularly the creator's experiences with Lisps. This is where a lot of the "magic" comes from: multiple dispatch, the type system, metaprogramming, etc. The article covers this aspect.

2. A need to be accessible to those transitioning from other languages, like MATLAB and Python. MATLAB, for example, has guided function naming (although Numpy also has similar names for similar reasons). The author mentions the lack of distinction between creating a variable and changing its binding: I'd suggest this is an example of something affected by this design point.

3. A need to be fast. The author brings up the Int vs BigInt distinction. Python, for example, allows Ints to get as big as you want but at a cost. Adding to Ints is not simply an add instruction, you must do a lot more work. Julia, falling on the side of performance, elects to distinguish between arbitrary BigInts and machine Int.

"Nurse scheduling competitions" seem to alternate between IP and CP approaches - my feeling is that when the number of solutions is "small", CP pulls ahead, but when there are many solutions and the objective is important, IP wins. Very case-by-case dependent, regardless.

I don't think it truly qualifies as an expert system because, to the best I can determine from this limited article, it doesn't make any inferences from a base set of rules. Rather, it is provided with a comprehensive set of all rules, and attempts to find the best solution that satisfy those rules (or, in the language of operations research, constraints). The value provided then is that, because it can consider the space of solutions efficiently, it may discover solutions which are not obvious to human operators.

The way these systems are made, and as the article mentions, is that the obvious rules are added, and solutions evaluated. Experience humans will then usually discover something about the solution that is impossible/impractical, but was not included in the provided rules. The new rules/constraints, and the process repeats until humans are comfortable with the feasibility of the solution/schedule.

This seems like a pretty standard application of scheduling/optimization/operations research. Other applications include:

- Crew scheduling for airlines (e.g. how to satisfy union rules/minimize time-on-ground/get people back home)

- Container flow at ports

- Railway yard scheduling (e.g. allocating cars to engines)

For another example of this particular kind of work (allocating maintenance staff to projects), see a colleague's paper on work for a large gas/electric utility: http://stuff.mit.edu/people/uichanco/scheduling.html

Calling this AI is really a stretch, although the definition of AI is fairly loose I suppose. All the "smarts" are entered by humans in the form of constraints (rules, in this article), the computer's role is essentially just very efficiently searching a combinatorial search space for the best solution. Integer linear programming is a common approach for getting optimal solutions, but can require deep expertise to make fast enough. It seems in this case they have settled for heuristic solutions from a genetic algorithm - perfectly reasonable approach.

The real story for any system like this is actually getting humans to buy into it, see e.g. the many articles about the UPS ORION system for more coverage on this. The last paragraph hints at this but doesn't talk about how they got buy-in, which is something that would be really interesting.

While it is a nice tool, RStudio is AGPL, which means it can't be used in many companies due to contamination fears, including Google but I understand many other companies as well.

Tried with /JuliaLang/julia and got garbage results - my guess is that the build instructions in the README dominate. Trying something like /JuliaOpt/Optim.jl, which has a very on-topic README, faired slightly better but still had some bizzare things like /sergiotapia/go-style-guide

I think you should invest some time into checking out "good kid, m.A.A.d city" then, really fantastic album.

The language I used, JuMP [1], is quite similar to AMPL. In fact in [2] we do performance comparisons with it. Check it out if you have a chance.

[1] https://github.com/JuliaOpt/JuMP.jl

[2] http://arxiv.org/abs/1312.1431

I suppose it could, and would be fairly easy to do!

Could be a challenge: write an IPLANG program with multiple "interesting" solutions

It might be possible. Consider adding new auxiliary variables that represent the state of memory after each operation. You may be then able to add (linear) constraints to those auxiliary variables that are meaningful. Including user input could be tricky though.

Mostly an exercise in using a tool for something not intended - art?

You can definitely express any Brainfuck program as a integer program, and you can add constraints that will constrain what the program does/must do, but it isn't clear to me how to add useful constraints/objective that are still linear. It'd be an interesting exercise though, and something I'll be thinking about.

Integer optimization does have some practical uses related to programming though - its use has been explored in compilers. E.g. http://www.sciencedirect.com/science/article/pii/S0898122197...