Of course, I see now, when you copy you have to update the reference 
counts in each atomic box.  That explains the performance of a great 
many expressions that I couldn't understand before.  Thanks.

I'll be at the conference!

Henry Rich

On 11/24/2011 8:08 PM, Roger Hui wrote:
> The logic is more or less correct but the "official" terminology would be
> different; the official terminology reflects the actual implementation with
> high fidelity.
>
> The basic data structure in the interpreter has type A.  It is used for
> arrays as well as for verbs, adverbs, etc. (even parens!).  Every type A
> object has a header and a value.  The header has the type, element count,
> rank, shape, reference count, and other stuff.  The value is interpreted
> differently ("cast") depending on the type of object.
>
> An A object of an indirect type (boxed, extended integer, rational, etc.)
> can have type A objects in its value, and those objects can themselves have
> reference counts, etc.
>
> The reference counting in the J implementation can be improved.
>
> Regarding your last example.  It is highly unlikely that the space
> accounting is incorrect, because the same simple mechanism is used for
> every kind of object and expression.  I believe that for c =. bb the
> interpreter traversed the whole of bb updating all the reference counts.
> It takes time to do that, but little space.  It looks like c =. ] bb made a
> copy of bb, but in theory it shouldn't have to.
>
> The uncertainty I expressed is due to that I haven't looked at it for a
> long time.  The mechanism was devised in the early days (1989) and I
> haven't had many reasons to revisit it.
>
> Come to the J conference and I will give you a more polished story.
>
>
>
> On Thu, Nov 24, 2011 at 10:18 AM, Henry Rich<[email protected]>  wrote:
>
>> As examples of what Roger is saying:
>>
>>     abb =. (1e6 $ 5) ; (1e6 $ 5)
>>     ts '''a b'' =. abb'
>> 8.36834e_6 1600    NB. no data-copying here
>>     ab =. (1e6 $ 5) ,: (1e6 $ 5)
>>     ts '''a b'' =. ab'   NB. data was copied
>> 0.0227605 1.25844e7
>>     ts 'c =. a;b'
>> 7.53628e_6 960   NB. no copying
>>
>> My understanding has been that an unboxed noun contains a header which
>> includes a pointer to a data block which comprises all the values of the
>> noun.  This data block carries a reference-count, with no
>> reference-count for any subarrays.  An boxed noun is represented as an
>> array (or atom) of such headers, one for each atomic box.
>>
>> So, in your example
>> 'a b c' =. abc =. i.3 4 5
>>
>> there is no header for each row of abc, and the data for a, b, and c
>> will be copied.
>>
>> In
>> 'n m' =. nm =. 12; 'monkeys'
>>
>> there is a header for each atom of nm, so no copy is required.
>>
>> In
>>
>> 'p q r' =. y
>>
>> it depends on y.  If y was created from (a;b;<c) the case will be like
>> the monkeys example, but if by (a,b,c) a copy will be required.
>>
>> I would be obliged if Roger would indicate what he wasn't sure about,
>> because it would show where my understanding is deficient.  I know there
>> is more to boxed arrays than my model accounts for, in particular when
>> and whether the array of headers gets copied when a verb is evaluated.
>> A puzzling example is:
>>
>>     bb =.<"0 i. 10 11 12 13 100
>>     ts 'c =. bb'
>> 0.343118 704
>>     ts 'c =. ] bb'
>> 0.543127 7.02944e6
>>
>> In c =. bb, the interpreter reports that it filled 704 bytes, but it
>> took 1/3 of a second to do it.  Could that be an error in space
>> accounting?  But the suggests that the array of headers is rebuilt when
>> the noun is copied.
>>
>> In c =. ] bb, apparently it used an array that was 4 bytes per atom of
>> bb, which suggests that the array of headers was rebuilt for the
>> execution of ]  .
>>
>> Henry Rich
>>
>>
>> On 11/24/2011 1:44 AM, Roger Hui wrote:
>>> This does not apply for the first example, nor for the general case of
>> the
>>> third example.  Not sure about the second example.  In any case you can
>> get
>>> answers to these questions yourself by doing some experiments and
>> checking
>>> the space consumed.
>>>
>>>
>>>
>>> On Wed, Nov 23, 2011 at 10:35 PM, Ben Gorte - LR<[email protected]
>>> wrote:
>>>
>>>> Thanks for the explanation. Would this also apply to
>>>>
>>>> 'a b c' =. abc =. i.3 4 5
>>>>
>>>> or to
>>>>
>>>> 'n m' =. nm =. 12; 'monkeys'     ?
>>>>
>>>> In that case it is perhaps not so expensive to pass more than two things
>>>> to a verb and separate these inside it wilh
>>>>
>>>> 'p q r' =. y    (?)
>>>>
>>>> Ben
>>>> ________________________________________
>>>> From: [email protected] [
>> [email protected]]
>>>> on behalf of Roger Hui [[email protected]]
>>>> Sent: Wednesday, November 23, 2011 3:36 PM
>>>> To: Programming forum
>>>> Subject: Re: [Jprogramming] One noun with two names
>>>>
>>>> Names are reference-counted so that if you say a=:b=: 123 the reference
>>>> counts for a and b are each one more than if you'd said a=:123 and
>> b=:123.
>>>> Before the interpreter modifies an array it checks the reference count
>> and
>>>> if that count is not the minimum it will make a copy of the array before
>>>> modifying it.
>>>>
>>>>> (but what would be the prupose?)
>>>>
>>>> Shorter code.   a=:b=:c=: blah  is a common construct, in many
>> programming
>>>> languages.
>>>>
>>>>
>>>>
>>>> On Wed, Nov 23, 2011 at 6:16 AM, Ben Gorte - LR<[email protected]
>>>>> wrote:
>>>>
>>>>>
>>>>> Dear J forum,
>>>>>
>>>>> To my surprise I found out that
>>>>>
>>>>>      a =. b =. 480 640$0
>>>>>
>>>>> is not the same as
>>>>>
>>>>>      a =.  480 640$0
>>>>>      b =.  480 640$0
>>>>>
>>>>> as the first gives you two names pointing to the same data. I guess
>> that
>>>>> should be ok, and it saves space (but what would be the prupose?)
>>>>>
>>>>> I passed both as pointers to a DLL (a .so in linux), which was supposed
>>>> to
>>>>> put two different images in a and b, and then the first is not ok. It
>>>> only
>>>>> works with the second variant :-)
>>>>>
>>>>> Greetings from Cape Town,
>>>>> Ben
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>>>
>>>> ----------------------------------------------------------------------
>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>> ----------------------------------------------------------------------
>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>>
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to