# MATLABArrays.jl needed (similar to ElasticArrays.jl)

**URL:** <https://discourse.julialang.org/t/matlabarrays-jl-needed-similar-to-elasticarrays-jl/46108>\
**Category:** General Usage\
**Created:** [September 5, 2020, 3:18pm UTC](https://discourse.julialang.org/t/matlabarrays-jl-needed-similar-to-elasticarrays-jl/46108 "2020-09-05T15:18:28Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 5, 2020, 3:18pm UTC](https://discourse.julialang.org/t/matlabarrays-jl-needed-similar-to-elasticarrays-jl/46108/1 "2020-09-05T15:18:28Z")

</div>

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:

> **[GitHub - JuliaArrays/ElasticArrays.jl: Resizeable multi-dimensional arrays...](https://github.com/JuliaArrays/ElasticArrays.jl)**
>
> Resizeable multi-dimensional arrays for Julia. Contribute to JuliaArrays/ElasticArrays.jl development by creating an account on GitHub.

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:

> [@1d arrays vs 1-column matrices](https://discourse.julialang.org/t/1d-arrays-vs-1-column-matrices/46101):
>
> Does this mean that storing vectors as x(n,) rather than x(n,1) has performance benefits?

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [September 5, 2020, 3:32pm UTC](https://discourse.julialang.org/t/matlabarrays-jl-needed-similar-to-elasticarrays-jl/46108/2 "2020-09-05T15:32:15Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 5, 2020, 4:08pm UTC](https://discourse.julialang.org/t/matlabarrays-jl-needed-similar-to-elasticarrays-jl/46108/3 "2020-09-05T16:08:25Z")

</div>

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
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:

> **[GitHub - JuliaInterop/MATLAB.jl: Calling MATLAB in Julia through MATLAB Engine](https://github.com/JuliaInterop/MATLAB.jl)**
>
> Calling MATLAB in Julia through MATLAB Engine. Contribute to JuliaInterop/MATLAB.jl development by creating an account on GitHub.

> 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.

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [September 5, 2020, 4:11pm UTC](https://discourse.julialang.org/t/matlabarrays-jl-needed-similar-to-elasticarrays-jl/46108/4 "2020-09-05T16:11:18Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 5, 2020, 8:41pm UTC](https://discourse.julialang.org/t/matlabarrays-jl-needed-similar-to-elasticarrays-jl/46108/5 "2020-09-05T20:41:22Z")

</div>

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.:

> **[GitHub - JuliaMath/ChangePrecision.jl: macro to change the default...](https://github.com/JuliaMath/ChangePrecision.jl)**
>
> macro to change the default floating-point precision in Julia code - GitHub - JuliaMath/ChangePrecision.jl: macro to change the default floating-point precision in Julia code

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

> [@\[ANN\] SafeREPL: use BigInt by default at the REPL](https://discourse.julialang.org/t/ann-saferepl-use-bigint-by-default-at-the-repl/41271):
>
> With Julia 1.5 around the corner, I’m happy to present [SafeREPL](https://github.com/rfourquet/SafeREPL.jl), a little experimental package which by default interprets Int and Int128 REPL literals as BigInt, and Float64 literals as BigFloat: julia\> using SafeREPL julia\> factorial(40) 815915283247897734345611269596115894272000000000 julia\> sqrt(2.0) 1.414213562373095048801688724209698078569671875376948073176679737990732478462102 julia\> c = 299\_792\_458; c^3 # the cube of the speed of light can even be computed safely! 26944002417373989…

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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [September 6, 2020, 9:04am UTC](https://discourse.julialang.org/t/matlabarrays-jl-needed-similar-to-elasticarrays-jl/46108/6 "2020-09-06T09:04:45Z")

</div>

> [@Palli](#):
>
> 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

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).