[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-users] 2D array question




> El 7 mar 2019, a las 8:02 PM, jamshark70@xxxxxxxxx escribió:
> 
>> On Wed, Mar 6, 2019 at 10:38 AM James Harkins <jamshark70@xxxxxxxxx> wrote:
>>> On Wed, Mar 6, 2019 at 1:02 AM <brianlheim@xxxxxxxxx> wrote:
>>> It's the other way around -- the implementation mirrors the semantics exposed to the programmer.
>> 
>> I do understand what you say, and it's both formally correct and
>> interesting. From a teaching perspective, though, I think it
>> introduces unnecessary confusion.
> 
> Not a super-urgent topic, but because (effectively) one of the
> functions of the mailing list is teaching, I think it's worth
> following up.
> 
> x = 5;        // A
> y = x;        // B
> x = x + 1;    // C
> [x, y]
> -> [ 6, 5 ]
> 
> We could explain this to nonprogrammers in pass-by-value terms as:
> 
> A. x is a sheet of paper with 5 on it
> B. y is a sheet of paper with 5 on it
> C. you take the 5 from x's sheet of paper, add 1, and now you have
> another sheet of paper with 6 on it. Then you throw away x's old 5,
> and replace it with the new 6. You've done nothing to y.
> 
> Then:
> 
> x = [0, 1];    // A
> y = x;        // B
> x[0] = 2;    // C
> [x, y]
> -> [ [ 2, 1 ], [ 2, 1 ] ]
> 
> At this point, nonprogrammers will want to extend the analogy:
> 
> A. x is a sheet of paper with [0, 1] on it
> B. y is a sheet of paper with [0, 1] on it
> C. you've done something to x's sheet of paper, and this has magically
> affected y's sheet of paper.
> 
> So the analogy introduces "pass by value" (`x + 1` operates directly
> on data) but it confuses.
> 
> Now, if you explain the first case as:
> 
> A. x is an arrow pointing to "integer 5" somewhere
> B. y is an arrow pointing to the same "integer 5" that x is pointing to

Out of curiosity, is this actually what happens in sclang's implementation? I.e. there's an "integer 5" somewhere that both x and y have pointers to? In other words, if you were to look in memory, you'd see one "00000101" and not two?

That wasn't my intuition - I thought of it as x "having a 5 value," with no pointer, and y having a totally separate 5 value. I definitely could be wrong, though! (The semantics are the same)

Tom

> C. resolve x --> 5; add 1; you get 6, and now change x's arrow to
> point to this 6 (wherein it becomes clear that changing the target of
> x's arrow doesn't change the target of y's arrow)
> 
> ... and you can explain the second case using the same analogy.
> 
> A. x is an arrow pointing to [0, 1]
> B. y is an arrow pointing to the same [0, 1] that x is pointing to
> C. you've done something to the thing that x is pointing to. But y is
> pointing to the same thing. So if you look at x, you see the change,
> and if you look at y, you also see the change, because they're
> pointing in the same direction.
> 
> One analogy that explains both scenarios is better than introducing a
> distinction between two cases that doesn't actually arise in usage. So
> I think I *am* keeping it simple ;)
> 
> hjh
> 
> _______________________________________________
> sc-users mailing list
> 
> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: https://listarc.bham.ac.uk/marchives/sc-users/
> search: https://listarc.bham.ac.uk/lists/sc-users/search/

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/