Re: asynchronous task communication

[Charles Hixson <charleshixsn@earthlink.net>]

On 01/02/2013 12:35 PM, Dmitry A. Kazakov wrote:
> On Wed, 02 Jan 2013 11:02:54 -0800, Charles Hixson wrote:
>
>> On 01/02/2013 01:55 AM, Dmitry A. Kazakov wrote:
>>> On Tue, 01 Jan 2013 23:36:13 -0800, Charles Hixson wrote:
>>>
>>>> On 01/01/2013 10:54 AM, Robert A Duff wrote:
>>>>> Charles Hixson<charleshixsn@earthlink.net>    writes:
>>>>>
>>>>>> ...I really preferred a language with a garbage collector,
>>>>>
>>>>> I have used the Boehm garbage collector successfully with Ada.
>>>>>
>>>>> You could also consider use-defined storage pools.
>>>>> I don't know enough detail of what you're doing to know
>>>>> if they would help.
>>>>>
>>>> I don't think storage pools would help, though I admit I don't
>>>> understand them.
>>>
>>> Storage pools allow implementation of arenas and stacks which are extremely
>>> useful when dealing with graphs. I don't know how many nodes you have, but
>>> in my system a decision tree might have hundreds of thousands of nodes.
>>> Merely finalization of such a structure would take a lot of time if nodes
>>> are allocated in the standard memory pool.
>>>
>>>> Actually, for the current project the need for garbage collection is
>>>> minimal...but I often do things where garbage collection really
>>>> simplifies memory management.
>>>
>>> Not really. And for graphs seems just the opposite.
>>>
>>> Though you would need to carefully design for which graph edges the
>>> references will be strong and which ones weak.
>>>
>>>> Even on this one I'm going to need to
>>>> figure out how to recycle memory with Ada.Collections.Vectors attached,
>>>> as different cells will connect to differing numbers of other cells.
>>>
>>> Variable structures like Ada.Containers usually allocate memory in advance
>>> to speed up incremental insertions. For NN I would consider a custom
>>> fixed-size structure.
>>>
>>> You might also consider refactoring subgraphs. Structures like that tend to
>>> combinatorial explosion when the same graph pattern keeps on repeating
>>> itself. Memory use and training/classification times could be reduced when
>>> repeating subgraphs are shared rather than replicated. This is another
>>> argument to consider a custom implementation.
>>>
>> A constant size container is not reasonable...though it would certainly
>> make things simpler if it was.
>
> You make node a discriminated record type. Usually when a node is created
> it is already known how many children and/or parents it will have. E.g.
That's not true in this case.  The node adds references depending on the 
data that it encounters.
OTOH, I suppose I could declare a series of different node types, each 
with a maximum number of children, and when I hit the maximum I 
reallocate the node with a different type.  If I doubled the number of 
children with each type I'd need around 10-12 different types...

Yes, it's doable, but I'd *really* rather avoid that.  And I'm sure 
there must be some reasonable way to deallocate a Vector.  That I don't 
know what it is doesn't convince me that it doesn't exist.  Perhaps 
Clear or Delete would do it, but I haven't found this documented.  I'm 
guessing that if I store access variables in a Vector, and then 
deallocate the item the access variable holds (updating the access 
variable to null), that will free most of the space, but deallocating 
the Vector itself is not so clear.  I can't tell whether there are any 
handles to it that I don't know about.  Perhaps it's somewhere in the AARM.
>
>     type Node;
>     type Node_Ptr is access Node;
>     for Node_Ptr'Storage_Pool use Arena;
>     type Node_Ptr_Array is array (Positive range<>) of Node_Ptr;
>     type Node (Children_Number : Positive) is record
>         Successors : Node_Ptr_Array (1..Children_Number);
>     end record;
>
>> But I really can't see how storage pools
>> would help, as cells would not be freed in any predictable pattern, and
>> not en-mass.
>
> You allocate all graph or a layer of in the storage pool. Nodes are usually
> allocated in the LIFO order which makes allocation much more efficient then
> allocation in a standard pool. Deallocation is usually all-at-once, e.g.
> you drop the pool and that is.
When you say "layer", I know I haven't explained the model of what I'm 
trying to do well enough.  That's a part of why I explicitly denied that 
it was what is normally meant by a neural net.  That's just the closest 
model in common language.  Even the "base layer", such as it is, isn't 
allocated all at once, but only as appropriate stimuli arrive.  Higher 
levels *try* to be a similar distance from the "base layer" (Note the 
quotes! Don't take this description literally.), but this isn't 
guaranteed, and, indeed, I expect that mixtures between layers will be 
common.  And I'm not actually convinced that I should even try to 
minimize this.  (There are lots of reasons why it might improve responses.)

That said, I'm well aware that this may well not work out.  But if I 
don't try, I'll never know.  There are lots of places where I don't have 
a clear model of what I'm trying to build, but initial cell generation 
is one place where I'm pretty sure, except for some details.
>
>> P.S.:  Is there any way to generate documentation for Ada, better than
>> robodoc?
>
> By hands. I write docs manually. It is tedious, I admit. Consider it as an
> extra code review step, helps finding inconsistencies and gaps which
> otherwise slip through.
In my experience, code that's documented that way tends to have 
documentation that's incomplete, out of date, or both.  Perhaps this is 
just me, but enough people seem to have had the same experience that I 
doubt it.

Adabrowse can be used to produce decent end-user documentation, but I 
want developer documentation.  That means documenting 
function/procedures/types/etc that only exist in *.adb files.  I'm after 
something that makes it easy for me to see what routines I've written, 
what they're called, what they're for, and any notes to myself that 
aren't appropriate for compile time warnings.  I want to be able to come 
back to the code in 6 months or a year and figure out what it's doing 
easily.  (Not what I intended for it to do, which is what the specs give 
me.  But what I actually did, and where I chose an approach because it 
was quick to do, but that needs to be updated. ... cases that aren't 
handled deserve a compile time warning, and an execution time error, but 
this for is things like an optimization that was postponed.)  For this 
kind of thing my only complaint about DOxygen is that it's too verbose. 
  Well, and that it doesn't handle Ada.  (Actually DOxygen can produce 
both user and developer documentation, depending on how you set it to 
handle display of private variable, routines, etc.  But it doesn't 
handle Ada.)

I sure hope I can find something better than robodoc.