commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] LeastSquaresOptimizer Design
Date Thu, 24 Sep 2015 23:09:25 GMT
On Thu, 24 Sep 2015 18:01:13 -0500, Ole Ersoy wrote:
> On 09/24/2015 04:05 PM, Gilles wrote:
>> On Thu, 24 Sep 2015 08:43:38 -0500, Ole Ersoy wrote:
>>> On 09/24/2015 06:31 AM, luc wrote:
>>>> Le 2015-09-24 04:16, Ole Ersoy a écrit :
>>>>> On 09/23/2015 03:09 PM, Luc Maisonobe wrote:
>>>>>> CM is not intended to be a design pattern people should mimic. 
>>>>>> We are so bad at this it would be a shame. No one in its right 
>>>>>> mind would copy or reuse this stuff. It is for internal use only

>>>>>> and we don't even have the resources to manage it by ourselves so

>>>>>> we can't consider it as a path people should follow as we are 
>>>>>> leading them. Here we would be leading them directly against the

>>>>>> wall.
>>>>>
>>>>> Hehe - I think that's like Michael Jordan saying - "Guys, don't 
>>>>> try to
>>>>> be like me.  I just play a little ball.  Dunk from the free throw
>>>>> line.  Six world championships, but THATs it!".  In any case, I 
>>>>> really
>>>>> appreciate you and Gilles taking the time to talk.  Luc (And 
>>>>> possibly
>>>>> Gilles) - I can actually see why you are getting a bit annoyed,
>>>>> because I'm ignoring something important.
>>>>>
>>>>> I've been doing 90% NodeJS stuff lately (Which is event loop 
>>>>> based and
>>>>> relies callbacks) so I forgot one very important thing that I 
>>>>> think
>>>>> you have both tried to tell me.  The exception undoes the current
>>>>> callstack / breaks the current program flow, bubbling up to the
>>>>> handler.  Thaaaats a good point.
>>>>>
>>>>> OK - So scratch the callback thinking for synchronous code. The
>>>>> Lombok stuff should still be good though and hopefully some of 
>>>>> the
>>>>> callback discussion around and asynchronous option - I hope! 
>>>>> Geez.
>>>>>
>>>>> What do you think about having one exception per class with an 
>>>>> Enum
>>>>> that encodes the various types of exceptional conditions that the
>>>>> class can find itself in?  So in the case of
>>>>> LevenbergMarquardtOptimizer there would be a:
>>>>> - LevenbergMarquardtOptimizerException:
>>>>> - LevenbergMarquardtOptimizerExceptionEnum
>>>>>
>>>>> When the exception is thrown it sets the Enum indicating the root
>>>>> cause.  The enum can then be used as a key to lookup the 
>>>>> corresponding
>>>>> message.
>>>>>
>>>>> Any better?
>>>>
>>>> Sure. I would suggest adding some parameters to help the upper 
>>>> level formatting
>>>> a meaningful message (say the number of iterations performed if 
>>>> you hit a max
>>>> iteration, so users become aware they should have set the limit 
>>>> higher). Nothing
>>>> over-engineered, a simple Object[] that can be used as last 
>>>> argument to something
>>>> like String.format() would be enough.
>>> Brilliant - I'll setup a repository and start experimenting. Thanks 
>>> again,
>>> - Ole
>>
>> I don't understand what Luc proposed.
>> But just having "Object[]" mentioned makes me shiver... :-{
>>
>> Thanks to the "ExceptionContext" it is readily possible to add as 
>> many "messages"
>> as we want to be displayed. [There is no need to ask the caller to 
>> use "format()"
>> as it is done in CM.]
>> And there are also a methods for setting and getting an "Object".
>>
>> I'd be for using more (possibly "local") exceptions if we want to 
>> convey
>> more, and more specific, information.  This should be done with 
>> getters that
>> return typed information, not "Object"s.
>
> Javascripters do what Luc is advocating all the time, so I'm used to 
> it.
>
> If the exception is specific to the class throwing the exception then
> we could attach a reference to the instance throwing the exception 
> and
> use Lombok to generate binary getters.
>

Why should the instance throwing the exception hold a field with the
information? Separation of concerns: optimizer does the computation,
then the exception holds what's needed for a full report of the 
failure.

Or the report is done at the observer's level, based on complete
information routinely returned by the optimizer at every step (cf.
previous mail).

Gilles

> Cheers,
> - Ole
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message