Yeah, I am.

Infact part 2 is something I tried already, but gave up because the SVM I
was using was from a JNI wrapper and it did not have clean memory
management, and the application would hang with an out of memory error. I
never got the time to try a pure Java SVM, but I feel it is possible to
optimize parameters in a "timebound-predictable" manner, especially with
case of SVM. It is something I am going to explore when I make a faster SMSD
version of Maxtox.

>From what i observed of the process
a) Extensive parameter variation is easy to conceive, but difficult to
outline in reality
b) When a parameter or parameters are varied, the logic usually has a close
connection to the algorithm itself - meaning a generic mechanism may not
work.
c) Intelligent choice of direction of parameter optimization, itself plays a
big role in obtaining an acceptable model in reasonable time
d) Serious computational resources are required especially when such
requirements often spiral exponentially. One way out was to run in a cloud
like EC2 on Amazon, and start and stop extra server instances from within
the code - to cater to exponential demands.
e) Lastly and I feel most importantly, if we are to assume consumer
indiscretion (in raw terms - more dumb than bright) , then there has to be a
component of AI in the workflow for parameter optimization. A blunt "try
everything" approach will simply not cut it (or for that matter satisfy our
target audience)

Cheers
Suro

On 26 October 2011 14:37, Barry Hardy <barry.hardy at douglasconnect.com>wrote:

> Two application needs based on OpenTox components that have surfaced:
>
> a. an application allowing user choice on algorithm and parameters for
> creating a validated model
>
> b. an application/workflow supporting automated extensive
> parameter/algorithm variation to produce an optimed model based on
> user-supplied criteria
>
> Let us know if you are interested!
>
> Barry
>
> Am 26.10.2011 10:58, schrieb Christoph Helma:
>
>> Starting a new thread from a semi-private conversation.
>>
>> On Wed, 26 Oct 2011 10:01:51 +0200, Barry Hardy<barry.hardy@**
>> douglasconnect.com <barry.hardy at douglasconnect.com>>  wrote:
>>
>>> I don't this is a good argument for ToxCreate. It might be for say
>>> "Christoph's lazar application" or a controlled "ToxReachModeller".
>>>
>>>  From the point of view of the ToxCreate Use Case, and OpenTox and a
>>> component-based design, in my opinion, the application should allow the
>>> user to select the algorithm.
>>>
>> ToxCreate should be a simple tool for novice users (without an
>> understanding of algorithms and parameters).  How can we expect that a
>> novice user makes an informed decision if even we (i.e.  the experts)
>> cannot provide better alternatives?
>>
>> Christoph
>>
>> PS We have been discussing a medium-level GUI with selection of
>> algorithms and parameters from the beginning, but I have always clearly
>> stated that we will not have the resources to implement that in
>> ToxCreate. Anyone who is interested can take our opento-ruby library and
>> wrap a GUI around it.
>>
>>
>>
> ______________________________**_________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/**mailman/listinfo/development<http://www.opentox.org/mailman/listinfo/development>
>



-- 
Surajit Ray
Partner
www.rareindianart.com