Re: asynchronous task communication

[Charles Hixson <charleshixsn@earthlink.net>]

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.  Perhaps I could have a few standard 
sizes...but the range between the smallest and the largest will be a 
factor of about (uncertain) 5000, with the smallest size dominating in 
frequency.  And cells will change in the number of their connections.
At least if I do things right.  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.

The shape of the graph is going to be dependent on the data, as what I'm 
doing is essentially measuring what comes near what, as a prediction of 
what parts of a pattern are missing.  I expect sub-graphs to develop 
automatically, but they can't be imposed from the start.

OTOH, limiting a combinatorial explosion is certainly one of the things 
that is going to require work.  But if I limit propagation too much, 
then the thing won't work.  So even if I get the basic design right, 
it's going to require a lot of ad hoc tuning.  I am currently planning, 
when I get things designed sufficiently, to tinker with activation 
levels and decay rates to control the combinatorial explosion...and also 
to keep signals from dying away too quickly.  That's probably going to 
require some "evolutionary programming" where similar programs with 
slightly different "gosh numbers" are run against each other, as I don't 
see any theoretical grounds for picking particular values.

Probably, when I get sufficient experience with Ada, I'll install the 
Boehm garbage collector.  Now that looks like asking for trouble.  Even 
GPS is giving me grief.

P.S.:  Is there any way to generate documentation for Ada, better than 
robodoc?  I don't count turning the program files into HTML to be 
documentation.  It doesn't add much over the bare files.  Something 
similar to DOxygen or Javadoc?  (Though DOxygen also tends to be too 
verbose.)