I have a larger expression involving purely element-wise operations on vector elements. Using functions like abs(), log10() requires the use of dot-syntax in julia 0.6 unless one ignores the depreciation warning you get when using the program non-interactively, i.e. I will have to use for example
log10.(abs.(vector)). At this point I would like to use the @. macro instead of explicitely writing these dots .
According to More Dots: Syntactic Loop Fusion in Julia the @. macro should be equivalent to explicit dots. Only that it is not in connection with using length() as demonstrated in a brief made up example below ( I suspect this is a more general issue):
julia> abs.(x[1:Int64(round(length(x)/2.0))])
2-element Array{Float64,1}:
1.0
2.0
julia> @. abs(x[1:Int64(round(length(x)/2.0))])
ERROR: MethodError: no method matching colon(::Int64, ::Array{Int64,1})
Closest candidates are:
colon(::T<:Real, ::Any, ::T<:Real) where T<:Real at range.jl:47
colon(::A<:Real, ::Any, ::C<:Real) where {A<:Real, C<:Real} at range.jl:14
colon(::T, ::Any, ::T) where T at range.jl:46
...
Naturally two questions arrive:
Is this non-equivalence a feature, a bug, a missing feature or am I using it wrong ? If I am using it wrong how should I use it ?
length(x)/2 is not automatically cast to integer as for example in matlab as far as I have observed. I apparently have to convert it explicitely with Int64(round(length(x)/2.0)) ? This looks as if I am doing something stupid. Is there a better way to do this ?
And no, I do not like to use throw-away-variables to do a
Actually, the blog post is exactly right: adding @. in front of an expression is equivalent to changing all function calls from f(x) to f.(x). That’s actually what’s happening and it’s what’s causing your error. The reason is that you want length(x) to operate on the array x and return a scalar length. But by adding @. out front, you’ve turned that into length.(x) which returns an array consisting of the length of each element of x. That’s exactly what @. is supposed to do, but it’s just not what you want in this case. The error comes because what ends up being evaluated is 1:Int64.(round.(length.(x) ./ 2.0))) and Julia doesn’t have a method for a range from an integer to a vector.
Splitting out lastindex is a perfectly good solution (and has no performance penalty at all), as is just manually adding dots only where appropriate rather than using @.. Which one you pick is, of course, up to you.
As for (2), dividing two integers (or an integer and a float as you’re doing) always produces a float. Because of that, you can just divide by 2 and not 2.0 and you will still get the correct answer (unlike python2). Unlike Matlab, Julia doesn’t allow you to index into an array with a float, so yes, rounding and converting to Int is necessary. If you don’t like the nested function calls, you can also do round(Int, length(x) / 2)).
So if you want to use the @. macro, you’ll need to separate out the components that operate on the vector as a whole (like length here — you don’t want the length of every element in this case).
As far as division, yes, you need to be explicit in how you want to convert the result to an index. In many cases, you can use the ÷ infix operator to do integer division, but that behaves differently from round — it truncates instead. You can also round directly to Int with round(Int, length(x)/2). Or similarly with ceil or floor. Unfortunately there’s not a “one true way” that everyone always wants, so we have chosen not to do this automatically.
(As an aside, in this particular instance, you can also use the special end keyword to represent the last index in the collection: @. abs(x[1:endĂ·2])).
Indeed I missed the emphasis on the word “every” which is in the online documentation of the macro.
Apparently this would work too without the need to introduce a throw-away-variable
2-element Array{Float64,1}:
1.0
4.0
which is of course simple once I understood the emphasis on “every” in the documentation. Not used to macros I guess, there must be of course limits on the complexity of transforms it can do.
With respect to the indexing:
round(Int64, end/2)
using “end” as a value is sure much nicer than what I have been doing. But I still will have to get used to it.
@mbauman: That would be the same as div(length(x),2) as fasr as I can see ? I am not sure how I would enter that infix operator, is that using UTF-8 I assume ?
Yes, exactly. You can ask Julia how to enter it by copy/pasting it into a ? help prompt:
help?> Ă·
"Ă·" can be typed by \div<tab>
search: Ă· .Ă·
div(x, y)
Ă·(x, y)
The quotient from Euclidean division. Computes x/y, truncated to an integer.
that is of course nicely documented and might make code more readable.
I will probably stick to div(), though, as I would have to find out how to for example search for it in vim without copy&paste of the character (among other things). I remain a bit sceptical of using UTF-8 characters I do not have on my keyboard Of course all of this has been discussed elsewhere, so I would like to just thank you again for your help.
Of course all of this has been discussed elsewhere, so I would like to just thank you again for your help.