[Math] Issue 348

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Math] Issue 348

Gilles Sadowski
Hello.

I'm ready to make the changes proposed in
  https://issues.apache.org/jira/browse/MATH-348

Any objection?

Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Luc Maisonobe

----- "Gilles Sadowski" <[hidden email]> a écrit :

> Hello.
>
> I'm ready to make the changes proposed in
>   https://issues.apache.org/jira/browse/MATH-348

Hi Gilles,

Sorry, I forgot to comment on the issue. I agree with you, go ahead with the changes.

Luc

>
> Any objection?
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Ted Dunning
In reply to this post by Gilles Sadowski
I don't see any changes proposed.

I see a couple of statements that getters are used (usually considered
good), and a question about over-riding.

What are you proposing?

On Fri, Mar 5, 2010 at 4:34 AM, Gilles Sadowski <
[hidden email]> wrote:

> Hello.
>
> I'm ready to make the changes proposed in
>  https://issues.apache.org/jira/browse/MATH-348
>
> Any objection?
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Ted Dunning, CTO
DeepDyve
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Gilles Sadowski
Hello.

> I don't see any changes proposed.

I propose to use the instance variable in place of the accessor.

> I see a couple of statements that getters are used (usually considered
> good), and a question about over-riding.

Getters are for accessing to encapsulated data. Within the class itself the
data is readily accessible, so using the accessor is, at best, less
efficient.
Moreover, if, by mistake, a sub-class overrides the accessor, you can get
inconsistent result: the overridden accessor can return some value while it
is another (the one stored in the instance variable) that is used to perform
the calculation.

Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

sebb-2-2
On 05/03/2010, Gilles Sadowski <[hidden email]> wrote:

> Hello.
>
>
>  > I don't see any changes proposed.
>
>
> I propose to use the instance variable in place of the accessor.
>
>
>  > I see a couple of statements that getters are used (usually considered
>  > good), and a question about over-riding.
>
>
> Getters are for accessing to encapsulated data. Within the class itself the
>  data is readily accessible, so using the accessor is, at best, less
>  efficient.

Not necessarily - if it turns out that the field needs to be
synchronized, then always using the getter/setter rather than direct
access makes it very easy to fix the problem.

>  Moreover, if, by mistake, a sub-class overrides the accessor, you can get
>  inconsistent result: the overridden accessor can return some value while it
>  is another (the one stored in the instance variable) that is used to perform
>  the calculation.

If there is a good reason to override the getter/setter, then it is
likely that the sub-class wants the new value to be used throughout.

>  Best,
>  Gilles
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Gilles Sadowski
Hi.

> >  > I don't see any changes proposed.
> >
> >
> > I propose to use the instance variable in place of the accessor.
> >
> >
> >  > I see a couple of statements that getters are used (usually considered
> >  > good), and a question about over-riding.
> >
> >
> > Getters are for accessing to encapsulated data. Within the class itself the
> >  data is readily accessible, so using the accessor is, at best, less
> >  efficient.
>
> Not necessarily - if it turns out that the field needs to be
> synchronized, then always using the getter/setter rather than direct
> access makes it very easy to fix the problem.

As I note in
  https://issues.apache.org/jira/browse/MATH-349
you cannot always use the getters/setters, namely in contructors.

I don't have a broad view of CM yet, but in principle I'd think it's better
to avoid synchronization at the CM level, and rather push toward
immutability.
E.g. do we loose performance significantly if we have to instantiate a new
"NormalDistributionImpl" for each combination of "mean" and "sigma" instead
of calling "setMean(m)" and "setStandardDeviation(s)" on an exisitng object?
[A few months ago, people here convinced me that we don't, in the case of
"Vector3D".]

> >  Moreover, if, by mistake, a sub-class overrides the accessor, you can get
> >  inconsistent result: the overridden accessor can return some value while it
> >  is another (the one stored in the instance variable) that is used to perform
> >  the calculation.
>
> If there is a good reason to override the getter/setter, then it is
> likely that the sub-class wants the new value to be used throughout.

Can you imagine a not contrived example? I.e. why would one inherit from a
class while throwing away the implementation?


Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

sebb-2-2
On 05/03/2010, Gilles Sadowski <[hidden email]> wrote:

> Hi.
>
>
>  > >  > I don't see any changes proposed.
>  > >
>  > >
>  > > I propose to use the instance variable in place of the accessor.
>  > >
>  > >
>  > >  > I see a couple of statements that getters are used (usually considered
>  > >  > good), and a question about over-riding.
>  > >
>  > >
>  > > Getters are for accessing to encapsulated data. Within the class itself the
>  > >  data is readily accessible, so using the accessor is, at best, less
>  > >  efficient.
>  >
>  > Not necessarily - if it turns out that the field needs to be
>  > synchronized, then always using the getter/setter rather than direct
>  > access makes it very easy to fix the problem.
>
>
> As I note in
>   https://issues.apache.org/jira/browse/MATH-349
>  you cannot always use the getters/setters, namely in contructors.

That is a separate issue.
It is possible to overload methods called by a constructor, but it is
easy to get it wrong.

>  I don't have a broad view of CM yet, but in principle I'd think it's better
>  to avoid synchronization at the CM level, and rather push toward
>  immutability.
>  E.g. do we loose performance significantly if we have to instantiate a new
>  "NormalDistributionImpl" for each combination of "mean" and "sigma" instead
>  of calling "setMean(m)" and "setStandardDeviation(s)" on an exisitng object?
>  [A few months ago, people here convinced me that we don't, in the case of
>  "Vector3D".]
>
>
>  > >  Moreover, if, by mistake, a sub-class overrides the accessor, you can get
>  > >  inconsistent result: the overridden accessor can return some value while it
>  > >  is another (the one stored in the instance variable) that is used to perform
>  > >  the calculation.
>  >
>  > If there is a good reason to override the getter/setter, then it is
>  > likely that the sub-class wants the new value to be used throughout.
>
>
> Can you imagine a not contrived example? I.e. why would one inherit from a
>  class while throwing away the implementation?

It's precisely to keep the implementation that the parent needs to use
the getter.

If the parent does not use the getter, then the sub-class will have to
re-implement the parts of the parent code that don't use the
(overloaded) getter.

>
>  Best,
>  Gilles
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Ted Dunning
In reply to this post by Gilles Sadowski
Well, the exponential, chi^2 and Maxwell-Boltzman distributions are all
specializations of the gamma distribution.

If you working on a Monte-carlo estimate where the parameters of your chi^2
distribution vary according to a hyper-distribution, then it would be nice
to implement the chi^2 distribution by changing the getter's for the two
parameters of the Gamma distribution to get the specialized values.  Then it
would be nice to implement the generalized hyper-distributed chi^2 by
over-riding the getters for the parameters of the chi^2 distribution to
sample from the hyper-distribution.

If you use getters throughout, then chi^2 is nearly a one-liner, the
hyper-distributed chi^2 is another one-liner.  The JIT will optimize away
all of the abstractions and give a result that is as fast as any other
implementation.

You can complain that this example is contrived, but an over dispersed
exponential is a common concept and is best described in this same fashion.

It might be that you could do all of this eagerly, having the hyper-chi^2
instantiate a new chi^2 which instantiates a new gamma for ever sample, but
then everybody has to be injecting a random number generator up and down the
chain (because those *are* often heavyweight and can't be instantiated
cheaply).  Over-riding the getters is way cleaner when you need to
implement.

On Fri, Mar 5, 2010 at 1:56 PM, Gilles Sadowski <
[hidden email]> wrote:

> Can you imagine a not contrived example? I.e. why would one inherit from a
> class while throwing away the implementation?
>



--
Ted Dunning, CTO
DeepDyve
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Gilles Sadowski
Hi.

> Well, the exponential, chi^2 and Maxwell-Boltzman distributions are all
> specializations of the gamma distribution.
>
> If you working on a Monte-carlo estimate where the parameters of your chi^2
> distribution vary according to a hyper-distribution, then it would be nice
> to implement the chi^2 distribution by changing the getter's for the two
> parameters of the Gamma distribution to get the specialized values.  Then it
> would be nice to implement the generalized hyper-distributed chi^2 by
> over-riding the getters for the parameters of the chi^2 distribution to
> sample from the hyper-distribution.
>
> If you use getters throughout, then chi^2 is nearly a one-liner, the
> hyper-distributed chi^2 is another one-liner.  The JIT will optimize away
> all of the abstractions and give a result that is as fast as any other
> implementation.

Sorry, I don't follow you. Could you give a code example of these
one-liners?

> [...]

Thanks,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Gilles Sadowski
In reply to this post by sebb-2-2
> > Can you imagine a not contrived example? I.e. why would one inherit from a
> >  class while throwing away the implementation?
>
> It's precisely to keep the implementation that the parent needs to use
> the getter.
>
> If the parent does not use the getter, then the sub-class will have to
> re-implement the parts of the parent code that don't use the
> (overloaded) getter.

By "implementation" I meant the instance variable in the base class. If the
getter returns another value, then this base class instance variable has
become useless, obviously.
But I'm not sure that we talk about the same thing...

I mean the following situation:
---
public class A {
  private double a;

  public double getA() {
    return a;
  }
}
---
Then you might want to override the getter while still relying on the base
implementation (i.e. calling the base class getter so that both getters
actually refer to the same variable):
---
public class SubA extends A {
  private Logger log = Logger.getLogger(SubA.class);
  public double getA() {
    log.debug("getA()");
    return super.getA();
  }  
}
---
But I don't understand this:
---
public class AnotherSubA extends A {
  private double subA;

  public double getA() {
    return subA;
  }  
}
---
This looks more like hijacking rather than extending the base class... ;-)

Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Ted Dunning
In reply to this post by Gilles Sadowski
Here is one.  The goal is to provide an over-dispersed exponential
distribution which is defined as an exponential distribution with a prior
distribution on the lambda parameter.

/**
 * Sample from an exponential distribution whose parameter is distributed
according
 * to a Gamma distribution.
 */
public class UncertainExponentialDistribution extends
ExponentialDistribution {
    private Gamma prior;

    public UncertainExponentialDistribution(double alpha, double beta) {
        prior = new Gamma(alpha, beta);
    }

    public double getLambda() {
        return prior.next();
    }
}

Doing this with an immutable super class is a royal pain in the ass.  Doing
this with setters on lambda isn't sooo bad, but it really obscures the real
point which is that the over-dispersed exponential distribution is *exactly*
an exponential distribution but lambda varies.  The implementation above
says exactly that.

So what about the layer below?  The exponential can be defined as a
specialized Gamma which benefits from the same sort of idiom (yes I know
that this distribution can be implemented as -lambda * log(1-rand()), but we
are talking principles here, not specifics).

public class ExponentialDistribution extends AbstractDistribution {
    private double lambda;

    private Gamma wrapped;

    public ExponentialDistribution() {
    }

    public ExponentialDistribution(double lambda) {
        this.lambda = lambda;
        wrapped = new Gamma(1, 1 / lambda) {
            @Override
            public double getAlpha() {
                return 1;
            }

            @Override
            public double getBeta() {
                return 1 / getLambda();
            }
        };
    }

    public double next() {
        return wrapped.next();
    }

    /**
     * Default implementation of this getter just returns the value we
know.  Sub-classes
     * might over-ride this for special effects.
     * @return
     */
    public double getLambda() {
        return lambda;
    }
}

Again, we have clarity of expression.  The phrase "gamma distribution with
alpha = 1 and beta = 1/lambda" is just what is in the code here.  You
*could* do this with setters, but at considerable loss of clarity and no
gain in efficiency.

On Fri, Mar 5, 2010 at 3:51 PM, Gilles Sadowski <
[hidden email]> wrote:

> Sorry, I don't follow you. Could you give a code example of these
> one-liners?
>



--
Ted Dunning, CTO
DeepDyve
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Phil Steitz
In reply to this post by Luc Maisonobe
[hidden email] wrote:

> ----- "Gilles Sadowski" <[hidden email]> a écrit :
>
>> Hello.
>>
>> I'm ready to make the changes proposed in
>>   https://issues.apache.org/jira/browse/MATH-348
>
> Hi Gilles,
>
> Sorry, I forgot to comment on the issue. I agree with you, go ahead with the changes.
>


+0

Sorry to be late to the party on this.  I suspect the reason for
encapsulating getters originally for distribution parameters was to
allow implementations to compute them from internal state, which
might not map directly to distribution parameters.  This is the case
for some of the other distributions not listed in the ticket. Look,
for example, at how ChisquareDistributionImpl implements
getDegreesOfFreedom.  Changing implementations so parameters are not
stored in instance fields for the classes above after this change
will require that the change be reverted.  With contemporary JDKs, I
am not sure the performance impact is worth considering.  Overrides
should not cause a problem unless they incorrectly compute the
parameters, which are all defined (some better than others ;) in the
interface documentation.

I am OK with the change, but do not see it as necessary.

Phil


> Luc
>
>> Any objection?
>>
>> Best,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Phil Steitz
In reply to this post by Gilles Sadowski
Gilles Sadowski wrote:

> Hi.
>
>>>  > I don't see any changes proposed.
>>>
>>>
>>> I propose to use the instance variable in place of the accessor.
>>>
>>>
>>>  > I see a couple of statements that getters are used (usually considered
>>>  > good), and a question about over-riding.
>>>
>>>
>>> Getters are for accessing to encapsulated data. Within the class itself the
>>>  data is readily accessible, so using the accessor is, at best, less
>>>  efficient.
>> Not necessarily - if it turns out that the field needs to be
>> synchronized, then always using the getter/setter rather than direct
>> access makes it very easy to fix the problem.
>
> As I note in
>   https://issues.apache.org/jira/browse/MATH-349
> you cannot always use the getters/setters, namely in contructors.
>
> I don't have a broad view of CM yet, but in principle I'd think it's better
> to avoid synchronization at the CM level, and rather push toward
> immutability.
> E.g. do we loose performance significantly if we have to instantiate a new
> "NormalDistributionImpl" for each combination of "mean" and "sigma" instead
> of calling "setMean(m)" and "setStandardDeviation(s)" on an exisitng object?
> [A few months ago, people here convinced me that we don't, in the case of
> "Vector3D".]

This is a separate issue, as you point out.  I am +1 on deprecating
the setters so these all become immutable in 3.0.

Phil

>
>>>  Moreover, if, by mistake, a sub-class overrides the accessor, you can get
>>>  inconsistent result: the overridden accessor can return some value while it
>>>  is another (the one stored in the instance variable) that is used to perform
>>>  the calculation.
>> If there is a good reason to override the getter/setter, then it is
>> likely that the sub-class wants the new value to be used throughout.
>
> Can you imagine a not contrived example? I.e. why would one inherit from a
> class while throwing away the implementation?
>
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Ted Dunning
Making these immutable will be a real pain as demonstrated by the
over-dispersed exponential example.  In particular, to maintain performance,
it would require that all constructors be arranged to allow injection of a
random number generator.  Management of that would be a nasty code issue.
Better to just allow the parameters to be changed so that a user can ignore
the issue of which PRNG is used.


On Sat, Mar 6, 2010 at 7:32 AM, Phil Steitz <[hidden email]> wrote:

> This is a separate issue, as you point out.  I am +1 on deprecating
> the setters so these all become immutable in 3.0.
>



--
Ted Dunning, CTO
DeepDyve
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Gilles Sadowski
In reply to this post by Ted Dunning
Hello.

> Here is one.  The goal is to provide an over-dispersed exponential
> distribution which is defined as an exponential distribution with a prior
> distribution on the lambda parameter.
>
> /**
>  * Sample from an exponential distribution whose parameter is distributed
> according
>  * to a Gamma distribution.
>  */
> public class UncertainExponentialDistribution extends
> ExponentialDistribution {
>     private Gamma prior;
>
>     public UncertainExponentialDistribution(double alpha, double beta) {
>         prior = new Gamma(alpha, beta);
>     }
>
>     public double getLambda() {
>         return prior.next();
>     }
> }
>
> Doing this with an immutable super class is a royal pain in the ass.  Doing
> this with setters on lambda isn't sooo bad, but it really obscures the real
> point which is that the over-dispersed exponential distribution is *exactly*
> an exponential distribution but lambda varies.  The implementation above
> says exactly that.
>
> So what about the layer below?  The exponential can be defined as a
> specialized Gamma which benefits from the same sort of idiom (yes I know
> that this distribution can be implemented as -lambda * log(1-rand()), but we
> are talking principles here, not specifics).
>
> public class ExponentialDistribution extends AbstractDistribution {
>     private double lambda;
>
>     private Gamma wrapped;
>
>     public ExponentialDistribution() {
>     }
>
>     public ExponentialDistribution(double lambda) {
>         this.lambda = lambda;
>         wrapped = new Gamma(1, 1 / lambda) {
>             @Override
>             public double getAlpha() {
>                 return 1;
>             }
>
>             @Override
>             public double getBeta() {
>                 return 1 / getLambda();
>             }
>         };
>     }
>
>     public double next() {
>         return wrapped.next();
>     }
>
>     /**
>      * Default implementation of this getter just returns the value we
> know.  Sub-classes
>      * might over-ride this for special effects.
>      * @return
>      */
>     public double getLambda() {
>         return lambda;
>     }
> }
>
> Again, we have clarity of expression.  The phrase "gamma distribution with
> alpha = 1 and beta = 1/lambda" is just what is in the code here.  You
> *could* do this with setters, but at considerable loss of clarity and no
> gain in efficiency.

I must say that I don't understand the example.
Is it based on anything in CM?  I don't see a method "next()" anywhere...
You say that it can't be done with an immutable super-class but nothing is
mutable in the above (or is it precisely "next()" that is altering the
content of the undefined "Gamma" class?).
I don't understand why the "wrapped" variable has an overridden "getAlpha()"
since it actually returns 1 and it is the first parameter passed to the
constructor (which is what the accessor in the base class is supposed to
return).
All of this is quite unclear to me, so that I can't even judge what
functionality would be useful (and how it could perhaps be achieved in some
other way). Maybe it would make more sense if I could run a working example.

Sorry,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Ted Dunning
Hmm... no this is not dependent on CM.  This is an example that I wrote in 3
minutes to illustrate the point.

I think the confusion is that I assumed that commons.math distributions
supported sampling.  I don't think that capability is available even now
(although a user contributed patches months ago to do that).  My example is
geared towards that.

The problem is probably mine.  I haven't been using commons math since the
Mahout project decided that it wasn't usable for our needs and I assumed
that this basic capability was available.

If distributions are viewed only as a pure function that computes the
density and cumulative distribution function, then what I say has no
utility, but then again, without sampling distributions are also much less
useful.

On Sat, Mar 6, 2010 at 3:42 PM, Gilles Sadowski <
[hidden email]> wrote:

> I must say that I don't understand the example.
> Is it based on anything in CM?  I don't see a method "next()" anywhere...
> You say that it can't be done with an immutable super-class but nothing is
> mutable in the above (or is it precisely "next()" that is altering the
> content of the undefined "Gamma" class?).
> I don't understand why the "wrapped" variable has an overridden
> "getAlpha()"
> since it actually returns 1 and it is the first parameter passed to the
> constructor (which is what the accessor in the base class is supposed to
> return).
> All of this is quite unclear to me, so that I can't even judge what
> functionality would be useful (and how it could perhaps be achieved in some
> other way). Maybe it would make more sense if I could run a working
> example.
>



--
Ted Dunning, CTO
DeepDyve
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Gilles Sadowski
Hello.

> Hmm... no this is not dependent on CM.  This is an example that I wrote in 3
> minutes to illustrate the point.
>
> I think the confusion is that I assumed that commons.math distributions
> supported sampling.  I don't think that capability is available even now
> (although a user contributed patches months ago to do that).  My example is
> geared towards that.

Where has this patch gone?

> The problem is probably mine.  I haven't been using commons math since the
> Mahout project decided that it wasn't usable for our needs and I assumed
> that this basic capability was available.
>
> If distributions are viewed only as a pure function that computes the
> density and cumulative distribution function, then what I say has no
> utility, but then again, without sampling distributions are also much less
> useful.

So, maybe this should be the starting point: adding this feature to the
distribution classes. Which gets back to the above question...

Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Phil Steitz
Gilles Sadowski wrote:

> Hello.
>
>> Hmm... no this is not dependent on CM.  This is an example that I wrote in 3
>> minutes to illustrate the point.
>>
>> I think the confusion is that I assumed that commons.math distributions
>> supported sampling.  I don't think that capability is available even now
>> (although a user contributed patches months ago to do that).  My example is
>> geared towards that.
>
> Where has this patch gone?
>
>> The problem is probably mine.  I haven't been using commons math since the
>> Mahout project decided that it wasn't usable for our needs and I assumed
>> that this basic capability was available.
>>
>> If distributions are viewed only as a pure function that computes the
>> density and cumulative distribution function, then what I say has no
>> utility, but then again, without sampling distributions are also much less
>> useful.
>
> So, maybe this should be the starting point: adding this feature to the
> distribution classes. Which gets back to the above question...

The sampling patch is in MATH-310, but this is irrelevant to the
question of whether or not to deprecate the property setters.

I am -1 on implementing the patch in MATH-310 as provided.  This
functionality belongs in the random package, where it already exists
for some distributions. Inversion is just one way to generate
deviates and including a potentially bad impl with every
distribution is not a good idea, IMO, beyond the issue of separation
of concerns.  See discussion here, where I suggested an alternative
way to extend to other distributions:

http://markmail.org/message/kolivuytbt5cj25s

It is on my todo list to resolve MATH-310 by implementing the
extension to RandomData described there.  Patches, alternatives
welcome.  I am open to alternatives, but I will need clear, simple,
practical arguments explaining why it is not bad separation of
concerns to duplicate all of this into the distributions classes
themselves, or a good argument for why we should deprecate the
random package.

Phil




>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Ted Dunning

I think we had that discussion.  I provided examples of other packages  
considered sampling to be a key property of a distribution, how users  
of these packages expected to be able to sample from distributions.  
Others concurred. You vetoed the contribution.

Doesn't bother me that much personally for that style of development  
to happen with commons math since we have just replaced commons math  
with other code.  My guess is that other potential contributors have  
also wandered off as well for similar reasons.

On Mar 7, 2010, at 2:40 PM, Phil Steitz <[hidden email]> wrote:

>  I am open to alternatives, but I will need clear, simple,
> practical arguments explaining why it is not bad separation of
> concerns to duplicate all of this into the distributions classes
> themselves

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Issue 348

Gilles Sadowski
Hello.

On the basis of the KISS principle, I still think that the change is
reasonable.
The strongest argument against it is based on a construction that is
currently impossible since it assumes a yet non-existent "nextSample()"
method. After that other issue (MATH-310) is resolved, we can come back to
the feature described by Ted, and I'll be willing to change back again if
necessary.
Is that OK?

Best regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12