Re: [sc-users] 2D array question

On Fri, Mar 8, 2019, 11:50 AM <abreubacelar@xxxxxxxxx> wrote:

this smells like a Flyweight pattern. Just thinking...

i haven't look at the code, but, if this is the case, Integer would be a factory, and each real Integer is keep on the memory only once (in a flyweight pool).

when we ask for a integer object it first checks if that integer "exists". If not, it creates it and put it in the pool, then returns a pointer to that only instance of Integer that contains that number, and many objects may be pointing to that same object.

if we change the number, the pointer goes to another instance in the pool. and if no pointer is looking at this instance it can be released from memory.

this makes sense?

Yes, that is flyweight pattern, but (just to keep things crystal clear) it makes little sense to do that for an integer that takes up less space than a pointer, which is why we don't do it in practice. And here is where James's point about mutability comes in -- if all your values are immutable, and you make frequent copies --as you would with value semantics --, and want to keep values actually instantiated in memory to a minimum, you could use a flyweight pattern; otherwise you'd need something like copy-on-write to give efficient value semantics.

Brian

Em Sex, 8 de mar de 2019 13:36, <amindfv@xxxxxxxxx> escreveu:

> 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/