[Biopython-dev] Bio.NeuralNetwork question and updates on 'testseq.'

[Brad Chapman]

Adil and Peter;
Thanks for looking at the NeuralNetwork code. I did write this and used it for
a project back then, but I'm sure it is completely out of date with best
practices and there are better libraries to use.

I'd be happy to if y'all wanted to deprecate/remove it and suggest or build
off an alternative implementation that is more up to date. Thanks again,
Brad


> [ text/plain ]
> Hi Adil,
>
> Replies below.
>
> On Wed, Jun 7, 2017 at 6:50 AM, Adil Iqbal <aiqbal85 at gmail.com> wrote:
>
>> ​Hello all,
>>
>> *TL:DR - Neural Network module is out of date. Also, I'm having an issue
>> with the unit test for the "testseq" function. *
>>
>> Just a quick question about the Neural Network module. The module seems
>> just a bit out of date. It only has one available activation function and
>> it's located in *the BackPropagation.Layer module
>> <http://biopython.org/DIST/docs/api/Bio.NeuralNetwork.BackPropagation.Layer-pysrc.html>*
>> for some reason.
>>
>> [image: Inline image 2]
>>
>> Machine learning research is progressed pretty far, and no one is really
>> using the logistic function as much anymore. The big thing now, especially
>> for hidden layers is ReLU, or at the very least TanH, both of which are no
>> where to be found in the code. That's not to say that the logistic function
>> shouldn't be included, but it should definitely not be the only option. The
>> binary step function should also definitely be included - if only for
>> output layers.
>>
>> Really, there should be a module *just* for activation functions. *And it
>> should include all of them.*
>> <https://en.wikipedia.org/wiki/Activation_function#Comparison_of_activation_functions>
>>
>> It's not that difficult, its really just a matter of plugging an argument
>> into a mathematical formula and returning the result. It might be prudent
>> to have an "Activation" class with each of the activation formulas as a
>> method of the class. Though, the backprop code would have to refactored to
>> account for that.
>>
>> Anyways, just a thought. I'd love to participate on that project, though
>> it would have to be a community effort.
>>
>
>
> Currently the Bio.NeuralNetwork module is not under active development, so
> you could perhaps take over this role? Alternatively, if you are familiar
> with the current state-of-the-art, there may be a much more mature Python
> library in this area we could recommend instead, and deprecate and later
> remove Bio.NeuralNetwork from Biopython?
>
> https://github.com/biopython/biopython/tree/master/Bio/NeuralNetwork
>
> Other than style and compatibility updates, it does not seem to have been
> changed meaningfully from the first commit by Brad Chapman back in 2001,
>
> https://github.com/biopython/biopython/commit/8641712c2c648dbb28230a08eab1f525f465d2e8
>
> Brad - did you write this or was it a contribution from someone else? The
> headers do not have any copyright statements.
>
>
>
>>
>> I've also written a *unit test for the testseq function
>> <https://github.com/Adil-Iqbal/biopython/blob/master/Tests/test_testseq.py>*
>> called test_testseq.py. However, it is failing the Travis CI tests because
>> it is unable to import testseq.py from the Scripts directory. I attempted
>> using both relative and absolute imports (*PEP328*
>> <https://www.python.org/dev/peps/pep-0328/>) but that did not work. I am
>> actively looking for a solution, though I would appreciate any advice you
>> guys could give me. (A pull request might be more efficient way clue me in
>> than actually explaining the concept.)
>>
>>
>
> Right now none of the Scripts/*.py or Doc/examples/*.py are checked from
> our main test suite. That is a project worth thinking about.
>
> One solution could be to write Scripts/some_file.py with a __main__ if
> statement so that it can be run and tested at the command line using:
>
> $ python Scripts/some_file.py
>
> If you do that, then your Tests/test_some_script.py could call this in a
> similar way via subprocess?
>
>
>> Also, I've finalized the code for testseq. The seeding worked perfectly,
>> but it was acting too much like a method and not enough like an argument. I
>> had some of my younger cousins use it and they were a bit confused by how
>> the seeding worked. Since the folks who would use the code are most likely
>> students, teachers, and presenters (not necessarily Python experts), I
>> decided to revert to an earlier solution. In this case, it is fair to trade
>> a bit of elegance for easier intuitiveness.
>>
>> Thanks again,
>> Adil
>>