# What is the future of \`sin(::Vector)\` when there is \`sin.(::Vector)\`?

**URL:** <https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677>\
**Category:** Internals & Design\
**Created:** [December 1, 2016, 5:28pm UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677 "2016-12-01T17:28:56Z")\
**Posts on this page:** 15\
**Page:** 2

<div class="post-metadata">

**Author:** ![johnmyleswhite](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnmyleswhite/32/31_2.png) [@johnmyleswhite](https://discourse.julialang.org/u/johnmyleswhite)\
**Post date:** [December 6, 2016, 10:48pm UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/21 "2016-12-06T22:48:16Z")

</div>

> [@dlfivefifty](#):
>
> sin.(1) returns sin(1), So always use sin.(x) if you want it to work on both Vector and Number interchangeably.

I’m not sure this is always good advice. Lots of things in Base are messy because people wanted to make generic code work for scalars and vectors. It seems like it may be too late to fix that decision, but I’m not totally sure we should advocate a design pattern that depends on functions on vectors happening to also work on numbers.

---

<div class="post-metadata">

**Author:** ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)\
**Post date:** [December 6, 2016, 10:53pm UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/22 "2016-12-06T22:53:17Z")

</div>

I think the behaviour that `sin.(x::Number) == sin(x)` should not be seen as the result of numbers acting like vectors, but rather that `broadcast(f,x::Number)` should return a `Number`.

This behaviour of `broadcast(f,::Number)::Number` would actually allow the removal of numbers-as-vectors without any obvious drawback.

---

<div class="post-metadata">

**Author:** ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)\
**Post date:** [December 6, 2016, 11:02pm UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/23 "2016-12-06T23:02:54Z")

</div>

More generally, this is the behaviour I would expect from broadcast:

```julia
broadcast(f,::T) # returns a scalar of type typeof(f(::T))
broadcast{T}(f,::AbstractVector{T}) # returns AbstractVector{typeof(f(::T))}
broadcast{T}(f,::AbstractMatrix{T}) # returns an AbstractMatrix{typeof(f(::T))}
broadcast{T}(f,::MyAbstractContainerType{T}) # should be overloaded to return a MyAbstractContainerType{typeof(f(::T))}

```

So the return result has the same “shape” as the second argument, where the definition of “shape” is dictated by the type. E.g., if I had a ragged array type, it should return a ragged array of the same shape. The shape of a number is a “scalar” so the current behaviour is natural to me.

---

<div class="post-metadata">

**Author:** ![JeffreySarnoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeffreysarnoff/32/1980_2.png) [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)\
**Post date:** [December 6, 2016, 11:24pm UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/24 "2016-12-06T23:24:19Z")

</div>

@johnmyleswhite This does get to the heart of the matter. Julia should have a predilection either for considering organized multiplicities as distinguished from their constituent _1-pliciities_ (elements) or for considering a whole as a complete part and vice-versa. It would be better for Julia’s ease of adoption (unsharpening one more edge) and allow us to advance a coherent cognitive mereotopological model [wholes, parts, melds, adjacencies, encompassing|embedable, superveniences – that’s what it means to me]. This seems a good place not to take both the forks.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [December 7, 2016, 12:50am UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/25 "2016-12-07T00:50:51Z")

</div>

> [@dlfivefifty](#):
>
> I think the behaviour that sin.(x::Number) == sin(x) should not be seen as the result of numbers acting like vectors, but rather that broadcast(f,x::Number) should return a Number.

Another reason for this is that, in 0.6, operators like `.+` are planned to be `broadcast` calls. By longstanding convention, such “dot operators” behave like the ordinary scalar operators when acting on scalars.

---

<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:** [December 9, 2016, 12:20am UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/26 "2016-12-09T00:20:44Z")

</div>

A question to ask is _why are you trying to write a method that works for both scalars and arrays in the first place?_ With the new `f.(args...)` syntax, it’s easy (and more efficient) to take a scalar function and vectorize it “at the last moment” – instead of the old style of trying to let the vectorization flow through the code. Now that we’re moving to actively deprecate the vectorized forms of standard library functions that are just straightforward factorizations of their core scalar versions, the only cases I can think of where you would want to let both scalars and arrays “flow through” the same method is something like a polynomial evaluation where the same definition is equally sensible for scalars or matrices. Something like this:

```julia
julia> p(x) = x^2 - 2x + I
p (generic function with 1 method)

julia> p(3)
4

julia> A = rand(3,3)
3×3 Array{Float64,2}:
 0.442283 0.839404 0.917475
 0.377142 0.815185 0.640569
 0.320895 0.487319 0.730314

julia> p(A)
3×3 Array{Float64,2}:
  0.922036 -0.176181 -0.221426
 -0.074485 0.662893 0.0548796
 -0.0817207 0.0478732 0.679305

```

But in the analagous case for the `sin` function, you’d want to call `sinm` rather than vectorized `sin` anyway.

---

<div class="post-metadata">

**Author:** ![JeffreySarnoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeffreysarnoff/32/1980_2.png) [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)\
**Post date:** [December 9, 2016, 2:05am UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/27 "2016-12-09T02:05:18Z")

</div>

> Why are you trying to write a method that works for both scalars and arrays in the first place?

Maybe because the most important distinguishing quality is not ‘collectivity’, probably because ‘collectivity’ is not an organizing principle of the type design in play. For example, _ **Gestalt** _ as an implemented type: here, a whole is more than the sum of its parts and an unsummed part is less than whole … yet still, as a perceptual aspect, a gestalt.

---

<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:** [December 9, 2016, 4:47pm UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/28 "2016-12-09T16:47:44Z")

</div>

All I’m saying is that writing functions that could operate on scalars or elementwise on arrays of them was always a symptom of language limitations, not an inherent need. The actual need was always to be able to efficiently vectorize scalar functions, which we can now do directly and more efficiently. So why hang on to what was always a symptom of a language limitation and not an inherently desirable feature in the first place?

---

<div class="post-metadata">

**Author:** ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)\
**Post date:** [December 9, 2016, 8:16pm UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/29 "2016-12-09T20:16:39Z")

</div>

> [@StefanKarpinski](#):
>
> But in the analagous case for the sin function, you’d want to call sinm rather than vectorized sin anyway.

Hopefully the secret plan is to deprecate `sinm` and use `sin(::Matrix)` in its place…

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [December 9, 2016, 8:22pm UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/30 "2016-12-09T20:22:26Z")

</div>

I would hope the same for the matrix exponential function?

---

<div class="post-metadata">

**Author:** ![johnmyleswhite](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnmyleswhite/32/31_2.png) [@johnmyleswhite](https://discourse.julialang.org/u/johnmyleswhite)\
**Post date:** [December 9, 2016, 8:57pm UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/31 "2016-12-09T20:57:00Z")

</div>

I think Jeff has indicated his desire to do both of those in the past.

---

<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:** [December 9, 2016, 9:49pm UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/32 "2016-12-09T21:49:24Z")

</div>

That could be a longer term plan, but it’s pretty dangerous to deviate silently from what people expect from Matlab, Python, etc. I’m not sure it’s that necessary since writing code for scalars or matrices that uses `exp` or `sin` is pretty rare – and you can always just use `expm` and `sinm` in those cases. Of course, getting rid of a whole parallel universe of `???m` functions would be rather nice.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [December 10, 2016, 7:27am UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/33 "2016-12-10T07:27:01Z")

</div>

> [@StefanKarpinski](#):
>
> pretty dangerous to deviate silently from what people expect from Matlab, Python, etc

My concern would be the difference between `sin.(matrix)` and `sin(matrix)` — miss the dot, and you have a bug which will be pretty hard to pin down, as both return matrices of the same size.

I can see the allure of mathematical elegance though.

---

<div class="post-metadata">

**Author:** ![yurivish](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yurivish/32/307_2.png) [@yurivish](https://discourse.julialang.org/u/yurivish)\
**Post date:** [December 10, 2016, 8:19am UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/34 "2016-12-10T08:19:20Z")

</div>

@Tamas_Papp: Since dot vectorization is a syntax-level feature, you could imagine this being indicated via syntax highlighting.

---

<div class="post-metadata">

**Author:** ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)\
**Post date:** [December 10, 2016, 12:08pm UTC](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677/35 "2016-12-10T12:08:19Z")

</div>

Ah, that’s why `fft(::Matrix)` behaves the same as in MATLAB 😜

[Previous page](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677.md?page=1)