How to get a matrix with the inverse of each element of another matrix?

New to Julia
,
1

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

2

You can use B = 1 ./ A
Note the dot in front of “/”.

3

Also inv.(A).

(This is a bit more general than 1 ./ A, e.g. it works even if the elements of A are invertible matrices.)

1 Like
4

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?

5

Good question! For instance this leads to ambiguity

1.+x

https://docs.julialang.org/en/v1/manual/mathematical-operations/#man-dot-operators
I believe that this wouldn’t

1+.x

I am guessing the reasons for the position of the dot are historical(?)

2 Likes
6

But

x+.1

would be ambiguous again…

7

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) vs 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 Module..sin(v) ? Module.(.sin(v)) ? Module.(.sin)(v) ? .Module.sin(v) ?

stevengj: .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.

A . prefix also makes 3.sin(x) ambiguous between 3.0sin(x) and 3 * .sin(x) (a problem that we already have with .^ etc.), whereas sin.(x) makes the parsing of the . unambiguous.

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 .+ to +. 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 f.(x) and .+ 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.

3 Likes
8

Your cheat sheet fails for a ./ b though.

10

The op. is just wrong, it should be .op for all operators?

2 Likes
11

Got confused, sorry.

# Vectorizing
@. expr          # vectorize/fuse expressions
fun.(a)          # function calls
.op a, a .op b   # operators