Re: [VOTE] Apache Commons to sponsor agimatec-validation incunbation
Sorry guys. Guess using my Yahoo mail and Thunderbird for list subscriptions was a bad idea I've been seeing other posts to the d...@commons list and directly to me, but none about this thread until today for some reason Niall, let me know if you need any help collecting the source tar to post with the SGA. Thanks, Donald Niall Pemberton wrote: On Wed, Dec 9, 2009 at 12:03 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Dec 7, 2009, at 9:00 PM, Niall Pemberton wrote: On Mon, Dec 7, 2009 at 8:16 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: So Niall, whats next and please if there is anything I can help in let me know about it. I was waiting for Donald to take the lead. Hes posted a couple of message about the vote which I responded to but he doesn't seem to be around much. Its ready AFAIC to post the proposal to gene...@incubator. I think Donald must be having subscription problems with this mailing list. Don't think he's seen either response (or the other notes). I've nudged him off-list. I tried that and got no response :( Niall --kevan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Apache Commons to sponsor agimatec-validation incunbation
They were all sitting in the spam folder in Yahoo mail. Sorry for that. -Donald Donald Woods wrote: Sorry guys. Guess using my Yahoo mail and Thunderbird for list subscriptions was a bad idea I've been seeing other posts to the d...@commons list and directly to me, but none about this thread until today for some reason Niall, let me know if you need any help collecting the source tar to post with the SGA. Thanks, Donald Niall Pemberton wrote: On Wed, Dec 9, 2009 at 12:03 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Dec 7, 2009, at 9:00 PM, Niall Pemberton wrote: On Mon, Dec 7, 2009 at 8:16 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: So Niall, whats next and please if there is anything I can help in let me know about it. I was waiting for Donald to take the lead. Hes posted a couple of message about the vote which I responded to but he doesn't seem to be around much. Its ready AFAIC to post the proposal to gene...@incubator. I think Donald must be having subscription problems with this mailing list. Don't think he's seen either response (or the other notes). I've nudged him off-list. I tried that and got no response :( Niall --kevan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] 1.3/1.4 RC1 available for review
On Dec 8, 2009, at 7:51 AM, Mark Thomas wrote: Phil Steitz wrote: I have prepared release candidates for DBCP 1.3 and 1.4. Please all interested parties have a look and test. If all goes well, I will kick off a release VOTE based on these artifacts in the next couple of days. I see these as really two sets of artifacts associated with one release, so I am inclined to just do one VOTE including both versions. If anyone disagrees with this, please speak up. I am happy to run two VOTEs. They look good to me. +1 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Apache Commons to sponsor agimatec-validation incunbation
On Wed, Dec 9, 2009 at 12:35 PM, Donald Woods dwo...@apache.org wrote: Sorry guys. Guess using my Yahoo mail and Thunderbird for list subscriptions was a bad idea I've been seeing other posts to the d...@commons list and directly to me, but none about this thread until today for some reason Niall, let me know if you need any help collecting the source tar to post with the SGA. I have checked the foundation records and found the SGA (its recorded now as keba-agimatec.pdf). I don't think we need to do anything with the source until the proposal has been accepted by the incubator. So the next thing is to post the proposal to gene...@incubator. Give an opportunity for discussion - once thats complete then call a vote. I was hoping you would do that, but if not then I can. Niall Thanks, Donald Niall Pemberton wrote: On Wed, Dec 9, 2009 at 12:03 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Dec 7, 2009, at 9:00 PM, Niall Pemberton wrote: On Mon, Dec 7, 2009 at 8:16 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: So Niall, whats next and please if there is anything I can help in let me know about it. I was waiting for Donald to take the lead. Hes posted a couple of message about the vote which I responded to but he doesn't seem to be around much. Its ready AFAIC to post the proposal to gene...@incubator. I think Donald must be having subscription problems with this mailing list. Don't think he's seen either response (or the other notes). I've nudged him off-list. I tried that and got no response :( Niall --kevan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Lang package name change. Was: [(LANG-561) unescapeHtml has been dropped without going through deprecation]
Guys, following the list over Gmane it is not even possible to post to the issues list ... - Jörg sebb wrote at Mittwoch, 9. Dezember 2009 16:18: Fine by me too. If the package name change is agreed then I'm happy to close LANG-561. Also, we probably ought to make 2.x the 'default' Gump project for LANG, so other projects have to deliberately choose lang-3. On 09/12/2009, Paul Benedict pbened...@apache.org wrote: After thoughtful deliberation, I also favor lang3 package change. My reasoning is so that migration is not an all-or-nothing for users. They can use both lang 3 and lang 3 simultaneously and transition overtime. Paul On 12/9/2009 2:52 AM, Henri Yandell wrote: Sorry - forgot the marker. On Wed, Dec 9, 2009 at 12:51 AM, Henri Yandellflame...@gmail.com wrote: Perhaps now is the right time to do the package change? Does anyone have a better idea than: org.apache.commons.lang - org.apache.commons.lang3? That kind of sets us up for lang 4.0 needing a package change as well, but I don't think that's necessarily a bad thing. Hen On Tue, Dec 8, 2009 at 11:00 AM, Niall Pemberton (JIRA)j...@apache.org wrote: [ https://issues.apache.org/jira/browse/LANG-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanelfocusedCommentId=12787657#action_12787657 ] Niall Pemberton commented on LANG-561: -- Presumably there is going to be a package name change before Lang 3.0 is released? If so everything breaks. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Lang package name change. Was: [(LANG-561) unescapeHtml has been dropped without going through deprecation]
On 2009-12-09, sebb seb...@gmail.com wrote: Also, we probably ought to make 2.x the 'default' Gump project for LANG, so other projects have to deliberately choose lang-3. I'd assume the Maven groupId would change as well, so any projects building with mvn will only ever see one of either. For Ant and Maven 1.x projects, it will be pretty easy to make them use Lang 2.x in Gump and we'll see pretty fast which ones will need to migrate. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[math] getting changes included into commons-math (was Re: Home for the colt fork)
Ted Dunning a écrit : Actually, the reason that we have Colt in Mahout is it has proven impossible to get changes into commons math. We really, really wanted to use commons math rather than have our own linear algebra package, but it just proved impossible and we didn't want to wait forever. If you really, really wants to use commons math and want changes to be included, contribute them. I think the only change that was proposed and not done because of lack of consensus was the inclusion of MTJ (and I don't consider the discussion closed on that topic either, so it may still happen some day). All the other changes that are desired are simply lacking someone to do the work. There were proposals to extend the linear algebra API, proposals to add more support for sparse matrices, proposals to get partial decomposition ... But sparse contributions (pun intended). I try to do what I can, but as you have probably seen have been rather silent since 2.0 release. For my part, I really, really need help. I would like to fix the problems in the eigen decomposition and SVD but need a good kick to get on it, and having only requests and no help is not really motivating. Luc If that problem were solved, then it would be great to depend on commons math. If that problem isn't solved, then there is no way to depend on commons math. On Tue, Dec 8, 2009 at 6:19 AM, Benson Margulies bimargul...@gmail.comwrote: We can't possibly have a dependency on Mahout in the long term. Either we all go shares on code in some other piece of commons, or we end up with two forks, which would be sad. On Tue, Dec 8, 2009 at 8:33 AM, James Carman ja...@carmanconsulting.com wrote: I wouldn't like to see a dependency on mahout code in a commons library. That seems kind of backwards. If Mahout wants to offload this stuff, we can move it into a library in commons (which is typically how stuff used to happen in Jakarta). On Tue, Dec 8, 2009 at 8:18 AM, Benson Margulies bimargul...@gmail.com wrote: Mahout now has a fork of a portion of the 'category A' portion of the CERN colt library forked. The Mahout fork is, of course, in the Mahout tree under a Mahout Java package and Maven triple. I want to use the collections classes from Mahout as the core to a new set of commons-primitives classes that do the useful things that GNU Trove does. The classes I want to start from depend on the classes that are in the Mahout fork. As a temporary expedient, I can depend on their there. However, I submit that it would be more better if the mathematical code were in commons-math. Was this option explored? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Colt vs. Primitives
So, the silence is rather noisy in response to the discussion about commons-math. Commons PMC members, what's the story here? Why is it apparently easy for me to tee up code for primitives and impossible for the corresponding activity for -math? On Mon, Dec 7, 2009 at 5:26 PM, Ted Dunning ted.dunn...@gmail.com wrote: Bring them in! We will likely need them as well. On Mon, Dec 7, 2009 at 2:23 PM, Benson Margulies bimargul...@gmail.comwrote: maps. On Dec 7, 2009, at 5:16 PM, Ted Dunning ted.dunn...@gmail.com wrote: Which part did you care about? On Mon, Dec 7, 2009 at 2:12 PM, Benson Margulies bimargul...@gmail.com wrote: Aha, you didn't take the part I care about most, but your grab of the jet stuff may help me grab the collections stuff. This is almost messy enough for me to go back to coding from scratch from Knuth. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Ted Dunning, CTO DeepDyve - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Advertising (for free)
stackoverflow.com is accepting free filler adds from open source things. Should this group come up with an add for asf-via-mentoring? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Advertising (for free)
On Wed, Dec 9, 2009 at 10:50 AM, Benson Margulies bimargul...@gmail.com wrote: stackoverflow.com is accepting free filler adds from open source things. Should this group come up with an add for asf-via-mentoring? This group? No. Anything we do there would need to go through the PRC: http://www.apache.org/press/ -- Martin Cooper - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] getting changes included into commons-math (was Re: Home for the colt fork)
This is interesting. We have a raft of mathematically qualified committers on Mahout, and this message asking for help on commons-math, and a raft of code marooned at mahout that wants to be in commons math. If I were one of those mathematically competant individuals, I'd be off attaching a patch or three to a JIRA or two ... On Wed, Dec 9, 2009 at 1:48 PM, Luc Maisonobe luc.maison...@free.fr wrote: Ted Dunning a écrit : Actually, the reason that we have Colt in Mahout is it has proven impossible to get changes into commons math. We really, really wanted to use commons math rather than have our own linear algebra package, but it just proved impossible and we didn't want to wait forever. If you really, really wants to use commons math and want changes to be included, contribute them. I think the only change that was proposed and not done because of lack of consensus was the inclusion of MTJ (and I don't consider the discussion closed on that topic either, so it may still happen some day). All the other changes that are desired are simply lacking someone to do the work. There were proposals to extend the linear algebra API, proposals to add more support for sparse matrices, proposals to get partial decomposition ... But sparse contributions (pun intended). I try to do what I can, but as you have probably seen have been rather silent since 2.0 release. For my part, I really, really need help. I would like to fix the problems in the eigen decomposition and SVD but need a good kick to get on it, and having only requests and no help is not really motivating. Luc If that problem were solved, then it would be great to depend on commons math. If that problem isn't solved, then there is no way to depend on commons math. On Tue, Dec 8, 2009 at 6:19 AM, Benson Margulies bimargul...@gmail.comwrote: We can't possibly have a dependency on Mahout in the long term. Either we all go shares on code in some other piece of commons, or we end up with two forks, which would be sad. On Tue, Dec 8, 2009 at 8:33 AM, James Carman ja...@carmanconsulting.com wrote: I wouldn't like to see a dependency on mahout code in a commons library. That seems kind of backwards. If Mahout wants to offload this stuff, we can move it into a library in commons (which is typically how stuff used to happen in Jakarta). On Tue, Dec 8, 2009 at 8:18 AM, Benson Margulies bimargul...@gmail.com wrote: Mahout now has a fork of a portion of the 'category A' portion of the CERN colt library forked. The Mahout fork is, of course, in the Mahout tree under a Mahout Java package and Maven triple. I want to use the collections classes from Mahout as the core to a new set of commons-primitives classes that do the useful things that GNU Trove does. The classes I want to start from depend on the classes that are in the Mahout fork. As a temporary expedient, I can depend on their there. However, I submit that it would be more better if the mathematical code were in commons-math. Was this option explored? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Lang package name change. Was: [(LANG-561) unescapeHtml has been dropped without going through deprecation]
I hope to see org.apache.commons:commons-lang:3.0 Paul On Wed, Dec 9, 2009 at 11:14 AM, Stefan Bodewig bode...@apache.org wrote: On 2009-12-09, sebb seb...@gmail.com wrote: Also, we probably ought to make 2.x the 'default' Gump project for LANG, so other projects have to deliberately choose lang-3. I'd assume the Maven groupId would change as well, so any projects building with mvn will only ever see one of either. For Ant and Maven 1.x projects, it will be pretty easy to make them use Lang 2.x in Gump and we'll see pretty fast which ones will need to migrate. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-configuration-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 112 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-configuration-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/configuration/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/configuration/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/gump_work/build_apache-commons_commons-configuration-test.html Work Name: build_apache-commons_commons-configuration-test (Type: Build) Work ended in a state of : Failed Elapsed: 6 mins 57 secs Command Line: mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/configuration] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/configuration/target/commons-configuration-1.7-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/jexl/target/commons-jexl-2.0-SNAPSHOT.jar - testInitCopy(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDelimiterParsingDisabled(org.apache.commons.configuration.TestXMLConfiguration) testSetRootAttribute(org.apache.commons.configuration.TestXMLConfiguration) testLoadAndSaveFromFile(org.apache.commons.configuration.TestXMLConfiguration) testSaveToURL(org.apache.commons.configuration.TestXMLConfiguration) testSaveToStream(org.apache.commons.configuration.TestXMLConfiguration) testAutoSave(org.apache.commons.configuration.TestXMLConfiguration) testSaveAttributes(org.apache.commons.configuration.TestXMLConfiguration) testCloneWithSave(org.apache.commons.configuration.TestXMLConfiguration) testEmptyElements(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithNullEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctype(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctypeIDs(org.apache.commons.configuration.TestXMLConfiguration) testSubsetWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationsAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testGetKeysWithReload(org.apache.commons.configuration.TestXMLConfiguration) testSetTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testClearTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabled(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabledAttrs(org.apache.commons.configuration.TestXMLConfiguration) testMultipleAttrValuesEscaped(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithReloadingStrategy(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveAddNodes(org.apache.commons.configuration.TestXMLConfiguration) testAddNodesAndSave(org.apache.commons.configuration.TestXMLConfiguration) testRegisterEntityId(org.apache.commons.configuration.TestXMLConfiguration) testSaveAfterCreateWithCopyConstructor(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootName(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootNameNoDocument(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithValidation(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithValidationFailure(org.apache.commons.configuration.TestXMLConfiguration) Tests run: 1456, Failures: 0, Errors: 60, Skipped: 0 [INFO]
Re: [math] getting changes included into commons-math (was Re: Home for the colt fork)
On Wed, Dec 9, 2009 at 11:09 AM, Benson Margulies bimargul...@gmail.comwrote: This is interesting. We have a raft of mathematically qualified committers on Mahout, and this message asking for help on commons-math, and a raft of code marooned at mahout that wants to be in commons math. If I were one of those mathematically competant individuals, I'd be off attaching a patch or three to a JIRA or two The commons-math linear APIs have been described as effectively locked until 3.0, due to back-compat requirements. This means that any code contributed into c-math would live in a parallel (no pun intended) to the linear primitives which exist already in there. Adopting something like MTJ or Colt in Mahout turned out to be easier, because we are on release 0.2 (heading for 0.3 now), and have less stringent back-compat requirements, so we are overhauling our linear apis (read: even user-facing interface changes) to take advantage of useful parts of Colt, and are planning on using our Colt fork as the underlying implementation. Commons-math expressed that changing linear APIs is not something they can do, given the maturity of their library, so where would Colt *go* in c-math? It's own submodule, having its own eigendecompositions and svd and so forth, running parallel to the current c-math impls? Why? Who would maintain it and write tests for it, and how do you explain to end-users which they should use? On Wed, Dec 9, 2009 at 1:48 PM, Luc Maisonobe luc.maison...@free.fr wrote: Ted Dunning a écrit : Actually, the reason that we have Colt in Mahout is it has proven impossible to get changes into commons math. We really, really wanted to use commons math rather than have our own linear algebra package, but it just proved impossible and we didn't want to wait forever. If you really, really wants to use commons math and want changes to be included, contribute them. I have submitted patches for the following tickets: MATH-312 (and acceptance of that patch blocks my patch for MATH-314), MATH-316 and MATH-317, none of which have appear to have had much progress on. All of my patches come with unit tests for new functionality. On the other hand, when I opened the discussion about extending the functions package to enable composable functions (MATH-313), I got an entirely hostile response, which only tempered as far as +0 on adding it after discussion. In particular, my first step at making commons-math something Mahout could standardize on for linear work was MATH-312, which I did submit a patch for, and revised it many times after discussion about what is acceptable practice in c-math. Not yet applied, months later. It's probably far out of date now... Similarly, when I tried to ask what the status on decisions on whether to adopt MTJ or Colt, the statement by Phil was basically that commons-math would not adopt anything which had any external dependencies or not-easily-human-readable java source (which ruled out MTJ because of f2j produced code), and which had to be fully tested and maintained prior to adoption (which rules out Colt which has no unit tests yet). Ted and I weren't making requests for other people to do work, we were wondering whether even offers to do some of the work would be accepted, and for many of the questions/suggestions we had, it seems the desires and requirements of the Mahout community were incompatible with those of commons-math. -jake I think the only change that was proposed and not done because of lack of consensus was the inclusion of MTJ (and I don't consider the discussion closed on that topic either, so it may still happen some day). All the other changes that are desired are simply lacking someone to do the work. There were proposals to extend the linear algebra API, proposals to add more support for sparse matrices, proposals to get partial decomposition ... But sparse contributions (pun intended). I try to do what I can, but as you have probably seen have been rather silent since 2.0 release. For my part, I really, really need help. I would like to fix the problems in the eigen decomposition and SVD but need a good kick to get on it, and having only requests and no help is not really motivating. Luc If that problem were solved, then it would be great to depend on commons math. If that problem isn't solved, then there is no way to depend on commons math. On Tue, Dec 8, 2009 at 6:19 AM, Benson Margulies bimargul...@gmail.com wrote: We can't possibly have a dependency on Mahout in the long term. Either we all go shares on code in some other piece of commons, or we end up with two forks, which would be sad. On Tue, Dec 8, 2009 at 8:33 AM, James Carman ja...@carmanconsulting.com wrote: I wouldn't like to see a dependency on mahout code in a commons library. That seems kind of backwards. If Mahout wants to offload this stuff, we can move it into a library in commons
Re: [math] getting changes included into commons-math (was Re: Home for the colt fork)
Similarly, https://issues.apache.org/jira/browse/MATH-310 had code from a contributor and got totally shot down basically with We don't care what you think, we don't want it. Extensive attempts on my part to find common ground just got shot down by Phil with -1 and essentially no more discussion than don't like it. Mahout has some unusual requirements and definitely can't use Math as is. It is also fast moving and needs changes to actually happen. The experience has been that only totally trivial non-changes get accepted ( https://issues.apache.org/jira/browse/MATH-267 and https://issues.apache.org/jira/browse/MATH-222 are examples). Anything more interesting seems to get bogged down in NIH or endless alternations of not-now we are about to have a major release and can't be distracted and not-now because we aren't doing a major release and have stay compatible. On Wed, Dec 9, 2009 at 11:58 AM, Jake Mannix jake.man...@gmail.com wrote: On Wed, Dec 9, 2009 at 11:09 AM, Benson Margulies bimargul...@gmail.com wrote: This is interesting. We have a raft of mathematically qualified committers on Mahout, and this message asking for help on commons-math, and a raft of code marooned at mahout that wants to be in commons math. If I were one of those mathematically competant individuals, I'd be off attaching a patch or three to a JIRA or two The commons-math linear APIs have been described as effectively locked until 3.0, due to back-compat requirements. This means that any code contributed into c-math would live in a parallel (no pun intended) to the linear primitives which exist already in there. Adopting something like MTJ or Colt in Mahout turned out to be easier, because we are on release 0.2 (heading for 0.3 now), and have less stringent back-compat requirements, so we are overhauling our linear apis (read: even user-facing interface changes) to take advantage of useful parts of Colt, and are planning on using our Colt fork as the underlying implementation. Commons-math expressed that changing linear APIs is not something they can do, given the maturity of their library, so where would Colt *go* in c-math? It's own submodule, having its own eigendecompositions and svd and so forth, running parallel to the current c-math impls? Why? Who would maintain it and write tests for it, and how do you explain to end-users which they should use? On Wed, Dec 9, 2009 at 1:48 PM, Luc Maisonobe luc.maison...@free.fr wrote: Ted Dunning a écrit : Actually, the reason that we have Colt in Mahout is it has proven impossible to get changes into commons math. We really, really wanted to use commons math rather than have our own linear algebra package, but it just proved impossible and we didn't want to wait forever. If you really, really wants to use commons math and want changes to be included, contribute them. I have submitted patches for the following tickets: MATH-312 (and acceptance of that patch blocks my patch for MATH-314), MATH-316 and MATH-317, none of which have appear to have had much progress on. All of my patches come with unit tests for new functionality. On the other hand, when I opened the discussion about extending the functions package to enable composable functions (MATH-313), I got an entirely hostile response, which only tempered as far as +0 on adding it after discussion. In particular, my first step at making commons-math something Mahout could standardize on for linear work was MATH-312, which I did submit a patch for, and revised it many times after discussion about what is acceptable practice in c-math. Not yet applied, months later. It's probably far out of date now... Similarly, when I tried to ask what the status on decisions on whether to adopt MTJ or Colt, the statement by Phil was basically that commons-math would not adopt anything which had any external dependencies or not-easily-human-readable java source (which ruled out MTJ because of f2j produced code), and which had to be fully tested and maintained prior to adoption (which rules out Colt which has no unit tests yet). Ted and I weren't making requests for other people to do work, we were wondering whether even offers to do some of the work would be accepted, and for many of the questions/suggestions we had, it seems the desires and requirements of the Mahout community were incompatible with those of commons-math. -jake I think the only change that was proposed and not done because of lack of consensus was the inclusion of MTJ (and I don't consider the discussion closed on that topic either, so it may still happen some day). All the other changes that are desired are simply lacking someone to do the work. There were proposals to extend the linear algebra API, proposals to add more support for sparse matrices, proposals to get partial decomposition ... But sparse contributions (pun intended).
Re: [math] getting changes included into commons-math (was Re: Home for the colt fork)
I don't want to denigrate the large contributions of Phil and Luc (especially Luc), but I have drawn a stronger conclusion that it isn't worth my time to contribute to commons-math because interesting changes likely won't get accepted. On Wed, Dec 9, 2009 at 11:58 AM, Jake Mannix jake.man...@gmail.com wrote: Ted and I weren't making requests for other people to do work, we were wondering whether even offers to do some of the work would be accepted, -- Ted Dunning, CTO DeepDyve
Re: [math] getting changes included into commons-math (was Re: Home for the colt fork)
Jake Mannix a écrit : On Wed, Dec 9, 2009 at 11:09 AM, Benson Margulies bimargul...@gmail.comwrote: This is interesting. We have a raft of mathematically qualified committers on Mahout, and this message asking for help on commons-math, and a raft of code marooned at mahout that wants to be in commons math. If I were one of those mathematically competant individuals, I'd be off attaching a patch or three to a JIRA or two The commons-math linear APIs have been described as effectively locked until 3.0, due to back-compat requirements. This means that any code contributed into c-math would live in a parallel (no pun intended) to the linear primitives which exist already in there. Adopting something like MTJ or Colt in Mahout turned out to be easier, because we are on release 0.2 (heading for 0.3 now), and have less stringent back-compat requirements, so we are overhauling our linear apis (read: even user-facing interface changes) to take advantage of useful parts of Colt, and are planning on using our Colt fork as the underlying implementation. Commons-math expressed that changing linear APIs is not something they can do, given the maturity of their library, so where would Colt *go* in c-math? It's own submodule, having its own eigendecompositions and svd and so forth, running parallel to the current c-math impls? Why? Who would maintain it and write tests for it, and how do you explain to end-users which they should use? On Wed, Dec 9, 2009 at 1:48 PM, Luc Maisonobe luc.maison...@free.fr wrote: Ted Dunning a écrit : Actually, the reason that we have Colt in Mahout is it has proven impossible to get changes into commons math. We really, really wanted to use commons math rather than have our own linear algebra package, but it just proved impossible and we didn't want to wait forever. If you really, really wants to use commons math and want changes to be included, contribute them. I have submitted patches for the following tickets: MATH-312 (and acceptance of that patch blocks my patch for MATH-314), MATH-316 and MATH-317, none of which have appear to have had much progress on. All of my patches come with unit tests for new functionality. I had these patches in my backlog and considered them accepted. I should have commited them before, sorry for that. I'll take care of them right now. On the other hand, when I opened the discussion about extending the functions package to enable composable functions (MATH-313), I got an entirely hostile response, which only tempered as far as +0 on adding it after discussion. The discussion was not entirely hostile as we get some intermediate consensus at some points. I understand your feelings after several patches that did not get committed fast enough. Please accept my apologizes for this. Luc In particular, my first step at making commons-math something Mahout could standardize on for linear work was MATH-312, which I did submit a patch for, and revised it many times after discussion about what is acceptable practice in c-math. Not yet applied, months later. It's probably far out of date now... Similarly, when I tried to ask what the status on decisions on whether to adopt MTJ or Colt, the statement by Phil was basically that commons-math would not adopt anything which had any external dependencies or not-easily-human-readable java source (which ruled out MTJ because of f2j produced code), and which had to be fully tested and maintained prior to adoption (which rules out Colt which has no unit tests yet). Ted and I weren't making requests for other people to do work, we were wondering whether even offers to do some of the work would be accepted, and for many of the questions/suggestions we had, it seems the desires and requirements of the Mahout community were incompatible with those of commons-math. -jake I think the only change that was proposed and not done because of lack of consensus was the inclusion of MTJ (and I don't consider the discussion closed on that topic either, so it may still happen some day). All the other changes that are desired are simply lacking someone to do the work. There were proposals to extend the linear algebra API, proposals to add more support for sparse matrices, proposals to get partial decomposition ... But sparse contributions (pun intended). I try to do what I can, but as you have probably seen have been rather silent since 2.0 release. For my part, I really, really need help. I would like to fix the problems in the eigen decomposition and SVD but need a good kick to get on it, and having only requests and no help is not really motivating. Luc If that problem were solved, then it would be great to depend on commons math. If that problem isn't solved, then there is no way to depend on commons math. On Tue, Dec 8, 2009 at 6:19 AM, Benson Margulies bimargul...@gmail.com wrote: We can't possibly have a
Re: Colt vs. Primitives
Hi Benson, I would assume that contributing to commons-math requires some good math background whereas primitives seem a little bit easier ... :-) Cheers, Siegfried Goeschl Benson Margulies wrote: So, the silence is rather noisy in response to the discussion about commons-math. Commons PMC members, what's the story here? Why is it apparently easy for me to tee up code for primitives and impossible for the corresponding activity for -math? On Mon, Dec 7, 2009 at 5:26 PM, Ted Dunning ted.dunn...@gmail.com wrote: Bring them in! We will likely need them as well. On Mon, Dec 7, 2009 at 2:23 PM, Benson Margulies bimargul...@gmail.comwrote: maps. On Dec 7, 2009, at 5:16 PM, Ted Dunning ted.dunn...@gmail.com wrote: Which part did you care about? On Mon, Dec 7, 2009 at 2:12 PM, Benson Margulies bimargul...@gmail.com wrote: Aha, you didn't take the part I care about most, but your grab of the jet stuff may help me grab the collections stuff. This is almost messy enough for me to go back to coding from scratch from Knuth. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Ted Dunning, CTO DeepDyve - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] getting changes included into commons-math (was Re: Home for the colt fork)
I can see how everyone ends up with a headache here. As the person who threw the most recent rock into the lake, let me re-present the situation as I got into it. CERN Colt is a library with a mixture of 'category A' material and 'category B-or-worse' material. In other words, it is not an attractive dependency for ASF code as a lump. Part of the 'category A' code is a set of very pretty associative containers for primitive types. My goal is to take this code and modernize it to use Generics as appropriate -- and otherwise make it a replacement for the LGPL Trove library. The associative code uses some math code. I'm pretty sure that all of the math code that it uses is also category A. In fact, I believe that all of it is in the portion that Mahout forked. This includes some things that aren't in commons-math at all. So, we have some adoptable code in Colt that overlaps functionality in -math, some that doesn't, and some that I want to use as the basis for work in -primitives. If the messages in this thread mean that the code already in -math is in fact moving in a direction to support mahout, then it might be acceptable for the additional, non-overlapping, Colt math code to end up in -math, and then everyone ends up happy? Another question: OK, -math is a stable, high-compatibility library. Mahout, on the other hand, wants to be a fast-moving, somewhat fluid, build of code (naturally including some math code) adapted for map-reduce. So, how about a branch of math that could release frequently with a new major version number? Obviously, from a work standpoint, this would depend on some of the Mahouts achieving committer status in commons. On Wed, Dec 9, 2009 at 3:46 PM, Luc Maisonobe luc.maison...@free.fr wrote: Jake Mannix a écrit : On Wed, Dec 9, 2009 at 11:09 AM, Benson Margulies bimargul...@gmail.comwrote: This is interesting. We have a raft of mathematically qualified committers on Mahout, and this message asking for help on commons-math, and a raft of code marooned at mahout that wants to be in commons math. If I were one of those mathematically competant individuals, I'd be off attaching a patch or three to a JIRA or two The commons-math linear APIs have been described as effectively locked until 3.0, due to back-compat requirements. This means that any code contributed into c-math would live in a parallel (no pun intended) to the linear primitives which exist already in there. Adopting something like MTJ or Colt in Mahout turned out to be easier, because we are on release 0.2 (heading for 0.3 now), and have less stringent back-compat requirements, so we are overhauling our linear apis (read: even user-facing interface changes) to take advantage of useful parts of Colt, and are planning on using our Colt fork as the underlying implementation. Commons-math expressed that changing linear APIs is not something they can do, given the maturity of their library, so where would Colt *go* in c-math? It's own submodule, having its own eigendecompositions and svd and so forth, running parallel to the current c-math impls? Why? Who would maintain it and write tests for it, and how do you explain to end-users which they should use? On Wed, Dec 9, 2009 at 1:48 PM, Luc Maisonobe luc.maison...@free.fr wrote: Ted Dunning a écrit : Actually, the reason that we have Colt in Mahout is it has proven impossible to get changes into commons math. We really, really wanted to use commons math rather than have our own linear algebra package, but it just proved impossible and we didn't want to wait forever. If you really, really wants to use commons math and want changes to be included, contribute them. I have submitted patches for the following tickets: MATH-312 (and acceptance of that patch blocks my patch for MATH-314), MATH-316 and MATH-317, none of which have appear to have had much progress on. All of my patches come with unit tests for new functionality. I had these patches in my backlog and considered them accepted. I should have commited them before, sorry for that. I'll take care of them right now. On the other hand, when I opened the discussion about extending the functions package to enable composable functions (MATH-313), I got an entirely hostile response, which only tempered as far as +0 on adding it after discussion. The discussion was not entirely hostile as we get some intermediate consensus at some points. I understand your feelings after several patches that did not get committed fast enough. Please accept my apologizes for this. Luc In particular, my first step at making commons-math something Mahout could standardize on for linear work was MATH-312, which I did submit a patch for, and revised it many times after discussion about what is acceptable practice in c-math. Not yet applied, months later. It's probably far out of date now... Similarly, when I tried to ask what the status on decisions on whether
Re: Colt vs. Primitives
Yes, of course. I'm not qualified to do much for Math, but Ted and others at Mahout are. On Wed, Dec 9, 2009 at 4:05 PM, Siegfried Goeschl siegfried.goes...@it20one.at wrote: Hi Benson, I would assume that contributing to commons-math requires some good math background whereas primitives seem a little bit easier ... :-) Cheers, Siegfried Goeschl Benson Margulies wrote: So, the silence is rather noisy in response to the discussion about commons-math. Commons PMC members, what's the story here? Why is it apparently easy for me to tee up code for primitives and impossible for the corresponding activity for -math? On Mon, Dec 7, 2009 at 5:26 PM, Ted Dunning ted.dunn...@gmail.com wrote: Bring them in! We will likely need them as well. On Mon, Dec 7, 2009 at 2:23 PM, Benson Margulies bimargul...@gmail.comwrote: maps. On Dec 7, 2009, at 5:16 PM, Ted Dunning ted.dunn...@gmail.com wrote: Which part did you care about? On Mon, Dec 7, 2009 at 2:12 PM, Benson Margulies bimargul...@gmail.com wrote: Aha, you didn't take the part I care about most, but your grab of the jet stuff may help me grab the collections stuff. This is almost messy enough for me to go back to coding from scratch from Knuth. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Ted Dunning, CTO DeepDyve - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] getting changes included into commons-math (was Re: Home for the colt fork)
On Wed, Dec 9, 2009 at 12:46 PM, Luc Maisonobe luc.maison...@free.frwrote: I have submitted patches for the following tickets: MATH-312 (and acceptance of that patch blocks my patch for MATH-314), MATH-316 and MATH-317, none of which have appear to have had much progress on. All of my patches come with unit tests for new functionality. I had these patches in my backlog and considered them accepted. I should have commited them before, sorry for that. I'll take care of them right now. On the other hand, when I opened the discussion about extending the functions package to enable composable functions (MATH-313), I got an entirely hostile response, which only tempered as far as +0 on adding it after discussion. The discussion was not entirely hostile as we get some intermediate consensus at some points. I understand your feelings after several patches that did not get committed fast enough. Please accept my apologizes for this. Luc, looking back over that thread, I should say that no, it was not entirely hostile - and we did come to more of a consensus later on (although even that consensus was given a very lukewarm +0 from Phil). I apologize for any implication that I was being treated poorly or unfairly. It just seems that as Benson says later, that the rate of change of c-math and mahout are rather different, and this discussion around those JIRA tickets simply highlighted what this understanding was. -jake
Re: [math] getting changes included into commons-math (was Re: Home for the colt fork)
On Wed, Dec 9, 2009 at 1:17 PM, Benson Margulies bimargul...@gmail.comwrote: CERN Colt is a library with a mixture of 'category A' material and 'category B-or-worse' material. In other words, it is not an attractive dependency for ASF code as a lump. Yep, that's why when I made my original patch of Colt for Mahout, I stripped out all dependency on the 'category B-or-worse' material, and tried to keep everything else other than the physics specific stuff that nobody was going to need. Part of the 'category A' code is a set of very pretty associative containers for primitive types. My goal is to take this code and modernize it to use Generics as appropriate -- and otherwise make it a replacement for the LGPL Trove library. I believe Mahout kept all this: look in o.a.m.matrix.list and o.a.m.matrix.map The package name they're both in (o.a.m.matrix) is bad - it used to be colt, but that name is trademarked by CERN, so even if the code is freely licensable, the name isn't. It might be better called collections or something. The associative code uses some math code. I'm pretty sure that all of the math code that it uses is also category A. In fact, I believe that all of it is in the portion that Mahout forked. This includes some things that aren't in commons-math at all. Oh, this is what you're saying here, ok. So, we have some adoptable code in Colt that overlaps functionality in -math, some that doesn't, and some that I want to use as the basis for work in -primitives. The stuff you want in primitives is also stuff we use/want to use for our linear work in Mahout, by the way (OpenDoubleIntHashMap, DoubleArrayList, etc...). If the messages in this thread mean that the code already in -math is in fact moving in a direction to support mahout, then it might be acceptable for the additional, non-overlapping, Colt math code to end up in -math, and then everyone ends up happy? None of the patches mentioned above contain Colt code, so no, c-math is not moving in a direction to support what mahout needs, not really, because of the backwards compatibility constraints and the fact that it's hard to tell what is the non-overlapping part of Colt math: for example: vectors in Colt provide complex aggregation methods, but c-math vectors do not (as an interface). Is this non-overlapping code? If it is, then how would you suppose this would be incorporated in c-math? Add a new interface, the ColtVector, which is basically the same as c-math's RealVector, but with some methods removed and some others added? This doesn't really make sense. Implementations are one thing, but interfaces which consumers see is another. Another question: OK, -math is a stable, high-compatibility library. Mahout, on the other hand, wants to be a fast-moving, somewhat fluid, build of code (naturally including some math code) adapted for map-reduce. So, how about a branch of math that could release frequently with a new major version number? Well, actually, a more feasible version of this, instead of branches, would be to use the current experimental source submodule in commons-math. If that could be a faster moving fluid build which could include colt math etc, that would be great, and Mahout could possibly use this. This brings up another point though: if commons-primitives is what you're creating, and want to base it on colt, well, we in Mahout could probably handle depending on you, but colt math linear depends on these, so can commons-math depend on commons-primitives, or does that violate c-math's no external dependencies rule? This would keep c-math from adopting colt math, because those would need the colt-primitives stuff. -jake
Re: svn commit: r889008 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/linear/ site/xdoc/ test/java/org/apache/commons/math/linear/
There are some things I don't like about this, but will try to find the time
to fix them myself . Comments inline (and I can't veto anything in [math],
so these are just suggestions).
- Original Message -
From: l...@apache.org
To: comm...@commons.apache.org
Sent: Wednesday, December 09, 2009 2:56 PM
Subject: svn commit: r889008 - in /commons/proper/math/trunk/src:
main/java/org/apache/commons/math/linear/ site/xdoc/
test/java/org/apache/commons/math/linear/
Author: luc
Date: Wed Dec 9 22:56:11 2009
New Revision: 889008
URL: http://svn.apache.org/viewvc?rev=889008view=rev
Log:
Added mapping and iteration methods to vectors.
Provided a default implementation for the numerous simple methods in the
RealVectorInterface.
+protected class SparseEntryIterator implements IteratorEntry {
+
+/** Dimension of the vector. */
+private final int dim;
+
+/** Temporary entry (reused on each call to {...@link #next()}. */
+private EntryImpl tmp = new EntryImpl();
+
+/** Current entry. */
+private EntryImpl current;
+
+/** Next entry. */
+private EntryImpl next;
+
+/** Simple constructor. */
+protected SparseEntryIterator() {
+dim = getDimension();
+current = new EntryImpl();
+if (current.getValue() == 0) {
+advance(current);
+}
This totally doesn't work if the vector consists of all zero elements. The
'hasNext' method (below) will return true, and you will get an exeption
trying to get the first element.
+next = new EntryImpl();
+next.setIndex(current.getIndex());
+advance(next);
+}
+
+/** Advance an entry up to the next non null one.
+ * @param e entry to advance
+ */
+protected void advance(EntryImpl e) {
+if (e == null) {
+return;
+}
+do {
+e.setIndex(e.getIndex() + 1);
+} while (e.getIndex() dim e.getValue() == 0);
+if (e.getIndex() = dim) {
+e.setIndex(-1);
+}
+}
This is fragile, since it relies on e.getIndex() == -1 when invalid (and
then you scan the vector once more).
+
+/** {...@inheritdoc} */
+public boolean hasNext() {
+return current != null;
+}
+
quick fix is to check that current.getIndex() = 0
+/** {...@inheritdoc} */
+public Entry next() {
+tmp.setIndex(current.getIndex());
+if (next != null) {
+current.setIndex(next.getIndex());
+advance(next);
+if (next.getIndex() 0) {
+next = null;
+}
+} else {
+current = null;
+}
+return tmp;
+}
+
+/** {...@inheritdoc} */
+public void remove() {
+throw new UnsupportedOperationException(Not supported);
+}
+}
+
+}
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/OpenMapRealVector.java
URL:
http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/OpenMapRealVector.java?rev=889008r1=889007r2=889008view=diff
==
---
commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/OpenMapRealVector.java
(original)
+++
commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/OpenMapRealVector.java
Wed Dec 9 22:56:11 2009
@@ -27,7 +27,7 @@
* @version $Revision$ $Date$
* @since 2.0
*/
-public class OpenMapRealVector implements SparseRealVector, Serializable
{
+public class OpenMapRealVector extends AbstractRealVector implements
SparseRealVector, Serializable {
/** Default Tolerance for having a value considered zero. */
public static final double DEFAULT_ZERO_TOLERANCE = 1.0e-12;
@@ -41,8 +41,11 @@
/** Dimension of the vector. */
private final int virtualSize;
-/** Tolerance for having a value considered zero. */
-private double epsilon;
+/** Negative tolerance for having a value considered zero. */
+private double minusEpsilon;
+
+/** Positive tolerance for having a value considered zero. */
+private double plusEpsilon;
If non-zero defaultValues are allowed, then we need to store the
defaultValue, to avoid floating point precision issues where (plusEpsilon +
minusEpsilon)/2 != defaultValue.
/**
* Build a 0-length vector.
@@ -54,7 +57,7 @@
* into this vector./p
*/
public OpenMapRealVector() {
-this(0, DEFAULT_ZERO_TOLERANCE);
+this(0, DEFAULT_ZERO_TOLERANCE, 0);
}
/**
@@ -62,18 +65,19 @@
* @param dimension size of the vector
*/
public OpenMapRealVector(int dimension) {
-this(dimension, DEFAULT_ZERO_TOLERANCE);
+
Re: svn commit: r889008 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/linear/ site/xdoc/ test/java/org/apache/commons/math/linear/
Hey Bill,
I'm glad you looked at this! You point out something which is really
weird - as my comment in the JIRA ticket indicates, I believe I removed any
allowing of nonzero default values, for exactly the reasons you brought up
(in short, they're a total pain to deal with), and many more:
New patch. This one has no reference to the nonzero default values for
sparse vectors, which can be addressed in another JIRA ticket. This patch
now only deals with the following files:
At least I *thought* I'd reverted that change in the patch, and that's what
I was trying to submit. I have to look at the set of patches which were on
that ticket, and if neither of them were what I thought, then mea culpa,
that should have been removed (and I wish you'd responded to my comment in
the JIRA implying that I had already fixed it, and asking you if you were
using the most recent patch - had you replied saying 'yes I am, actually!',
I could have caught this and fixed it ages ago)!
On Wed, Dec 9, 2009 at 9:28 PM, Bill Barker billwbar...@verizon.net wrote:
There are some things I don't like about this, but will try to find the
time to fix them myself . Comments inline (and I can't veto anything in
[math], so these are just suggestions).
+/** Simple constructor. */
+protected SparseEntryIterator() {
+dim = getDimension();
+current = new EntryImpl();
+if (current.getValue() == 0) {
+advance(current);
+}
This totally doesn't work if the vector consists of all zero elements. The
'hasNext' method (below) will return true, and you will get an exception
trying to get the first element.
Yes, this is a great unit test case, should have been checked for (and is a
special case, which should possibly be dealt with separately).
And actually, as I mention in the javadocs for this SparseIterator class,
this class has limited usefulness: when would *not* writing a specialized
implementation of iterateNonZero() be done in particular implementations of
RealVector? In Mahout's version of this class, the contract is a little
looser: iterateNonZero() doesn't try to gaurantee that it only iterates over
nonzero elements, it is really just the sparseIterator - default behavior
in the abstract base class is to delegate iterateNonZero() to iterate(), and
let subclasses decide whether there is something more sparse that can be
done. I think that's a lot cleaner, and avoids the dancing you have to do
to walk the AbstractRealVector sparsely without knowing what your
implementation is.
-jake
Re: [lang] Lang package name change. Was: [(LANG-561) unescapeHtml has been dropped without going through deprecation]
Paul Benedict wrote at Mittwoch, 9. Dezember 2009 20:16: I hope to see org.apache.commons:commons-lang:3.0 No, not if it is no longer backwards compatible to 2.0 APIs. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
