As I understand it, IJulia already works with JupyterLab, and has for some time. JupyterLab uses the same ZMQ messaging protocol as the Jupyter notebook to “talk” to language back-end kernels, so it should work as-is with existing kernels like IJulia. Not many people have used it yet, though, so please feel free to bang on it and file issues as they arise.
Not that I’m aware of. Julia’s parser is written in Lisp, and you can get it to print the reserved-words list by typing julia --lisp and typing reserved-words, though. Currently this gives
(begin while if for try return break continue function macro quote let local
global const do struct abstract typealias bitstype type immutable module
baremodule using import export importall end else catch finally true false)
And because the interpolation allows for grabbing things like the derivative, you can make your current derivative depend on the past derivatives, etc. MATLAB probably built theirs on top of ddesd for this reason, but of course this doesn’t cover all problems so this should be one of many methods available.
You can AD through f functions (we already do this for our implicit solvers) or you can also AD through the entire ODE solver. So yes, you can. What are you looking to do? If you want to discuss this more, you may want to go to the JuliaDiffEq channel since this is getting a little off topic from the 1.0 thread.
The point with a generalized LTI is twofold, I guess.
1.a. LTI models are typically used for simulating step and impulse responses in MATLAB’s control toolbox. I assume similar possibilities are relevant for a Julia control package.
1.b. LTI models are also used for operating on the Laplace transform of a system, typically plotting Bode diagrams (amplitude/magnitude in dB vs. frequency, and phase angle vs. frequency), Nyquist diagrams, and Nichols diagrams. For this use, differential equations solvers are not normally used.
Most distributed parameter systems are more complicated than advection/time delay. As an example, various configurations of heat exchangers lead to 1 PDE or 2 coupled PDEs. When linearized, these do not give time delays. Furthermore, it is normally easy to find analytic transfer function which look much more complex than time delays (they may include hyperbolic functions of s, etc.) – alternatively, these transfer functions can be computed by solving boundary value problems for each frequency (Laplace transform variable s is set to j*omega, where j is sqrt(-1) and omega is frequency in rad/time unit).
Anyway, most distributed models are not advection models, and thus lead to transfer functions which may differ widely from time delays.
OK – I guess this discussion fits better in a more specialized forum :-). I’m interested in getting involved somewhat in a discussion of a control package. I have looked briefly at the one developed at KTH/Stockholm; that looks like an excellent start. I’ll try to cook up a simple example of what I have in mind and send separately (both on control package and DiffEq linearization).
At this point, there seems to be a variety of LTI libraries directly and as components of other packages. See Introducing a new Control Toolbox for Julia with Interactive root locus for some discussions. My guess is that post v0.7 freeze it might make sense to collect everyone who uses those sorts of control libraries, and see if a standardized interface is possible.
much like small PRs are easier to review, small frequent breaking changes are easier to adapt to. the changelog for 0.7 makes me shudder.
matlab’s annual release cycle is by far superior to julia and python’s desire to remain completely backwards compatible for years at a time.
would be great if we just stopped with the triage now, push out an alpha-0.7 ASAP (like tomorrow), and in 9 months do a 0.8 if there are still changes to be made.
Any thoughts on a solid set of documentation for language design decisions?
It seems like it would help reduce breaking changes and possibly point out where they are likely/ plus might make a pretty good reference for people learning julia, and future julialang-d.d.'s.
Perhaps I misunderstand, but I see no contradiction between delaying v1.0 and making smaller incremental steps to get there.
Changesare piling up. Many of them are extensions, but some will be breaking and require careful review of the code. Also, there are many minor independent changes, which are harder to keep track of (as opposed to previous large changes that had an organizing theme, eg the arraypocalypse or the constructor syntax changes).
Another argument for an earlier v0.7 is that it has so many great features as is and it would be great to use them sooner if possible.
Also, it brings some new features (eg named tuples), which may lead to usage patterns or problems unanticipated by design and require further changes to the semantics, necessitating a v0.8 (this is not uncommon in software, and has happened before, eg with Nullable and broadcast).
That said, I understand that many related changes (eg Pkg3) are WIP and it may not be easy to make a release now.
Delaying 1.0 by several years and making breaking changes more incrementally is indeed a consistent position (if that is the position). I was interested in clarification because @bjarthur’s previous take seemed to be that we should take our time and make many more breaking changes to the language, whereas this comment seems to be more concerned about too many breaking changes overall and slowing down the rate and perhaps total volume of them. Those are fairly different positions and I’m interested in which one his thinking is closer to – and if it’s changed or if I just misunderstood previously.
The 0.7 release is essentially frozen at this point. We are trying to get 0.7-alpha out the door as soon as we can. There are only two major changes that are still in the works:
Iteration protocol change #18823 – @keno is working on this.
There are no more major Pkg3-related behavior changes to be made in base anymore, although I’m sure there will be some feature additions and bug fixes. We’re working on documentation and tooling improvements now.
There are three issues on the triage label at the moment, one of which is a reversion of a deprecation made earlier (which has turned out to be annoying). Another is a syntax feature request (opened by @Tamas_Papp in October) which is technically breaking, but like so many technically breaking changes, actually unlikely to break much code. The last one is one of the broadcast changes mentioned above.
my core feeling is that we should never put ourselves in a position where we hesitate to improve the language with a breaking change. releases should be made at least yearly, so that folks get the benefit of using new features, and get used to adapting to breaking changes.
at this point, the main shortcomings i see in julia is not a stable API, but rather slow compilation and lack of tooling. i have reluctantly had to return to matlab and python at a customers request recently, but boy am i enjoying dbstop if error and import pdb; pdb.set_trace().
@bjarthur I think Julia is super fantastic as-is right now, and has been for quite some time, I don’t need to switch back to madlab, in fact I shudder at the idea of doing it. It’s very healthy that the Julia language is under such scrutiny and that it is being improved.
@StefanKarpinski So are there no more changes that will be made to Pkg3 for 0.7 then? I think it should be fairly easy and quick to finish up the keywords and description feature.
We all want to get to that place as fast as we can. The same features that make Julia so much faster than interpreted languages like Matlab and Python also make it much harder to implement tools like debuggers. This isn’t for lack of effort – it’s inherently harder to debug a fully JIT language implementation like Julia’s than it is to write a debugger for an interpreted language runtime.
That doesn’t mean we won’t get there, but a somewhat stable base language API is a necessary prerequisite for stable tooling around the language. This is true for many reasons, not least of all that Julia isn’t backed by a big company and the same people who develop the language also develop the tools. We can’t really work on both at the same time, so we need to get big language changes done now and have some breathing room to focus on the ecosystem and tools. If you know anyone with a few hundred million dollars they want to spend on a new, fast, open source numerical programming language, we’re all ears.
To put the release schedule in perspective, 0.6 was released 8 months ago and the typical interval between major Julia releases has been 9 months. That’s 25% more often than Matlab is released and much faster than major Python versions are released.
To clarify, stdlib/Pkg3 is going to keep being worked on and evolving after the 0.7-alpha, but the parts of Pkg3 which are in Base are not. This means that the LOAD_PATH and DEPOT_PATH code loading mechanisms are done and projects with project files and manifests that work on 0.7-alpha will continue to work on 0.7-beta, 0.7, 1.0, 1.1, 1.2, etc. The pkg> REPL interface and commands, on the other hand, are really just tools for creating and manipulating project and manifest files, and these will continue to change up until and after 1.0 in 1.x releases.
In general, stdlib packages – especially interactive ones – are not part of the 1.0 Base API freeze, which is one of the reasons getting them out of Base has been urgent. They will, however, be versioned and it will be possible to lock them to old versions using Pkg3 manifest files (which I think we’re going to rename to “lockfiles” since that seems to be rapidly becoming the standard term).
I think that the community recognizes that the core contributors are working tirelessly on the language, and significants improvements are being made. However, it would be great to have an occasional (eg roughly monthly) brief summary on how things stand and what to expect, for the benefit of those who are not following the details of the issues and the PRs of the Github repo.
It would be good if AbstractChar could be added to Base and make Char <: AbstractChar before v0.7 is frozen, even if all the methods are not updated to use AbstractChar instead of Char yet.
That would greatly help the addition in external packages (or stdlib) of other Char types, such as I’ve implemented in the Strs.jl package.
I am going to say something delibrately provocative here. I often see responses here along the lines of “I would love to use Julia but there is no IDE and no debugger”
Regarding an IDE the Atom/Juno combination looks pretty good to me. There are extensions for VisualStudio.
But for a debugger - how much of a barrier is that in reality?
Did Grace Murray Hopper have a debugger - apart from a flyswat and sellotape?
Well, for me, one of the best things about Julia is the improved programmer productivity (while retaining similar performance to C/C++), at least so far as writing the code in the first place, but not having good debugging tools makes maintenance of code take longer, so I hope that will be one of the biggest focuses after 0.7.