Why not cossin?

We have sincos, why not cossin? I have no idea why sincos is here and not cossin (perhaps because of the “awkward” ss in the name…), but for me the convention of xy in a 2D coordinate means that calculating a new coordinate from a known point, angle, and distance is awkward with a sincos function:

xy = SVector(1.0,2.0)
α = π/2
l = 1
xy2 = xy + l*SVector(sincos(α))[2:-1:1] # note the reordering of the elements

Maybe you have an explanation or a better solution?

1 Like

Do you need




Sure! I just read about it, or the Iterators.reverse version without the copy. Cool.

I don’t think there is a copy (if the compiler can infer things, eg inside a function), as sincos returns a tuple.


reverse(v [, start=1 [, stop=length(v) ]] )

  **Return a copy of v** reversed from start to stop. See also Iterators.reverse for reverse-order
  iteration without making a copy.

I think that docstring refers to the method where v is an array. As a rule of thumb, you can often create tuples of isbits types without allocations:

julia> @allocated reverse(sincos(1))

julia> @allocated collect(sincos(1)) #creating the vector would allocate

Well, in that case cossin is reverse(sincos), cool!

Depending on the interpretation there is a copy. It just doesn’t matter. Fwiw, by that interpretation it’s almost for sure that the iterator version is also making a copy.


Sure, technically it is a copy in the sense that it does not share modifiable structure with the argument. But for tuples that is always true.

What happens here should be equivalent to

x, y = sincos(r)
y, x