MATLABArrays.jl needed (similar to ElasticArrays.jl)

General Usage
1

I’m porting MATLAB code to Julia, and I know about the helpful packages (and the transpiler), I port gradually, and leave some stuff in MATLAB, or by now even Octave.

Does anyone know if there’s an array type (in a package) with similar or same semantics as MATLAB, e.g. 1x1 is a scalar? The closest I find is:

I’m not sure I would want to use such a package full time (I like the Julia semantics to, e.g. prevent off-by-one errors), but while translating code, it would be nice to have such an array, and maybe even leave it in after, as not all code is performance critical.

It seems it might also be helpful for people running into issues like:

2

what are you looking for exactly? because you can use a 1x1 array if you want, and you can index a scalar at [1] anyways.

2 Likes
3

ElasticArrays.jl only grows in the last dimension. I had e.g. something like that in mind, exactly the same semantics, growable in all dimensions, like in MATLAB.

I’m actually not sure I know all the differences, so the fewer the better, just for piece of mind. I’m just getting errors in my converted code, and then I have to think about were I made a mistake in the conversion (maybe way earlier in the code).

I’ve often had to e.g. change code that uses A, to vec(A).

In Matlab I get 2, while in Julia (need some way to e.g. prevent that):

julia> 1 + [1]
ERROR: MethodError: no method matching +(::Int64, ::Vector{Int64})
For element-wise addition, use broadcasting with dot syntax: scalar .+ array

I did take a look and thought I have actually found what I want, having overlooked:

mxarray(Float64, n) # creates an n-by-1 MATLAB zero array of double valued type
mxarray(Int32, m, n) # creates an m-by-n MATLAB zero array of int32 valued type

but it seems to exists for other purposes.

4

I almost feel like you just need to write more type-stable/clear code and make functions work together instead of rely on some weird scalar + array = scalar behavior of MATLAB

if you know you expect scalar in the end, you can 1 + only([1]), if the latter can be 1 or [1] only

5 Likes
5

I agree, for all new code–written from scratch–I would rather have Julia’s default behavior. I’m only thinking of a new type to help with porting, kind of like training wheels, you could later take off (or not), why I want the exact same semantics, then could later change to “1 + only([1])”. The first step would be such a type, and possibly a package, with a macro to apply it (to e.g. functions) with same syntax, similar to e.g.:

If you want MATLAB-semantics globally, this could help (extended to arrays):

As always in software, you should first get correct, then optimize for speed. So, you would take off the “training-wheels” to enable the faster Julia semantics (assuming the semantics of growing arrays automatically isn’t actually used). Or for non-speed critical code could leave in.

6

Broadcasting and arrays are so deeply baked into the language that I don’t think that it would be easy to provide some kind of a wrapper for a seamless transition.

AFAIK there is nothing magical about growing arrays in Matlab: it just reallocates, which gets more and more expensive as the array grows in size. You can emulate this if you prefer very easily (just wrap an Array and copy over into a new one when setindex! would be out of bounds).

3 Likes