Brett Porter wrote:
Please let me know if:
[ ] you would like the project set up on the new machine with a clean slate
+1
[ ] you would like the project (and it's build history if possible)
moved over
[ ] you are no longer interested in using vmbuild for CI/nightlies/whatever
Thanks, Brett
[
https://issues.apache.org/jira/browse/MATH-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511356
]
Luc Maisonobe commented on MATH-160:
The applied fix added new public methods to the interface. This is considered
Phil Steitz (JIRA) wrote:
[
https://issues.apache.org/jira/browse/MATH-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510905
]
Phil Steitz commented on MATH-167: --
Thanks for reporting this. I see three alternatives
[ ] +1, don't let Rahul get away - lets try to get him to join the new PMC
[ ] -1, no leave him out
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ ] +1, don't let Simon get away - lets try to get him to join the new PMC
[ ] -1, no leave him out
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Torsten Curdt a écrit :
But seriously: be realistic. Those people building the releases from
will have subversion on their machine. And what can be simpler than a
one-liner to checkout the sources? Even downloading it from an apache
mirror is more work.
People may have subversion but may not
Torsten Curdt wrote:
See above ...I think subversion is our source distribution. I don't
really see a point in providing a classic source distribution. But
maybe that's too much change for now ;)
Yes, too much for me at least. In theory, voting on a tag and
pointing users there to get
[EMAIL PROTECTED] wrote:
+/**
+ * Modify the normal distribution used to compute normal approximations.
+ * The caller is responsible for insuring the normal distribution has the
+ * proper parameter settings.
+ * @param value the new distribution
+ * @since 1.2
+
Phil Steitz wrote:
I updated the 1.2 release plan here:
http://wiki.apache.org/jakarta-commons/math/1%2e2ReleasePlan
I have also completed the maven 2 build and regenerated the web site
with up to date reports.
http://jakarta.apache.org/commons/math/
Pls all interested parties have a
[
https://issues.apache.org/jira/browse/MATH-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-156.
Resolution: Fixed
Fix Version/s: (was: 1.2)
Nightly Builds
fixed
[EMAIL PROTECTED] wrote:
Javadoc. Replaced MathML entity with numeric character reference.
I thought the sqrt; entity was allowed since it is an HTML 4.0 entity.
A quick check showed I also used alpha; delta; mu; pi; plusmn;
middot; and times;
Do you want me to fix these entities too ?
Luc
[
https://issues.apache.org/jira/browse/MATH-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496925
]
Luc Maisonobe commented on MATH-165:
This seems a great idea to me. It could be easily implemented for 1.2 we
[
https://issues.apache.org/jira/browse/MATH-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe updated MATH-165:
---
Fix Version/s: 1.2
Simplify use of EstimationProblem
Phil Steitz [EMAIL PROTECTED] wrote:
I think that modulo some cleanup, testing and review and the one
dangling item below, we should be ready for a [math] release.
I first wanted to introduce SVD but now think I need to work more on this. This
would delay a release for quite long. I therefore
[
https://issues.apache.org/jira/browse/MATH-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494375
]
Luc Maisonobe commented on MATH-164:
I confirm the issue. Currently, the multiplication operator is implemented
Phil Steitz wrote:
As we ramp up to a 1.2 release, I think its a good idea to move to
Maven 2 as the standard build. That means deprecating the m1 build
(leaving in the 1.2 release, if possible), moving the site and
nightlies, etc.
Lets view this as lazy consensus - i.e., scream now or
Phil Steitz wrote:
I have also been looking at the *great* progress getting the
Mantissa stuff in and will propose that we move to a 1.2 release.
Looks about ready to bundle up in terms of contents previously
discussed, other than the setter injection stuff that I will add. Do
you feel like
Phil Steitz wrote:
Yeah, assuming the m2's work. Its probably best in each case to post
something like
[foo] moving to m2
and make sure that nobody screams, all are OK with the pom can get the
build to work, etc., before moving the associated nightly and
deprecating the m1 build (to be
[
https://issues.apache.org/jira/browse/MATH-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478135
]
Luc Maisonobe commented on MATH-82:
---
The FractionFormatTest patch has been applied almost one year ago.
The problem
[EMAIL PROTECTED] wrote :
Modified: jakarta/commons/proper/math/trunk/pom.xml
[snip]
- nameJörg Weimar/name
+ nameJ�rg Weimar/name
It seems the name of this contributor get corrupted when I checked in
the pom file after modifying unrelated lines. The XML header does not
specify
I have started to commit some Mantissa parts into commons-math. I'm
sorry about the spam concerning these messages. It seems I messed
something with my client which did not identify some simple moves and
instead considered new files were created from scratch :-(
I still have two important
Rahul Akolkar wrote :
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/MaxIterationsExceededException.java
(with props)
snip/
This file, and a few others added today are missing license headers.
Please add them.
Ooops. Sorry. Fixed.
J.Pietschmann wrote :
Looks like there have been line ending issues. The overview shows the
prop changes as well. I've got the proper line endings here after svn
up, but could you double check everything is ok on your side as well?
Everything seems OK here, both at editor level and running
Rahul Akolkar wrote :
On 2/12/07, Luc Maisonobe [EMAIL PROTECTED] wrote:
Yes, it seems many files have strange settings. I use a Linux box and on
a fresh checkout, I get some files with DOS-like line endings. If I set
them to a line ending compliant with my local host, then set the
property
Phil Steitz wrote :
The problem with that is that generic handlers that display messages would
not work. I like the idea of carrying the data along, though and exposing
it, as well as providing translate (see
Phil Steitz wrote :
My recommendation is that we just modify the Mantissa class to
expose the key and parts (so add members for them) and add
getMessage(Locale). That is simple, not far from what we already have, and
sufficient to meet localization needs and support other sorts of processing
Craig McClanahan wrote:
I'm late to the table on this thread, and only care about the Commons
libraries I care about :-)
Thanks for your interest in this thread.
but you should be aware that this attitude will
disqualify the use of such libraries from use within code from organizations
Selon Jörg Schaible [EMAIL PROTECTED]:
you cannot build a common
library with meaningful exception messages (or log entries) that really makes
sense for a user in the context of an application that builds on it.
This is often true, in this case the exception is caught by some middle layer
Concluding the thread.
Adding localization to exception is considered a wrong move by most people.
Adding an API to allow localization to be performed at application level
is a good way but implies probably both a large number of classes and a
large number of new methods (for example Mantissa
Hello,
As a non-native english speaker, I am quite eager to provide users with
libraries that can be embedded seemlessly into localized applications.
This implies that either the getMessage() and getLocalizedMessages() of
Exception instances provide two different messages, or that the
Stephen Colebourne a écrit :
I disagree strongly with the whole concept of localized exception
messages. Localization for users yes, but developers no.
[snip]
IMO, a localized application actually means localization for users, and
implies nothing for developers.
I agree with both your
Hello,
I just realized recently that not all commits to the subversion base
generated mails to the dev list.
Since the repository is also shared by other Apache projects outside of
commons, I thought there was some filter for commons, based for example
on directories tree structure.
Stephen Colebourne wrote:
I include the binary jar file in the source distribution as I want to
ensure that the maximum number of people possible get the genuine binary
jar as created by us and no-one else (eg. minimises JDK1.3 vs JDK1.6 issues)
[snip]
I include the source zip in the
Selon Phil Steitz [EMAIL PROTECTED]:
We have added a lot of new functionality to [math] since the 1.1
release, and Mantissa includes quite a bit more. We need a 1.2
release plan, incorporating some elements of Mantissa. Here is a
straw man - please any and all jump in to comment and most of
: Luc Maisonobe
Priority: Trivial
I have released Mantissa 7.0 recently.
The mantissa version that is being integrated into commons-math is based on
version 6.4.
Version 7.0 is safer since many low level small objects are now guaranteed to
be completely immutable, so commons-maths
[ http://issues.apache.org/jira/browse/MATH-162?page=all ]
Luc Maisonobe updated MATH-162:
---
Attachment: mantissa.patch
this patch updates the mantissa components that are in the commons-math source
tree to version 7.0 of mantissa
update to mantissa 7.0
[ http://issues.apache.org/jira/browse/MATH-161?page=all ]
Luc Maisonobe updated MATH-161:
---
Attachment: mantissa.patch
the patch by itself
patch for Mantissa
--
Key: MATH-161
URL: http
An issue has been identified in the Mantissa 6.3 version that was used
as a base for the code base I donated some time ago. I have set up a
patch that should fix the issue in this base. Should I send it directly
to the list (it is 24k uncompressed) or to someone else (Phil) ?
The problem was
Phil Steitz a écrit :
Luc,
I am about to commit the code. Actually was working on that when I
saw this. Once I have the code in, submit the patch against the code
in svn.
Here is the patch. I hope it is not too large to be submitted through
this list. If anybody is upset with this, please
someone said:
So what does a major version mean? Surely a major version means
we have changed the code so it is no longer compatible, you cannot
upgrade simlpy and easily
This may or may not be true and it also depend on how the product is
used. Some power users may consider an apparent
[
http://issues.apache.org/jira/browse/MATH-160?page=comments#action_12442651 ]
Luc Maisonobe commented on MATH-160:
I'm affraid code from any of the Numerical Recipes book cannot be included in
commons-math.
See the redistribution
[
http://issues.apache.org/jira/browse/MATH-60?page=comments#action_12442653 ]
Luc Maisonobe commented on MATH-60:
---
doesn't the answers provided by Phil Steitz suit you ? This issue is marked as
closed, do you want to reopen it ?
[math
Kevin Jackson a écrit :
Adding these would greatly simplify my current code, or if anyone
knows how to get the mantissa without resorting to String manipulation
- even using x * 10^mantissaLength % 10^mantissaLength /
10^mantissaLength is fairly nasty in client code (and you get rounding
errors
Hello,
As I have stated one week ago, I have reviewed Mantissa classes with
respect to the IP issues. Henri Yandell thought the Minpack and Hairer
licenses were acceptable and nobody in the legal list stated otherwise
during the week.
So I have set up an archive containing all the classes,
Hello,
As mentioned a few times on this list, I have proposed to donate the
Mantissa (http://www.spaceroots.org/software/mantissa/index.html) code
to Apache and continue maintaining it here along with commons math.
Almost everything has been both designed and coded by me, so I was able
to
Henri Yandell wrote :
It looks like the Minpack license is a BSD license with an extended
warranty and liability section. I'll ping the legal-discuss mailing
list about it, but it looks fine to me. Just some government
boilerplate tacked onto a BSD license I think.
Thanks. I'm not subscribed
Thanks for your suggestion, Tyler, it looks interesting to me.
Could you however put it as a request for enhancement in Jira, this
would help not forgetting it before time to implement it is found. The
same remark applies to your other suggestion about SVD.
Thanks again,
Luc
Tyler Ward wrote
Hello,
Are there customisation files available (formatter profile, editor
preferences, templates ...) for the Eclipse IDE tailored to the commons
style ?
Luc
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Hello,
Following this week discussion about copyright issues in math code, I think two
more Mantissa classes should not be included as is to commons-math code. I
really did write them myself but took inspiration from existing code, not only
texbooks. The first class is the Gragg-Bulirsch-Stoer
Phil Steitz [EMAIL PROTECTED] wrote:
Commit diffs are not spam, IMO, nor are issue reports / comments.
This is core to what is happening on a project.
This is true for someone deeply involved in the project life, but may be
overwhelming for someone who only wants to keep an eye on the
Tyler Ward wrote :
Hi guys, I haven't sent mail to this list before. I've noticed that apache
doesn't have an SVD algorithm, so I put one together. Are you guys
interested?
As far as I am concerned, yes.
More specifically, the householder transformation is absolutely naieve,
Perhaps we
Tyler Ward wrote :
Hi guys, I haven't sent mail to this list before. I've noticed that
apache
doesn't have an SVD algorithm, so I put one together. Are you guys
interested?
By the way, could you add [math] as a marker in your subject for this
list (I forgot to fix it in my previous mail,
Selon Phil Steitz [EMAIL PROTECTED]:
I am still -0 on adding a separate stateful
impl, but could be convinced if others feel differently and someone is
willing to volunteer to research, code, doc and write tests for it.
I have no personal opinion on this subject. I only think that if users
J.Pietschmann wrote :
Well, the majority of the num math text books on my shelf actually
recommend computing the sum of the squared errors instead of the
algebraic equivalent form given in the more analytically oriented
text books (and used above). This is, of course, more complicated
and still
[
http://issues.apache.org/jira/browse/MATH-85?page=comments#action_12419184 ]
Luc Maisonobe commented on MATH-85:
---
The problem is related to computation accuracy in a corner case.
The data (110.7178495, 8915.102), (110.7264895, 8919.302), (110.7351295
[ http://issues.apache.org/jira/browse/MATH-85?page=all ]
Luc Maisonobe updated MATH-85:
--
Attachment: math-85.patch
patch adding a test case for issue MATH-85
[math] SimpleRegression getSumSquaredErrors
Phil Steitz (JIRA) a écrit :
I agree this is a corner case and the negative result is due to rounding. The question is, should we force the result to 0 when a negative value is returned by the computation?
Yes, I think this would be wiser than what I said in my previous
comment. I forgot
Martin van den Bemt wrote :
I read somewhere that linux will speed up doing encryption when eg the
keyboard is used (those tokens are used in the linux SecureRandom
generator.
It is true when the generator is based on bytes read from the
/dev/random device, false when /dev/urandom device is
[ http://issues.apache.org/jira/browse/MATH-151?page=all ]
Luc Maisonobe updated MATH-151:
---
Attachment: math-151.patch
This patch is an attempt to solve the issue.
The principle is to add a nexAfter method in MathUtils and to use it in order
to very
[
http://issues.apache.org/jira/browse/MATH-151?page=comments#action_12416287 ]
Luc Maisonobe commented on MATH-151:
I was looking for a way to characterize those bad IEEE754 representations.
Here is one proposal:
we could had an implementation
[
http://issues.apache.org/jira/browse/MATH-151?page=comments#action_12415733 ]
Luc Maisonobe commented on MATH-151:
The point is neither on the rounding method not on the scale factor, it is
rather on the initial number itself.
39.245 has no exact
[
http://issues.apache.org/jira/browse/MATH-151?page=comments#action_12415048 ]
Luc Maisonobe commented on MATH-151:
I think this behaviour is normal.
Despite 39.245 has a finite representation in decimal, this is not true in base
2, it has a infinite
Selon Phil Steitz [EMAIL PROTECTED]:
First, thanks for your interest in joining forces.
You're welcome.
So if your
interest is in bringing in code and maybe more contributors and
working on it here, then that will be great.
This is what I want, contributing. Mantissa is one of my pet
Hello,
I am the creator of the Mantissa library
(http://www.spaceroots.org/software/mantissa/index.html), a Java library
providing some mathematical algorithms.
Mantissa provides several algorithms that could be useful for
Commons-Math. I think the objectives of the two libraries are quite
Luc Maisonobe wrote :
I don't think everything in Mantissa is useful for Commons-Math. IMHO,
the most interesting parts are :
- the estimation package
Gauss-Newton estimator (based on LU decomposition),
Levenberg-Marquardt estimator (based on QR decomposition)
- the fitting package
Beyond what is available in the API (Q and R), what exactly does the
QR Decomp know that makes solving easier?
foreword :
what is stated below is oriented only for least squares problems, it is
not a general discussion about decomposition algorithms.
When using QR decomposition in least
66 matches
Mail list logo
