When I was first starting I was horrified by this, when trying to literally translate Fortran to Julia: julia> function f() local x = Vector{Float64}(undef,3) local y = Vector{Float64}(undef,3) y[1] = 1.0 x = y y[1] = 2.0 println(x[1]) …

Maybe this will help. Note that y1 is just a pointer to the M object. So is y2, consequently when you modify the inside of y2 using the name y2, since the name y1 points to the same thing, y1 also looks like its modified. In contrast, you can’t modify x2.x because its not a mutable struct. The “two…

Ok thanks for the example pdeffebach, I will check it out.

[image] pdeffebach: The “two names for the same object” logic doesn’t work. Hunh? It definitely still works. You still have two names for the same object — but the object cannot change. Mixing up mutation and naming is part of why I think this is so confusing to newcomers. They’re totally …

Yes for sure. By this logic I only mean only the thinking “if I change this variable it shows up in y1”

This reminds of something I read about Python years ago. Someone compared a python object to a cat that travels between two houses. In one house the cat is called Tigger and in the other it’s called Fluffy. The cat doesn’t know its name.

I may have read this wrong, but I think some part of the confusion may be an expectation that code looks and works more like math. Let’s say this little bit here was just math on paper: xNew = xOld + 1 xOld = xNew This would indeed imply an impossible equation xOld = xOld + 1. But = and xOld = xOl…

In Fortran you would have declared xOld and xNew at the beggining of the code giving the sensation that it each is a variable with a specific position in memory, without any ambiguity. Therefore, xNew = xOld copies the value of xOld into xNew. Now that I am immersed in this world of labels, etc, …

Just to add one thing. There is nothing mysterious about StaticArrays. They are convenient immutable structures, which you could have defined yourself, with the same allocation results: julia> struct P x :: Float64 y :: Float64 z :: Float64 end julia> function upd…

The fact that x = , x .= and x[i] = mean totally different things is quite unintuitive, and I remember being confused by this when I started julia. This doesn’t look really covered in the docs, at least not at a place a beginner is going to look at. Might be a good idea to add a small section on ar…

I think I understand what is going on under the hood based on this discussion. Can someone confirm that my comments are accurate? x=[2] # x points to memory location m1 y=x # y points to memory location m1 x=[3] # x points to memory location m2, y still points to m1 z=x # z points to memory…

Julia's assignment behavior differs from Fortran?

General Usage

lmiq November 18, 2020, 7:24pm 46

There is an attempt to build that list here: Noteworthy differences from Fortran

1 Like

Topic		Replies	Views
Noteworthy differences from Fortran General Usage documentation , fortran	38	3275	August 12, 2020
Julia's loop scope behavior differs from Fortran? General Usage	38	2940	November 18, 2020
Fortran vs Julia stack allocated arrays Performance array , memory-allocation	18	6675	November 29, 2018
In place assignment of scalars vs vectors Performance	20	1615	June 25, 2021
Trying to understand how to write good code (example) New to Julia	34	3155	February 16, 2017

Julia's assignment behavior differs from Fortran?

Related topics