I really like where the below discussion is going. Just wanted to provide
another code example of some of the ideas I was toying with. It might be too
cumbersome, but I figured I'd throw it out there.
The PoissonDistribution throws a NotStrictlyPositiveException. I imagine several other
cla
Le 2012-09-06 00:38, Gilles Sadowski a écrit :
On Wed, Sep 05, 2012 at 08:16:34PM +0200, Luc Maisonobe wrote:
Le 05/09/2012 19:09, Ole Ersoy a écrit :
> Hi Gilles,
>
> On 09/04/2012 06:48 PM, Gilles Sadowski wrote:
>> Hello.
>>
>> There are ideas that sound good we experiment with them within a
On Wed, Sep 05, 2012 at 08:16:34PM +0200, Luc Maisonobe wrote:
> Le 05/09/2012 19:09, Ole Ersoy a écrit :
> > Hi Gilles,
> >
> > On 09/04/2012 06:48 PM, Gilles Sadowski wrote:
> >> Hello.
> >>
> >> There are ideas that sound good we experiment with them within a limited
> >> framework (like a cour
Le 05/09/2012 19:09, Ole Ersoy a écrit :
> Hi Gilles,
>
> On 09/04/2012 06:48 PM, Gilles Sadowski wrote:
>> Hello.
>>
>> There are ideas that sound good we experiment with them within a limited
>> framework (like a course on programming, for example); and then become a
>> nightmare when you find y
Hi Gilles,
On 09/04/2012 06:48 PM, Gilles Sadowski wrote:
Hello.
There are ideas that sound good we experiment with them within a limited
framework (like a course on programming, for example); and then become a
nightmare when you find yourself constantly trying to get around them.
I mean that a
Hello.
>
> I realize I'm a little late to the party here,
Late or early; these issues pop up again after while... :-)
> so if I'm asking or
> suggesting things that are naive just let me know straight up,
> and I'll try to educate myself better.
There are ideas that sound good we experiment wi
Hi,
I realize I'm a little late to the party here, so if I'm asking or suggesting
things that are naive just let me know straight up, and I'll try to educate
myself better. I will say that I really enjoy reading these threads because I
learn a great deal from them.
As a user of commons math
> > [...]
> >
> > There must be something imprecise in the CM project description which I've
> > read somewhere, mentioning "state-of-the-art". I understood it as "best
> > practices in Java programming and OO design", but I must have been wrong.
>
> Probably what you remember reading is this on t
On 9/2/12 4:44 PM, Gilles Sadowski wrote:
> Hi.
>
>>> I'd like to stress that using exceptions for control flow is, by default, an
>>> anti-pattern. It should pose question about how to improve CM so that you
>>> don't have to fall back on this kind of construct...
>> Please don't focus only on th
Hi.
> > I'd like to stress that using exceptions for control flow is, by default, an
> > anti-pattern. It should pose question about how to improve CM so that you
> > don't have to fall back on this kind of construct...
>
> Please don't focus only on this example but look at the rest of the
> ar
Le 02/09/2012 14:00, Gilles Sadowski a écrit :
> Hi again.
>
>>>
>>
> [...]
> I encountered this need in two different cases. The first one was to
> identify very precisely an error type, even with finer granularity
> than
> exception type. Parsing
Hi again.
> >
> > >
> > >>>
> > >> [...]
> > >> I encountered this need in two different cases. The first one was to
> > >> identify very precisely an error type, even with finer granularity
> > >> than
> > >> exception type. Parsing the error message to recognize the except
Jumping in the middle ... Just about naming:
The "unexpected" in the name is redundant IMO because it is an
"exception". It also does not need to be distinguished from an
"expected" exception. NIE would work or IllegalNIE if you want to be
more wordy. On the other extreme, there is also the existi
On Sun, Sep 02, 2012 at 12:24:58PM +0200, Luc Maisonobe wrote:
> Le 02/09/2012 00:16, Gilles Sadowski a écrit :
> > Hello Luc.
>
> Hi Gilles,
>
> >
> >>>
> >> [...]
> >> I encountered this need in two different cases. The first one was to
> >> identify very precisely an error type, e
Le 02/09/2012 00:16, Gilles Sadowski a écrit :
> Hello Luc.
Hi Gilles,
>
>>>
>> [...]
>> I encountered this need in two different cases. The first one was to
>> identify very precisely an error type, even with finer granularity than
>> exception type. Parsing the error message to
Hello Luc.
> >
> [...]
> I encountered this need in two different cases. The first one was to
> identify very precisely an error type, even with finer granularity than
> exception type. Parsing the error message to recognize the exception is
> evil, checking the enumerate
Le 29/08/2012 22:02, Gilles Sadowski a écrit :
> Hello.
>
[...]
I encountered this need in two different cases. The first one was to
identify very precisely an error type, even with finer granularity than
exception type. Parsing the error message to recognize the exception is
>
Hello.
> >> [...]
> >> I encountered this need in two different cases. The first one was to
> >> identify very precisely an error type, even with finer granularity than
> >> exception type. Parsing the error message to recognize the exception is
> >> evil, checking the enumerate used in the patter
One example I often use is launch window computation for rockets.
One way to compute them is brute force simulation: you simply try
all launch times and for each one you perform the simulation of the
early orbits phase. If at any time something breaks (a polynomial
that never crosses zero, an optim
Le 29/08/2012 00:51, Gilles Sadowski a écrit :
> Hi Luc.
Hi Gilles,
>
> First off, I'd like to make it quite clear that _I_ was fine (and still am)
> about a singly rooted hierarchy of exceptions for CM.
>
> I nevertheless answer to your reply because we differ on the rationale for
> such a cha
Hi Luc.
First off, I'd like to make it quite clear that _I_ was fine (and still am)
about a singly rooted hierarchy of exceptions for CM.
I nevertheless answer to your reply because we differ on the rationale for
such a change, or more exactly, we differ on how exceptions are to be
integrated in
On 8/28/12 5:36 AM, Luc Maisonobe wrote:
>
> I thought I had. Perhaps this feature was set up after I gave up
> on this discussion.
It would be quite easy to change, if it would make your life easier.
The more so that I never saw what is gained from copying the Java hierachy
Le 28/08/2012 16:04, Gilles Sadowski a écrit :
> Hello.
>
>>> [...]
>
> Applications that call CM would be safe (apart from bugs raising "NPE")
> with a unique catch clause intercepting "MathRuntimeException".
I am happy (and surprised) to read that.
I would really much like
Hello.
> > [...]
> >>>
> >>> Applications that call CM would be safe (apart from bugs raising "NPE")
> >>> with a unique catch clause intercepting "MathRuntimeException".
> >> I am happy (and surprised) to read that.
> >> I would really much like to go back to a single root exception
> >> hierarch
Le 26/08/2012 19:42, Phil Steitz a écrit :
> On 8/26/12 12:20 AM, Luc Maisonobe wrote:
>> Le 25/08/2012 23:43, Gilles Sadowski a écrit :
>>> Hello Luc.
>> Hi Gilles,
>>
>>> On Fri, Aug 24, 2012 at 09:31:41AM +0200, Luc Maisonobe wrote:
Le 24/08/2012 01:35, Gilles Sadowski a écrit :
> On Th
Hello.
> [...]
> >>
> >> Another really important part is that CM doesn't have anymore a
> >> hierarchy of exception. It has a bunch of completely unrelated
> >> exceptions, all extending different standard Java exceptions. This is
> >> the part that really bothers me, but this is the current cons
On 8/26/12 12:20 AM, Luc Maisonobe wrote:
> Le 25/08/2012 23:43, Gilles Sadowski a écrit :
>> Hello Luc.
> Hi Gilles,
>
>> On Fri, Aug 24, 2012 at 09:31:41AM +0200, Luc Maisonobe wrote:
>>> Le 24/08/2012 01:35, Gilles Sadowski a écrit :
On Thu, Aug 23, 2012 at 12:00:56PM -0700, Phil Steitz wro
Le 25/08/2012 23:43, Gilles Sadowski a écrit :
> Hello Luc.
Hi Gilles,
>
> On Fri, Aug 24, 2012 at 09:31:41AM +0200, Luc Maisonobe wrote:
>> Le 24/08/2012 01:35, Gilles Sadowski a écrit :
>>> On Thu, Aug 23, 2012 at 12:00:56PM -0700, Phil Steitz wrote:
On 8/23/12 5:37 AM, Luc Maisonobe wrot
Hello Luc.
On Fri, Aug 24, 2012 at 09:31:41AM +0200, Luc Maisonobe wrote:
> Le 24/08/2012 01:35, Gilles Sadowski a écrit :
> > On Thu, Aug 23, 2012 at 12:00:56PM -0700, Phil Steitz wrote:
> >> On 8/23/12 5:37 AM, Luc Maisonobe wrote:
> >>> Le 23/08/2012 13:37, Gilles Sadowski a écrit :
> On T
Le 24/08/2012 16:09, Gilles Sadowski a écrit :
> Hello Sébastien.
>
>>>
> [...]
I see that's another area where everyone has its own opinion because
of various experiences. I was previously in favor of exceptions, but
maybe it's too much for such a low-level component as a
Hello Sébastien.
> >
> > > > [...]
> > >
> > > I see that's another area where everyone has its own opinion because
> > > of various experiences. I was previously in favor of exceptions, but
> > > maybe it's too much for such a low-level component as a standard or
> > > special function. So I am n
Hi Gilles,
2012/8/24 Gilles Sadowski
>
> Hi.
>
> > > [...]
> >
> > I see that's another area where everyone has its own opinion because
> > of various experiences. I was previously in favor of exceptions, but
> > maybe it's too much for such a low-level component as a standard or
> > special func
Hi.
> > [...]
>
> I see that's another area where everyone has its own opinion because
> of various experiences. I was previously in favor of exceptions, but
> maybe it's too much for such a low-level component as a standard or
> special function. So I am now convinced that NaN should be returned
Hi,
2012/8/24 Luc Maisonobe :
> Le 24/08/2012 01:35, Gilles Sadowski a écrit :
>> On Thu, Aug 23, 2012 at 12:00:56PM -0700, Phil Steitz wrote:
>>> On 8/23/12 5:37 AM, Luc Maisonobe wrote:
Le 23/08/2012 13:37, Gilles Sadowski a écrit :
> On Thu, Aug 23, 2012 at 12:35:18PM +0200, Sébastien
Le 24/08/2012 01:35, Gilles Sadowski a écrit :
> On Thu, Aug 23, 2012 at 12:00:56PM -0700, Phil Steitz wrote:
>> On 8/23/12 5:37 AM, Luc Maisonobe wrote:
>>> Le 23/08/2012 13:37, Gilles Sadowski a écrit :
On Thu, Aug 23, 2012 at 12:35:18PM +0200, Sébastien Brisard wrote:
> Hi Gilles,
>
On Thu, Aug 23, 2012 at 12:00:56PM -0700, Phil Steitz wrote:
> On 8/23/12 5:37 AM, Luc Maisonobe wrote:
> > Le 23/08/2012 13:37, Gilles Sadowski a écrit :
> >> On Thu, Aug 23, 2012 at 12:35:18PM +0200, Sébastien Brisard wrote:
> >>> Hi Gilles,
> >>>
> >>> 2012/8/23 Gilles Sadowski :
> On Thu,
On 8/23/12 12:42 PM, Ted Dunning wrote:
> On Thu, Aug 23, 2012 at 3:00 PM, Phil Steitz wrote:
>
>> The problem is that contracts can often be written so that instances
>> of 1) are turned into instances of 0). Gamma(-) is a great
>> example. The singularities at negative integers could be viewed
On Thu, Aug 23, 2012 at 3:00 PM, Phil Steitz wrote:
> The problem is that contracts can often be written so that instances
> of 1) are turned into instances of 0). Gamma(-) is a great
> example. The singularities at negative integers could be viewed as
> making negative integer arguments "illeg
Hi,
thanks for all these answers.
2012/8/23 Phil Steitz :
> On 8/23/12 5:37 AM, Luc Maisonobe wrote:
>> Le 23/08/2012 13:37, Gilles Sadowski a écrit :
>>> On Thu, Aug 23, 2012 at 12:35:18PM +0200, Sébastien Brisard wrote:
Hi Gilles,
2012/8/23 Gilles Sadowski :
> On Thu, Aug 23,
On 8/23/12 5:37 AM, Luc Maisonobe wrote:
> Le 23/08/2012 13:37, Gilles Sadowski a écrit :
>> On Thu, Aug 23, 2012 at 12:35:18PM +0200, Sébastien Brisard wrote:
>>> Hi Gilles,
>>>
>>> 2012/8/23 Gilles Sadowski :
On Thu, Aug 23, 2012 at 10:05:10AM +0200, Sébastien Brisard wrote:
> Hi Luc,
>>
Le 23/08/2012 13:37, Gilles Sadowski a écrit :
> On Thu, Aug 23, 2012 at 12:35:18PM +0200, Sébastien Brisard wrote:
>> Hi Gilles,
>>
>> 2012/8/23 Gilles Sadowski :
>>> On Thu, Aug 23, 2012 at 10:05:10AM +0200, Sébastien Brisard wrote:
Hi Luc,
2012/8/23 Luc Maisonobe :
> Le 23/08/
On Thu, Aug 23, 2012 at 12:35:18PM +0200, Sébastien Brisard wrote:
> Hi Gilles,
>
> 2012/8/23 Gilles Sadowski :
> > On Thu, Aug 23, 2012 at 10:05:10AM +0200, Sébastien Brisard wrote:
> >> Hi Luc,
> >>
> >> 2012/8/23 Luc Maisonobe :
> >> > Le 23/08/2012 05:16, Sébastien Brisard a écrit :
> >> >> Hi
Hi Gilles,
2012/8/23 Gilles Sadowski :
> On Thu, Aug 23, 2012 at 10:05:10AM +0200, Sébastien Brisard wrote:
>> Hi Luc,
>>
>> 2012/8/23 Luc Maisonobe :
>> > Le 23/08/2012 05:16, Sébastien Brisard a écrit :
>> >> Hi,
>> >> in MATH-849, I have proposed an implementation of Gamma(x)
>> >> (previously,
On Thu, Aug 23, 2012 at 10:05:10AM +0200, Sébastien Brisard wrote:
> Hi Luc,
>
> 2012/8/23 Luc Maisonobe :
> > Le 23/08/2012 05:16, Sébastien Brisard a écrit :
> >> Hi,
> >> in MATH-849, I have proposed an implementation of Gamma(x)
> >> (previously, class Gamma had only logGamma(x)). Gamma(x) is
Hi Luc,
2012/8/23 Luc Maisonobe :
> Le 23/08/2012 05:16, Sébastien Brisard a écrit :
>> Hi,
>> in MATH-849, I have proposed an implementation of Gamma(x)
>> (previously, class Gamma had only logGamma(x)). Gamma(x) is not
>> defined for x negative integer. In such instances, I would like to
>> thro
Le 23/08/2012 05:16, Sébastien Brisard a écrit :
> Hi,
> in MATH-849, I have proposed an implementation of Gamma(x)
> (previously, class Gamma had only logGamma(x)). Gamma(x) is not
> defined for x negative integer. In such instances, I would like to
> throw an exception instead of returning Double
Hi,
in MATH-849, I have proposed an implementation of Gamma(x)
(previously, class Gamma had only logGamma(x)). Gamma(x) is not
defined for x negative integer. In such instances, I would like to
throw an exception instead of returning Double.NaN. However, creating
a new exception in o.a.c.m.exceptio
47 matches
Mail list logo
