From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8e11100f675ea2df X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.74.135 with SMTP id t7mr6066402pav.29.1357153732032; Wed, 02 Jan 2013 11:08:52 -0800 (PST) Path: s9ni78282pbb.0!nntp.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 02 Jan 2013 13:08:51 -0600 Date: Wed, 02 Jan 2013 11:02:54 -0800 From: Charles Hixson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: asynchronous task communication References: <1c2dnd5E6PMDR33NnZ2dnUVZ_sednZ2d@earthlink.com> <50e18094$0$6583$9b4e6d93@newsspool3.arcor-online.net> <7NednS4s2oukfXzNnZ2dnUVZ_oadnZ2d@earthlink.com> <7cudnYloBfQDw3_NnZ2dnUVZ_rKdnZ2d@earthlink.com> In-Reply-To: Message-ID: <6bqdndEYjoxeGHnNnZ2dnUVZ_sadnZ2d@earthlink.com> X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 216.244.16.210 X-Trace: sv3-2m4fhiT1wAJhs8jwrlbQq40NirD3wJsSwc4RIUkhnz3brCmDPXwjQwsAsbXDLkumO5/YBz6BsKtBsDh!nEqwZA9EAzR2AqcOhtDNq9PyFHnmnh/NDwtv052w1te8Nj0kKElPhPxT5tSjgro4Lyfh3n9FAq4J!SZgngjoxUVJPKChhP/t9SA== X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 5597 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2013-01-02T11:02:54-08:00 List-Id: 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 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.)