^ I proposed some sort of SIG for MATLAB users who like me are coming from a MATLAB background and either migrating code to Julia or considering whether to do so:
… and was encouraged (thanks!) to start a new thread:
Flesh out the Wikibook that I recently started (don’t get too excited, it’s just embryonic at this point)
“Revive” MatlabCompat.jl in some sense (IMO before hacking on it we should step back and think about things like different use cases, avoiding too many dependencies, etc.)
As I expressed in the earlier thread, I also think that coming from any other language there will be similar questions, so I hope that if folks band together similarly for, e.g. Python users learning Julia, that we can combine forces here.
Just my 2c worth: I found that the array indexing being superficially similar in Matlab and in Julia helped with porting low-level code from Matlab to Julia. On the other hand, I found that making a decisive and clean break from Matlab by totally rejecting its software design principles is the only way to get a nice Julia code. By that I mean for instance taking full advantage of multiple dispatch, modifiable arguments (especially arrays), and getting rid of the vectorized-code-is-the-only-way thinking.
I don’t know we’re you got the idea that we want to write vectorized (awfully memory wasteful) code and ignore multiple dispatch.
I also don’t know for others but for me I just want to be able to use familiar function names (linspace, strtok, flipdim, cumsum, repmat, etc…) without having to loose time digging in the docs how to do the same thing with Julia functions/constructs.
I certainly wouldn’t presume to suggest that you would write bad code. It was purely a reflection on the value of maintaining some semblance of the Julia code to Matlab code, including potentially having the “same” code run on both platforms.
I personally believe that making a clean break and sticking to Julia conventions will make my code easier to read for anyone familiar with Julia (but not with Matlab). And that is much more valuable to me than having to learn a few new names.
I agree but: Did you feel the same when you first switched? Is this still true if just quickly want to hack together a crude test that is not intended to be read / reused?
Virtually everybody on this thread is (relatively speaking) a power user. Please don’t forget about beginners or just people who need to write a few simple codes to publish a paper but couldn’t care less about how elegant and consistent the design of the language is.
There are a few different audiences of Matlab natives, and each group needs to be directed towards different sets of resources to get up to speed in Julia.
True beginners: they’ve played with a few scripts in Matlab, but they haven’t been around long enough to pick up bad habits. Send 'em towards a guide with lots of in-depth examples aimed at novice programmers, e.g. Chris’s fantastic intro or the QuantEcon course.
Intermediates: they know enough to be dangerous. They have expectations about how functions fit together, how to structure code to make it fast, and how to use and abuse the syntax. They need a syntax cheat sheet, e.g. this or this (which they’ll be able to find on their own), plus full explanations of ‘surprising’ things about Julia, including noteworthy differences, performance tips, and gotchas.
It’d also be worthwhile to collect all the Matlab-conversion Discourse threads in one place (maybe with a tag?), since there are few better ways to learn than by example.
Experts/application builders: they’ll start with the same set of resources as intermediates, but they don’t need much handholding and’ll just start RTFMing of their own accord.
Additionally, I think there’s a lot of value in having a meta-package that re-exports everything needed to get a Matlab or SciPy-like experience. from scipy import * is a terrible software engineering practice, but that doesn’t make it any less useful for exploratory work. I went through the Matlab docs and came up with the rough list below; I don’t think everything there necessarily belongs in Batteries.jl, but it’s a start. I’m really not looking forward to resolving the swarm of namespace conflicts this’ll spit out.
Mathematics
Elementary math
Primes.jl
Combinatorics.jl
Polynomials.jl
DSP.jl
SpecialFunctions.jl
CoordinateTransformations.jl
SpecialMatrices.jl
MatrixDepot.jl
Base.MathConstants
Linear algebra
LinearAlgebra (stdlib)
Random numbers
Random (stdlib)
Interpolation
Interpolations.jl
Dierckx.jl
ScatteredInterpolation.jl
Optimization
Optim.jl
LsqFit.jl
Numerical integration and differential equations
DifferentialEquations.jl
QuadGK.jl
ApproxFun.jl
Fourier analysis and filtering
FFTW.jl
DSP.jl
Sparse matrices
SparseArrays (stdlib)
IterativeSolvers.jl
Graphs
LightGraphs.jl
GraphPlot.jl
Computational geometry
GeometricalPredicates.jl
VoronoiDelaunay.jl
Graphics
Plots.jl
Luxor.jl
Images.jl
ImageView.jl
Data import and analysis
Data import and export
Text files
DelimitedFiles (stdlib)
CSV.jl
CSVFiles.jl
Spreadsheets
Too many options! Need a performance shootout.
ExcelReaders.jl for raw arrays
ExcelFiles.jl for use with DataFrames
Taro.jl
XLSX.jl
Images
FileIO.jl
ImageMagick.jl
Scientific data
NetCDF.jl
HDF5.jl
FITSIO.jl
Audio and video
FileIO.jl
VideoIO.jl
Still missing a convenient, portable video-writing interface
Creating such a package should be conceptually easy, just really tedious. If a few users (or just one person) truly finds this valuable, then they should just do it.
Indeed, and along with those experience based audiences I’ll add that I think there are people who might be in any of the groups you identify and also are trying to determine:
If Julia is suitable for porting a specific existing piece of Matlab code to Julia. These people will want to know to what extent whatever Matlab functionality they are using has an existing equivalent in Julia. Depending on their familiarity with Julia they may need an almost drop-in replacement, or if that isn’t available and they are more comfortable in Julia they may just want to plan to spend some time developing the Julia equivalent.
Whether Julia can be used in a certain domain where otherwise Matlab would be used. Often this will be in a business context. For instance, an aerospace controls engineering team might wonder if Julia could be used for design and analysis of the controller for their next product, where they would otherwise default to Matlab (plus toolboxes). Decisions such as these will be a function of a number of things: the degree to which Julia already has the needed equivalent functionality, how stable/complete that functionality is, the projected costs of the team members learning Julia, costs for team members’ time to implement missing functionality, and so on.
In both of these cases the decision involves (or should involve) a determination of whether an investment of resources today will be worthwhile over time based on some prediction of how popular a language Julia will become. Clearly there is a snowball effect with language popularity–despite Matlab’s many warts because it was widely used in certain areas it attracted more users, and this in turn attracted more, etc. Hopefully Julia’s broader applicability (and availability, being open source) as a language will accelerate this process, much in the way that happened with Python.
I’ll add another audience: For those who know neither language yet, there are those making a decision of whether to learn Julia or Matlab. Julia should have a huge advantage here given its free availability, though from many university students’ perspectives, at least, Matlab appears to be effectively free or nearly so due to site licensing and/or educational discounts. Maybe this suggests that for adoption in the longer term it is worthwhile for the community (and Julia Computing) to focus some resources on helping younger people learn Julia.
I like what this idea is getting at, and there may be other ways to accomplish the same goal. For instance, especially for exploratory work, what if there was a hotkey in the REPL (or maybe OhMyREPL) that when hit following a Matlab keyword/function name would pop up suggestions for Julia equivalents? Or as I’ve suggested before as part of a package of Matlab ‘aliases’ there was an option where something like deprecation warnings could be enabled so that at runtime based on the specific data types (and even values) being used, more appropriate Julia-native suggestions could be made?
Actually I wonder too if the notional Batteries.jl (maybe it should be called MatlabBatteries.jl) could be written such that it doesn’t directly have any dependencies but defines all the keywords that are available in a number of distinct packages. Further the help system could be leveraged to encourage users of this package to use native Julia equivalents with something similar to the deprecation warnings that are printed in 0.7 when methods like eye are called. So the main package could be designed that you could do something like:
julia>using MatlabBatteries
julia>eye(3)
ERROR: To use a Matlab drop-in replacement for eye, add a using statement:
using MatlabFundamentals
julia>using MatlabFundamentals
julia>?eye
A drop-in for the MATLAB function eye is available:
julia> using MatlabFundamentals: eye; twotimesidentity = 2 * eye(3)
3×3 Array{Float64,2}:
2.0 0.0 0.0
0.0 2.0 0.0
0.0 0.0 2.0
For a direct native Julia replacement, consider `Matrix(1.0I, m, m)` or
`Matrix{Float64}(I, m, m)`. If `Float64` element type is not necessary,
consider the shorter `Matrix(I, m, m)` (with default `eltype(I)` `Bool`).
Awesome! I’m definitely going to borrow from this list to help populate the Wikibook, thanks! This also reminds me that I need to add an Acknowledgments section.
I think we have the first function name for MatlabPuns.jl:
export goodbeye
function goodbeye(m::Integer)
return Matrix{Float64}(I, m, m)
end
function goodbeye(::Type{T}, m::Integer) where T
return Matrix{T}(I, m, m)
end
function goodbeye(m::Integer, n::Integer)
return Matrix{Float64}(I, m, n)
end
function goodbeye(::Type{T}, m::Integer, n::Integer) where T
return Matrix{T}(I, m, n)
end
function goodbeye(A::AbstractMatrix{T}) where T
return Matrix(one(T)I, size(A))
end
function goodbeye(::Type{Diagonal{T}}, n::Int) where T
return Diagonal{T}(I, n)
end
