Hello Bert

BF> What are you using #withIndexDo: for? One third is a rather large
BF> percentage (provided this is not an aliasing error with the  
BF> floatarray prims).

First: I have an Array of Neurons and I have to train its
neighbourhood (seen in 2D or 1D) So for every neuron I have an array
(neighbours) pointing to its neighbours.

Second: the learnrate depends on the proximity of two neurons and they
also are stored in a precalculated array.

This results in a method like:

learnOneStepAtVariableRate
        "find the neuron with the strongest reaction, train this one and its 
         neighbourhood with the SOFM rule. The learning rate for each neuron 
        comes from an array"

        | mostExcited trainees |
        mostExcited := outputs indexOf: outputs max.
        trainees := neighbours at: mostExcited.
        trainees withIndexDo: 
                        [:each :index | 
                        (neurons at: each)
                                sofmLearnAtLearnRate: (learnRates at: index);
                                normalizeCoefficients]

To get rid of a bit of this overhead in other places, I changed:

"sample normalizedInputs
        withIndexDo: [:input :indx | network inputs at: indx put: input]."

into:
network inputs replaceFrom: 1  to: network inputs size with: sample normalizedInputs startingAt: 1.

which is a private method in FloatArray and bad style.

I'm happy for every suggestion to do it speedier!

If Tim reads this, I'll get scolded for premature optimisation if not
worse :-))

Sorry this went to your private mail.

Thanks,

Herbert                            mailto:herbertkoenig at gmx.net