# 1.0 annoyances and Matlab comparison

**URL:** <https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433>\
**Category:** Internals & Design\
**Created:** [March 1, 2018, 9:49pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433 "2018-03-01T21:49:56Z")\
**Posts on this page:** 20\
**Page:** 5

<div class="post-metadata">

**Author:** ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)\
**Post date:** [March 4, 2018, 12:26pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/82 "2018-03-04T12:26:00Z")

</div>

> [@kristoffer.carlsson](#):
>
> You would need to use e.g. OffsetArray{T}(uninitialized, dims…) for any AbstractArray other than Arrays.

Not if the `T` @liso meant was the array type, not the element type, i.e.:  
`empty(OffsetArray{String}, dims...)`

---

<div class="post-metadata">

**Author:** ![nalimilan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nalimilan/32/147_2.png) [@nalimilan](https://discourse.julialang.org/u/nalimilan)\
**Post date:** [March 4, 2018, 1:25pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/83 "2018-03-04T13:25:57Z")

</div>

FWIW, `empty` is completely different from what we’re discussing here: it creates a collection with zero elements. So another name would be needed (`uninitialized`, `uninit`, etc.).

Anyway `uninitialized(Array{Int}, dims...)` is almost identical to `Array{Int}(uninitialized, dims...)`, so the main question is rather whether we can find something shorter than `uninitialized`.

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [March 4, 2018, 1:52pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/84 "2018-03-04T13:52:02Z")

</div>

> [@y4lu](#):
>
> A default would probably be handy for arrays of Union types, and could even be performant if done lazily? ie set or return the default value on read if still undefined / unwritten, like a hidden(?) union of type x + initialized boolean that will fall back to type x on true (initialized)

When requesting uninitialized data, then initializing the types for the union defies the point. Also, uninitialized arrays only exist for inlinealloc / bitstype data.

That way, you can request a nice 50TB array of uninitialized memory; the kernel will lazily reserve physical memory for you. If you do this with explicit initialization, then you will kill your system.

Something that might make sense is an option for zero-byte initialization, though, if this was internally implemented via `calloc` for large arrays, instead of `malloc` + `memset`). Regardless, this is probably not a good style, since the gc gets very very unhappy if you give it control over giant chunks of virtual memory exceeding your physical memory (so you need to do the `calloc` yourself and then `unsafe_wrap` without handling control to the gc, in order to get a giant vector and a gc that is not panicking about memory usage; not worth the effort, but a fun way to avoid the `ccall` on `push!`).

What zero-byte means depends on the type, but zero-byte init and uninitialized are both qualitatively different from `fill` (if `calloc` is used).

edit: I did not actually try this with 50TB, but I did play around with this branch-free `push!`, where the resizing is punted to kernel/hardware. Not sure whether this works on non-linux systems.

---

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [March 4, 2018, 4:38pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/85 "2018-03-04T16:38:51Z")

</div>

To me, `Array` is special because it seems to be the most common of all `AbstractArray`s. I agree that one needs a general way of creating all kinds of uninitialized `AbstractArray`s. This will probably be something like `Array{T}(uninit, dims...)`. However, what’s wrong about in addition having special convenience function `uninit(T, dims...)` and `ones(T,dims...)` and so on that always create `Array`s?

I don’t see much of a point in e.g. `uninit(Array{Int}, 2, 2)` i.e. taking T not as eltype of `Array` but full type, as this is no shorter than `Array{Int}(uninit, 2, 2)` and in my eyes wouldn’t be a _convenience_ function at all.

---

<div class="post-metadata">

**Author:** ![Seif\_Shebl](https://avatars.discourse-cdn.com/v4/letter/s/eada6e/32.png) [@Seif\_Shebl](https://discourse.julialang.org/u/Seif_Shebl)\
**Post date:** [March 4, 2018, 6:26pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/86 "2018-03-04T18:26:19Z")

</div>

What about `A = Array{T}(new, dims…)`? To me, `new` means request an uninitialized memory for array of dimensions `dims…`, this is somehow analogous to `uninitialized`? but more easier to type and much shorter?

---

<div class="post-metadata">

**Author:** ![Christopher\_Fisher](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/christopher_fisher/32/26132_2.png) [@Christopher\_Fisher](https://discourse.julialang.org/u/Christopher_Fisher)\
**Post date:** [March 4, 2018, 7:19pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/87 "2018-03-04T19:19:29Z")

</div>

I really dislike the initialized syntax, but I don’t completely understand the rationale aside from making the intent to create an initialized object explicit. From my perspective, adding an extra argument for the sake of being explicit appears to be solving a problem that doesn’t really exist. It should be clear that `x = Array{Float64}(n)` does not contain sensible values because no values were given or implied by the statement. Adding the extra argument makes the syntax more verbose, annoying to type, and less readable, like Java.

I have been tripped up by the reference behavior of Julia a few times ([see](http://www.johnmyleswhite.com/notebook/2014/09/06/values-vs-bindings-the-map-is-not-the-territory/)). This behavior could be made more explicit with `x[i] = ReferenceTo(myObject)`. Unlike the case of the constructor, being explicit for references seems more justifiable. However, I would rather learn the default behavior of the language and have more readable code.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [March 4, 2018, 8:08pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/88 "2018-03-04T20:08:25Z")

</div>

Did anyone read the explanation that was given by @mbauman and linked to multiple times?

> [@Array{T}(initialization,...) syntax](https://discourse.julialang.org/t/array-t-initialization-syntax/9298/2):
>
> We’ve long supported constructing an Array with a set of known contents like Array(1:3) or Array(sprand(4,4,.4)). We want to generalize this to all iterables and all Abstract Array types, but the specifying-dimension-sizes-for-an-uninitialized-array is ambiguous: Is Array(2) constructing [2] or [#undef, #undef] (since numbers are iterable collections themselves)? Using an explicit initialization object allows us to disambiguate this case… and also support Array(3I, 5, 5) and maybe other clever…

Despite what people keep insisting here, the motivation was not to punish people who want to allocate uninitialized arrays by forcing them to type a long word. The motivation was this:

- Collections are generally constructed in Julia by passing an iterable argument which is used to populate the collection as described [here](https://julialang.org/blog/2016/10/julia-0.5-highlights#initializing-collections).

- Arrays constructors predate this convention and are now an awkward exception to this general pattern. By this convention, `Array((2,3))` should construct the vector `[2,3]` instead of an uninitialized 2×3 matrix. Similarly, `Array(3)` should construct `[3]` instead of an uninitialized 3-element vector.

- `Array(dims...)` is a dangerously simple syntax for a fundamentally dangerous operation. Allocating uninitialized memory can introduce non-determinism and bugs into programs if not used correctly. `Array(2,3)` looks like a very innocuous operation. So not only is this syntax now at odds with how collections generally work, but it’s a dangerous operation.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [March 4, 2018, 10:05pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/89 "2018-03-04T22:05:50Z")

</div>

The code snippet you posted looks horribly unoptimized to me: it allocates zillions of tiny (length 4!) temporary arrays.

This is not how to write fast Julia code, so you can’t draw meaningful performance conclusions from it.

(You should either use StaticArrays or lose the Matlab habit of using vectors for every inner loop.)

---

<div class="post-metadata">

**Author:** ![y4lu](https://avatars.discourse-cdn.com/v4/letter/y/47e85d/32.png) [@y4lu](https://discourse.julialang.org/u/y4lu)\
**Post date:** [March 5, 2018, 2:06am UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/90 "2018-03-05T02:06:43Z")

</div>

I figured after that it could probably be implemented with a call to map and a bitvector / bitarray on the side for the uninitialized data state, possibly like `map((x,y)->x?defaultval:y, initvec, datavec)`  
I thought it might be slightly faster in the case of resetting an array, especially if it happens often… simple testing seems to disagree though

> setting 100\_000\_000 bitarray with `x[:]=` - 0.002sec  
> setting 100\_000\_000 Int64s with `y[:]= ` - 0.15sec  
> indexing Int64 with bitarray `y[x] ` - 1.17 sec  
> default val map (as above) - 1.92 sec

---

<div class="post-metadata">

**Author:** ![EthanAnderes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ethananderes/32/2028_2.png) [@EthanAnderes](https://discourse.julialang.org/u/EthanAnderes)\
**Post date:** [March 5, 2018, 4:33am UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/91 "2018-03-05T04:33:07Z")

</div>

I think `uninitialized` would be an easier sell to the general user if there was an example or two that could demonstrate new cool stuff that can be done with the syntax. For me, I still have a hard time understanding how to take advantage of it. The first thing I tried when I saw it was

```julia
a = Float32[x for x in uninitialized]  
a = Float32[uninitialized for x in 1:5]

```

thinking that it was some type of iterable that would just initialize what ever the inferred type of the container was. The next thing I tried was

```julia
fill(Array{Complex{Float32}}(uninitialized, 2,2), 5, 5)

```

hoping it wouldn’t fill a 5x5 matrix of pointers to the same 2x2 array.

So, even though I’ve read the explanations of why, to me it basically just behaves like special function syntax for telling the computer to `allocate an array of a certain size/shape`, rather than a general way to think about container constructors that fits in with the whole language design. I also think this is why the consistency argument doesn’t resonate with me yet … i.e. I can’t seem to use `uninitialized` as I would other iterators.

Hope I don’t sound like I’m complaining here. Just thought this perspective could help tune how the new syntax is sold to others. Indeed, if I could overload it somehow to help me initialize custom containers with uninitialized objects of specific memory layout, I would love it.

---

<div class="post-metadata">

**Author:** ![kevin.squire](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevin.squire/32/62_2.png) [@kevin.squire](https://discourse.julialang.org/u/kevin.squire)\
**Post date:** [March 5, 2018, 6:18pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/92 "2018-03-05T18:18:10Z")

</div>

> I’d really like a naive empty(T, dims…) from a users perspective. But I guess I can also live with uninit(T, dims…) given the fact that there is an empty function already with a different meaning.

Right now, the relevant definition of `empty` is `empty(v::AbstractVector, [eltype])`, which can only create empty vectors. How about

1. Adding a length argument to the current definition, to allow creation of undefined arrays
2. Creating a variant for N\>1 dimensional arrays (with `dims`)
3. Creating a variant with just `eltype` and `dims`.

This might look like

```julia
empty(v::AbstractVector, [eltype], [length])
empty(v::AbstractArray, dims::NTuple{N,T})
empty(v::AbstractArray, eltype, dims::NTuple{N,T})
# alternative or additional convenience def:
# empty(v::AbstractArray; eltype::DataType, dims::NTuple{N,T})
empty(eltype, dims::NTuple{N,T})

```

This would be familiar to people coming from `numpy`, and would sidestep `uninitialized` entirely.

Thoughts? If there’s interest, I can try to get a pull request together.

Cheers,  
Kevin

---

<div class="post-metadata">

**Author:** ![nalimilan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nalimilan/32/147_2.png) [@nalimilan](https://discourse.julialang.org/u/nalimilan)\
**Post date:** [March 5, 2018, 7:31pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/93 "2018-03-05T19:31:44Z")

</div>

`empty` sounds really weird for this operation. There’s nothing empty here: neither the returned collection, nor its elements.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [March 5, 2018, 7:32pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/94 "2018-03-05T19:32:18Z")

</div>

I really don’t like the word `empty` for this. These arrays aren’t empty. They’re just filled with junk. A zero-length vector `isempty`. As is a 0x0 matrix.

A `Vector{Int}(uninitialized, 20)` is not empty.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [March 5, 2018, 7:36pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/95 "2018-03-05T19:36:52Z")

</div>

We can’t give examples that work now because the old behavior still works but is deprecated on 0.7-DEV (master) – any new behavior cannot be implemented until 1.0 or later. But it could look something like this:

```julia
julia> Vector(k^2 for k = 1:5)
5-element Array{Int64,1}:
  1
  4
  9
 16
 25

```

Of course, this is equivalent to `[k^2 for k = 1:5]` but the same thing works for other vector types, e.g. when using [StaticArrays](https://github.com/JuliaArrays/StaticArrays.jl) one could write `SVector(k^2 for k = 1:5)` instead of what you currently need to write which is `@SVector [k^2 for k = 1:5]`.

Note that the values passed in don’t necessarily need to be all of an abstract array’s values. Instead, for some types we’d like to provide an iterable that gives a certain subset of values. For example, constructing a diagonal matrix like this (this also doesn’t work yet):

```julia
julia> Diagonal(k^2 for k = 1:5)
5×5 LinearAlgebra.Diagonal{Int64,Array{Int64,1}}:
 1 ⋅ ⋅ ⋅ ⋅
 ⋅ 4 ⋅ ⋅ ⋅
 ⋅ ⋅ 9 ⋅ ⋅
 ⋅ ⋅ ⋅ 16 ⋅
 ⋅ ⋅ ⋅ ⋅ 25

```

But in order for all of this to work and be coherent and consistent in the future, we need to pave the way by “taking away” the syntaxes where dimensions and tuples of dimensions are passed to array types in order to get uninitialized instances with those dimension sizes. I have to say that I had not anticipated that this would be such a sticking point for people. (Although I did suspect that using the word `uninitialized` was not going to be so popular).

---

<div class="post-metadata">

**Author:** ![jeff.bezanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeff.bezanson/32/48_2.png) [@jeff.bezanson](https://discourse.julialang.org/u/jeff.bezanson)\
**Post date:** [March 5, 2018, 8:02pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/96 "2018-03-05T20:02:19Z")

</div>

> [@EthanAnderes](#):
>
> if I could overload it somehow to help me initialize custom containers with uninitialized objects of specific memory layout

I’m not totally sure what you mean, but it is possible to define methods with `::Uninitialized` to make other constructors that work similarly.

> [@EthanAnderes](#):
>
> fill(Array{Complex{Float32}}(uninitialized, 2,2), 5, 5)

I know some people dislike the fact that this fills an array with references to the same object (which we aren’t going to change), but I don’t see what that has to do with `uninitialized`. The same applies to any array or object passed to `fill`.

---

<div class="post-metadata">

**Author:** ![kevin.squire](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevin.squire/32/62_2.png) [@kevin.squire](https://discourse.julialang.org/u/kevin.squire)\
**Post date:** [March 5, 2018, 8:29pm UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/97 "2018-03-05T20:29:48Z")

</div>

> `empty` sounds really weird for this operation. There’s nothing empty here: neither the returned collection, nor its elements.

> I really don’t like the word `empty` for this. These arrays aren’t empty. They’re just filled with junk. A zero-length vector `isempty`. As is a 0x0 matrix.
> 
> A Vector{Int}(uninitialized, 20) is not empty.

Fair enough. I was looking for a short solution, and this [does have precedence](https://docs.scipy.org/doc/numpy/reference/generated/numpy.empty.html).

But I would be happy enough with `undef(T, dims)` (and would define this myself, if it isn’t provided). (And no, it doesn’t work for alternate array types, unless `T<:AbstractArray`, which mostly defeats the purpose.)

Cheers,  
Kevin

---

<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:** [March 6, 2018, 7:06am UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/98 "2018-03-06T07:06:47Z")

</div>

> [@StefanKarpinski](#):
>
> I have to say that I had not anticipated that this would be such a sticking point for people.

Perhaps because the possibilities above did not get enough exposure (I am seeing this for the first time, although I admit that a lot of things about the deprecation path become more clear in retrospect), and also because suggestions that creating uninitialized arrays is something that one should not do, “unless you know what you are doing”.

---

<div class="post-metadata">

**Author:** ![pablosanjose](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pablosanjose/32/7006_2.png) [@pablosanjose](https://discourse.julialang.org/u/pablosanjose)\
**Post date:** [March 6, 2018, 9:53am UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/99 "2018-03-06T09:53:57Z")

</div>

For what it’s worth, I actually like the verbose `uninitialized` constructor. It makes such statements very visible in code, and lends them the weight they deserve. I also like the potential for future extensions of the syntax.

---

<div class="post-metadata">

**Author:** ![swissr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/swissr/32/208_2.png) [@swissr](https://discourse.julialang.org/u/swissr)\
**Post date:** [March 6, 2018, 11:27am UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/100 "2018-03-06T11:27:59Z")

</div>

> [@pablosanjose](#):
>
> I actually like the verbose uninitialized constructor

Initially I thought the same. But now, looking at code in [boot.jl](https://github.com/JuliaLang/julia/blob/master/base/boot.jl) and [array.jl](https://github.com/JuliaLang/julia/blob/master/base/array.jl), `uninitialized` is occupying sooo much space and weight. It likely would annoy me in future. In e.g.

```julia
similar(a::Array{T,1}) where {T} = Vector{T}(uninitialized, size(a,1))
similar(a::Array{T,2}) where {T} = Matrix{T}(uninitialized, size(a,1), size(a,2))
similar(a::Array{T,1}, S::Type) where {T} = Vector{S}(uninitialized, size(a,1))

```

the focus goes to uninitialized and the type and the dimension fade. For me, the balance is wrong.

In earlier times I didn’t really distinguish between (initialized) `fill`, `zeros` and (uninitialized) `Array{Int32}(2,3)`. I thought, `fill` takes much more time, `Array` would be the standard and was not fully aware of the ‘uninitialized-dangers’. Now I think a more subdued hint, even `new`, my personal favorite, would be enough to point out the difference:

```julia
uninitialized arrays | initialized arrays
---------------------|---------------------
Array{..}(new, ..) | Array{..}(nothing|missing, ...
                     | fill, zeros, ones

```

Admittedly with `new` one would have to read the manual/help once, but afterwards I believe, the rule, new means uninitialized, is in the mind. In addition, `Array{..}(new, ..)` is ‘strange’ enough that one would look up the meaning of `new`.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [March 6, 2018, 11:49am UTC](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433/101 "2018-03-06T11:49:49Z")

</div>

> [@swissr](#):
>
> Initially I thought the same. But now, looking at code in boot.jl and array.jl, uninitialized is occupying sooo much space and weight.

I agree. The weight is _too_ great, more than they deserve.

I also suspect that creating uninitialized arrays is a lot more common than what was presumed. I create uninitialized arrays _by default_, excepting only when I actively want there to be a default value, such as zero.

[Previous page](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433.md?page=4)

[Next page](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433.md?page=6)