I have the same reservations about creating a dependency. Paul Houle
however, has been very open minded in the past and would donate it
officially to Apache if necessary. It may be simpler just to acquire
the whole RngPack source into the math tree and rename the packages so
its embedded in
Phil Steitz wrote:
No, you are not missing anything. What you are suggesting should
work fine, with similar change for getResult.
A little nit -- I would prefer to use a boolean for the property
(unless there are more than two values) and not rely on the *value*
of the int constant
Hi Phil,
I guess my inclination at this point is to make the property
boolean-valued for Variance, StandardDeviation and omit it altogether
(for now) for Skewness and Kurtosis. Is everyone OK with this?
I can live with this. For the time being, I have no good examples in
which anything else than
Kim van der Linde wrote:
Mark R. Diggory wrote:
This is the sort of thing that defeats the purpose of having the
RealMatrix package. Such computations could be used to abuse the
contents of the internal data structure effectively breaking the
original Matrix.
We need a more OO strategy for
Can you give us an example of your solution?
-Mark
Kim van der Linde wrote:
Kim van der Linde wrote:
Mark R. Diggory wrote:
This is the sort of thing that defeats the purpose of having the
RealMatrix package. Such computations could be used to abuse the
contents of the internal data structure
Yup, see here under (although it is a bit long). What I do is wait with
generating the matrix till it is needed, and I still do use the
getData() method, but do not need the getDataRef() anymore. If you want
to get rid of that too, I would be less happy with that.
This routine takles about 30
: [math] API changes for RC2
Phil Steitz wrote:
Spooky -- delightful word choice ;-) The getDataRef method is
there to limit copy operations and to support hacking the underlying
array -- evil, hazardous, breaks encapsulation
Phil Steitz wrote:
Spooky -- delightful word choice ;-) The getDataRef method is
there to limit copy operations and to support hacking the underlying
array -- evil, hazardous, breaks encapsulation --
... and every decent sparse matrix implementation will break its
implied semantics.
Make it
that we need to maintain it?
-Original Message-
From: Kim van der Linde [mailto:[EMAIL PROTECTED]
Sent: Mon 9/27/2004 11:21 AM
To: Jakarta Commons Developers List
Cc:
Subject: Re: [math] API changes for RC2
Phil Steitz wrote:
Spooky -- delightful word
Phil Steitz wrote:
No, you are not missing anything. What you are suggesting should
work fine, with similar change for getResult.
A little nit -- I would prefer to use a boolean for the property
(unless there are more than two values) and not rely on the *value*
of the int constant (flag) in
This is the sort of thing that defeats the purpose of having the
RealMatrix package. Such computations could be used to abuse the
contents of the internal data structure effectively breaking the
original Matrix.
We need a more OO strategy for capturing the requirements of your
example. I
Mark R. Diggory wrote:
This is the sort of thing that defeats the purpose of having the
RealMatrix package. Such computations could be used to abuse the
contents of the internal data structure effectively breaking the
original Matrix.
We need a more OO strategy for capturing the requirements
Phil Steitz wrote:
Henri Yandell wrote:
Some thoughts from a general Commons perspective:
Thanks!
1) +0, This is worth getting right early on as package renaming does
tend to confuse users and takes a long time to work through
deprecation etc.
Ugh.. Lots of change incompatible with RC1
On Sun, 26 Sep 2004 00:41:33 -0400, Phil Steitz [EMAIL PROTECTED] wrote:
Phil Steitz wrote:
Henri Yandell wrote:
Some thoughts from a general Commons perspective:
Thanks!
1) +0, This is worth getting right early on as package renaming does
tend to confuse users and takes a
Phil Steitz wrote:
The following changes have been suggested recently. Before cutting 1.0
final, we should make sure we are all OK postponing or forgoing these:
1) Eliminate the univariate/multivariate distinction in the stat
package, because this seems confusing to some. Change .univariate
Mark R. Diggory wrote:
1) Eliminate the univariate/multivariate distinction in the stat
package, because this seems confusing to some. Change .univariate to
.descriptive and .multivariate to .regression
Univariate and Multivariate are just classifications. There is no
suggestion of changing
Phil Steitz wrote:
These are new feature
requests that came in after RC1 was cut and they can be accomodated in
1.1 without breaking backward compatability. I see no reason to hold the
release for this.
I have requested these weeks before the RC1 was cut.
Kim
--
http://www.kimvdlinde.com
Kim van der Linde wrote:
Phil Steitz wrote:
These are new feature requests that came in after RC1 was cut and they
can be accomodated in 1.1 without breaking backward compatability. I
see no reason to hold the release for this.
I have requested these weeks before the RC1 was cut.
Uh...no. The
Phil Steitz wrote:
Mark R. Diggory wrote:
1) Eliminate the univariate/multivariate distinction in the stat
package, because this seems confusing to some. Change .univariate to
.descriptive and .multivariate to .regression
Univariate and Multivariate are just classifications. There is no
Phil Steitz wrote:
Kim van der Linde wrote:
Phil Steitz wrote:
These are new feature requests that came in after RC1 was cut and
they can be accomodated in 1.1 without breaking backward
compatability. I see no reason to hold the release for this.
I have requested these weeks before the RC1
You are right. Blur of the mind.
Kim
Phil Steitz wrote:
Kim van der Linde wrote:
Phil Steitz wrote:
These are new feature requests that came in after RC1 was cut and
they can be accomodated in 1.1 without breaking backward
compatability. I see no reason to hold the release for this.
I have
Mark R. Diggory wrote:
Yes, I have no problem with .descriptive and .regression. Your correct
about the hierarchical decomposition, thats why if we can identify our
own policy for hierarchical decomp. then at least we have a clear
defense when package renaming is requested.
OK, I will get to
Kim van der Linde wrote:
You are right. Blur of the mind.
Kim
Happens to the best of us - daily ;-)
Like I said, the main point is to get to consensus on what we are
releasing. Your feedback and ideas are appreciated. I apologize for the
impatience -- which is not about the ideas, only getting
The following changes have been suggested recently. Before cutting 1.0
final, we should make sure we are all OK postponing or forgoing these:
1) Eliminate the univariate/multivariate distinction in the stat package,
because this seems confusing to some. Change .univariate to .descriptive
and
1) +1 (although I can see that some statistics (like PCA, factorial,
cluster analysis and so) might end up in a multivariate package).
2) +1
3) +0 (I can see that it might be more logical to implement it after
1.0, but them I would be in favour of dropping PNRG all together in this
release.)
4)
Some thoughts from a general Commons perspective:
1) +0, This is worth getting right early on as package renaming does
tend to confuse users and takes a long time to work through
deprecation etc.
2) -0. This is a new feature. If it's easy, add it. If it involves
effort, don't bother until 1.1.
Just to enhance my 4) bit, I'd advise dropping in this case and not
releasing this code if you plan to change the internal functionality.
If it's going to involve an API change with the new code though, go
ahead and release.
Hen
On Sat, 25 Sep 2004 23:02:57 -0400, Henri Yandell [EMAIL
Population variance and sample variances do only differ in the number
the summed difference (second moment) is divided through. The way I have
implemented it in my Variances class is by keeping the methods as they
are (I do believe setting the default to sample variances is right) and
Henri Yandell wrote:
Some thoughts from a general Commons perspective:
Thanks!
1) +0, This is worth getting right early on as package renaming does
tend to confuse users and takes a long time to work through
deprecation etc.
Ugh.. Lots of change incompatible with RC1 here...but if others agree...
Subject line says it all...what changes do we feel are necessary to get
1.0 out the door?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
30 matches
Mail list logo
