# Indexing a number

**URL:** <https://discourse.julialang.org/t/indexing-a-number/88735>\
**Category:** Internals & Design\
**Tags:** numbers, indexing\
**Created:** [October 14, 2022, 2:51pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735 "2022-10-14T14:51:27Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![Woodmouth](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/woodmouth/32/24394_2.png) [@Woodmouth](https://discourse.julialang.org/u/Woodmouth)\
**Post date:** [October 14, 2022, 2:51pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/1 "2022-10-14T14:51:27Z")

</div>

If a number is generally treated as a list,

```julia
> 1[1]
1
> 1[2]
BoundsError
>length(1)
1

```

and so on, how come `1[:]` gives an error?  
I would have expected the result to be the same as `[1][:]`.

I think this should be included for consistency.

The use case I have for this is that I import data that could be a number or a list. I use a function to import the data, and I have an optional index parameter:

```julia
function foo(filedata, index=:)
     return filedata[index]
end 

```

Without this feature I now have to make a special case for when `filedata` is a number.

---

<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:** [October 14, 2022, 2:55pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/2 "2022-10-14T14:55:19Z")

</div>

> [@Woodmouth](#):
>
> I would have expected the result to be the same as `[1][:]`.

that would imply you extracted a vector out of a scalar, which should be impossible.

```julia
julia> [1][:]
1-element Vector{Int64}:
 1

julia> [1][1:1]
1-element Vector{Int64}:
 1

julia> a = 1;

julia> a[1:1]
ERROR: MethodError: no method matching getindex(::Int64, ::UnitRange{Int64})
Closest candidates are:

```

---

<div class="post-metadata">

**Author:** ![Woodmouth](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/woodmouth/32/24394_2.png) [@Woodmouth](https://discourse.julialang.org/u/Woodmouth)\
**Post date:** [October 14, 2022, 3:04pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/3 "2022-10-14T15:04:07Z")

</div>

> [@jling](#):
>
> that would imply you extracted a vector out of a scalar, which should be impossible.

I agree that it is strange to extract a vector out of a scalar, but I still feel as though _if_  
`1[1]` gives `1`, _then_ `1[1:1]` should give the same result. It is no stranger to index a scalar in my opinion. I agree that it is strange, but for consistency I think `1[:]` should be allowed.

---

<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:** [October 14, 2022, 3:13pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/4 "2022-10-14T15:13:43Z")

</div>

> [@Woodmouth](#):
>
> but I still feel as though _if_  
> `1[1]` gives `1`, _then_ `1[1:1]` should give the same result.

well, if you agree you shouldn’t be able to extract a vector out of a scalar, then it’s clear why `1[1:1]` shouldn’t work.

Because `[:]` and `[1:1]` etc. always return a collection

---

<div class="post-metadata">

**Author:** ![Woodmouth](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/woodmouth/32/24394_2.png) [@Woodmouth](https://discourse.julialang.org/u/Woodmouth)\
**Post date:** [October 14, 2022, 3:17pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/5 "2022-10-14T15:17:16Z")

</div>

> [@jling](#):
>
> Because `[:]` and `[1:1]` etc. always return a collection

Ahh, that makes sense. ` :` always returns a collection. Thanks 🙂

---

<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:** [October 14, 2022, 3:19pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/6 "2022-10-14T15:19:25Z")

</div>

right; should have said that earlier, btw idk if this is true, but my mental model for `Colon()` is that:

```julia
a[:] === a[eachindex(a)]

```

and for a regular vector,

```julia
eachindex(a) == firstindex(a):lastindex(a) == 1:length(a)

```

---

<div class="post-metadata">

**Author:** ![Woodmouth](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/woodmouth/32/24394_2.png) [@Woodmouth](https://discourse.julialang.org/u/Woodmouth)\
**Post date:** [October 14, 2022, 3:39pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/7 "2022-10-14T15:39:44Z")

</div>

I think the big breakthrough for me is more that `1:1 !== 1` but a collection from 1 to 1. I was just a bit lost in the nuance there. It’s easy to think that `a[1] == a[1:1]` is true for all `a` since it so often is the case. But it turns out that because indexing over scalars is (for some reason) allowed, it is not true. 🤷‍♂️

---

<div class="post-metadata">

**Author:** ![Woodmouth](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/woodmouth/32/24394_2.png) [@Woodmouth](https://discourse.julialang.org/u/Woodmouth)\
**Post date:** [October 14, 2022, 3:55pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/8 "2022-10-14T15:55:34Z")

</div>

```julia
julia> a = 1
1

julia> a[eachindex(a)[1]]
1

```

I’m just saying… If you can do `eachindex(1)` and it doesn’t throw an error… you shouldn’t have to add the extra `[1]` to make it work. 😅

Maybe `eachindex(a::Number)` should just return 1 instead of `Base.OneTo(1)`? That would resolve the issue. Then I could use `eachindex` instead of `:`

(But yes, I see the arguments against, and I am no longer very upset that it doesn’t work like that. Only a little bit.)

---

<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:** [October 14, 2022, 3:57pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/9 "2022-10-14T15:57:15Z")

</div>

Yeah, it’s the fact that the dimensionality of the indexed variable must match the sum of the dimensionality of the indices. This is also the reason why the first dimension is ‘dropped’ in `M[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:** [October 14, 2022, 4:06pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/10 "2022-10-14T16:06:56Z")

</div>

> [@Woodmouth](#):
>
> If a number is generally treated as a list,  
> `> 1[1]`

Not a list (that’s Python terminology), it’s there treated as an Array (though not really), and I found it surprising anyone (you) would try, but it seems intentional, since you can even treat as an n-dim `Array` (I suppose for (partial) support with MATLAB, that I thnk would even would allow `1[:]`, just because it’s possible and not too slow):

```julia
julia> 1[1, 1, 1] # See with @edit 1[1, 1, 1]
1

getindex(x::Number) = x
function getindex(x::Number, i::Integer)
    @inline
    @boundscheck i == 1 || throw(BoundsError())
    x
end
function getindex(x::Number, I::Integer...)
    @inline
    @boundscheck all(isone, I) || throw(BoundsError())
    x
end

```

Since people went to the lengths of supporting this, I was curious couldn’t you just return a collection for e.g. `1[:]`? A (regular) array, lives on the heap and is mutable, but a number can be on the stack, so a pointer to it (unless copied, and even then), wouldn’t be a good idea. That, and what is supported is slower, so why did YOU even try it?

---

<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:** [October 14, 2022, 7:53pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/11 "2022-10-14T19:53:45Z")

</div>

It does seem to me that this should work since this does:

```julia
julia> fill(1)[1:1]
1-element Vector{Int64}:
 1

```

I took the liberty of filing an issue on GitHub: [1[1:1] should work · Issue #47166 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/47166).

---

<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:** [October 14, 2022, 9:00pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/12 "2022-10-14T21:00:53Z")

</div>

Should it? fill(1) creates a (0-dim) Array, and thus allocates (on the heap) as all `Array`s, so that’a different story?

---

<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:** [October 14, 2022, 9:03pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/13 "2022-10-14T21:03:57Z")

</div>

Heap allocation is an implementation detail, not sure why it should inform semantics.

---

<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:** [October 14, 2022, 9:08pm UTC](https://discourse.julialang.org/t/indexing-a-number/88735/14 "2022-10-14T21:08:27Z")

</div>

Ok, I can understand that, and you might want to support more general. Maybe I’m blind to it, but is it really helpful to index a number? I thought you added it since easy in a non-allocating way, but adding more support reduces corner cases (and maybe allocations shouldn’t be to surprising).