[jira] [Commented] (MATH-1023) Javadoc in SummaryStatistics (o.a.c.m.stat.descriptive)
[ https://issues.apache.org/jira/browse/MATH-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757492#comment-13757492 ] Gilles commented on MATH-1023: -- bq. it must be activated before any data has been added - i.e., before any calls to addValue. When I read that, I assume that the call is part of the initialization, and that addValue will fail if I have not called setXxxxImpl. This is harmless, as people who read the doc will just write unnecessary code... (I wrote the code before, and observed that it didn't raise as the doc would seem to imply). Simply adding your explanation above would clarify a lot IMO. Javadoc in SummaryStatistics (o.a.c.m.stat.descriptive) --- Key: MATH-1023 URL: https://issues.apache.org/jira/browse/MATH-1023 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Gilles Priority: Trivial Labels: documentation The documentation for methods set...Impl(...) indicates: --- This method must be activated before any data has been added - i.e., before addValue has been used to add data; otherwise an IllegalStateException will be thrown. --- However, every instance is created with default implementations; the warning is thus obsolete. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-804) Redundant check for zero in HashCodeBuilder ctor
[ https://issues.apache.org/jira/browse/LANG-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757502#comment-13757502 ] Allon Mureinik commented on LANG-804: - There are two issues here: The original issue - is there any point in explicitly checking (and documenting) for zero? Probably not, as you stated in the original case, and as my proposed patch solves. Should the ctor allow negative coefficients? With the given algorithm, the proper way to ensure that there are a minimal amount of clashes is to use two primes. Two relative primes could be also probably be used pretty safely. The question is how strict do you want to be? IMHO, disallowing negative coefficients is an arbitrary limitation. (-17, -37) would probably give better hash codes than (1, 1), or even any combination of the form (a, na) for most classes. Should those be disallowed too? (and if so - should/could this be done now? It would break backwards compatibility) Redundant check for zero in HashCodeBuilder ctor Key: LANG-804 URL: https://issues.apache.org/jira/browse/LANG-804 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Reporter: Sebb Priority: Minor The HashCodeBuilder(int, int) ctor checks both parameters for zero, as well as checking for an odd number. Zero is never odd, so the zero check could be eliminated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-1027) Create Combinations class
[ https://issues.apache.org/jira/browse/MATH-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757522#comment-13757522 ] Gilles commented on MATH-1027: -- Committed in revision 1519924. Create Combinations class --- Key: MATH-1027 URL: https://issues.apache.org/jira/browse/MATH-1027 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Minor Labels: api Fix For: 3.3 A new class will be created (with most of the code already implemented by Phil in combinationIterator method in o.a.c.m.util.CombinatoricsUtils). Cf. the [conclusion|http://markmail.org/message/2al2cxi4c4ce37lk] of a discussion on the ML. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-1027) Create Combinations class
[
https://issues.apache.org/jira/browse/MATH-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757525#comment-13757525
]
Gilles commented on MATH-1027:
--
TODO: Make the class implement {{Comparatorint[]}} (code to be taken from
lexNorm in test part of the repository).
Create Combinations class
---
Key: MATH-1027
URL: https://issues.apache.org/jira/browse/MATH-1027
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Minor
Labels: api
Fix For: 3.3
A new class will be created (with most of the code already implemented by
Phil in combinationIterator method in o.a.c.m.util.CombinatoricsUtils).
Cf. the [conclusion|http://markmail.org/message/2al2cxi4c4ce37lk] of a
discussion on the ML.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-1027) Create Combinations class
[ https://issues.apache.org/jira/browse/MATH-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757527#comment-13757527 ] Gilles commented on MATH-1027: -- In Combinations, I have created an enum to define the type of iteration (currently only lexicographic) to allow for future extension (e.g. random order iteration). Does that make sense? Any idea how to implement a random order (without keeping every iterate in memory)? Create Combinations class --- Key: MATH-1027 URL: https://issues.apache.org/jira/browse/MATH-1027 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Minor Labels: api Fix For: 3.3 A new class will be created (with most of the code already implemented by Phil in combinationIterator method in o.a.c.m.util.CombinatoricsUtils). Cf. the [conclusion|http://markmail.org/message/2al2cxi4c4ce37lk] of a discussion on the ML. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DAEMON-305) jsvc and Debian not work with arg procname
Alain Perreault created DAEMON-305: -- Summary: jsvc and Debian not work with arg procname Key: DAEMON-305 URL: https://issues.apache.org/jira/browse/DAEMON-305 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.15 Environment: Debian 3.2.46-1 x86_64 GNU/Linux Reporter: Alain Perreault Priority: Blocker Fix For: 1.0.15 command line with procname it's not working, the process name is jsvc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-1023) Javadoc in SummaryStatistics (o.a.c.m.stat.descriptive)
[ https://issues.apache.org/jira/browse/MATH-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-1023. --- Resolution: Fixed Fix Version/s: 3.3 Sorry, I get it now. I did not understand the problem at first. Fixed in r1520076. Javadoc in SummaryStatistics (o.a.c.m.stat.descriptive) --- Key: MATH-1023 URL: https://issues.apache.org/jira/browse/MATH-1023 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Gilles Priority: Trivial Labels: documentation Fix For: 3.3 The documentation for methods set...Impl(...) indicates: --- This method must be activated before any data has been added - i.e., before addValue has been used to add data; otherwise an IllegalStateException will be thrown. --- However, every instance is created with default implementations; the warning is thus obsolete. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-1032) Recover final tableau values from SimplexSolver
Renato Cherullo created MATH-1032: - Summary: Recover final tableau values from SimplexSolver Key: MATH-1032 URL: https://issues.apache.org/jira/browse/MATH-1032 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Renato Cherullo When the Simplex algorithm finds an optimal solution, the tableau is full of useful information that (in the current implementation) can't be retrieved, like shadow prices, sensitivity info, etc. Thus, it would be great if a future version allowed for the retrieval of such information. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-305) jsvc and Debian not work with arg procname
[ https://issues.apache.org/jira/browse/DAEMON-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-305: Fix Version/s: (was: 1.0.15) jsvc and Debian not work with arg procname --- Key: DAEMON-305 URL: https://issues.apache.org/jira/browse/DAEMON-305 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.15 Environment: Debian 3.2.46-1 x86_64 GNU/Linux Reporter: Alain Perreault Priority: Blocker command line with procname it's not working, the process name is jsvc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-1032) Recover final tableau values from SimplexSolver
[ https://issues.apache.org/jira/browse/MATH-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758331#comment-13758331 ] Renato Cherullo commented on MATH-1032: --- I realize that I didn't provide much specifics, but I couldn't find any reference to this kind of feature here or in the ML, so I just wanted to kick start the discussion. Well, just adding a getter to the final tableau is clearly not enough. The SimplexTableau needs some new getters too, for example to retrieve the column which corresponds to the slack variable of a given constraint. I'm willing to implement this, but I need some guidance. Recover final tableau values from SimplexSolver --- Key: MATH-1032 URL: https://issues.apache.org/jira/browse/MATH-1032 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Renato Cherullo When the Simplex algorithm finds an optimal solution, the tableau is full of useful information that (in the current implementation) can't be retrieved, like shadow prices, sensitivity info, etc. Thus, it would be great if a future version allowed for the retrieval of such information. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COLLECTIONS-480) BidiMap.values() should be declared to return a Set
Hollis Waite created COLLECTIONS-480: Summary: BidiMap.values() should be declared to return a Set Key: COLLECTIONS-480 URL: https://issues.apache.org/jira/browse/COLLECTIONS-480 Project: Commons Collections Issue Type: Improvement Components: BidiMap Affects Versions: 4.0-alpha1 Reporter: Hollis Waite Priority: Minor Since values are guaranteed to be unique, BidiMap.values() should be overridden to return a Set. See http://sourceforge.net/p/collections/bugs/1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
