Brain.js: Private Functions in NeuralNetwork

Created on 13 Jan 2018 · 8Comments · Source: BrainJS/brain.js

So I have been thinking about https://github.com/BrainJS/brain.js/issues/99 and I think another thing that can get new users bogged down is how many methods and variables are exposed. For example in the REPL I instantiate a simple NeuralNetwork and her are the things I have control over:

How many of these do we actually want the user to be interacting with? If the user trains a network, then randomly calls initialize with some given size their network is dust in the wind.

I think if we take the methods that are meant to only be used internally within the class and declare them in the constructor (or some other scheme for having them not public). I think that might also help those new to the library. I don't mind doing this If you want me to.

Just check boxes you want Private and I will take care of it.

[ ] adjustWeights
[ ] calculateDeltasLeakyRelu
[ ] calculateDeltasRelu
[ ] calculateDeltasSigmoid
[ ] calculateDeltasTanh
[ ] createTrainStream
[ ] formatData
[ ] fromJSON
[ ] initialize
[ ] run
[ ] runInputLeakyRelu
[ ] runInputRelu
[ ] runInputSigmoid
[ ] runInputTanh
[ ] setActivation
[ ] test
[ ] toFunction
[ ] toJSON
[ ] train
[ ] trainPattern
[ ] activation
[ ] biases
[ ] binaryThresh
[ ] calculateDeltas
[ ] changes
[ ] deltas
[ ] errors
[ ] hiddenLayers
[ ] hiddenSizes
[ ] learningRate
[ ] momentum
[ ] outputLayer
[ ] outputs
[ ] runInput
[ ] sizes

Source

freddyC

Most helpful comment

So I was talking to @robertleeplummerjr about this a bit. The main thing I think would help new users is a more clear interface on which methods are meant for them to interact with. At the same time, I think for those looking through the code it would be more clear to have smaller functions in the neural-network itself, so it is easier to read and understand.

How about adding _ before methods that are meant to be private?

This would let us break out private functions into smaller and easier to read methods, without confusing those starting with the library, since the publicly intended functions are a bit more explicit.

Thoughts?

freddyC on 18 Jan 2018

👍3

All 8 comments

I'm hesitant to alter those items because of a few reasons:

I would much rather we focus attention on v2 and v3, and utilizing ultra fast performance
In javascript, there really isn't an a concept of private, it is more implied, most libraries just document the items they want supported in the wild, which we do, but could probably be enhanced
the library has been established long before I ever became involved in it
it can make future development more difficult
the community often makes the best calls for this type of thing

So maybe if the community starts to respond: "Hey, yea, this has always bugged me, lets make it so!" then I'd be on board, but for now, I want to focus on innovation.

I'm really loving this energy!