Re: Commons Math, Commons Nightlies, vmbuild
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 Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-160) Chi-Square Test for Comparing two binned Data Sets
[ 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 an incompatible API change by the clirr maven plugin which now fails when comparing with version 1.1. Should the next version been bumped to 2.0 ? Previous discussions on the version numbering missed the point with this issue. Chi-Square Test for Comparing two binned Data Sets -- Key: MATH-160 URL: https://issues.apache.org/jira/browse/MATH-160 Project: Commons Math Issue Type: New Feature Reporter: Matthias Hummel Priority: Minor Fix For: 1.2 Attachments: commons-math.patch Current Chi-Square test implementation only supports standard Chi-Square testing with respect to known distribution. We needed testing for comparison of two sample data sets where the distribution can be unknown. For this case the Chi-Square test has to be computed in a different way so that both error contributions (one for each sample data set) are taken into account. See Press et. al, Numerical Recipes, Second Edition, formula 14.3.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (MATH-167) ConvergenceException in normal CDF
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 to address - appreciate comments. 1) Determine tail resolution possible with current impl (hopefully not different on different JDKs, platforms) and top code, checking arguments and returning 0 or 1, resp if argument is too far in SD units from the mean. To find the cut points, empirically determine where convergence starts to fail. Document the cut points in javadoc for Impl. 2) Catch ConvergenceException and return 0 or 1, resp if argument is far from the mean; rethrow otherwise (though this should never happen). 3) Resolve as WONTFIX and leave it to client to catch and handle ConvergenceException, examining argument. Document algorithm more fully and warn that ConvergenceException will be thrown if tail probability cannot be accurately estimated or distinguished from 0. My first thought was 2 and I guess I still favor that, since 3) is inconvenient for users and 1) may not be stable unless cut points are conservative. Note that this same problem may apply to tail probablilities of other continuous distributions and we should check and address all of these before resolving this issue. I also think 2) is the better choice. I don't think finding the cut point for 1) is even feasible reliably for all JVM implementations, so 2) as the advantage of being self-adaptive. Another reason I like this is that this is really an exceptional case so exceptions are really suited to that, they should not be restricted to error handling only. Using them here is probably more efficient as it saves two a priori if statements that are really not needed most of the time. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Invite Rahul Akolkar to join the Apache Commons PMC
[ ] +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]
Re: [VOTE] Invite Simon Kitching to join the Apache Commons PMC
[ ] +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]
Re: [vote] releasing jci RC3 as 1.0 ...maybe this time?
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 be able to use it. For example, I cannot use svn (nor cvs for that matter) through my corporate firewall. Wait a sec - you cannot use http from your development machine? http is fine from browsers that handle proxy with username/password, https was allowed only recently and may be shut down at any time, svn, ssh, cvs pserver are all filtered. Configuring svn clients to handle proxy username/password is not straightforward. For command-line svn it is handled by the user configuration file for servers, not by command-line options. I don't know about graphical clients or IDE embedded clients. I also know another company where http filtering is more strict, with files without any extension suppressed, files with some extensions suppressed, files modified on the fly to comply with some rules, user-agent is checked to allow only certified browsers to connect ... For example on this network, these so called « security rules » prevented me from downloading security upgrades for Debian computers (which are simple binary files downloads on an http server) ... When I need a package that is only available by checking out from its repository, I have to check it out from home, put it on an USB stick and copy it the next day at work. It is very inconvenient. That's a truly sad story ...but we cannot provide a good solution for every awkward workplace. I agree this is weird and cannot be generalized. I also agree that in the Apache case, this can be circumvented as anonymous access to the subversion server is http-based. I only wanted to point out that since a version control system is not a publication system, using it for that purpose may be tough for some people. What would you think - how many percent of the developers that require to build a project from the source have no http access to the internet? Well, for jci I will personally send them a tar of the checkout - if they have email :-p I would only advise to have a simple and classical way to distribute: an archive on a web server people can retrieve using a web browser. Well, this is only my view and it is probably distorted, you can ignore it. regards, Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] releasing jci RC3 as 1.0 ...maybe this time?
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 sources still could be viewed as a release, but that is a big change from current practice and inconvenient for users who prefer to build from release sources. It is a big change ...but who says that changes are bad? ;) 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 be able to use it. For example, I cannot use svn (nor cvs for that matter) through my corporate firewall. When I need a package that is only available by checking out from its repository, I have to check it out from home, put it on an USB stick and copy it the next day at work. It is very inconvenient. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r545184 - /jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/PoissonDistributionImpl.java
[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
+ */
+public void setNormal(NormalDistribution value) {
+normal = value;
}
Should we check for null parameters here and throw a NPE ourselves or
simply allow null parameters and let the JVM throw the NPE when the
distribution is used ?
I am fine with the current choice of letting the JVM handle this by
itself, I only wondered what others think about this.
Luc
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Plan for 1.2 release
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 look at the release plan, look over / weigh in on the open issues and feel free to submit / commit patches to help move things along. I will play the RM role. I will update both the plan and the site to reflect progress as we go. Thanks! This looks fine for me. I will try to commit new explanation for the random vector generation and to reduce coberture/findbugs/checkstyle warnings and errors. I have not much time available for the few next weeks, but will do my best. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (MATH-156) Brent solver is non-optimal, because it doesn't use the user's guess.
[ 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 in SVN revision 536283 (checked in 2007-05-08) Brent solver is non-optimal, because it doesn't use the user's guess. - Key: MATH-156 URL: https://issues.apache.org/jira/browse/MATH-156 Project: Commons Math Issue Type: Improvement Reporter: Tyler Ward Assigned To: Luc Maisonobe Fix For: Nightly Builds Hi guys, I noticed that your brent solver isn't using the initial guess given by the user. This can often radically improve the performance of the solver. In my tests, it improved it by roughly 30% or more, with a decent guess. Basically, we should try the guess first. If that's close enough, rreturn it. Otherwise, try one of the end points. If that's close enough, return it. Then if that brackets, go into the main loop. If that doesn't bracket, then we instead try the other endpoint. If that's close enough, return it. If that doesn't bracket, throw an exception. If it does bracket, go into the main loop with all three trial points available, allowing the quadratic interpolation to be used immediately. Worst case scenario, the initial guess doesn't bracket. In that case it is better than the default algorithm only if the user's initial guess is better than linear interpolation, which I imagine it almost always would be. If the user can't guess better than linear interpolation, presumably they wouldn't provide a guess at all, and then nothing would change. It's a small addition, less than 100 lines of code. I can't send it in due to legal at work, but from the above ideas, you should be able to put it in easily. One caveat. You may need to slightly modify the baisic solve(double, double) method to linearly interpolate a good beginning point and then break out a six double (solve(x0, y0, x1, y1, x2, y2)) method that both solve(min, max) and solve(min, max, initial) can use. If you don't do this, then solve(min, max) will bisect on its first iteration rather than intepolating, which could cost performance. If you do break it out like so, then this will always perform better than the current implementation. As a good case study, here's our situation from work. We are trying to compute a root, we know it falls in a VERY large interval (in this case -1.0 to 1.0), but more than 99% of the time it will be between (say) 1.04 and 1.07. We can guess with stunning accuracy, at least 90% of the time we can come to within 10^-4 for very little cost (a very nice cubic approximation of the more complicated function), but we really need it to within 10^-8 or better. In addition, that 1% of the time, it can fall in very strange areas (0.9, or -0.3 or so), and our guess isn't very good when that happens. So we can't tighten down the interval, because that would cause spurious errors, and at the same time your linear interpolation isn't going to be very good at all. It easily takes you 3 or 4 steps to get as close as our first guess. Using the first guess in this manner would cut the steps to convergence from about 8-10 to about 3-5. A speed up of around 100%, with no loss in accuracy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r539909 - /jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/random/UniformRandomGenerator.java
[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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-165) Simplify use of EstimationProblem
[
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 are
going to release.
Simplify use of EstimationProblem
Key: MATH-165
URL: https://issues.apache.org/jira/browse/MATH-165
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Assigned To: Luc Maisonobe
Priority: Minor
The use of the EstimationProblem interface could be simplified by providing
a helper (abstract) class that would implement
the getMeasurements getAllParameters and getUnboundParameters methods.
Currently, each new implementation of the interface has to do it even if they
are typically only called from the Estimator class (and not by the user
code).
That same helper class could also take care of storing the partial
derivatives.
A skeleton for the requested class could be as follows:
public abstract class SimpleEstimationProblem
implements EstimationProblem {
// ... storage for measurements and partial derivatives ...
protected void addParameter(EstimatedParameter p,
ComputableFunction partial,
boolean isBound) {
// ...
}
protected void addParameter(EstimatedParameter p,
ComputableFunction partial) {
addParameter(p, partial, false);
}
protected double getPartial(EstimatedParameter p,
double x) {
// ...
}
protected void addMeasurement(WeightedMeasurement m) {
_observations.add(m);
}
public WeightedMeasurement[] getMeasurements() {
// ...
}
public EstimatedParameter[] getAllParameters() {
// ...
}
public EstimatedParameter[] getUnboundParameters() {
// ...
}
}
Best,
Gilles
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-165) Simplify use of EstimationProblem
[
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
Key: MATH-165
URL: https://issues.apache.org/jira/browse/MATH-165
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Assigned To: Luc Maisonobe
Priority: Minor
Fix For: 1.2
The use of the EstimationProblem interface could be simplified by providing
a helper (abstract) class that would implement
the getMeasurements getAllParameters and getUnboundParameters methods.
Currently, each new implementation of the interface has to do it even if they
are typically only called from the Estimator class (and not by the user
code).
That same helper class could also take care of storing the partial
derivatives.
A skeleton for the requested class could be as follows:
public abstract class SimpleEstimationProblem
implements EstimationProblem {
// ... storage for measurements and partial derivatives ...
protected void addParameter(EstimatedParameter p,
ComputableFunction partial,
boolean isBound) {
// ...
}
protected void addParameter(EstimatedParameter p,
ComputableFunction partial) {
addParameter(p, partial, false);
}
protected double getPartial(EstimatedParameter p,
double x) {
// ...
}
protected void addMeasurement(WeightedMeasurement m) {
_observations.add(m);
}
public WeightedMeasurement[] getMeasurements() {
// ...
}
public EstimatedParameter[] getAllParameters() {
// ...
}
public EstimatedParameter[] getUnboundParameters() {
// ...
}
}
Best,
Gilles
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Release planning, IOC-friendlyness
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 agree with you and propose to delay SVD to next release. I will RM if no one else wants to, but would appreciate it (and support by sharing gruntwork) if someone else volunteers. I would be happy to help. However I never followed the release process before, so it may be to early for this one. Regardless of who manages the release, I will add the public subkey I have set up for releases signing in the KEYS file. Here are some questions to resolve in the release plan: 1. Is this 1.2 or 2.0? There is so much in the added Mantissa classes that 2.0 makes sense from a functionality standpoint. On the other hand, we have not broken backward compatibility with anything (yet) and if we decide to go 2.0, we could consider some API change. My vote is to keep compatibility in place, but still name it 2.0. I also think we should use 2.0 as the release number. There are some API changes as some methods have been deprecated. I also wonder if it would'nt be safer to change some unchecked exceptions to checked exceptions. An example for this is the solve method for UnivariateRealSover. Solvers may throw an IllegalArgumentException when the provided interval doesn't bracket the root for example. This is explained in javadoc but I would prefer to enforce it by replacing this by something like SearchIntervalException or even a broad SolverException. Of course, this would be break compatibility (but user code would be easy to fix). 2. What if anything should we add to make pluggability as designed in the library compatible with IOC frameworks? It won't work to add setters for the main factories, since we use the static getInstance factory pattern (see e.g. UnivariateRealSoverFactory). What might make more sense would be to add setters for the individual solvers in e.g. UnivariateRealSoverFactoryImpl. Any ideas on how best to attack this? For those not familiar with [math] who may have ideas, the basic setup is that we use abstract factories with static getInstance methods that return concrete factories looked up using commons-discovery. The concrete factories themselves source multiple different object types . Adding setters seems a bit strange to me. I thought either we use abstract/concrete factories and let the user provide his own factories by extending the default one overriding only the factory method he need, or we use only one concrete factory and setters in the spirit of IOC. Providing both at the same time is confusing. I personally prefer the IOC way but once again this would be an incompatible change (this one is more difficult to fix in user code, but I'm not sure many people used this feature). Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-164) Complex - Issue with non-compliance to C99!
[ 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 using a single check for NaN and using the simple rules on real and imaginary parts if the check succeeds. A quick check shows that there are several other related problems. For example, the isInfinite method checks for isNaN first and checks for infinite parts only afterwards. However, C99 explicitely states that a complex is considered to be an infinity as soon as one part is infinity, even if the other one is NaN. So it appears that the handling of special values like NaN and infinity in the Complex class is not compliant with C99 at several places. Solving this needs some forethought. Thanks for reporting it. Complex - Issue with non-compliance to C99! --- Key: MATH-164 URL: https://issues.apache.org/jira/browse/MATH-164 Project: Commons Math Issue Type: Wish Affects Versions: 1.1 Reporter: Richard Lyon Priority: Minor Complex z1, z2, z3; // assign values to the two complex numbers z1 = new Complex(1.0, 0.0); z2 = new Complex(Double.POSITIVE_INFINITY, Double.POSITIVE_INFINITY); // multiply the two complex numbers z3 = z1.multiply(z2); The result is that both the real and imaginary part of z3 are NaN. Isn't it somewhat desirable that both parts of the complex should be Infinity? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Proposal: move build to m2
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 forever hold your peace. Assuming no objections in the next couple of days, we can start battling - er, I mean working - with m2. +1 Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] towards a 1.2 release (was docs on doing maven2 releases)
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 putting together a release plan? I think we should close MATH-120, MATH-156 and MATH-157 before the release. MATH-120: I have commited a trivial documentation update (one line in a table listing the available distributions). MATH-156: concerning the Brent solver issue, I will implement the solution sketched by the reporter and commit it. MATH-157: this is a really important one. As there has already been some discussion on Jira, I think we could start by simply reviewing and commiting the last version of the patch. By the way, I would like to put my name as assignee (is this an english word ?) for MATH-157. I don't see a way to do this, should I request further authorizations on Jira first ? Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] docs on doing maven2 releases
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 removed in next release). I was planning something like that for [math]. It would be really nice if you could do that for [math]. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-82) [math] FractionFormatTest doesn't compile under JDK 1.3
[ 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 with ComplexUtilsTest seems OS-specific and not related to commons-math. Could we close this bug ? [math] FractionFormatTest doesn't compile under JDK 1.3 Key: MATH-82 URL: https://issues.apache.org/jira/browse/MATH-82 Project: Commons Math Issue Type: Bug Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Niall Pemberton Priority: Minor Attachments: math_FractionFormatTest_JDK13.patch, TEST-org.apache.commons.math.complex.ComplexUtilsTest.txt FractionFormatTest uses NumberFormat.getIntegerInstance() which is a JDK 1.4 method. Changing this to use getInstance() instead and then using setParseIntegerOnly(true) allows it to compile under JDK 1.3 - and the test runs and passes. Its probably a moot point though since ComplexUtilsTest fails using JDK 1.3.1_04 (on both W2K and Windows XP). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r512384 - in /jakarta/commons/proper/math/trunk: pom.xml project.xml
[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 any encoding here, so the default value should be UTF-8 but in fact the original character was not UTF-8. I could fix this either by simultaneaously ensuring UTF-8 encoding in the XML header and using an UTF-8 character, or by using a XML entity (#246; in this case). Is there some widely adopted policy for pom files and do they really support non-ASCII characters ? Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sorry for the numerous commit messages
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 packages to commit. I will not do it before tomorrow (european time) and will try to find whats wrong with my workspace before, in an attempt to have shorter diffs. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] svn commit: r506585 [1/2]
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. jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/analysis/LaguerreSolver.java (contents, props changed) snap/ This file, and many others seem to be missing the eol-style settings, causing much larger diffs. Please look through [math] and add the correct SVN properties, where needed. 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 to native and then commit the change, this will create (hopefully only once) a huge diff. If I understand correctly, after that change, further commits will not depend on contributor platform. Do you want me to do that or is there a smarter way ? Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r506591 - in /jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/fraction: Fraction.java FractionConversionException.java
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 some Junit tests. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] svn commit: r506585 [1/2]
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 to native and then commit the change, this will create (hopefully only once) a huge diff. If I understand correctly, after that change, further commits will not depend on contributor platform. Do you want me to do that or is there a smarter way ? Sounds good, I had earlier missed that you also corrected the svn:eol-style! I will reset the svn:eol-style property for a number of files soon. It seems 38 text files in the [math] repository do not have any eol-style property set. In my local worspace, they show up as 22 with DOS-like eol (which is wrong in my box) and 16 with Unix-like eol (which is right in my box). I will try to fix everything in two steps for clarity in a few minutes. You should expect a huge diff when the 22 DOS files will be checked in, sorry for inconveniance. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] exceptions and localization
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 http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spaceroots/mantissa/MantissaException.java?view=markup ) and getMessage(Locale) methods. That gives client apps the most flexibility. What do you think, Luc? Trying to synthetize all use cases, here is what I think is expected by everyone who has expressed views : 1) allow application level code to contribute to/configure message building 2) allow low layers to build messages with variable parts 3) allow localized messages 4) expose message parts (key and parameters) 5) allow handlers using only no arguments getMessage() to work as usual 6) use a mechanism robust enough to work even in case of code changes and missing localization data (of course in degraded, i.e. non localized mode) The following proposal is an attempt to address all these points. Two main classes would be used: the MathException base class and a MessageFactory base class. MathException would delegate to MessageFactory the task to build the message from its String key and Object[] parameters (point 2). Both the key, parameters and message would be available with appropriate getters (point 4 and 5). A static method in MathException would allow upper layers to prepend a customized MessageFactory instance (point 1) in front of already registered factories following a chain of responsibility. The initial chain would contain three different MessageFactory instances : - a LocalizedMessageFactory using the key to retrieve a pattern from a ResourceBundle for the default Locale (Locale.geDefault()) and MessageFormat to build the message (point 3) - a NonLocalizedMessageFactory using the key directly as a pattern for MessageFormat - a RawMessageFormat simply concatenating everything with toString The chain of responsibility is intended to provide robustness (point 6): the first message factory providing a non null message is used. If a factory fails, the next one is used. The last factory cannot fail. A user who simply wants to get messages localized for a Locale which is not the default one would therefore only need to do : MathException.prependMessageFactory(new LocalizedMessageFactory(myLocale)); This would work even if its locale is not supported as its factory would always fail but the following ones would be triggered as needed. I think an appropriate policy would be to always use US-english patterns as keys as it would allow to get meaningful messages even if everything else fails, and as it would help the translators tasks. Does this seems sensible ? Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] exceptions and localization
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 for clients who want to do that. OK. I'll do that. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] exceptions and localization
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 that have strict rules about implementing localization. I work for such an organization (Sun) ... the key rules are that any message that might be visible to users *must* be localizable. I agree with you and thought localization should be provided by the layer which provides the message. Other people think this should be done at application level, if done at all. For log messages, that tends to translate into a straightforward policy that DEBUG and TRACE type messages do not need to be localized, but anything from INFO level above must be. The issue for exception messages is a bit more interesting. How does the library developer know whether or not the message part of the exception will be displayed to end users? From a pragmatic viewpoint, you can pretty much assume this will happen with exceptions in webapps, while many Swing apps will hide that sort of stuff to some degree. I think that since low level components may be used almost anywhere, their messages *may* be displayed and this sole possibility is enough to justify a localized version should be made available. If the application gets an error it really doesn't know about, it can simply display it. But, as a bottom line, if I'm interested in maximum adoption of a Commons library I work on, I will diligently ensure that exception messages are localizable :-). When I first started this long thread, I thought the need for localized error messages as provided by exceptions was acknowledged by everyone and asked for the way to implement it, starting from a simple one which already works. I was wrong. The disagreement started about the need itself and slipped to the level at which implementation should be done. I would really like to reach a compromise on this issue, something that could by accepted by everybody. I don't want to get banned with a -1 on a commit, but at least a few people would like localized error messages that can be simply forwarded upward from lower layers to upper layer for display without processing. Standard java already provides Throwable.getLocalizedMessage() since JDK 1.1. I could set up for [math] only an exception hierarchy that only add a few constructors and an implementation of this method without any change in the Throwable.getMessage() behaviour. Does this sound reasonable ? Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] exceptions and localization
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 and either replaced by or wrapped within another one, regardless of the message being localized or not. This decision depends on the understanding of the exception at the middle layer. In the advertised case, the layer really knew the meaning of this error at its own level despite it has been triggered at a lower level, so it knew how to build a better message (again, regardless of the localization). There are cases, however, when the middle layer has no hint about what meaningful information to add, despite it knows a larger or more abstract context, so it better let the exception go as is without even catching it. As we build reusable components that will be embedded in other components, we cannot rely on a single use case of our code. It has to be as versatile as possible to meet many requirements. Some users will rewrite every message, others will simply display what was built at low level, both are legitimate use. We have some global players as customers and they all have very specific needs for logging and error messages (e.g. every logged entry has to be defined and must have an ID and has fields with fixed length, exceptions have to be reported as part of the return value of service calls again with special identifiers and filled-in parameter values for the error). I know about those needs and they are well addressed by exceptions that can be caught and modified at will, regardless of the localization status. My bottom line: If you build an application, you have to do localization (of exception and logging) at the application layer, because only there you can give the user a context, that is really useful. I think error messages belong to the information set that *may* be propagated to upper layers according to upper layers design choices. If upper layer is localized, lower layers should also be localized. This implies catching exceptions from libraries and wrapping them with your own and it implies also, that you should have access to the basic parts of the exception (e.g. the file name) easily i.e. usign the exeption's API. This part can be provided by a common lib (and the JDK fails here often enough badly), but it cannot serve the requirements of an application it has no knowledge of. This is a really good idea and I strongly agree. Using very specific exceptions providing specialized getters allow users to refactor error handling easily. Well, it seems only Phil and I think this localization stuff is important and should be provided to users. If anyone steps up to support this idea, we could end up gathering all use cases from this thread in [math] by having getMessage() providing US-english messages that can be searched for (Stephen, Hen, Jörg), having getSomeBasicPart() methods in specialized exception for complete(Jörg), and having getLocalizedMessage() providing a new message (Phil and I). My goal is only to add more user-friendliness, and of course only to [math]. However, if nobody adds anything to the thread, I will remove my refactoring proposal. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] exceptions and localization
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 provides about 20 error cases that would need to be handled by upper level). One point that did not appear in the discussion is that this way somehow violates separation of concerns principles. As a conclusion, I will not attempt any refactoring of this kind. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] exceptions and localization
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
getMessage() already provides an localized message. In either case,
since some messages have both fixed parts and variable parts, some
localization layer should be used at the time of Exception creation,
i.e. in the commons components themselves.
I am willing to implement that for [math] (prior to retrofit the
Mantissa packages already selected), and was wondering how this is
handled by other components. The only two things I found were the
Fulcrum Localization Component in Turbine and the I18n component in sandbox.
I think building localized error messages is important so I would like
to change the current practice.
The first question I ask is what localization framework should be used
for that: standard java, i18n in sandbox, fulcrum localization ? My
personal choice would be standard java with embedded property files
(PropertyResourceBundle) first and i18n from sandbox second as I don't
want to add new dependencies to [math] and if a dependency is added it
should belong to commons obeying [math] proposal.
The second question I ask is at which stage should the localization
layer be triggered: before creating the exception or inside the
exception constructors ? My personal choice as implemented in Mantissa
is depicted in the example at the bottom of this message. It only adds
new constructors, thus allowing smooth transition towards providing
fully localized components with variable parts messages. I think it is
compatible with java 1.3 (but am not sure). From the user points of
view, the messages will be already localized in the getMessage() method,
however it is quite easy to change this implementation to provide both
english and localized messages.
What do you think about it ?
Luc
public class SomeException
extends Exception {
private static ResourceBundle resources =
ResourceBundle.getBundle(org.apache.commons.some.ExceptionsResources);
/** Translate a string. */
public static String translate(String s) {
try {
return resources.getString(s);
} catch (MissingResourceException mre) {
return s;
}
}
/** Translate a message. */
public static String translate(String specifier, String[] parts) {
return new MessageFormat(translate(specifier)).format(parts);
}
/* some more traditional constructors go there, with message
* only, or message and cause ...
*/
/** Simple constructor. */
public SomeException(String specifier, String[] parts) {
super(translate(specifier, parts));
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] exceptions and localization
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 rationale and your conclusion, but not with the implications. For me, error messages are users oriented, not developers oriented. Here are the few rules experience has teached me in the past 20 years: - error messages should be meaningful to end users who do not know the application design - meaningful error messages should include references to run time data, not only a fixed message. For example if a file access fails, I want both the name of the file and the reason (file not found, permission denied ...) - the previous item implies that error messages should be set up in the lowest layers where the information is available - an error at low level can be worked around at an upper level, or dismissed or displayed thanks to an application-dependent medium. Hence the message fate should be handled in the highest layer (aplication) - errors semantics may change as they bubble up through the layers. A critical error in a low level algorithm (say no solution to some problem) may be considered only as an end condition in some intermediate search loop or even be the result that was seeked (I used that operationally for years in order to compute launch windows for satellites) - as errors semantics change along their path through the middle layers, the error message may be reset to become more user-friendly if needed. For example no solution found in the [0.2 0.7] interval may become attitude constraints not fulfilled for launch date 2007-01-28T21:39:45Z. - exceptions are great for handling the four previous items (creation in the low layers, decision in the high layers, interception in the middle layers, wrapping within other exceptions if needed) - developer-oriented information is not a substitute to user-oriented error handling. If only one is set up, it should be the user-oriented one - developer-oriented information should not be pushed in front of users - developer-oriented information may be put in log files for later analysis If I understand your remark correctly, you do make the same strong difference between users and developers, but you seem to consider exceptions are for the latters. What do you provide to the formers for error messages ? And to what purpose do you use logging ? Adding localized error messages is another place for the application to go wrong, so you're going to have to test this fully. After all, if you get it wrong, you could lose the real exception and just get a meaningless failed to localize exception. And thats a terrible outcome. You are right. In the current Mantissa codebase, I used the english error message format as the key to find the translation and use it directly if no translation is found for that key. If some resource file gets outdated, the end user will end up with an untranslated message, which is a somewhat fail-safe behaviour. It's not perfect, for sure, but it is quite efficient. For the record, I would -1 any code commit to add localized error messages to a component I actively commit to. So we really have to sort out this issue before I start any work about it, regardless of the fact that you commit or not to [math]. Your opposition is strong enough and shows there is a serious misunderstanding between us that must be ironed out. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] when are svn commit mails generated ?
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. However, I performed a small commit for three files in [math] yesterday which bumped version to r496489 and no mail was generated. Since it was my very first commit, I am a little affraid I can have done something wrong. I used the subclipse plugin (version 1.1.9) with eclipse (version 3.2.1) on a Linux box. Should a specific commit procedure be followed or can I use any client ? Was the behaviour normal when no mail is generated ? Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] What's in a distribution?
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 binary distribution as I think most people want to attach the source to their jar files, at least in commons. I don't agree with this point of view. If people need these two parts (pristine sources and trusted binary), then they could grab both archives. But many other people only want either one or the other, depending on the use cases Hen depicted. We should take care about people having low bandwidth. There are many places in the world were 56K modems are still the only means to connect to the internet and were communication costs are high. Putting everything (source, binary, website ...) in an all-purpose distribution is not user friendly for these people. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Release 1.2 planning, incorporating Mantissa
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 all volunteer to take on tasks. 1. Start with a list of Mantissa features to introduce into [math] Agreed. In order to help the choice, here is the complete list of packages provided by Mantissa, with my own comments about them : algebra: univariate polynomials, orthogonal polynomials (very basic, straightforward and inefficient implementation) estimation : general estimation, least squares, Gauss-Newton, Levenberg-Marquardt (the package based on interfaces for problems and solvers, which should be in a approach similar to commons-math) fitting: general curve fitting, polynomials, harmonic series (this is a simple wrapper around estimation, except for harmonic fitting which is more complex, but is it useful ?) functions : scalar and vectorial functions interfaces definitions (was created for the sake of quadrature and fitting, I think commons-math provides something better) geometry : vectors and rotation in 3D (tiny package, the most important thing is Rotation3D which is quite elaborated and whose code is validated in real life space applications) linalg : linear algebra (very basic, straightforward, inefficient and incomplete implementation) ode: Ordinary Differential Equation (this this the most important and polished package, most Mantissa users downloaded it only for this package which is is quite elaborated, provides state of the art algorithm with all bells and whistles like continuous output, multiple switching functions supporting G-stop and discontinuities, integration driven in slave or master mode ...) quadrature : functions quadrature, Riemann, Trapezoid, enhanced Simpson, Gauss (classical package, use the function package) random : random generators and basic statistics (to be compared with commons-math) roots : simple root finding (only a Brent implementation) 1.2, based on the WishList and review of the Mantissa code base. Here is my suggested list for math 1.2: a. The entire Mantissa estimation package b. The entire Mantissa optimization package I would strongly suggest to add also the ode and geometry packages. 2. Repackage and refactor Mantissa code - not much, actually - to be consistent with the rest of [math] (interface encapsulation, pluggable implementations using new approach - see 5 below) Agreed. I also think some work needs to be done to merge error handling. Mantissa provides a way to localize messages, it could be a useful addition to commons-math. 3. Replace suboptimal implementations in math random and analysis packages with better impls in Mantissa, where this makes sense (TBD - comments / suggestions welcome). Also, leverage relevant bits and code recently contributed in MATH-157 to implement SVD. I'm not sure Mantissa has more optimal implementations :-( I am not a statistician and only implemented what I needed for my own work. I never had any feedback on these parts. 4. Clean up things added to math trunk since 1.1 5. Replace commons-discovery dependency injection mechanism with spring-compatible approach - patches welcome! I don't have a sufficient knowledge on commons-math yet to have an opinion on these tasks. 6. Get to zarro boogs (or a pretty Jira screen, I guess ;-) Yes :-) Comments, volunteers, patches, welcome! I can do all Mantissa refactoring tasks to merge it into the main tree once the merged parts are chosen. I would suggest to perform step 2 in Phil's proposal starting with error handling, followed by packages renaming, followed by interfaces refactoring. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MATH-162) update to mantissa 7.0
update to mantissa 7.0 -- Key: MATH-162 URL: http://issues.apache.org/jira/browse/MATH-162 Project: Commons Math Issue Type: Improvement Affects Versions: Nightly Builds Environment: all Reporter: 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 should be updated. I will provide a patch soon -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-162) update to mantissa 7.0
[ 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 -- Key: MATH-162 URL: http://issues.apache.org/jira/browse/MATH-162 Project: Commons Math Issue Type: Improvement Affects Versions: Nightly Builds Environment: all Reporter: Luc Maisonobe Priority: Trivial Attachments: mantissa.patch 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 should be updated. I will provide a patch soon -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-161) patch for Mantissa
[ 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://issues.apache.org/jira/browse/MATH-161 Project: Commons Math Issue Type: Improvement Environment: all Reporter: Luc Maisonobe Priority: Trivial Attachments: mantissa.patch Here is the patch for Mantissa, it includes the following items: - fix a problem when switching functions triggered derivatives discontinuities - remove methods and classes that were deprecated in Mantissa and do not need to be preserved in commons-math as upward compatibility is not a problem for this newly integrated code - changed Vector3D and Rotation to immutable classes for ease of use - improved some javadoc in class Rotation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] patching a mantissa issue
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 related to switching functions in the Ordinary Differential Equations package. If a switching function triggered a derivatives discontinuity (which is a classical use for switching functions), the integrator may still reuse the derivatives computed at the switch time before the switch instead of recomputing them still at the switch time but after the switch. This leads to stability problems and even failures in the Gragg-Bulirsch-Stoer integrator which by default does check stability. I took the opportunity to also remove the deprecated methods and classes I forgot to remove in the first place in two classes. I'm aware Mantissa is still in the incubator, are there any news about this state ? I have sent the updated Software Grant on October the 24th. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] patching a mantissa issue
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 accept my apologies.
The commit message I suggest is the following one:
fixed a problem when switching functions triggered derivatives
discontinuities
Luc
Index: /home/luc/sources/jakarta/commons-math/src/mantissa/src/org/spaceroots/mantissa/geometry/Rotation.java
===
--- /home/luc/sources/jakarta/commons-math/src/mantissa/src/org/spaceroots/mantissa/geometry/Rotation.java (revision 476939)
+++ /home/luc/sources/jakarta/commons-math/src/mantissa/src/org/spaceroots/mantissa/geometry/Rotation.java (working copy)
@@ -99,22 +99,6 @@
}
/** Build a rotation from the quaternion coordinates.
- * @param q0 scalar part of the quaternion
- * @param q1 first coordinate of the vectorial part of the quaternion
- * @param q2 second coordinate of the vectorial part of the quaternion
- * @param q3 third coordinate of the vectorial part of the quaternion
- * @deprecated since Mantissa 6.3, this method as been deprecated as it
- * does not properly handles non-normalized quaternions, it should be
- * replaced by [EMAIL PROTECTED] #Rotation(double, double, double, double, boolean)}
- */
- public Rotation(double q0, double q1, double q2, double q3) {
-this.q0 = q0;
-this.q1 = q1;
-this.q2 = q2;
-this.q3 = q3;
- }
-
- /** Build a rotation from the quaternion coordinates.
* pA rotation can be built from a emnormalized/em quaternion,
* i.e. a quaternion for which qsub0/subsup2/sup +
* qsub1/subsup2/sup + qsub2/subsup2/sup +
@@ -120,9 +104,6 @@
* qsub1/subsup2/sup + qsub2/subsup2/sup +
* qsub3/subsup2/sup = 1. If the quaternion is not normalized,
* the constructor can normalize it in a preprocessing step./p
- * pThis method replaces the [EMAIL PROTECTED] #Rotation(double, double,
- * double, double) constructor using only 4 doubles} which was deprecated
- * as of version 6.3 of Mantissa./p
* @param q0 scalar part of the quaternion
* @param q1 first coordinate of the vectorial part of the quaternion
* @param q2 second coordinate of the vectorial part of the quaternion
Index: /home/luc/sources/jakarta/commons-math/src/mantissa/src/org/spaceroots/mantissa/MessagesResources_fr.java
===
--- /home/luc/sources/jakarta/commons-math/src/mantissa/src/org/spaceroots/mantissa/MessagesResources_fr.java (revision 476939)
+++ /home/luc/sources/jakarta/commons-math/src/mantissa/src/org/spaceroots/mantissa/MessagesResources_fr.java (working copy)
@@ -91,7 +91,7 @@
{ dimensions mismatch: ODE problem has dimension {0},
+ state vector has dimension {1},
incompatibilit\u00e9 de dimensions entre le probl\u00e8me ODE ({0}),
-+ et le vecteur d'\u00e9tat ({1}) },
++ et le vecteur d''\u00e9tat ({1}) },
{ too small integration interval: length = {0},
intervalle d''int\u00e9gration trop petit : {0} },
Index: /home/luc/sources/jakarta/commons-math/src/mantissa/src/org/spaceroots/mantissa/ode/GraggBulirschStoerIntegrator.java
===
--- /home/luc/sources/jakarta/commons-math/src/mantissa/src/org/spaceroots/mantissa/ode/GraggBulirschStoerIntegrator.java (revision 476939)
+++ /home/luc/sources/jakarta/commons-math/src/mantissa/src/org/spaceroots/mantissa/ode/GraggBulirschStoerIntegrator.java (working copy)
@@ -880,7 +880,11 @@
interpolator.storeTime(currentT);
handler.handleStep(interpolator, lastStep);
-switchesHandler.reset(currentT, y);
+if (switchesHandler.reset(currentT, y) ! lastStep) {
+ // some switching function has triggered changes that
+ // invalidate the derivatives, we need to recompute them
+ firstStepAlreadyComputed = false;
+}
int optimalIter;
if (k == 1) {
Index: /home/luc/sources/jakarta/commons-math/src/mantissa/src/org/spaceroots/mantissa/ode/RungeKuttaFehlbergIntegrator.java
===
--- /home/luc/sources/jakarta/commons-math/src/mantissa/src/org/spaceroots/mantissa/ode/RungeKuttaFehlbergIntegrator.java (revision 476939)
+++ /home/luc/sources/jakarta/commons-math/src/mantissa/src/org/spaceroots/mantissa/ode/RungeKuttaFehlbergIntegrator.java (working copy)
@@ -311,7 +311,11 @@
System.arraycopy(yDotK[stages - 1], 0, yDotK[0], 0, y0.length);
}
- switchesHandler.reset(currentT, y);
+ if (switchesHandler.reset(currentT, y) ! lastStep) {
+// some switching function has triggered changes that
+// invalidate the derivatives, we need to recompute
Re: [PROPOSAL] Major versions require package name change
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 minor change breaks their code because they used some undocumented feature or side effect while some other users relying only on a small part of a library may even not notice any change when a major version is released. It may even be false from the developper point of view. Sometimes, I did bump the major version number of my products when no incompatible changes were introduced but when only a very important new feature was added, even if all the rest was exactly the same. I am quite reluctant to adopt a drastic approach for all major versions. I agree with the need for a new package name in the example case of generifying [collections], but hope this case is extremelly rare. Package names changes could be decided after discussions and involving the users rather than as the result of a mandatory rule. (I'm not sure I allowed to express this opinion as I am only a new contributor, please ignore this message if you consider this a reserved topic). Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-160) Chi-Square Test for Comparing two binned Data Sets
[ 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 conditions in the NR site here: http://www.numerical-recipes.com/infotop.html#distinfo If the code is a well known algorithm with public references independant from NR, then it is OK. But the comments in your patch directly references the NR book in C++. Of course, this only my point of view, could anybody else give an advice on this topic ? Chi-Square Test for Comparing two binned Data Sets -- Key: MATH-160 URL: http://issues.apache.org/jira/browse/MATH-160 Project: Commons Math Issue Type: New Feature Reporter: Matthias Hummel Priority: Minor Attachments: commons-math.patch Current Chi-Square test implementation only supports standard Chi-Square testing with respect to known distribution. We needed testing for comparison of two sample data sets where the distribution can be unknown. For this case the Chi-Square test has to be computed in a different way so that both error contributions (one for each sample data set) are taken into account. See Press et. al, Numerical Recipes, Second Edition, formula 14.3.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-60) [math] Function math.fraction.ProperFractionFormat.parse(String, ParsePosition) return illogical result
[
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] Function math.fraction.ProperFractionFormat.parse(String,
ParsePosition) return illogical result
---
Key: MATH-60
URL: http://issues.apache.org/jira/browse/MATH-60
Project: Commons Math
Issue Type: Bug
Affects Versions: 1.1 Final
Environment: Operating System: other
Platform: Other
Reporter: nhung.nnguyen
Hello,
I find illogical returned result from function Fraction parse(String source,
ParsePostion pos) (in class ProperFractionFormat of the Fraction Package) of
the Commons Math library. Please see the following code segment for more
details:
ProperFractionFormat properFormat = new ProperFractionFormat();
result = null;
String source = 1 -1 / 2;
ParsePosition pos = new ParsePosition(0);
//Test 1 : fail
public void testParseNegative(){
String source = -1 -2 / 3;
ParsePosition pos = new ParsePosition(0);
Fraction actual = properFormat.parse(source, pos);
assertNull(actual);
}
// Test2: success
public void testParseNegative(){
String source = -1 -2 / 3;
ParsePosition pos = new ParsePosition(0);
Fraction actual = properFormat.parse(source, pos); // return Fraction 1/3
assertEquals(1, source.getNumerator());
assertEquals(3, source.getDenominator());
}
Note: Similarly, when I passed in the following inputs:
input 2: (source = 1 2 / -3, pos = 0)
input 3: ( source = -1 -2 / 3, pos = 0)
Function Fraction parse(String, ParsePosition) returned Fraction 1/3 (means
the result Fraction had numerator = 1 and denominator = 3)for all 3 inputs
above.
I think the function does not handle parsing the numberator/ denominator
properly incase input string provide invalid numerator/denominator.
Thank you!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math][patch] Mantissa + Characteristic methods for MathUtils
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 that way). Here is some code from the org.apache.commons.math.util.MathUtils.nextAfter method: // split the double in raw components long bits = Double.doubleToLongBits(d); long sign = bits 0x8000L; long exponent = bits 0x7ff0L; long mantissa = bits 0x000fL; This snippet cuold be promoted to public methods by itself (beware that the exponent part is the raw exponent which includes an offset, it is not a simple integer). Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Mantissa source
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, including the Levenberg-Marquardt and Gragg-Bulirsch-Stoer algorithms, and excluding only the unneeded four-tap and Mersenne twister random generators. I have followed the ASF Source Header and Copyright Notice Policy (http://www.apache.org/legal/src-headers.html) and moved myself the various copyright and license texts in a NOTICE.txt file, and added the Apache header to all files. The archive is publicly available at the following URL: http://www.spaceroots.org/software/mantissa/mantissa-for-commons-math.zip The MD5 hash for the file is: f9ecc079d79d2e0009a7b97e95d1e8de mantissa-for-commons-math.zip Should I resubmit the software grant listing all the sources included in the archive and the MD5 hash via snail mail to Apache ? I have already submitted a more general software grant a few months ago for Mantissa. I will be away for the week, and probably unable to read my mail before next week-end. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Mantissa inclusion and copyright issues
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 sign a Software Grant myself for everything except one class already identified since the beginning. However, after some checks, four additional Mantissa classes could induce some copyright issues and I am seeking for advices for these classes. org.spaceroots.mantissa.estimation.LevenbergMarquardtEstimator: This class is an implementation of the Levenberg-Marquardt algorithm. The internal code is a translation in Java of the 1980 fortran lmder, lmpar and qrsolv routines (http://www.netlib.org/minpack/lmder.f, http://www.netlib.org/minpack/lmpar.f, http://www.netlib.org/minpack/qrsolv.f) which are distributed as part of minpack under the following license: http://www.netlib.org/minpack/disclaimer. The code I want to donate includes the following changes from minpack: - complete translation of all code in Java - complete redesign of the interface to fit with the existing Mantissa Estimator interface - complete rewrite of the Q.R decomposition part to use another implementation derived from a textbook - adaptation of the upper-level code (calling the Q.R decomposition) to the lower-level implementation changes (calls, indices and columns reordering handling) The implementation of the estimate (lmder), determineLMParameter (lmpar) and determineLMDirection (qrsolv) are the parts that come from Minpack, their origin are advertised (as required by Minpack license) and only the translation in Java and the adaptation are new. All the rest of the class (interface, all other methods including qrDecomposition) is original work. From a users perspective, it is a very important algorithm and a clear improvement for commons math. It also seems that most (if not all) implementations of the algorithm are indeed translations of these minpack routines. It seems difficult to ask for the original authors to provide a software grant to Apache. Is this class acceptable in commons math or should it be dropped (it would be difficult to reimplement the three methods directly translated from minpack) ? org.spaceroots.mantissa.ode.GraggBulirschStoerIntegrator and org.spaceroots.mantissa.ode.GraggBulirschStoerInterpolator These classes are an implementation of the Gragg-Bulirsch-Stoer integrator. The internal code is a translation in Java of the fortran odex code by E. Hairer and G. Wanner (http://www.unige.ch/math/folks/hairer/prog/nonstiff/odex.f) distributed under the following license (BSD type): http://www.unige.ch/~hairer/prog/licence.txt The algorithm is described in the well known Hairer, Norsett and Wanner textbook Solving Differential Equations (part I, nonstiff problems). The code I want to donate includes the following changes from odex: - complete translation of all code in Java - complete redesign of the interface to fit with the existing Mantissa FirstOrderIntegrator interface From a users perspective, this integrator could be omitted. It is one of the best integrators available for nonstiff problems, of course, but Mantissa also includes the Dormand-Prince 8(5,3) which is another very good integrator, and which was implemented from scratch and shares the design of other Runge-Kutta-Fehlberg integrators. Should these two classes be included in commons math ? org.spaceroots.mantissa.random.MersenneTwister: This class is an implementation of the Mersenne twister pseudo-random generator. It is a translation of the Makoto Matsumoto and Takuji Nishimura c code. As there is already an implementation of the Mersenne twister in commons math, it seems irrelevant to include this new implementation. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Mantissa inclusion and copyright issues
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 to the legal-discuss list, could you tell me when you'll have an answer ? The Hairer license is as you say, a BSD-like license, so that's fine. Fine. For both cases, we don't need software grants. Instead we put the information in the NOTICE.txt file. I presume the original files you took the code from had copyright statements at the top? No, there was no formal copyright statements, just authors lists like you would find in a mathematical paper. In fact I had to dig around in the sites in order to find the licences. In Mantissa, I put the text of theses licenses in the Javadoc at class level and displayed the original authors names in @author statements. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Brent Solver improvements.
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 : Hi guys, I noticed that your brent solver isn't using the initial guess given by the user. This can often radically improve the performance of the solver. In my tests, it improved it by roughly 30% or more, with a decent guess. Basically, we should try the guess first. If that's close enough, rreturn it. Otherwise, try one of the end points. If that's close enough, return it. Then if that brackets, go into the main loop. If that doesn't bracket, then we instead try the other endpoint. If that's close enough, return it. If that doesn't bracket, throw an exception. If it does bracket, go into the main loop with all three trial points available, allowing the quadratic interpolation to be used immediately. Worst case scenario, the initial guess doesn't bracket. In that case it is better than the default algorithm only if the user's initial guess is better than linear interpolation, which I imagine it almost always would be. If the user can't guess better than linear interpolation, presumably they wouldn't provide a guess at all, and then nothing would change. It's a small addition, less than 100 lines of code. I can't send it in due to legal at work, but from the above ideas, you should be able to put it in easily. One caveat. You may need to slightly modify the baisic solve(double, double) method to linearly interpolate a good beginning point and then break out a six double (solve(x0, y0, x1, y1, x2, y2)) method that both solve(min, max) and solve(min, max, initial) can use. If you don't do this, then solve(min, max) will bisect on its first iteration rather than intepolating, which could cost performance. If you do break it out like so, then this will always perform better than the current implementation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
eclipse customisation files for commons ?
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 commands, e-mail: [EMAIL PROTECTED]
[math] beware before adding Mantissa code to an experimental directory
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 integrator which was inspired from an implementation by Hairer and Wanner. The second class is the highest level part of the Levenberg-Marquardt implementation which was inspired from NETLIB code (is this acceptable for commons-math ?). The lowest level part, on the other hand, which is the QR decomposition with columns reordering, is an orginal implementation following a french textbook from the 80's. For these two classes, I will see if I can provide completely original implementations. I hope no other classes present the same problem, I will check each one. sorry for the inconvenience Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Splitting the mailing list
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 discussions about future directions and new features. As far as the arguments about getting new contributors in, I would like to hear from them. I am just stepping in now. As I really want to contribute and to invest my time in this project, I am interested in the commits and Jira stuff. The fact de dev list is shared among many projects is more an issue to me than the level of messages that are exchanged on the list for a given project. However, I think this choice has been made for good reasons and will not complain about it. I take the lists as they are. This is only a personal opinion, from someone who is both new to the project and wants to get involved. Many other use cases for the lists are possible. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SingularValueDecomposition
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 should have a look to the various Householder transforms implementations we have. One has been added recently, one is hiding underneath the Levenberg-Marquardt algorithm in Mantissa to be added soon (I hope), and one is now provided by you. Some generalization around these three implementations may be worth a try. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Re: SingularValueDecomposition
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, sorry). The list is shared among a lot of projects, so these markers help filtering the messages for all subscribers. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (MATH-85) [math] SimpleRegression getSumSquaredErrors
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 need accuracy, they should get accuracy and if they need speed, they should get speed as both can be done easily ... but not at the same time. The problem with two implementations is that is confuses users and reduces time devoted to develop other topics. The trade off is to be based on users needs. For now, there has only been one remark which was not a strong requirement (yet). Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (MATH-85) [math] SimpleRegression getSumSquaredErrors
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 prone to adverse numerical effects unless the sequence is also sorted. You are right, but this would also imply storing all values and either recompute everything as points are added/removed or set up a dirty flag to perform lazy evaluation only when needed. This has an impact on both memory and CPU usage. The current implementation does not retain each points, it simply handles them on the fly by updating a few running sums. It can handle an extremely large number of points with a very little memory footprint. Do you think we should provide two implementations, one being memory/CPU friendly and the other one being accuracy-friendly ? Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-85) [math] SimpleRegression getSumSquaredErrors
[
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,
8923.502) represent three points on a perfect straigth line, with the second
point exactly at the middle of the two extreme points. In this case, the sum of
the squares of the errors should be exactly 0 as all points lie exactly on the
estimated line.
If instead of checking reg.getSumSquaredErrors() = 0.0 I print the value, I
get -7.105427357601002E-15 on my GNU/Linux box. This seems quite fair for me as
the computation involves computing a subtraction close to 35.28 - 35.28, where
both terms result from several former computations. This is consistent with
double precision.
What we observe here is simply a cancellation effect on subtraction. The result
is null in the first part of the test (where the x values are 100 times
smaller), slightly negative in the second part. I think the null result in the
first part is only good fortune (well, it is really related to the orders of
magnitude involved: x^2, y^2 and xy).
I suggest to consider this is not a bug.
I will add a patch with a slightly modified test case in a few minutes.
[math] SimpleRegression getSumSquaredErrors
Key: MATH-85
URL: http://issues.apache.org/jira/browse/MATH-85
Project: Commons Math
Type: Bug
Versions: 1.1.0
Environment: Operating System: Windows 2000
Platform: PC
Reporter: Mark Osborn
getSumSquaredErrors returns -ve value. See test below:
public void testSimpleRegression() {
double[] y = { 8915.102, 8919.302, 8923.502};
double[] x = { 1.107178495, 1.107264895, 1.107351295};
double[] x2 = { 1.107178495E2, 1.107264895E2, 1.107351295E2};
SimpleRegression reg = new SimpleRegression();
for (int i = 0; i x.length; i++) {
reg.addData(x[i],y[i]);
}
assertTrue(reg.getSumSquaredErrors() = 0.0); // OK
reg.clear();
for (int i = 0; i x.length; i++) {
reg.addData(x2[i],y[i]);
}
assertTrue(reg.getSumSquaredErrors() = 0.0); // FAIL
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-85) [math] SimpleRegression getSumSquaredErrors
[ 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
Key: MATH-85
URL: http://issues.apache.org/jira/browse/MATH-85
Project: Commons Math
Type: Bug
Versions: 1.1.0
Environment: Operating System: Windows 2000
Platform: PC
Reporter: Mark Osborn
Attachments: math-85.patch
getSumSquaredErrors returns -ve value. See test below:
public void testSimpleRegression() {
double[] y = { 8915.102, 8919.302, 8923.502};
double[] x = { 1.107178495, 1.107264895, 1.107351295};
double[] x2 = { 1.107178495E2, 1.107264895E2, 1.107351295E2};
SimpleRegression reg = new SimpleRegression();
for (int i = 0; i x.length; i++) {
reg.addData(x[i],y[i]);
}
assertTrue(reg.getSumSquaredErrors() = 0.0); // OK
reg.clear();
for (int i = 0; i x.length; i++) {
reg.addData(x2[i],y[i]);
}
assertTrue(reg.getSumSquaredErrors() = 0.0); // FAIL
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (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 that people often compute the square root of such sums, mainly to compare them with some dimensioning threshold. We really know that the value must be positive and that if it is negative, this is due to cancellation. Hence we could force the value in this case. Just replace the return statement by : Math.amx(0, sumYY - sumXY * sumXY / sumXX); ... and fix my test case by replacing ther 1.0e-14 back to = 0. Sorry, I didn't reflect enough Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r418646 - /jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/random/RandomDataTest.java
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 used. The former can block read access when the entropy pool gathering environmental noise is empty. This pool is replenished when events caused by keyboard use, mouse motion and interrupts from disk or other devices. This is the price to pay for cryptographically secure randomness except if you motherborad has some hardware-based random generator chip supported by the kernel (I think there are some) ... However this is far beyond the scope of this list. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-151) MathUtils.round incorrect result
[ 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 slightly shift the numbers (by one ulp) in the expected rounding direction in order to avoid some degenerate cases. Note that if someone REALLY wants to round a number like 39.24499974420461512636 and NOT 39.245, we will produce a wrong result. I didn't put any warning about this behaviour in the javadoc, but I think that if this patch is finally applied, the javadoc should be exlpicit. I understand the user problem but do not really like answering like that, it seems more like an ad hoc trick to me. I'm not very proud of my first patch :-( MathUtils.round incorrect result Key: MATH-151 URL: http://issues.apache.org/jira/browse/MATH-151 Project: Commons Math Type: Bug Versions: 1.1 Final Environment: Win2K, Sun JDK1.5.0_05 b05 Reporter: Buza Zoltán Attachments: math-151.patch MathUtils.round(39.245, 2) results 39.24, however it should be 39.25, with default rounding mode BigDecimal.ROUND_HALF_UP. I found that internally MathUtils.round multiplies the given number by 10^scale. 39.245 * 100.0 results 3924.4...5 , and after this the calculation is not correct any more. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-151) MathUtils.round incorrect result
[ 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 of the nextAfter method, either in MathUtils or in a new IeeeFunctions method in case we want also to add other interesting functions defined by the IEEE754 standard. The signature of this method is: static double nextAfter(double d, double direction) It returns the next representable number after its first argument which lies on the same side as the second argument. Using this, we could compare the rounding of x and nextAfter(x, x+1) when the rounding mode is ROUND_HALF_UP. If the results is different, the IEEE754 representation of x is on some boundary. In fact, I think we could always return the rounding of nextAfter in this mode (after all if round(x) and round(nextAfter(x)) are the same, we could return either and if they are not the same, we want to return round(nextAfter, at least in some rounding methods). The test could be performed in the roundUnscaled method, and similar tests could be implemented in the other branches of the switch for other rounding methods. This would be slower than the current implementation, but probably much faster than going back to rebuild a String and parsing it as a BigDecimal. I have written an implementation of nextAfter. It is based on Double.doubleToLongBits, bits twiddling, and Double.longBitsToDouble. MathUtils.round incorrect result Key: MATH-151 URL: http://issues.apache.org/jira/browse/MATH-151 Project: Commons Math Type: Bug Versions: 1.1 Final Environment: Win2K, Sun JDK1.5.0_05 b05 Reporter: Buza Zoltán MathUtils.round(39.245, 2) results 39.24, however it should be 39.25, with default rounding mode BigDecimal.ROUND_HALF_UP. I found that internally MathUtils.round multiplies the given number by 10^scale. 39.245 * 100.0 results 3924.4...5 , and after this the calculation is not correct any more. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-151) MathUtils.round incorrect result
[ 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 representation in IEE754. it lies between two representable numbers (I forgot 4 bits in my previous post): 0x139f5c28f5c28f * 2^-47 39.2450x139f5c28f5c290 * 2^-47 or 0x27.3eb851eb851e39.24527.3eb851eb8520 or 39.24499974420461512636...39.245 39.24500045474735088646... When we talk about 39.245, we refer to the decimal representation that was parsed either by some data input function using something like Double.parseDouble(String) or we refer to a litteral value in the Java code, which in fact is also parsed at compilation time, probably also by double.parseDouble(String) or a similar function. The virtual machine doesn't see the 39.245 real number we want, it sees either 0x27.3EB851EB851E or x27.3EB851EB8520 depending on the parsing behaviour. This is not a Java-related problem, it is also true for languages like C, C++, fortran, whatever. In the case discussed here, the value was the low one (i.e. 0x27.3EB851EB851E, or 39.24499974420461...). The parsing method did a good job here in my opinion as this number is the closest one to the real number we wanted (the error is about 2.55e-15 and it would have been 4.54e-15 if the other alternative were chosen). Going back to the initial problem, and assuming we now start from 39.24499974420461..., we want to round this number 2 digits after the decimal point. MathUtils.round answer is 39.24 (really 39.2419895...), which is only 0.00499954525264... away from out number. Answering 39.25 (which CAN be represented exactly in IEEE754) would be 0.0050002557953848... away. The initial number is not exactly at a 0.5 * 10^-n boundary, so switching between ROUND_HALF_DOWN, ROUND_HALF_UP or ROUND_HALF_EVEN does not change anything (I have checked this). MathUtils.round incorrect result Key: MATH-151 URL: http://issues.apache.org/jira/browse/MATH-151 Project: Commons Math Type: Bug Versions: 1.1 Final Environment: Win2K, Sun JDK1.5.0_05 b05 Reporter: Buza Zoltán MathUtils.round(39.245, 2) results 39.24, however it should be 39.25, with default rounding mode BigDecimal.ROUND_HALF_UP. I found that internally MathUtils.round multiplies the given number by 10^scale. 39.245 * 100.0 results 3924.4...5 , and after this the calculation is not correct any more. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-151) MathUtils.round incorrect result
[ 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 number of digits. For the sake of simplicity, here is the representation in base 16 (much more readable than base 2) : 0x27.3EB851EB851EB851EB851... Note that the pattern EB851 repeats itself ad infinitum, in base 2 it is a 20 bits pattern. If this number could be represented in a virtual infinite register, multiplying it by 100.0 (base 10) would be multiplying it by 0x64 (base 16) and the result would be 0xF54.8 which is 3924.5 as could be rounded as expected. However, primitive doubles are represented in Java using the IEEE754 norm, where the mantissa is 53 bits long, counting an implicit first bit. This implies that in the previous infinite number only the following is represented in IEE754: 0x27.3EB851EB851 hence, when this number is multiplied by 100, we get the result: 0xF54.7A4 or 3924.499477040546480566263198... So the error is exactly 0x0.05C or 92/16^11 which is approximately 5.229e-12. The problem comes from the fact the original number cannot be represented exactly (it is not what is sometimes called a floating-point number or normal number), and in this case the first neglected hexadecimal digit is large (E) which explains the large error (7 wrong bits after the multiplication). I would say this is not an issue with commons-math but with IEE754, we cannot do anything about it. Note that the same would occur if we could add one pattern by adding 20 bits. In this case, the final number would be 3924.450126700065666 and the error appoximately 4.987e-18 (92/16^16), but still lesser than 3924.5 MathUtils.round incorrect result Key: MATH-151 URL: http://issues.apache.org/jira/browse/MATH-151 Project: Commons Math Type: Bug Versions: 1.1 Final Environment: Win2K, Sun JDK1.5.0_05 b05 Reporter: Buza Zoltán MathUtils.round(39.245, 2) results 39.24, however it should be 39.25, with default rounding mode BigDecimal.ROUND_HALF_UP. I found that internally MathUtils.round multiplies the given number by 10^scale. 39.245 * 100.0 results 3924.4...5 , and after this the calculation is not correct any more. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] contributing Levenberg-Marquardt, Gauss-Newton, ODE, Brendt solver and more
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 projects, it is reliable and successfull, and used in several places. But I failed to gather myself a community around this project, and this is a major weakness. I am the sole developper behind Mantissa (except for one class which was contributed by a user and redesigned by me before inclusion). One developper means only one way of thinking, no peers reviews except from users, and a single point of failure. For now, I have been able to cope with this without problems and there are currently no identified bugs in the code base. Joining Apache will remove most of these problems. Of course, I will be the one who knows this part better at the beginning, but I hope others will look at this code and discuss about it to say what they like (I hope they will like some parts) and what they don't like, why and how it could be better done. This would be the best thing for this piece of code and its users. Another benefit for joining Apache is a much larger user base. This is mandatory for an open-source project. One housekeeping thing that we need to consider before we start to have real fun with Mantissa is to make sure that you *can* relicense and contribute portions of this code to apache. I can. I am the owner and developper of everything except for one contributed class, which is probably not interesting for Commons-Math (it is the Robert M. ZIff four-tap random numbers generator contributed to Mantissa by Bill Maier and redesigned by me). Everything was developped on my own spare time, and in addition I do have a specific clause concerning my open-source work in my contract with the company I work for, just to make sure there is no interference between private and paid work. Please have a look at the sections on this page http://www.apache.org/licenses/#clas on CLAs and Software Grants. If you and / or other Mantissa team members decide to contribute code to Apache based on Mantissa, you will need to be able to sign CLAs and, depending on how the code comes in, possibly a Software Grant (if we bring in a substantial amount of code in a lump instead of small, refactored bits incrementally, we need to do the Grant). I have read that. I will sign and send both the Individual Contributor License Agreement and the Software Grant (except for the FourTapRandom class, as I consider I do not have sufficient rights on it). I will snail mail both to the Forrest Hill Apache premises. Don't worry about the process stuff, I can handle that. The important thing is to make sure that a) you want to join the community and b) you can comply with the CLA and freely donate contributions. Feel free to ask questions here or offline. OK. For this introduction, I prefered to answer online. Now we can switch to a private discussion to avoid cluttering the list with this administrative stuff concerning only myself. Once again, thanks for your interest in commons-math and we look forward to working with you! Thanks to you to consider accepting my work. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] contributing Levenberg-Marquardt, Gauss-Newton, ODE, Brendt solver and more
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 similar, but I don't know (yet) the point were you consider commons problems addressed by Commons-Math end and where problems are considered too specific to be provided here. I would be very glad to donate parts of Mantissa code to Commons-Math if you wish so. Mantissa is released under a revised-BSD type license, but I am quite happy with Apache license too and ready to change. 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 (curve fitting, using the estimation package) - the Ordinary Differential Equations package this is clearly THE best package in Mantissa, with several state of the art integrators with fixed steps, variable stepsize (including Dormand-Prince 8 (5,3) and Gragg-Bulirsch-Stoer), all of them supporting continuous output and multiple switching functions (can be used for G-stop, but not limited to that), well tested and used - the roots package provides a Brent algorithm when the derivatives are not available Some package that may be interesting are : - the geometry package mainly for the 3D rotations implementations using quaternions internally and axes/angles, Cardan angles, Euler angles, matrices, single or double vectors pairs and quaternions in the interface - the functions package providing notions like computable or sampled functions - the quadrature package (Riemann, trapezoid, enhanced Simpson, Gauss-Legendre up to 5 points, easily extended) - the utilities package for the array mapping paradigm Some package that are probably not interesting are : - the algebra package orthogonal polynomials, inefficient and awkward implementation - the raw linear algebra package basic implementation developped for speed ... not sure the goal was achieved and using only straightforward algorithms, not state of the art - the random number generators supports correlated vectors generation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] contributing Levenberg-Marquardt, Gauss-Newton, ODE, Brendt solver and more
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 (curve fitting, using the estimation package) - the Ordinary Differential Equations package this is clearly THE best package in Mantissa, with several state of the art integrators with fixed steps, variable stepsize (including Dormand-Prince 8 (5,3) and Gragg-Bulirsch-Stoer), all of them supporting continuous output and multiple switching functions (can be used for G-stop, but not limited to that), well tested and used - the roots package provides a Brent algorithm when the derivatives are not available I forgot to talk about the optimization package (direct search methods using only functions values, without derivatives). This could also be interesting in addition to the estimation package. It provides one generic abstract solver and two implementations, Nelder-Mead and Virginia Torczon's mutidirectional search. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Q-R -decomposition
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 squares problems, you NEVER really compute Q explicitely, and if you don't retrieve Q, you don't retrieve R either. The decomposition algorithm keeps some information about Q (the Householder vectors, but also some coefficients and permutation indices if you want to support rank-deficient problems) and you use this information to compute transpose(Q).Q.V for some vector V without computing Q itself, and it uses R internally also to provide some higher level result, not Q and R to let you compute something with them. Q is a huge matrix, much larger than the Householder vectors it can be deduced from. This is especially true when the problem as a few parameters but a lot of measurements (in orbit determination problems, for example, you often have less than 10 parameters in the model and several tens of thousands of measurements). What makes least squares solving easier is not the QR decomposition itself, but the way it is used in the surrounding algorithm (Levenberg-Marquardt for example). In this case, you do NOT compute the normal equations (i.e. transpose(J).J where J is the jacobian matrix) and decompose the resulting square matrix like you would do in a Gauss-Newton solver. You decompose the jacobian matrix itself (this is the reason for the transpose(Q).Q.V part of the solver). Both decomposition are therefore not used the same way. The QR way is more accurate because there are situations where the squaring of the jacobian matrix involved in the normal equations computation leads to cancellation of some tiny values (epsilon - epsilon^2). For difficult problems, this is really important. On the other hand, using LU has other benefits. First, you may build the normal equations iteratively (i.e. build Jt.J by updating a matrix as measurements are considered one after the other) and second, the matrix size is small (mXm where m is the number of parameters of the model), which is smaller than the nXm matrix appearing in the QR decomposition (but beware, nobody really computes the nXn Q matrix). QR decomposition involves about twice the number of operations the LU decomposition. So the choice is size versus accuracy for simple problems, and you may only choose accuracy for difficult problems, as the other way alternative simply fails. For optimization problems, the Levenberg-Marquardt algorithm (which uses a QR decomposition as one of the many parts of the algorithm) is the method of choice you will find in many applications. It works really well and few people bother studying really what is the better alternative. In any case, for least squares problems, the decomposition used is an implementation choice and the user doesn't really need to see the intermediate steps (building J or not, decomposing Jt.J using LU or J using QR, applying residuals, updating the parameters). He chooses one method or the other and get the final result. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
