[ 
https://issues.apache.org/jira/browse/MATH-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843047#action_12843047
 ] 

Phil Steitz edited comment on MATH-349 at 3/9/10 1:47 PM:
----------------------------------------------------------

Issue (2) in the bug description remains open.  I think we should leave this 
issue open until we have a solution for this.  As stated above, I can see two 
ways to fix this:

a) modify the normal approximation implementation so that it does not change 
the parameters of z
b) eliminate pluggability of z (i.e., deprecate and then remove the constructor 
that accepts a normal instance as a parameter)

a) could be accomplished in 2.x, but it would complicate the code and could be 
bad for numerics.  My vote is for b) - add a warning (about safety as well as 
deprecation), deprecate now and if we get no complaints before 3.0, remove 
then.   Leave the issue open with fix version 3.0.

      was (Author: psteitz):
    Issue (2) in the bug description remains open.  I think we should leave 
this issue open until we have a solution for this.  As stated above, I can see 
two ways to fix this:

a) modify the normal approximation implementation so that it does not change 
the parameters of z
b) eliminate pluggability of z (i.e., deprecate and then remove the constructor 
that accepts a normal instance as a parameter)

a) could be accomplished in 2.x, but it would complicate the code and could be 
bad for numerics.  My vote is for b) - add a warning (about safety as well as 
deprecation), deprecate now and if we get no complaints before 3.0, remove then.
  
> Dangerous code in "PoissonDistributionImpl"
> -------------------------------------------
>
>                 Key: MATH-349
>                 URL: https://issues.apache.org/jira/browse/MATH-349
>             Project: Commons Math
>          Issue Type: Bug
>            Reporter: Gilles
>            Priority: Minor
>
> In the following excerpt from class "PoissonDistributionImpl":
> {code:title=PoissonDistributionImpl.java|borderStyle=solid}
>     public PoissonDistributionImpl(double p, NormalDistribution z) {
>         super();
>         setNormal(z);
>         setMean(p);
>     }
> {code}
> (1) Overridable methods are called within the constructor.
> (2) The reference "z" is stored and modified within the class.
> I've encountered problem (1) in several classes while working on issue 348. 
> In those cases, in order to remove potential problems, I copied/pasted the 
> body of the "setter" methods inside the constructor but I think that a more 
> elegant solution would be to remove the "setters" altogether (i.e. make the 
> classes immutable).
> Problem (2) can also create unexpected behaviour. Is it really necessary to 
> pass the "NormalDistribution" object; can't it be always created within the 
> class?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to