From: RaL <ravwar@...>
Date: 2008-03-20T19:20:38+09:00
Subject: Re: Google Summer of Code 2008?

I want to create a project devoted to Neural Networks. Would Ruby
Central be interested to support me and this project for Google Summer
of Code?

Right now, there are two gems with a Neural Network support -
http://ai4r.rubyforge.org/ É http://ruby-fann.rubyforge.org/. But both
of them implement only one learning algorithm - back-propagation (and
accordingly to that fact only one type of Neural Network - multilayer
perceptron) - also they don't have ability to choose different
activation functions for different layers and so you can't even build
Radial Basis Function Network with those gems. They don't have a built-
in interface to use even widespread learning strategies (e.g., begin
learning with a high learning rate and then switch to a low learning
rate after approaching some threshold).

So as a GSoC project I decide to implement several Neural Network
types, including multilayer perceptron, self-organizing feature map
(Kohonen net), auto-associative memory (Hopfield net) and recurrent
neural network. I want to build an easy but powerful interface to use
with. So it will support a range of learning strategies for fast start
but it will be very customizable in case of need. It will have a built-
in visualization module so you could see a net topology with all
values of weights, errors, input and output values in any moment of
time. You could also see a graphic of values (good to see a final
approximation) and errors (to understand a dependence on epoch count).
And as the last step i want to build a Neural Network web-editor via
silverlight and IronRuby.

So what does RubyCentral think about my proposal?

On Mar 19, 5:05špm, James Gray <ja...@grayproductions.net> wrote:
> On Mar 19, 2008, at 12:16 AM, Chiyuan Zhang wrote:
>
> > Is there any project ideas collected? Maybe something about Ruby 1.9,
> > Rubinius etc.
>
> I'm sure we can brainstorm some for you.
>
> Regarding your Ruby 1.9 idea: šmany libraries don't work correctly yet š
> in Ruby 1.9. šYou could come up with a list of favorites that don't š
> work and offer to patch them for Ruby 1.9. šI think that could be š
> quite a resource to the community. šI got this idea from Greg Brown š
> who may be doing a similar project soon, but I think there are more š
> than enough libraries to go around.
>
> Beyond that, here are a few other random ideas:
>
> * There's been a lot of talk about better documentation tools lately. š
> I believe Eric Hodel is working on revamping RDoc. šPerhaps you could š
> see what you could do to help with that. šJames Britt has also looked š
> at better ways to assemble the documentation for ruby-doc.org, so that š
> may be another place you could help out.
> * I've recently had need of a multiprocess event safe logger. šWhat I š
> mean by that is that I have two processes writing to the same log š
> file. šThey may log five things for each event. šIn the log file, I š
> would prefer the resulting ten entries not be interleaved. šYou could š
> provide a start event method and an end event method and only add š
> events to the log file after the event ended. šThis is more š
> complicated than it sounds since you will want to deal with large š
> logging data for a single event (probably using Tempfile), badly š
> behaved programs that don't manage to call the end event method, long š
> running events, etc.
> * Daniel Berger has requested a pure Ruby implementation of zlib a few š
> times now. šThis might give new options for Windows installers.
>
> I do encourage you to think up your own ideas though. šI've been a š
> mentor for the last two years and I can easily say that the š
> applications for unique ideas were generally more appealing. šThere š
> are two reasons for that. šThe first is that lots of applications come š
> in for the ideas we post publicly, so you're competing with a lot of š
> people who want to do the exact same thing. šThe other is that you š
> will just be more creative when running with your own idea. šDon't š
> hesitate to latch onto one of your own needs and run with it.
>
> James Edward Gray II