I'm confused by the answers to this previous question Creating copies in Julia with = operator:
Specifically I'm confused by the comments under StefanKarpinki's October 7th answer to that question, specifically when RedPointyJackson said
"Ok, I undestand that. But when I do b=a, it should be assignment because it's an operation in the x = ... style, right? So now I have b 'pointed' to a, and all changes in a should reflect whenever I evaluate b, don't they?" – RedPointyJackson Oct 9 '15 at 12:49
and then StefanKarpinski said
"Yes, that's correct and all of this behavior is completely in line with that. If you do a = b then any change to b also affects a. If the value bound to b is an immutable value like 42 then you can't mutate it anyway, so there's no way to tell if it was copied or referenced." – StefanKarpinski Oct 10 '15 at 4:47
Why are these previous comments suggesting that the Julia commands
a = 1;
b = a;
a = 2;
will change the value of b to 2? RedPointyJackson started that thread with evidence that b will remain equal to 1!! So why are the quoted comments suggesting that the value of b will change to 2!?
So why are the quoted comments suggesting that the value of b will change to 2!?
It looks like you misunderstood those comments.
If you do a = b then any change to b also affects a.
To be precise, this should be rephrased as "any change to the value bound to b also affects a." Note the only thing that matters here is the value to be bound, not the variable name b. Accordingly,
a = 1; # the variable name `a` is binding to the value `1`
b = a; # the variable name `b` is binding to the value(`1`) bound to `a`
a = 2; # the variable name `a` is binding to the value `2` (`b` is still binding to `1`.)
As 1 is an immutable value and there is no way to mutate it, we have to rebind a/b if we'd like to change "their content". Here is another example:
A = [1]; # the variable name `A` is binding to the value `[1]`(an array)
B = A; # the variable name `B` is binding to the value(`[1]`) bound to `A`
A[1] = 2; # this is called mutation. the value(`[1]`) bound to `A` has been changed to `[2]`. this value is also bound to `B`, so the "content" of `B` is changed accordingly.
A = 1; # the variable name `A` is binding to the value `1` (`B` is still binding to `[2]`.)
I am trying to explain this issue in the following terms (from an upcoming book):
Memory and copy issues
In order to avoid copying large amount of data, Julia by default copies only the memory address of objects, unless the programmer explicitly request a so-called "deep" copy or the compiler "judges" an actual copy more efficient.
Use copy() or deepcopy() when you don't want that subsequent modifications to the copied object would apply to the original object.
In details:
Equal sign (a=b)
performs a name binding, i.e. binds (assigns) the entity (object) referenced by b also to the a identifier (the variable name)
it results that:
if b then rebinds to some other object, a remains referenced to the original object
if the object referenced by b mutates (i.e. it internally changes), so does (being the same object) those referenced by a
if b is immutable and small in memory, under some circumstances, the compiler would instead create a new object and bind it to a, but being immutable for the user this difference would not be noticeable
a = copy(b)
creates a new, "independent" copy of the object and bind it to a. This new object may however reference in turn other objects trough their memory address. In this case it is their memory address that is copied and not the referenced objects themselves.
it results that:
if these referenced objects (e.g. the individual elements of a vector) are rebound to some other objects, the new object referenced by a maintains the reference to the original objects
if these referenced objects mutate, so do (being the same objects) those referenced by the new object referenced by a
a = deepcopy(b)
everything is deep copied recursively
Related
e=[[1,2,3],[4,5,6]]
f1=e
f2=e
f2[1][0]=e[1][0]+1
print(f2)
print(f1,e)
in this code, why value of f1 and e are changing by changing the value of an element in the array of f2? and why it is not happed in the case of assigning constant to e?
f1 and f2 are copys of e.
Here is described how copy works. https://docs.python.org/3/library/copy.html
The difference between shallow and deep copying is only relevant for compound objects (objects that contain other objects, like lists or class instances):
A shallow copy constructs a new compound object and then (to the extent possible) inserts references into it to the objects found in the original.
A deep copy constructs a new compound object and then, recursively, inserts copies into it of the objects found in the original.
You can fix such behavior for example by using deepcopy
import copy
e=[[1,2,3],[4,5,6]]
f1=copy.deepcopy(e)
f2=copy.deepcopy(e)
f2[1][0]=e[1][0]+1
print(f2)
print(f1,e)
Okay this might get a tad complex or not.
Have a file with a multivalues in attribute 4
I want to write another dictionary item that loops through the multivalue list, calls a subroutine and returns calculated values for each item in attribute 4.
somthing like
<4> a]b]c]d]e
New attribute
#RECORD<4>;SUBR("SUB.CALC.AMT", #1)
Result
<4> AMT
a 5.00
b 15.00
c 13.50
d 3.25
Not quite sure how to pass in the values from RECORD<4>, had a vague notion of a #CNT system variable, but that's not working, which might mean it was from SB+ or one of the other 4GLs.
You might be over thinking this.
You should just be able to reference it without out doing the ";" and #1 thing (I am not familiar with that convention). Using an I-Descriptor this should do the trick, though I have traditionally used the actual dictionary names instead of the #RECORD thing.
SUBR("SUB.CALC.AMT", #RECORD<4>)
This should work provided your subroutine is compiled, cataloged and returns your desired value with the same value/subvalue structure as #RECORD<4> in the first parameter of the Subroutine.
SUBROUTINE SUB.CALC.AMT(RETURN.VALUE,JUICY.BITS)
JBC = DCOUNT(JUICY.BITS<1>,#VM)
FOR X=1 TO JBC
RETURN.VALUE<1,X> = JUICY.BITS<1,X>:" or something else"
NEXT X
RETURN
END
Good luck.
dictOne = {'a':1, 'b':2}
dictTwo = {'aa':dictOne['a'], 'bb':dictOne['b']}
print(dictTwo['aa']
# returns 1
If I make a change to dictOne like:
dictOne['a'] = 2
print(dictOne['a'])
# returns 2
but the second dict that refers to the first still returns the original value.
print(dictTwo['aa'])
# returns 1
What is happening here? I'm sure this is somehow an inappropriate usage of dict but I need to resolve this in the immediate. Thanks.
You're extracting the value from the key 'a' inside dictOne with the below piece of code
dictTwo = {'aa':dictOne['a']}
You may find some value in reading the python FAQ on pass by assignment
Without knowing more about the problem, it's difficult to say exactly how you can solve this. If you need to create a mapping between different sets of keys, there's the option to do something like:
dictTwo = {'aa' : 'a', 'bb' : 'b'}
dictOne[dictTwo['aa']]
Although maybe what you're looking for is a multi key dict
The line here:
dictTwo = {'aa':dictOne['a'], 'bb':dictOne['b']}
Is equivalent to:
dictTwo = {'aa':1, 'bb':2}
Since dictOne['a'] and dictOne['b'] both return immutable values (integers), they are passed by copy, and not by reference. See How do I pass a variable by reference?
Had you done dictTwo = dictOne, updating dictOne would also update dictTwo, however they would have the same key values.
I have a recursive function which utilizes a global dict to store values already obtained when traversing the tree. However, at least some of the values stored in the dict seem to disappear! This simplified code shows the problem:
type id
level::Int32
x::Int32
end
Vdict = Dict{id,Float64}()
function getV(w::id)
if haskey(Vdict,w)
return Vdict[w]
end
if w.level == 12
return 1.0
end
w.x == -111 && println("dont have: ",w)
local vv = 0.0
for j = -15:15
local wj = id(w.level+1,w.x+j)
vv += getV(wj)
end
Vdict[w] = vv
w.x == -111 && println("just stored: ",w)
vv
end
getV(id(0,0))
The output has many lines like this:
just stored: id(11,-111)
dont have: id(11,-111)
just stored: id(11,-111)
dont have: id(11,-111)
just stored: id(11,-111)
dont have: id(11,-111)
...
Do I have a silly error, or is there a bug in Julia's dict?
By default, custom types come with implementations of equality and hashing by object identity. Since your id type is mutable, Julia is conservative and assumes that you care about distinguishing each instance from another (since they could potentially diverge):
julia> type Id # There's a strong convention to capitalize type names in Julia
level::Int32
x::Int32
end
julia> x = Id(11, -111)
y = Id(11, -111)
x == y
false
julia> x.level = 12; (x,y)
(Id(12,-111),Id(11,-111))
Julia doesn't know whether you care about the object's long-term behavior or its current value.
There are two ways to make this behave as you'd like:
Make your custom type immutable. It looks like you don't need to mutate the contents of Id. The simplest and most straightforward way to solve this is to define it as immutable Id. Now Id(11, -111) is completely indistinguishable from any other construction of Id(11, -111) since its values can never change. As a bonus, you may see better performance, too.
If you do need to mutate the values, you could alternatively define your own implementations of == and Base.hash so they only care about the current value:
==(a::Id, b::Id) = a.level == b.level && a.x == b.x
Base.hash(a::Id, h::Uint) = hash(a.level, hash(a.x, h))
As #StefanKarpinski just pointed out on the mailing list, this isn't the default for mutable values "since it makes it easy to stick something in a dict, then mutate it, and 'lose it'." That is, the object's hash value has changed but the dictionary stored it in a place based upon its old hash value, and now you can no longer access that key/value pair by key lookup. Even if you create a second object with the same original properties as the first it won't be able to find it since the dictionary checks equality after finding a hash match. The only way to lookup that key is to mutate it back to its original value or explicitly asking the dictionary to Base.rehash! its contents.
In this case, I highly recommend option 1.
I have been using the chr library along with the jpl interface. I have a general inquiry though. I send the constraints from SWI Prolog to an instance of a java class from within my CHR program. The thing is if the input constraint is leq(A,B) for example, the names of the variables are gone, and the variable names that appear start with _G. This happens even if I try to print leq(A,B) without using the interface at all. It appears that whenever the variable is processed the name is replaced with a fresh one. My question is whether there is a way to do the mapping back. For example whether there is a way to know that _G123 corresponds to A and so on.
Thank you very much.
(This question has nothing to do with CHR nor is it specific to SWI).
The variable names you use when writing a Prolog program are discarded completely by the Prolog system. The reason is that this information cannot be used to print variables accurately. There might be several independent instances of that variable. So one would need to add some unique identifier to the variable name. Also, maintaining that information at runtime would incur significant overheads.
To see this, consider a predicate mylist/1.
?- [user].
|: mylist([]).
|: mylist([_E|Es]) :- mylist(Es).
|: % user://2 compiled 0.00 sec, 4 clauses
true.
Here, we have used the variable _E for each element of the list. The toplevel now prints all those elements with a unique identifier:
?- mylist(Fs).
Fs = [] ;
Fs = [_G295] ;
Fs = [_G295, _G298] .
Fs = [_G295, _G298, _G301] .
The second answer might be printed as Fs = [_E] instead. But what about the third? It cannot be printed as Fs = [_E,_E] since the elements are different variables. So something like Fs = [_E_295,_E_298] is the best we could get. However, this would imply a lot of extra book keeping.
But there is also another reason, why associating source code variable names with runtime variables would lead to extreme complexities: In different places, that variable might have a different name. Here is an artificial example to illustrate this:
p1([_A,_B]).
p2([_B,_A]).
And the query:
?- p1(L), p2(L).
L = [_G337, _G340].
What names, would you like, these two elements should have? The first element might have the name _A or _B or maybe even better: _A_or_B. Or, even _Ap1_and_Bp2. For whom will this be a benefit?
Note that the variable names mentioned in the query at the toplevel are retained:
?- Fs = [_,F|_], mylist(Fs).
Fs = [_G231, F] ;
Fs = [_G231, F, _G375] ;
Fs = [_G231, F, _G375, _G378]
So there is a way to get that information. On how to obtain the names of variables in SWI and YAP while reading a term, please refer to this question.