Re: [math] integer factorization -> MATH-845

[matic <ma...@nimp.co.uk>]

Yes I was thinking a little bit more than just factorization, sorry I 
did not state it clearly at the start.
I created a ticket in JIRA for this: 
https://issues.apache.org/jira/browse/MATH-845
Please let me know your opinion about it.

About "fast prime number generation" what is missing with a 
"nextPrimeAfter" method ?

Sebastien

On 2012-08-12 14:32, J.Pietschmann wrote:
> Am 06.08.2012 02:43, schrieb matic@nimp.co.uk:
>> If the factorization of integers is not in scope of commons math, 
>> what
>> about removing it from "MathWishList" then ?
>
> Hmm, the MathWishList lists primality testing. This *is* in scope,
> and probably also fast prime number generation (not only the
> "nextPrimeAfter" mentioned elsewhere in this thread). Did you 
> actually
> mean this topic? In this case, your code is welcome!
>
> J.Pietschmann
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


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

Re: [math] assert policy

[Ted Dunning <te...@gmail.com>]

Asserts can be handy to inject additional checking into execution inside
private areas of a class during unit tests but it should be assumed that
they are disabled any other time (and the unit test should do real
assertion checking redundantly)

On Wed, Aug 15, 2012 at 9:33 PM, James Ring <sj...@jdns.org> wrote:

> Just a quick observation: at Google the Java practices guide says
> assert == "//". Assertions can be disabled, so you should never rely
> on it to crash if something is seriously wrong and you should never
> rely on side-effects of the assert expression.
>
> On Wed, Aug 15, 2012 at 4:02 PM, Gilles Sadowski
> <gi...@harfang.homelinux.org> wrote:
> > On Wed, Aug 15, 2012 at 10:46:06PM +0200, matic wrote:
> >> Sebb, Gilles and I would like to start a discussion [...]
> >   ^^^^
> >
> > It was not that "Sebb" who commented on MATH-845... ;-)
> >
> >> [...]
> >>
> >> @Gilles: sometimes assertion are a form of comments on steroid ->
> >> they will bark at you if you did not read them, and equally
> >> important: they are unambiguous. When I first write a method, it
> >> usually does not work right away. If it contains asserts, I usually
> >> get a clue of what's wrong, and if I don't, I try to write
> >> additional ones before tracking down the failure in a debug session.
> >> It is way faster, it forces me to understand better what I am coding
> >> (when I just follow a algorithm described in a paper, the typical
> >> situation for CM stuff) and the best of all: it will help anyone who
> >> later modify the code.
> >> -> in short, I see assertions as an invaluable tool to help
> >> developers, not just something to check input parameters in private
> >> methods. For this reason, I would support the following policy:
> >> 1. Use asserts as much as you like, but they are by no mean a
> >> substitute to runtime checks (code that throws "MathInternalError")
> >> for input parameters of public methods.
> >> 2. Asserts must be enabled in all unit tests
> >
> > I don't deny that assertions can help you while developing, but the
> > algorithms in the CM library should not be construed as a "work in
> > progress". To be sure, quite a few areas definitely need all kinds of
> > improvements, but what I mean is that when something is checked in, it
> > should be working as expected (bugs notwithstanding) by the developer.
> That
> > means: "assert" statements will not be triggered. Unit tests should be
> > provided to ensure that everything (ideally) behaves as expected.
> >
> > I understand that you did not mean to replace runtime check with
> assertions
> > but I'm a little afraid that "assert" will be considered enough (or
> better
> > than comments), such that the amount of comments will be reduced (while
> the
> > opposite should happen).
> > Moreover, "assert" generally checks "obvious" mistakes, which will happen
> > during development but are much less likely to occur when the finished
> code
> > is being called (I think). Once you start sprinkling "assert" statements
> in
> > a library like CM, it can quickly become littered with hundreds of them
> (in
> > fact there would probably be more "assert" than there are precondition
> > checks). I wondered how more readable that will make the code and for
> what
> > added value.
> > I understand that the readability would suffer (and even more) by
> > introducing logging statements all over the place, but at least that
> would
> > provide the benefit that one could be able to trace a bug to its root
> cause.
> > [I'm saying this because I recently wished I had logging inside a CM
> > alogrithm, while "assert" wouldn't have helped.]
> >
> >
> > Best regards,
> > Gilles
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [math] assert policy

[James Ring <sj...@jdns.org>]

Just a quick observation: at Google the Java practices guide says
assert == "//". Assertions can be disabled, so you should never rely
on it to crash if something is seriously wrong and you should never
rely on side-effects of the assert expression.

On Wed, Aug 15, 2012 at 4:02 PM, Gilles Sadowski
<gi...@harfang.homelinux.org> wrote:
> On Wed, Aug 15, 2012 at 10:46:06PM +0200, matic wrote:
>> Sebb, Gilles and I would like to start a discussion [...]
>   ^^^^
>
> It was not that "Sebb" who commented on MATH-845... ;-)
>
>> [...]
>>
>> @Gilles: sometimes assertion are a form of comments on steroid ->
>> they will bark at you if you did not read them, and equally
>> important: they are unambiguous. When I first write a method, it
>> usually does not work right away. If it contains asserts, I usually
>> get a clue of what's wrong, and if I don't, I try to write
>> additional ones before tracking down the failure in a debug session.
>> It is way faster, it forces me to understand better what I am coding
>> (when I just follow a algorithm described in a paper, the typical
>> situation for CM stuff) and the best of all: it will help anyone who
>> later modify the code.
>> -> in short, I see assertions as an invaluable tool to help
>> developers, not just something to check input parameters in private
>> methods. For this reason, I would support the following policy:
>> 1. Use asserts as much as you like, but they are by no mean a
>> substitute to runtime checks (code that throws "MathInternalError")
>> for input parameters of public methods.
>> 2. Asserts must be enabled in all unit tests
>
> I don't deny that assertions can help you while developing, but the
> algorithms in the CM library should not be construed as a "work in
> progress". To be sure, quite a few areas definitely need all kinds of
> improvements, but what I mean is that when something is checked in, it
> should be working as expected (bugs notwithstanding) by the developer. That
> means: "assert" statements will not be triggered. Unit tests should be
> provided to ensure that everything (ideally) behaves as expected.
>
> I understand that you did not mean to replace runtime check with assertions
> but I'm a little afraid that "assert" will be considered enough (or better
> than comments), such that the amount of comments will be reduced (while the
> opposite should happen).
> Moreover, "assert" generally checks "obvious" mistakes, which will happen
> during development but are much less likely to occur when the finished code
> is being called (I think). Once you start sprinkling "assert" statements in
> a library like CM, it can quickly become littered with hundreds of them (in
> fact there would probably be more "assert" than there are precondition
> checks). I wondered how more readable that will make the code and for what
> added value.
> I understand that the readability would suffer (and even more) by
> introducing logging statements all over the place, but at least that would
> provide the benefit that one could be able to trace a bug to its root cause.
> [I'm saying this because I recently wished I had logging inside a CM
> alogrithm, while "assert" wouldn't have helped.]
>
>
> Best regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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

Re: [math] assert policy

[Gilles Sadowski <gi...@harfang.homelinux.org>]

On Wed, Aug 15, 2012 at 10:46:06PM +0200, matic wrote:
> Sebb, Gilles and I would like to start a discussion [...]
  ^^^^

It was not that "Sebb" who commented on MATH-845... ;-)

> [...]
> 
> @Gilles: sometimes assertion are a form of comments on steroid ->
> they will bark at you if you did not read them, and equally
> important: they are unambiguous. When I first write a method, it
> usually does not work right away. If it contains asserts, I usually
> get a clue of what's wrong, and if I don't, I try to write
> additional ones before tracking down the failure in a debug session.
> It is way faster, it forces me to understand better what I am coding
> (when I just follow a algorithm described in a paper, the typical
> situation for CM stuff) and the best of all: it will help anyone who
> later modify the code.
> -> in short, I see assertions as an invaluable tool to help
> developers, not just something to check input parameters in private
> methods. For this reason, I would support the following policy:
> 1. Use asserts as much as you like, but they are by no mean a
> substitute to runtime checks (code that throws "MathInternalError")
> for input parameters of public methods.
> 2. Asserts must be enabled in all unit tests

I don't deny that assertions can help you while developing, but the
algorithms in the CM library should not be construed as a "work in
progress". To be sure, quite a few areas definitely need all kinds of
improvements, but what I mean is that when something is checked in, it
should be working as expected (bugs notwithstanding) by the developer. That
means: "assert" statements will not be triggered. Unit tests should be
provided to ensure that everything (ideally) behaves as expected.

I understand that you did not mean to replace runtime check with assertions
but I'm a little afraid that "assert" will be considered enough (or better
than comments), such that the amount of comments will be reduced (while the
opposite should happen).
Moreover, "assert" generally checks "obvious" mistakes, which will happen
during development but are much less likely to occur when the finished code
is being called (I think). Once you start sprinkling "assert" statements in
a library like CM, it can quickly become littered with hundreds of them (in
fact there would probably be more "assert" than there are precondition
checks). I wondered how more readable that will make the code and for what
added value.
I understand that the readability would suffer (and even more) by
introducing logging statements all over the place, but at least that would
provide the benefit that one could be able to trace a bug to its root cause.
[I'm saying this because I recently wished I had logging inside a CM
alogrithm, while "assert" wouldn't have helped.]


Best regards,
Gilles

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

[math] assert policy

[matic <ma...@nimp.co.uk>]

Sebb, Gilles and I would like to start a discussion about the use of 
assert in CM code.
This started by comments in a JIRA ticket 
(https://issues.apache.org/jira/browse/MATH-845), I rewrite below a 
summary:

Gilles, commenting on my code:
"assert" statements should be replaced by precondition checks (raising 
an appropriate exception if they fail).

myself:
In the case of private or package private methods, is it also required 
to turn them into runtime checks ? Is it acceptable to simply comment 
them if the performance impact is significant ?

Gilles:
AFAIK, there is no policy for the use of "assert" within the CM code.
In the case of a library like CM, robustness is important; I guess that 
it is less safe to use "assert" since an application could silently fail 
if assertions are not enabled.
In cases where the method is for internal use only, and we are sure 
that the CM code calls it correctly, my preference would be to just 
remove the unused statement, and replace it with an appropriate comment 
stating why an explicit check is not necessary.

Sebb:
Interesting! I was about to ask the same question on the ML for another 
issue (incomplete beta function).
I really would like to have this point discussed more widely, as I tend 
to prefer assertions over simple comments (assertions could be turned on 
(at least, locally) during testing).
Of course, I'm in favor of an additional comment stating that explicit 
check is deemed unnecessary for private or package private methods. In 
my case, some package private methods provide approximations of some 
functions over a specific interval. I would then state in the javadoc 
the interval, and also that it is the responsibility of the user to make 
sure that this approximation is not called outside its domain.

Gilles:
IMO, neither "assert" statements nor simple comments are useful for 
testing (or more precisely, debugging). What we'd need is logging.
"assert" aborts the program, but does not tell you how the wrong value 
made it there.
I think that "assert" is very useful, but in applications (meaning: 
don't bother with the rest of the computation, as I know that someting 
went wrong).
By contrast, in CM, no "assert" should ever be triggered from internal 
calls. Furthermore, no "assert" should ever be triggered from external 
calls, as that would mean that unsafe (if assertions are disabled) code 
can be called.
To be robust, CM raises a "MathInternalError" at places no code path 
should ever lead to; but if one does, at least something predictable 
happens.
One thing to check in the first place is whether a precondition check 
actually slows down things in an "unbearable" way.

end of comments in MATH-845, let's discuss this in ML from now.

@Gilles: sometimes assertion are a form of comments on steroid -> they 
will bark at you if you did not read them, and equally important: they 
are unambiguous. When I first write a method, it usually does not work 
right away. If it contains asserts, I usually get a clue of what's 
wrong, and if I don't, I try to write additional ones before tracking 
down the failure in a debug session. It is way faster, it forces me to 
understand better what I am coding (when I just follow a algorithm 
described in a paper, the typical situation for CM stuff) and the best 
of all: it will help anyone who later modify the code.
-> in short, I see assertions as an invaluable tool to help developers, 
not just something to check input parameters in private methods. For 
this reason, I would support the following policy:
1. Use asserts as much as you like, but they are by no mean a 
substitute to runtime checks (code that throws "MathInternalError") for 
input parameters of public methods.
2. Asserts must be enabled in all unit tests

Sebastien

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