ERROR: MethodError: no method matching cos(::Array{Int64,1})

New to Julia
1

What is the reason for this ?

2

You want cos.(array), not cos(array), for the elementwise cosine.

See https://docs.julialang.org/en/latest/manual/functions/#man-vectorized-1 and More Dots: Syntactic Loop Fusion in Julia

3 Likes
3

Since you ask for a reason:

A function like cosine is meaningful for certain arrays (e.g. as a power series for matrices) and using the notation cos(A) for something other that that when A is a matrix is simply incoherent. For a vector argument, cos(v) is mathematically meaningless but primitive languages saw fit to abuse the notation for element-wise application. The incoherent precedent of other languages seduced even the Julia developers for a few years, but now cos(A::Matrix) does the mathematically sensible thing in Julia; the vector case errors out; and we have a well-designed alternative for element-wise application.

Can you think of an improvement to Julia documentation that would have helped you to avoid this misapprehension?

2 Likes
4

Make it self-aware and nag the user until it is read.

5

cos(::AbstractVector) could be overloaded to return an error message pointing to cos.(x). Though it doesn’t help if they try to apply it to a square matrix.

6

Math is flexible — you can define symbols to mean whatever you want. Julia uses the dot notation for elementwise calls for more pragmatic reasons outlined in my blog post linked above.

  • f.(x) means that the caller can use any function elementwise — it’s not up to the function author to decide in advance which functions are useful to vectorize.
  • f.(x) exposes the elementwise nature of the call to Julia at the syntactic level, allowing Julia to provide a syntactic guarantee that nested calls like f.(g.(x)) are fused into a single broadcast call.

As a nice side effect, this frees up the name of functions like cos(x) so that we can use the same name for the matrix functions.

The tradeoff is that users coming from Matlab, Numpy, and similar are surprised at first by how Julia vectorization works — if you are interested, there was a long debate about this in #23233.

Yes, keeping deprecation messages indefinitely for common vectorized functions was definitely proposed when we made the dot-call changeover, but I can’t find the discussion at the moment.

1 Like
7

Actually I meant a standard error, not a deprecation warning. (The fact that it used to work just adds noise to the message.)