Best practice to handle type annotations

General Usage
1

From reading the Performance Tips in the Julia manual, I grasped that type declarations generally improve the performance and abstract types should be avoided. So lets say I have a function

function func(x, n::Integer)
    y = Real[]
    for i = 1:n
        push!(y, x^i)
    end
    return y
end

that I want to improve by replacing all abstract types:

function func(x, n::Integer)
    y = Float64[]
    for i = 1:n
        push!(y, x^i)
    end
    return y
end

Now I can imagine cases, where the specific type Float64 might be non-ideal, e.g. when the code is executed on a GPU that likes to work with 32-bit input. In that case, I would want to replace every hard-coded Float64 wtih Float32 etc. How can I avoid doing the replacement depending on my use case. Would declaring my own type somewhere in the package useful, so that I need to replace it only once?

const MyFloat = Float64

# [...]

function func(x, n::Integer)
    y = MyFloat[]
    for i = 1:n
        push!(y, x^i)
    end
    return y
end

I wolud like to hear your ideas for such a situation.

2

Read the performance tips again — that’s not what they say.

In particular, abstract types declarations for function arguments do not hurt performance. See argument-type declarations in the manual. Similarly for declaring return types or local-variable types.

This has no effect on performance compared to func(x::Real, y::Integer). It just makes your function less generic.

1 Like
3

The equally fast, but generic version of your function would look like this:

function func(x::T, n::Integer) where {T<:Real}
    y = T[]
    for i = 1:n
        push!(y, x^i)
    end
    return y
end
7 Likes
4

Thank you, I misunderstood this aspect in the manual. I changed the example in the question.

5

You could also just use y = typeof(x)[] or y = Vector{typeof(x}}(undef, 0). You don’t need to explicitly declare type parameters. This is also more flexible because you can compute types, e.g. typeof(float(x)^2) or calls to functions like promote_type.

The key idea in generic programming is to infer (either implicitly or explicitly) the types in your function from the types of the arguments.

4 Likes
6

But what if there is no variable to infer the type from, like in this example:

function func(n::Integer)
    y = Complex{typeof(??)}[] # replace ?? with the correct type
    for k = 1:n
        push!(y, exp(im * pi / k))
    end
    return y
end
7

Then you’ll need to make provisions to specify it manually. Something like

julia> function func(::Type{T}, n::Integer) where T
           y = complex(T)[]
           for k = 1:n
               push!(y, exp(im * pi / k))
               # EDIT: see comments below regarding doing the calculation with the target type
           end
           return y
       end
func (generic function with 1 method)

julia> func(Float16, 8)
8-element Vector{ComplexF16}:
  Float16(-1.0) + Float16(0.0)im
   Float16(0.0) + Float16(1.0)im
   Float16(0.5) + Float16(0.866)im
 Float16(0.707) + Float16(0.707)im
 Float16(0.809) + Float16(0.588)im
 Float16(0.866) + Float16(0.5)im
 Float16(0.901) + Float16(0.4338)im
 Float16(0.924) + Float16(0.3826)im

(You could alternatively use function func(T::Type, n::Integer) for the definition, but there can sometimes be performance differences between these for complicated reasons including but not limited to this.)

2 Likes
8

Here, it sounds like you want to infer the type from the type of exp(im * pi / k) (which is more efficiently computed as cis(pi/k), by the way). One way would be:

y = Complex{typeof(cis(pi/one(n)))}[]

Another way would be to use map, which works out the type for you:

y = map(k -> cis(pi/k), 1:n)

or broadcasting:

y = cis.(pi ./ (1:n))

or a comprehension as noted by @DNF below.

Or you could specify a precision via an argument as noted by @mikmoore.

Note that this may not do what you want, because it is not using T for the computation. You’d probably want:

push!(y, exp(im * T(pi) / k))

or similar. e.g. this would allow you to call func(BigFloat, n) and have the computation be done to BigFloat accuracy.

3 Likes
9

[qote=“dnldlg, post:6, topic:126925”]
push!(y, exp(im * pi / k))
[/quote]

Comprehension are really nice for this, particularly for simple expressions:

y = [cis(pi/k) for k in 1:n]

(i used cis instead of exp(im) since it’s faster.

2 Likes
10

BTW, a side remark. For performance you normally want avoid operations that get gradually more expensive, which x^i does as i increases (even if it only increases logarithmically). Instead, you can do

xi = x
for i in 1:n
    xi *= x
    push!(y, xi)
end
1 Like
11

Very insightful, thanks. Seems like one can infer more than I thought :grinning_face_with_smiling_eyes:

But let us assume that I encounter a situation where I absolutely cannot infer the precision, hence in such a situation I would go for @mikmoore’s suggestion. Now suppose that there is a large simulation where this precision has to be set many times. Would I use a solution like MyFloat in my original question, which I set in the beginning and use everywhere, or is there a magic command where the precision can be set globally?

12

Why would have to be set “many times” as opposed to being passed to one entrypoint function and propagating from there to the rest of the computation?

1 Like
13

Because of my sloppy programming style, I suppose :grimacing: Propagation it is a very good idea. Thank you all, you helped me a lot!