Prev: ===Christian Louboutin - www.vipchristianlouboutin.com
Next: sending characters to the standard input while a program is running
From: Janis Papanagnou on 6 Aug 2010 10:23 On 06/08/10 16:03, Ed Morton wrote: > On 8/6/2010 8:34 AM, Janis Papanagnou wrote: >> On 06/08/10 15:20, thdyoung(a)googlemail.com wrote: >>> On Aug 6, 12:59 am, Ed Morton<mortons...(a)gmail.com> wrote: >>>> On Aug 5, 3:52 pm, "thdyo...(a)googlemail.com"<thdyo...(a)gmail.com> >>>> wrote: >>>> >>>>> Thank you Janis. >>> But isn't Janis saying - "you can't have a different room number when >>> the bed in it is identical to another one" ? That's why the array >>> length stays the same for lines of input w the same first field. >> >> (I was not talking about rooms. :-) > > Sorry, I got hooked on using real-world analogies for OO patterns (e.g. > "State" == "the preset buttons on your radio", "Composite" == "company > org structure", etc.) back in the day and just can't seem to shake it. > Works well if you get the right analogy! If you don't though.... Oh, that's okay for me. It's often just quite difficult to provide an appropriate analogy, let alone a bullet-prove one. The hotel-room was, IMO, more misleading than helpful in the given context, but others may think differently. And having a lot of different kind of explanations might help a poster who is not that familiar with elementary computer science to understand the issue; so that's fine, don't worry. Anyway, I think we've provided enough explanations, so I'll bail out. :-) Janis > > Ed. >> >> To address an associative awk array you have exactly one key, and >> you have exactly one place (per key) to store a value that is then >> associated with that key. >> >> Janis >> >>> >>> Tom >>> >>>> >>>>> A lot to think about it. >>>> >>>> Try this: >>>> >>>> array = hotel >>>> index = room number >>>> memory where an element is stored = room >>>> element = bed >>>> >>>> You can't have a hotel with 2 rooms with identical numbers, but you >>>> can have identical beds in multiple rooms. >>>> >>>> Ed. >>> >> >
From: Janis Papanagnou on 6 Aug 2010 10:32 On 06/08/10 16:17, thdyoung(a)googlemail.com wrote: > I am reaching the point in the discussion when it's as well to stop. I > am not getting any more illumination and recognise the problem is > local not remote. But thanx Ed, Janis. > > arrayX[index1] == elementA (the number 3) > arrayX[index2] == elementA (the number 3) > > The above looks to me like the OK for an array to happily include > identical values w a different key. I'll try one additional notation to try to explain... a[k] = v a[k] = w means replace element in a that is identified by k by the value v replace element in a that is identified by k by the value w It does *not* mean append/add to element in a that is identified by k another value v append/add to element in a that is identified by k another value w Or in typical OO syntax it means a[k].replace-by-value(v) a[k].replace-by-value(w) but *not* a[k].add-another-value(v) a[k].add-another-value(w) Janis > > But I don't want to bore you by carrying on. I will now revert to > lurk. > > Tom
From: thdyoung on 6 Aug 2010 15:31
Janis, Ed Light is dawning - finally. a[$1] being an assoc array element is clear enough, and its behaviour's conformity to >> a[k] = v >> a[k] = w >> means >> replace element in a that is identified by k by the value v >> replace element in a that is identified by k by the value w I suspect I have been a bit dim. I have to say staring at the screen and thinking didn't work quite as well as getting up and going shopping. thnx again, Tom |