I’m new to Julia. Is there an easy way of getting a matrix with the inverses of each element in a matrix?
So an element of the new matrix would be: B_ij = 1/A_ij
I have seen that at least in Julia 0.2.0 the following sintax was possible: B = 1/A
However it seems to not work in Julia 1.6.4
You can use B = 1 ./ A
Note the dot in front of “/”.
(This is a bit more general than
1 ./ A, e.g. it works even if the elements of
A are invertible matrices.)
Thank you! I tried things like B = 1 /.(A) before
Is there a reason why for most operators (I have seen so far) the dot is after the operator, while this one is before?
Good question! For instance this leads to ambiguity
I believe that this wouldn’t
I am guessing the reasons for the position of the dot are historical(?)
would be ambiguous again…
This syntax was first implemented for infix operators. In this case the dot comes first, probably because of tradition from e.g. Matlab (
A .* B vs
A * B, etc.).
When the syntax was extended to functions, the choice of
sin.(A) was made after long discussions, see
Here are some particularly relevant comments from these discussions:
kmskire: When a module defines its own
sin (or whatever) function and we want to use that function on a vector, do we do
.sin(x) seems workable to me too, though it would be helpful to have an implementation of it to see what implications it has for the parser. An expression like
x.*.sin(x) looks a bit harder to read than
x.*sin.(x) , but not impossible.
. prefix also makes
3.sin(x) ambiguous between
3 * .sin(x) (a problem that we already have with
.^ etc.), whereas
sin.(x) makes the parsing of the
Note also that
.sin already has a meaning via
import .sin etcetera, so we would be overloading it.
stevengj: I don’t think we’re contemplating changing
+. etcetera; the former convention is too well-established. I agree the
.sin(x) would be more consistent, it’s mainly a question of whether it would cause any parser oddness in the context of Julia’s existing syntax. The easiest way to determine this is to try to implement it…
nalimilan: If you read
.( as the function call operator (as I mentioned above), then
.+ are consistent.
stevengj: My biggest concern with
.sin is that things like
.cos(x).*.sin(x) become hard to read because the
.*. is hard to disentangle, unless you require a space.
Your cheat sheet fails for
a ./ b though.
op. is just wrong, it should be
.op for all operators?
Got confused, sorry.
@. expr # vectorize/fuse expressions
fun.(a) # function calls
.op a, a .op b # operators