# The advantage of using a length-1-vector instead of an int/float variable (if any)?
**URL:** https://discourse.julialang.org/t/the-advantage-of-using-a-length-1-vector-instead-of-an-int-float-variable-if-any/20035
**Category:** General Usage
**Created:** [January 24, 2019, 2:10pm UTC](https://discourse.julialang.org/t/the-advantage-of-using-a-length-1-vector-instead-of-an-int-float-variable-if-any/20035 "2019-01-24T14:10:41Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@bsnyh](https://discourse.julialang.org/u/bsnyh)
#### Post date: [January 24, 2019, 2:10pm UTC](https://discourse.julialang.org/t/the-advantage-of-using-a-length-1-vector-instead-of-an-int-float-variable-if-any/20035/1 "2019-01-24T14:10:41Z")
```julia
t = Vector{Float}(1) # t is a Float-vector of length 1, i.e., it's a one-element vector
initMessage(t, msg) = doPrint && (t[1] = time(); print(msg)) # a simple function to check the progress of #running the code. Logic: if doPrint is true, assign the current CPU time to t[1] and print out the message
initTime(t) = doPrint && println(": ", round(time() - t[1], 2), " seconds")
# function definition. Logic: if doPrint is true, print out the time since the start so far in seconds, rounding up 2 decimials
```
The above code is easy to understand. I was wondering, are there any specific reasons that a length-1 float vector t is used instead of an float variable instead? Would it be quicker? If so, why?
---
### Author:  [@mauro3](https://discourse.julialang.org/u/mauro3)
#### Post date: [January 24, 2019, 2:37pm UTC](https://discourse.julialang.org/t/the-advantage-of-using-a-length-1-vector-instead-of-an-int-float-variable-if-any/20035/2 "2019-01-24T14:37:29Z")
It modifies the array in-place, i.e. after calling `initMessage` the `t` passed into it will be modified. This couldn’t be done with a float as that is immutable. Also, note the convention would be to name the function with a `!` at the end (and also not camel case), i.e. `init_message!`.
---
### Author:  [@bsnyh](https://discourse.julialang.org/u/bsnyh)
#### Post date: [January 24, 2019, 3:09pm UTC](https://discourse.julialang.org/t/the-advantage-of-using-a-length-1-vector-instead-of-an-int-float-variable-if-any/20035/3 "2019-01-24T15:09:53Z")
I tried some code as the following and I think the function parameter handling is not the same as variable assignments. That’s how I understand it.
```julia
julia> t=-1
-1
julia> initMessage!(t,msg)=(t=time(); print("laugh"))
initMessage! (generic function with 1 method)
julia> initMessage!(t,"smile")
laugh
julia> initMessage!(t,"smile")
laugh
julia> initMessage!(t,"smile")
laugh
julia> initMessage!(t,"smile")
laugh
julia> initMessage!(t,"smile")
laugh
julia> initMessage!(t,"smile")
laugh
julia> initMessage!(t,"smile")
laugh
julia> initMessage!(t,"smile")
laugh
julia> t
-1
julia> t=-1
-1
julia> t=-2
-2
```
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [January 24, 2019, 3:19pm UTC](https://discourse.julialang.org/t/the-advantage-of-using-a-length-1-vector-instead-of-an-int-float-variable-if-any/20035/4 "2019-01-24T15:19:32Z")
> [@bsnyh](#):
>
> `initMessage(t, msg) = doPrint && (t[1] = time(); print(msg))`
Note that this is not particularly idiomatic Julia code. It would be much more natural to simply return the time, to take `doprint` as an argument, and to use all lowercase (CamelCaps are used in Julia for types):
```julia
initmessage(msg, doprint=true) = let t = time(); doprint && print(msg); t; end
```
---
### Author:  [@mauro3](https://discourse.julialang.org/u/mauro3)
#### Post date: [January 24, 2019, 3:22pm UTC](https://discourse.julialang.org/t/the-advantage-of-using-a-length-1-vector-instead-of-an-int-float-variable-if-any/20035/5 "2019-01-24T15:22:53Z")
This is a good read: [Values vs. Bindings: The Map is Not the Territory · John Myles White](http://www.johnmyleswhite.com/notebook/2014/09/06/values-vs-bindings-the-map-is-not-the-territory/)
---
### Author:  [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)
#### Post date: [January 24, 2019, 4:04pm UTC](https://discourse.julialang.org/t/the-advantage-of-using-a-length-1-vector-instead-of-an-int-float-variable-if-any/20035/6 "2019-01-24T16:04:43Z")
The idiomatic way would be to use `Ref` instead of one-element arrays. Use a `const Ref` for variables that hold type-stable mutable global state, like `doPrint`.
```julia
julia> begin
timer = Ref(1.0)
const doPrint = Ref(true)
initMessage(t, msg) = doPrint[] && (t[] = time(); print(msg))
initTime(t) = doPrint[] && println(": ", round(time() - t[], 2), " seconds")
initMessage(timer, "m1")
doPrint[] = false
initMessage(timer, "m2")
end;
m1
```
Arrays are slower to access, have larger memory footprint and larger mental overhead than `Ref` (every reader needs to go through the entire codebase in order to check whether `t` really has exactly one element under all circumstances).
---
### Author:  [@bsnyh](https://discourse.julialang.org/u/bsnyh)
#### Post date: [January 24, 2019, 4:39pm UTC](https://discourse.julialang.org/t/the-advantage-of-using-a-length-1-vector-instead-of-an-int-float-variable-if-any/20035/7 "2019-01-24T16:39:07Z")
@foobar_lv2, not sure what exactly is this `Ref(1.0)`.
---
### Author:  [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)
#### Post date: [January 24, 2019, 5:58pm UTC](https://discourse.julialang.org/t/the-advantage-of-using-a-length-1-vector-instead-of-an-int-float-variable-if-any/20035/8 "2019-01-24T17:58:19Z")
For most intents and purposes, it is equivalent to
```julia
mutable struct MyRef{T}
contents::T
end
Base.getindex(x::MyRef) = x.contents
Base.setindex!(x::MyRef{T}, v) where T = (x.contents = convert(T, v); v)
```
It is a container that has exactly one element. Because there always is one element, you use `some_ref[]` instead of `some_ref[1]` for access.
One of the large advantages is that `Array` bookkeeping (allocation and free and resize) can never be elided or inlined by the compiler; these are all foreign function calls into a C library, and not native julia (array access is special cased in the JIT and hence fast, though).
Ref is pure julia, instead of julia wrapped around C.
---
### Author:  [@bennedich](https://discourse.julialang.org/u/bennedich)
#### Post date: [January 24, 2019, 8:17pm UTC](https://discourse.julialang.org/t/the-advantage-of-using-a-length-1-vector-instead-of-an-int-float-variable-if-any/20035/9 "2019-01-24T20:17:06Z")
Based on your sample code, it looks like you want to time something, then print out the elapsed time with a caption, is that correct? If so, I would advice a slightly different approach. First, performance is not something I would worry about at all. That print statement is likely to be thousands of times slower than accessing the time variable. Rather, the problems I see with the current approach are:
- Method directly modifies external data.
- Print statements separated, what if there’s other IO output in between, or you have multiple timers and happen to mix up captions and timers?
- Variable name `t` is so short that comments are needed to explain what it is.
- The single-element-vector idiom to achieve mutability, although fairly common in many languages, is often considered a hack, typically needs comments explaining what’s going on, and even then always attracts the wrong kind of attention during code reviews.
What I would suggest is a small immutable timer object holding the caption and start time:
```julia
const doPrint = true # assuming this is a global flag in your code
struct MyTimer{T<:AbstractString}
message::T
start_time::Float64
end
MyTimer(message) = MyTimer(message, time())
print_timer(timer) = doPrint && @printf("%s: %.2f seconds", timer.message, time() - timer.start_time)
```
Testing it:
```julia
julia> timer = MyTimer("doing stuff");
julia> # do stuff
julia> print_timer(timer)
doing stuff: 1.94 seconds
```
> [@foobar\_lv2](#):
>
> array access is special cased in the JIT and hence fast
It is fast, and should be fast enough under almost all circumstances, but note that it does incur an additional dereference to get from the array object to the raw data. Using a tuple can be faster.