[jira] [Commented] (LANG-810) StringUtils.join() endIndex, bugged for loop
[
https://issues.apache.org/jira/browse/LANG-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411282#comment-13411282
]
Joerg Schaible commented on LANG-810:
-
Sorry, but I cannot see what should be wrong here. Javadoc states that endIndex
is exclusive and that's exactly what the method does and what is required in
the implementation of Sebb's comment (the valid array index runs from 0 to
array.length-1).
> StringUtils.join() endIndex, bugged for loop
>
>
> Key: LANG-810
> URL: https://issues.apache.org/jira/browse/LANG-810
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.1
>Reporter: Krzysztof Nazarewski
>Assignee: Joerg Schaible
> Original Estimate: 1m
> Remaining Estimate: 1m
>
> endIndex is described as index, but for loop still checks it as "array
> length".
> Basically missing equal sign
> commons-lang3-3.1-sources.jar, StringUtils.java lines 3309, 3394:
> for (int i = startIndex; i < endIndex; i++) {
> should be:
> for (int i = startIndex; i <= endIndex; i++) {
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-462) FTPClient in PASSIVE_LOCAL_DATA_CONNECTION_MODE cannot work when host have several different IP
[ https://issues.apache.org/jira/browse/NET-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411093#comment-13411093 ] Sebb commented on NET-462: -- URL: http://svn.apache.org/viewvc?rev=1359960&view=rev Log: NET-462 FTPClient in PASSIVE_LOCAL_DATA_CONNECTION_MODE cannot work when host have several different IP Modified: commons/proper/net/trunk/src/changes/changes.xml commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/FTPClient.java > FTPClient in PASSIVE_LOCAL_DATA_CONNECTION_MODE cannot work when host have > several different IP > --- > > Key: NET-462 > URL: https://issues.apache.org/jira/browse/NET-462 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 3.1 > Environment: All OS,for example linux or windows and so on >Reporter: Junsheng Chen >Priority: Minor > Labels: ActiveIp, FTPClient, PASSIVE_LOCAL_DATA_CONNECTION_MODE > Fix For: 3.2 > > Attachments: ftp-bindlocal.diff > > Original Estimate: 24h > Remaining Estimate: 24h > > When host have several different IP and client setting to > PASSIVE_LOCAL_DATA_CONNECTION_MODE，_openDataConnection_ creating socket may > use the unexpected ip。 > For example, The host have two Ips, one for intra and the another for extern, > only the extern one can be connect with the outside。But when in > PASSIVE_LOCAL_DATA_CONNECTION_MODE, FTPClient may be select the intra Ip, So > it didn't work。 > So I change code like this, it can work normally by the specific ip. > Code: > In FTPClient._openDataConnection_(String command, String arg)，line 761 change > as bellow: > socket = _socketFactory_.createSocket(); > > // add begin > // local as client, transfer data must use the appointed local host > socket.bind(new InetSocketAddress(getHostAddress(), 0)); > // add end > After log in success,User can set the ip which he want to use by call the > method in FTPClient: > setActiveExternalIPAddress(String ip); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NET-462) FTPClient in PASSIVE_LOCAL_DATA_CONNECTION_MODE cannot work when host have several different IP
[ https://issues.apache.org/jira/browse/NET-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-462. -- Resolution: Fixed Thanks, patch applied with minor changes; also added method setPassiveLocalIPAddress(InetAddress inetAddress) for completeness > FTPClient in PASSIVE_LOCAL_DATA_CONNECTION_MODE cannot work when host have > several different IP > --- > > Key: NET-462 > URL: https://issues.apache.org/jira/browse/NET-462 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 3.1 > Environment: All OS,for example linux or windows and so on >Reporter: Junsheng Chen >Priority: Minor > Labels: ActiveIp, FTPClient, PASSIVE_LOCAL_DATA_CONNECTION_MODE > Fix For: 3.2 > > Attachments: ftp-bindlocal.diff > > Original Estimate: 24h > Remaining Estimate: 24h > > When host have several different IP and client setting to > PASSIVE_LOCAL_DATA_CONNECTION_MODE，_openDataConnection_ creating socket may > use the unexpected ip。 > For example, The host have two Ips, one for intra and the another for extern, > only the extern one can be connect with the outside。But when in > PASSIVE_LOCAL_DATA_CONNECTION_MODE, FTPClient may be select the intra Ip, So > it didn't work。 > So I change code like this, it can work normally by the specific ip. > Code: > In FTPClient._openDataConnection_(String command, String arg)，line 761 change > as bellow: > socket = _socketFactory_.createSocket(); > > // add begin > // local as client, transfer data must use the appointed local host > socket.bind(new InetSocketAddress(getHostAddress(), 0)); > // add end > After log in success,User can set the ip which he want to use by call the > method in FTPClient: > setActiveExternalIPAddress(String ip); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (NET-474) Problem, in __getReply method, parsing reply code with leading space
[
https://issues.apache.org/jira/browse/NET-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb closed NET-474.
> Problem, in __getReply method, parsing reply code with leading space
>
>
> Key: NET-474
> URL: https://issues.apache.org/jira/browse/NET-474
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.1
> Environment: UNIX
>Reporter: Ahmad AMIN
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> FTPClient.getStatus() function call failed complaining about malformed
> response code.
> After tracing the code, I found the problem at following class and line:
> *org.apache.commons.net.ftp.FTP.__getReply(FTP.java:333)*
> The issue is that this method always expects reply code at position 0 of the
> returned reply string. If the reply string has some leading spaces, it fails
> to parse the reply code and returns malformed reply string.
> Example of such a reply string:
> {noformat}
> 211-nhpssltest Ipswitch FTP Server
> Version 5.0.2
> Connected to 184.70.132.130
> Logged in as massba
> TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM
> No data connection
> 211 End of status
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-474) Problem, in __getReply method, parsing reply code with leading space
[
https://issues.apache.org/jira/browse/NET-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411079#comment-13411079
]
Sebb commented on NET-474:
--
Here is a sample session to a recent version of the server:
{noformat}
Connected to ftp.ipswitch.com.
220 ftp6.ipswitch.com X2 WS_FTP Server 7.5.1(76307814)
331 Enter password
230 User logged in
Remote system type is UNIX.
ftp> quote stat
211-System status Ipswitch FTP Server
Version WS_FTP Server 7.5.1
Connected to 192.168.100.130
Logged in as anonymous
TYPE: BINARY, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM
No data connection
211 End of status
ftp> bye
221 bye
{noformat}
Note that the reply codes start in column 1 (index 0).
> Problem, in __getReply method, parsing reply code with leading space
>
>
> Key: NET-474
> URL: https://issues.apache.org/jira/browse/NET-474
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.1
> Environment: UNIX
>Reporter: Ahmad AMIN
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> FTPClient.getStatus() function call failed complaining about malformed
> response code.
> After tracing the code, I found the problem at following class and line:
> *org.apache.commons.net.ftp.FTP.__getReply(FTP.java:333)*
> The issue is that this method always expects reply code at position 0 of the
> returned reply string. If the reply string has some leading spaces, it fails
> to parse the reply code and returns malformed reply string.
> Example of such a reply string:
> {noformat}
> 211-nhpssltest Ipswitch FTP Server
> Version 5.0.2
> Connected to 184.70.132.130
> Logged in as massba
> TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM
> No data connection
> 211 End of status
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-474) Problem, in __getReply method, parsing reply code with leading space
[
https://issues.apache.org/jira/browse/NET-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-474:
-
Fix Version/s: (was: 3.2)
> Problem, in __getReply method, parsing reply code with leading space
>
>
> Key: NET-474
> URL: https://issues.apache.org/jira/browse/NET-474
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.1
> Environment: UNIX
>Reporter: Ahmad AMIN
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> FTPClient.getStatus() function call failed complaining about malformed
> response code.
> After tracing the code, I found the problem at following class and line:
> *org.apache.commons.net.ftp.FTP.__getReply(FTP.java:333)*
> The issue is that this method always expects reply code at position 0 of the
> returned reply string. If the reply string has some leading spaces, it fails
> to parse the reply code and returns malformed reply string.
> Example of such a reply string:
> {noformat}
> 211-nhpssltest Ipswitch FTP Server
> Version 5.0.2
> Connected to 184.70.132.130
> Logged in as massba
> TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM
> No data connection
> 211 End of status
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-817) Multivariate Normal Mixture Model Fitting by Expectation Maximization
Jared Becksfort created MATH-817: Summary: Multivariate Normal Mixture Model Fitting by Expectation Maximization Key: MATH-817 URL: https://issues.apache.org/jira/browse/MATH-817 Project: Commons Math Issue Type: New Feature Reporter: Jared Becksfort Priority: Minor I will submit a class for fitting Multivariate Normal Mixture Models using Expectation Maximization. > Hello, > > I have implemented some classes for multivariate Normal distributions, > multivariate normal mixture models, and an expectation maximization fitting > class for the mixture model. I would like to submit it to Apache Commons > Math. I still have some touching up to do so that they fit the style > guidelines and implement the correct interfaces. Before I do so, I thought I > would at least ask if the developers of the project are interested in me > submitting them. > > Thanks, > Jared Becksfort Dear Jared, Yes, that would be very nice to have such an addition! Remember to also include unit tests (refer to the current ones for examples). The best would be to split a submission up into multiple minor ones, each covering a natural submission (e.g. multivariate Normal distribution in one submission), and create an issue as described at http://commons.apache.org/math/issue-tracking.html . If you run into any problems, please do not hesitate to ask on this mailing list. Cheers, Mikkel. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-816) Multivariate Normal Mixture Models
Jared Becksfort created MATH-816: Summary: Multivariate Normal Mixture Models Key: MATH-816 URL: https://issues.apache.org/jira/browse/MATH-816 Project: Commons Math Issue Type: New Feature Reporter: Jared Becksfort Priority: Minor I will submit a class for Multivariate Normal Mixture Models. Not sure it will allow sampling initially. > Hello, > > I have implemented some classes for multivariate Normal distributions, > multivariate normal mixture models, and an expectation maximization fitting > class for the mixture model. I would like to submit it to Apache Commons > Math. I still have some touching up to do so that they fit the style > guidelines and implement the correct interfaces. Before I do so, I thought I > would at least ask if the developers of the project are interested in me > submitting them. > > Thanks, > Jared Becksfort Dear Jared, Yes, that would be very nice to have such an addition! Remember to also include unit tests (refer to the current ones for examples). The best would be to split a submission up into multiple minor ones, each covering a natural submission (e.g. multivariate Normal distribution in one submission), and create an issue as described at http://commons.apache.org/math/issue-tracking.html . If you run into any problems, please do not hesitate to ask on this mailing list. Cheers, Mikkel. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-815) Multivariate Normal Distribution
Jared Becksfort created MATH-815: Summary: Multivariate Normal Distribution Key: MATH-815 URL: https://issues.apache.org/jira/browse/MATH-815 Project: Commons Math Issue Type: New Feature Reporter: Jared Becksfort Priority: Minor I will submit a class for Multivariate Normal Distributions. Not sure if it will allow sampling initially. > Hello, > > I have implemented some classes for multivariate Normal distributions, > multivariate normal mixture models, and an expectation maximization fitting > class for the mixture model. I would like to submit it to Apache Commons > Math. I still have some touching up to do so that they fit the style > guidelines and implement the correct interfaces. Before I do so, I thought I > would at least ask if the developers of the project are interested in me > submitting them. > > Thanks, > Jared Becksfort Dear Jared, Yes, that would be very nice to have such an addition! Remember to also include unit tests (refer to the current ones for examples). The best would be to split a submission up into multiple minor ones, each covering a natural submission (e.g. multivariate Normal distribution in one submission), and create an issue as described at http://commons.apache.org/math/issue-tracking.html . If you run into any problems, please do not hesitate to ask on this mailing list. Cheers, Mikkel. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-813) SimplexSolver bug?
[
https://issues.apache.org/jira/browse/MATH-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410764#comment-13410764
]
Thomas Neidhart commented on MATH-813:
--
Thanks for the report anyway!
I marked the issue as a duplicate of MATH-781 and changed the fix version to 3.1
> SimplexSolver bug?
> --
>
> Key: MATH-813
> URL: https://issues.apache.org/jira/browse/MATH-813
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Windows 7, JDK 1.7.0_03
>Reporter: Raghu Rangarajan
> Fix For: 3.1
>
> Attachments: Commons_Solver.java
>
>
> I am trying to use the SimplexSolver in commons-math3-3.0 and am getting
> unpredictable results. I am pasting the problem code below. Basically
> swapping the sequence of the last two constraints results in two different
> results (of which one is pure sub-optimal). Am I not using the solver
> correctly?
> --
> import java.util.ArrayList;
> import java.util.Collection;
> import org.apache.commons.math3.optimization.*;
> import org.apache.commons.math3.optimization.linear.*;
> public class Commons_Solver {
> public static void main(String[] args) {
> // describe the optimization problem
>
> LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1,
> 1, 1, 1, 1, 1, 0, 0 }, 0);
> Collection constraints = new
> ArrayList();
>
> //variables upper bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 38));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 34));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 1));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.LEQ, 6));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.LEQ, 17));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.LEQ, 11));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.LEQ, 101));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.LEQ, 1e10));
> //variables lower bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1,-1, -1, -1, -1,
> -1, 1, 0 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1, -1, -1, -1, -1,
> -1,0 , 1 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> -0.2841121495327103 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> -0.25420560747663556 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> -0.04485981308411215 }, Relationship.GEQ, 0));
>
> /*---
> Swapping the sequence of the below two constraints produces two different
> results
> --*/
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> -0.12710280373831778 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> -0.08224299065420561 }, Relationship.GEQ, 0));
> /*--*/
>
> PointValuePair solution = new SimplexSolver().optimize(f, constraints,
> GoalType.MAXIMIZE, false);
> // get the solution
> for (int i = 0 ; i < solution.getPoint().length; i++)
> System.out.println("x[" + i + "] = " + solution.getPoint()[i]);
>
> System.out.println("value = " + solution.getValue());
> }
> }
> --
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
[jira] [Resolved] (MATH-813) SimplexSolver bug?
[
https://issues.apache.org/jira/browse/MATH-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved MATH-813.
--
Resolution: Duplicate
Fix Version/s: (was: Nightly Builds)
3.1
Duplicate of MATH-781
> SimplexSolver bug?
> --
>
> Key: MATH-813
> URL: https://issues.apache.org/jira/browse/MATH-813
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Windows 7, JDK 1.7.0_03
>Reporter: Raghu Rangarajan
> Fix For: 3.1
>
> Attachments: Commons_Solver.java
>
>
> I am trying to use the SimplexSolver in commons-math3-3.0 and am getting
> unpredictable results. I am pasting the problem code below. Basically
> swapping the sequence of the last two constraints results in two different
> results (of which one is pure sub-optimal). Am I not using the solver
> correctly?
> --
> import java.util.ArrayList;
> import java.util.Collection;
> import org.apache.commons.math3.optimization.*;
> import org.apache.commons.math3.optimization.linear.*;
> public class Commons_Solver {
> public static void main(String[] args) {
> // describe the optimization problem
>
> LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1,
> 1, 1, 1, 1, 1, 0, 0 }, 0);
> Collection constraints = new
> ArrayList();
>
> //variables upper bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 38));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 34));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 1));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.LEQ, 6));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.LEQ, 17));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.LEQ, 11));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.LEQ, 101));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.LEQ, 1e10));
> //variables lower bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1,-1, -1, -1, -1,
> -1, 1, 0 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1, -1, -1, -1, -1,
> -1,0 , 1 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> -0.2841121495327103 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> -0.25420560747663556 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> -0.04485981308411215 }, Relationship.GEQ, 0));
>
> /*---
> Swapping the sequence of the below two constraints produces two different
> results
> --*/
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> -0.12710280373831778 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> -0.08224299065420561 }, Relationship.GEQ, 0));
> /*--*/
>
> PointValuePair solution = new SimplexSolver().optimize(f, constraints,
> GoalType.MAXIMIZE, false);
> // get the solution
> for (int i = 0 ; i < solution.getPoint().length; i++)
> System.out.println("x[" + i + "] = " + solution.getPoint()[i]);
>
> System.out.println("value = " + solution.getValue());
> }
> }
> --
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAd
[jira] [Reopened] (MATH-813) SimplexSolver bug?
[
https://issues.apache.org/jira/browse/MATH-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart reopened MATH-813:
--
> SimplexSolver bug?
> --
>
> Key: MATH-813
> URL: https://issues.apache.org/jira/browse/MATH-813
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Windows 7, JDK 1.7.0_03
>Reporter: Raghu Rangarajan
> Fix For: Nightly Builds
>
> Attachments: Commons_Solver.java
>
>
> I am trying to use the SimplexSolver in commons-math3-3.0 and am getting
> unpredictable results. I am pasting the problem code below. Basically
> swapping the sequence of the last two constraints results in two different
> results (of which one is pure sub-optimal). Am I not using the solver
> correctly?
> --
> import java.util.ArrayList;
> import java.util.Collection;
> import org.apache.commons.math3.optimization.*;
> import org.apache.commons.math3.optimization.linear.*;
> public class Commons_Solver {
> public static void main(String[] args) {
> // describe the optimization problem
>
> LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1,
> 1, 1, 1, 1, 1, 0, 0 }, 0);
> Collection constraints = new
> ArrayList();
>
> //variables upper bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 38));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 34));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 1));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.LEQ, 6));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.LEQ, 17));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.LEQ, 11));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.LEQ, 101));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.LEQ, 1e10));
> //variables lower bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1,-1, -1, -1, -1,
> -1, 1, 0 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1, -1, -1, -1, -1,
> -1,0 , 1 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> -0.2841121495327103 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> -0.25420560747663556 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> -0.04485981308411215 }, Relationship.GEQ, 0));
>
> /*---
> Swapping the sequence of the below two constraints produces two different
> results
> --*/
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> -0.12710280373831778 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> -0.08224299065420561 }, Relationship.GEQ, 0));
> /*--*/
>
> PointValuePair solution = new SimplexSolver().optimize(f, constraints,
> GoalType.MAXIMIZE, false);
> // get the solution
> for (int i = 0 ; i < solution.getPoint().length; i++)
> System.out.println("x[" + i + "] = " + solution.getPoint()[i]);
>
> System.out.println("value = " + solution.getValue());
> }
> }
> --
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (MATH-813) SimplexSolver bug?
[
https://issues.apache.org/jira/browse/MATH-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raghu Rangarajan reopened MATH-813:
---
> SimplexSolver bug?
> --
>
> Key: MATH-813
> URL: https://issues.apache.org/jira/browse/MATH-813
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Windows 7, JDK 1.7.0_03
>Reporter: Raghu Rangarajan
> Fix For: Nightly Builds
>
> Attachments: Commons_Solver.java
>
>
> I am trying to use the SimplexSolver in commons-math3-3.0 and am getting
> unpredictable results. I am pasting the problem code below. Basically
> swapping the sequence of the last two constraints results in two different
> results (of which one is pure sub-optimal). Am I not using the solver
> correctly?
> --
> import java.util.ArrayList;
> import java.util.Collection;
> import org.apache.commons.math3.optimization.*;
> import org.apache.commons.math3.optimization.linear.*;
> public class Commons_Solver {
> public static void main(String[] args) {
> // describe the optimization problem
>
> LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1,
> 1, 1, 1, 1, 1, 0, 0 }, 0);
> Collection constraints = new
> ArrayList();
>
> //variables upper bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 38));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 34));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 1));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.LEQ, 6));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.LEQ, 17));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.LEQ, 11));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.LEQ, 101));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.LEQ, 1e10));
> //variables lower bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1,-1, -1, -1, -1,
> -1, 1, 0 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1, -1, -1, -1, -1,
> -1,0 , 1 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> -0.2841121495327103 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> -0.25420560747663556 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> -0.04485981308411215 }, Relationship.GEQ, 0));
>
> /*---
> Swapping the sequence of the below two constraints produces two different
> results
> --*/
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> -0.12710280373831778 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> -0.08224299065420561 }, Relationship.GEQ, 0));
> /*--*/
>
> PointValuePair solution = new SimplexSolver().optimize(f, constraints,
> GoalType.MAXIMIZE, false);
> // get the solution
> for (int i = 0 ; i < solution.getPoint().length; i++)
> System.out.println("x[" + i + "] = " + solution.getPoint()[i]);
>
> System.out.println("value = " + solution.getValue());
> }
> }
> --
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-813) SimplexSolver bug?
[
https://issues.apache.org/jira/browse/MATH-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raghu Rangarajan resolved MATH-813.
---
Resolution: Fixed
> SimplexSolver bug?
> --
>
> Key: MATH-813
> URL: https://issues.apache.org/jira/browse/MATH-813
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Windows 7, JDK 1.7.0_03
>Reporter: Raghu Rangarajan
> Fix For: Nightly Builds
>
> Attachments: Commons_Solver.java
>
>
> I am trying to use the SimplexSolver in commons-math3-3.0 and am getting
> unpredictable results. I am pasting the problem code below. Basically
> swapping the sequence of the last two constraints results in two different
> results (of which one is pure sub-optimal). Am I not using the solver
> correctly?
> --
> import java.util.ArrayList;
> import java.util.Collection;
> import org.apache.commons.math3.optimization.*;
> import org.apache.commons.math3.optimization.linear.*;
> public class Commons_Solver {
> public static void main(String[] args) {
> // describe the optimization problem
>
> LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1,
> 1, 1, 1, 1, 1, 0, 0 }, 0);
> Collection constraints = new
> ArrayList();
>
> //variables upper bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 38));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 34));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 1));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.LEQ, 6));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.LEQ, 17));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.LEQ, 11));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.LEQ, 101));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.LEQ, 1e10));
> //variables lower bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1,-1, -1, -1, -1,
> -1, 1, 0 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1, -1, -1, -1, -1,
> -1,0 , 1 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> -0.2841121495327103 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> -0.25420560747663556 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> -0.04485981308411215 }, Relationship.GEQ, 0));
>
> /*---
> Swapping the sequence of the below two constraints produces two different
> results
> --*/
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> -0.12710280373831778 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> -0.08224299065420561 }, Relationship.GEQ, 0));
> /*--*/
>
> PointValuePair solution = new SimplexSolver().optimize(f, constraints,
> GoalType.MAXIMIZE, false);
> // get the solution
> for (int i = 0 ; i < solution.getPoint().length; i++)
> System.out.println("x[" + i + "] = " + solution.getPoint()[i]);
>
> System.out.println("value = " + solution.getValue());
> }
> }
> --
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/ji
[jira] [Closed] (MATH-813) SimplexSolver bug?
[
https://issues.apache.org/jira/browse/MATH-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raghu Rangarajan closed MATH-813.
-
> SimplexSolver bug?
> --
>
> Key: MATH-813
> URL: https://issues.apache.org/jira/browse/MATH-813
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Windows 7, JDK 1.7.0_03
>Reporter: Raghu Rangarajan
> Fix For: Nightly Builds
>
> Attachments: Commons_Solver.java
>
>
> I am trying to use the SimplexSolver in commons-math3-3.0 and am getting
> unpredictable results. I am pasting the problem code below. Basically
> swapping the sequence of the last two constraints results in two different
> results (of which one is pure sub-optimal). Am I not using the solver
> correctly?
> --
> import java.util.ArrayList;
> import java.util.Collection;
> import org.apache.commons.math3.optimization.*;
> import org.apache.commons.math3.optimization.linear.*;
> public class Commons_Solver {
> public static void main(String[] args) {
> // describe the optimization problem
>
> LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1,
> 1, 1, 1, 1, 1, 0, 0 }, 0);
> Collection constraints = new
> ArrayList();
>
> //variables upper bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 38));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 34));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 1));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.LEQ, 6));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.LEQ, 17));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.LEQ, 11));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.LEQ, 101));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.LEQ, 1e10));
> //variables lower bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1,-1, -1, -1, -1,
> -1, 1, 0 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1, -1, -1, -1, -1,
> -1,0 , 1 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> -0.2841121495327103 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> -0.25420560747663556 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> -0.04485981308411215 }, Relationship.GEQ, 0));
>
> /*---
> Swapping the sequence of the below two constraints produces two different
> results
> --*/
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> -0.12710280373831778 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> -0.08224299065420561 }, Relationship.GEQ, 0));
> /*--*/
>
> PointValuePair solution = new SimplexSolver().optimize(f, constraints,
> GoalType.MAXIMIZE, false);
> // get the solution
> for (int i = 0 ; i < solution.getPoint().length; i++)
> System.out.println("x[" + i + "] = " + solution.getPoint()[i]);
>
> System.out.println("value = " + solution.getValue());
> }
> }
> --
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-810) StringUtils.join() endIndex, bugged for loop
[
https://issues.apache.org/jira/browse/LANG-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410752#comment-13410752
]
Wilf Middleton commented on LANG-810:
-
The parameter description for join(Object array, String sep, int begining inde,
int end index) is wrong as it states that the last index is exclusive and must
not go past the end of the array. So the description is wring or the
implementation is wrong. The suggest fix fixes it and then the javadoc also
needs changing.
> StringUtils.join() endIndex, bugged for loop
>
>
> Key: LANG-810
> URL: https://issues.apache.org/jira/browse/LANG-810
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.1
>Reporter: Krzysztof Nazarewski
> Original Estimate: 1m
> Remaining Estimate: 1m
>
> endIndex is described as index, but for loop still checks it as "array
> length".
> Basically missing equal sign
> commons-lang3-3.1-sources.jar, StringUtils.java lines 3309, 3394:
> for (int i = startIndex; i < endIndex; i++) {
> should be:
> for (int i = startIndex; i <= endIndex; i++) {
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-813) SimplexSolver bug?
[
https://issues.apache.org/jira/browse/MATH-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raghu Rangarajan closed MATH-813.
-
Resolution: Fixed
Fix Version/s: Nightly Builds
> SimplexSolver bug?
> --
>
> Key: MATH-813
> URL: https://issues.apache.org/jira/browse/MATH-813
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Windows 7, JDK 1.7.0_03
>Reporter: Raghu Rangarajan
> Fix For: Nightly Builds
>
> Attachments: Commons_Solver.java
>
>
> I am trying to use the SimplexSolver in commons-math3-3.0 and am getting
> unpredictable results. I am pasting the problem code below. Basically
> swapping the sequence of the last two constraints results in two different
> results (of which one is pure sub-optimal). Am I not using the solver
> correctly?
> --
> import java.util.ArrayList;
> import java.util.Collection;
> import org.apache.commons.math3.optimization.*;
> import org.apache.commons.math3.optimization.linear.*;
> public class Commons_Solver {
> public static void main(String[] args) {
> // describe the optimization problem
>
> LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1,
> 1, 1, 1, 1, 1, 0, 0 }, 0);
> Collection constraints = new
> ArrayList();
>
> //variables upper bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 38));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 34));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 1));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.LEQ, 6));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.LEQ, 17));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.LEQ, 11));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.LEQ, 101));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.LEQ, 1e10));
> //variables lower bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1,-1, -1, -1, -1,
> -1, 1, 0 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1, -1, -1, -1, -1,
> -1,0 , 1 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> -0.2841121495327103 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> -0.25420560747663556 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> -0.04485981308411215 }, Relationship.GEQ, 0));
>
> /*---
> Swapping the sequence of the below two constraints produces two different
> results
> --*/
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> -0.12710280373831778 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> -0.08224299065420561 }, Relationship.GEQ, 0));
> /*--*/
>
> PointValuePair solution = new SimplexSolver().optimize(f, constraints,
> GoalType.MAXIMIZE, false);
> // get the solution
> for (int i = 0 ; i < solution.getPoint().length; i++)
> System.out.println("x[" + i + "] = " + solution.getPoint()[i]);
>
> System.out.println("value = " + solution.getValue());
> }
> }
> --
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: htt
[jira] [Commented] (MATH-813) SimplexSolver bug?
[
https://issues.apache.org/jira/browse/MATH-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410751#comment-13410751
]
Raghu Rangarajan commented on MATH-813:
---
Hi Thomas,
I too am able to get the right results with the latest trunk code. Thanks for
looking into this.
Raghu
> SimplexSolver bug?
> --
>
> Key: MATH-813
> URL: https://issues.apache.org/jira/browse/MATH-813
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Windows 7, JDK 1.7.0_03
>Reporter: Raghu Rangarajan
> Fix For: Nightly Builds
>
> Attachments: Commons_Solver.java
>
>
> I am trying to use the SimplexSolver in commons-math3-3.0 and am getting
> unpredictable results. I am pasting the problem code below. Basically
> swapping the sequence of the last two constraints results in two different
> results (of which one is pure sub-optimal). Am I not using the solver
> correctly?
> --
> import java.util.ArrayList;
> import java.util.Collection;
> import org.apache.commons.math3.optimization.*;
> import org.apache.commons.math3.optimization.linear.*;
> public class Commons_Solver {
> public static void main(String[] args) {
> // describe the optimization problem
>
> LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1,
> 1, 1, 1, 1, 1, 0, 0 }, 0);
> Collection constraints = new
> ArrayList();
>
> //variables upper bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 38));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 34));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 1));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.LEQ, 6));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.LEQ, 17));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.LEQ, 11));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.LEQ, 101));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.LEQ, 1e10));
> //variables lower bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1,-1, -1, -1, -1,
> -1, 1, 0 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1, -1, -1, -1, -1,
> -1,0 , 1 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> -0.2841121495327103 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> -0.25420560747663556 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> -0.04485981308411215 }, Relationship.GEQ, 0));
>
> /*---
> Swapping the sequence of the below two constraints produces two different
> results
> --*/
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> -0.12710280373831778 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> -0.08224299065420561 }, Relationship.GEQ, 0));
> /*--*/
>
> PointValuePair solution = new SimplexSolver().optimize(f, constraints,
> GoalType.MAXIMIZE, false);
> // get the solution
> for (int i = 0 ; i < solution.getPoint().length; i++)
> System.out.println("x[" + i + "] = " + solution.getPoint()[i]);
>
> System.out.println("value = " + solution.getValue());
> }
> }
> --
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIR
[jira] [Commented] (MATH-814) Kendalls Tau Implementation
[ https://issues.apache.org/jira/browse/MATH-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410709#comment-13410709 ] devl commented on MATH-814: --- Initial feedback from Phil Steitz I think a Kendal's Tau implementation would make a great addition to the correlation package (o.a.c.math3.stat.correlation). Here is how you can get started: 0) Get yourself set up to build commons math and run the unit tests. If you are familiar with maven, this should not be too hard. If you have any questions or run into problems checking out the sources, building locally, etc., don't hesitate to ask. 1) Look at the Spearman's implementation and the ranking classes in the stat.ranking package. That might give you some ideas on how to implement Kendal's consistently. 2) Open a JIRA ticket with the info above and start attaching patches implementing the new implementation class and associated test class. Run "mvn site" or checkstyle standalone to make sure your contributed code follows the style guidelines we use. 3) Be patient but persistent and we will get Kendall's Tau into commons math :) > Kendalls Tau Implementation > --- > > Key: MATH-814 > URL: https://issues.apache.org/jira/browse/MATH-814 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 4.0 > Environment: All >Reporter: devl > Labels: correlation, rank > Fix For: 4.0 > > Original Estimate: 840h > Remaining Estimate: 840h > > Implement the Kendall's Tau which is a measure of Association/Correlation > between ranked ordinal data. > A basic description is available at > http://en.wikipedia.org/wiki/Kendall_tau_rank_correlation_coefficient however > the test implementation will follow that defined by "Handbook of Parametric > and Nonparametric Statistical Procedures, Fifth Edition, Page 1393 Test 30, > ISBN-10: 1439858012 | ISBN-13: 978-1439858011." > The algorithm is proposed as follows. > Given two rankings or permutations represented by a 2D matrix; columns > indicate rankings (e.g. by an individual) and row are observations of each > rank. The algorithm is to calculate the total number of concordant pairs of > ranks (between columns), discordant pairs of ranks (between columns) and > calculate the Tau defined as > tau= (Number of concordant - number of discordant)/(n(n-1)/2) > where n(n-1)/2 is the total number of possible pairs of ranks. > The method will then output the tau value between -1 and 1 where 1 signifies > a "perfect" correlation between the two ranked lists. > Where ties exist within a ranking it is marked as neither concordant nor > discordant in the calculation. An optional merge sort can be used to speed up > the implementation. Details are in the wiki page. > Although this implementation is not particularly complex it would be useful > to have it in a consistent format in the commons math package in addition to > existing correlation tests. Kendall's Tau is used effectively in comparing > ranks for products, rankings from search engines or measurements from > engineering equipment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-814) Kendalls Tau Implementation
devl created MATH-814: - Summary: Kendalls Tau Implementation Key: MATH-814 URL: https://issues.apache.org/jira/browse/MATH-814 Project: Commons Math Issue Type: New Feature Affects Versions: 4.0 Environment: All Reporter: devl Fix For: 4.0 Implement the Kendall's Tau which is a measure of Association/Correlation between ranked ordinal data. A basic description is available at http://en.wikipedia.org/wiki/Kendall_tau_rank_correlation_coefficient however the test implementation will follow that defined by "Handbook of Parametric and Nonparametric Statistical Procedures, Fifth Edition, Page 1393 Test 30, ISBN-10: 1439858012 | ISBN-13: 978-1439858011." The algorithm is proposed as follows. Given two rankings or permutations represented by a 2D matrix; columns indicate rankings (e.g. by an individual) and row are observations of each rank. The algorithm is to calculate the total number of concordant pairs of ranks (between columns), discordant pairs of ranks (between columns) and calculate the Tau defined as tau= (Number of concordant - number of discordant)/(n(n-1)/2) where n(n-1)/2 is the total number of possible pairs of ranks. The method will then output the tau value between -1 and 1 where 1 signifies a "perfect" correlation between the two ranked lists. Where ties exist within a ranking it is marked as neither concordant nor discordant in the calculation. An optional merge sort can be used to speed up the implementation. Details are in the wiki page. Although this implementation is not particularly complex it would be useful to have it in a consistent format in the commons math package in addition to existing correlation tests. Kendall's Tau is used effectively in comparing ranks for products, rankings from search engines or measurements from engineering equipment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-474) Problem, in __getReply method, parsing reply code with leading space
[
https://issues.apache.org/jira/browse/NET-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410640#comment-13410640
]
Sebb commented on NET-474:
--
This is the first and only report of a server that apparently sends leading
spaces.
IMO adding lenient processing is overkill/unnecessary feature creep.
If it really is a genuine problem affecting more than 1 specific server version
then it might be worth allowing __getReply to be overridden, as that is
probably the easiest solution.
> Problem, in __getReply method, parsing reply code with leading space
>
>
> Key: NET-474
> URL: https://issues.apache.org/jira/browse/NET-474
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.1
> Environment: UNIX
>Reporter: Ahmad AMIN
> Fix For: 3.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> FTPClient.getStatus() function call failed complaining about malformed
> response code.
> After tracing the code, I found the problem at following class and line:
> *org.apache.commons.net.ftp.FTP.__getReply(FTP.java:333)*
> The issue is that this method always expects reply code at position 0 of the
> returned reply string. If the reply string has some leading spaces, it fails
> to parse the reply code and returns malformed reply string.
> Example of such a reply string:
> {noformat}
> 211-nhpssltest Ipswitch FTP Server
> Version 5.0.2
> Connected to 184.70.132.130
> Logged in as massba
> TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM
> No data connection
> 211 End of status
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-813) SimplexSolver bug?
[
https://issues.apache.org/jira/browse/MATH-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410637#comment-13410637
]
Thomas Neidhart commented on MATH-813:
--
Hi,
I quickly checked your test case with the latest trunk and I get exactly the
same result. Most likely your observed problem has been fixed already as part
of MATH-781. Could you please check yourself with the latest trunk and confirm
that the problem is not existent anymore?
Thanks,
Thomas
> SimplexSolver bug?
> --
>
> Key: MATH-813
> URL: https://issues.apache.org/jira/browse/MATH-813
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Windows 7, JDK 1.7.0_03
>Reporter: Raghu Rangarajan
> Attachments: Commons_Solver.java
>
>
> I am trying to use the SimplexSolver in commons-math3-3.0 and am getting
> unpredictable results. I am pasting the problem code below. Basically
> swapping the sequence of the last two constraints results in two different
> results (of which one is pure sub-optimal). Am I not using the solver
> correctly?
> --
> import java.util.ArrayList;
> import java.util.Collection;
> import org.apache.commons.math3.optimization.*;
> import org.apache.commons.math3.optimization.linear.*;
> public class Commons_Solver {
> public static void main(String[] args) {
> // describe the optimization problem
>
> LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1,
> 1, 1, 1, 1, 1, 0, 0 }, 0);
> Collection constraints = new
> ArrayList();
>
> //variables upper bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 38));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 34));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 1));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.LEQ, 6));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.LEQ, 17));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.LEQ, 11));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.LEQ, 101));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.LEQ, 1e10));
> //variables lower bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1,-1, -1, -1, -1,
> -1, 1, 0 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1, -1, -1, -1, -1,
> -1,0 , 1 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> -0.2841121495327103 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> -0.25420560747663556 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> -0.04485981308411215 }, Relationship.GEQ, 0));
>
> /*---
> Swapping the sequence of the below two constraints produces two different
> results
> --*/
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> -0.12710280373831778 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> -0.08224299065420561 }, Relationship.GEQ, 0));
> /*--*/
>
> PointValuePair solution = new SimplexSolver().optimize(f, constraints,
> GoalType.MAXIMIZE, false);
> // get the solution
> for (int i = 0 ; i < solution.getPoint().length; i++)
> System.out.println("x[" + i + "] = " + solution.getPoint()[i]);
>
> System.out.println("value = " + solution.getValue());
> }
> }
>
[jira] [Commented] (NET-474) Problem, in __getReply method, parsing reply code with leading space
[
https://issues.apache.org/jira/browse/NET-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410592#comment-13410592
]
Gary D. Gregory commented on NET-474:
-
Is it worth discussing adding a lenient vs. strict setting to the FTP class to
allow for such misbehaved servers? The strict mode is as it is now. Lenient
would trim to reply line before attempting to parse it.
If not, what about changing __getReply to protected to allow for overriding?
> Problem, in __getReply method, parsing reply code with leading space
>
>
> Key: NET-474
> URL: https://issues.apache.org/jira/browse/NET-474
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.1
> Environment: UNIX
>Reporter: Ahmad AMIN
> Fix For: 3.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> FTPClient.getStatus() function call failed complaining about malformed
> response code.
> After tracing the code, I found the problem at following class and line:
> *org.apache.commons.net.ftp.FTP.__getReply(FTP.java:333)*
> The issue is that this method always expects reply code at position 0 of the
> returned reply string. If the reply string has some leading spaces, it fails
> to parse the reply code and returns malformed reply string.
> Example of such a reply string:
> {noformat}
> 211-nhpssltest Ipswitch FTP Server
> Version 5.0.2
> Connected to 184.70.132.130
> Logged in as massba
> TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM
> No data connection
> 211 End of status
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NET-474) Problem, in __getReply method, parsing reply code with leading space
[
https://issues.apache.org/jira/browse/NET-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-474.
--
Resolution: Won't Fix
> Problem, in __getReply method, parsing reply code with leading space
>
>
> Key: NET-474
> URL: https://issues.apache.org/jira/browse/NET-474
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.1
> Environment: UNIX
>Reporter: Ahmad AMIN
> Fix For: 3.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> FTPClient.getStatus() function call failed complaining about malformed
> response code.
> After tracing the code, I found the problem at following class and line:
> *org.apache.commons.net.ftp.FTP.__getReply(FTP.java:333)*
> The issue is that this method always expects reply code at position 0 of the
> returned reply string. If the reply string has some leading spaces, it fails
> to parse the reply code and returns malformed reply string.
> Example of such a reply string:
> {noformat}
> 211-nhpssltest Ipswitch FTP Server
> Version 5.0.2
> Connected to 184.70.132.130
> Logged in as massba
> TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM
> No data connection
> 211 End of status
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-474) Problem, in __getReply method, parsing reply code with leading space
[
https://issues.apache.org/jira/browse/NET-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410540#comment-13410540
]
Sebb commented on NET-474:
--
Sorry, but unless you can point to documentation that says that leading spaces
are allowed by the FTP protocol, then the bug is in the server, not Commons NET.
I suggest advising them that the server appears to be faulty so they can
contact their supplier to get it fixed.
[By the way, a net search suggests that version 5.0.2 is quite old, and may
have some security issues, so it might be as well to upgrade anyway. That might
well fix the reply format too.]
> Problem, in __getReply method, parsing reply code with leading space
>
>
> Key: NET-474
> URL: https://issues.apache.org/jira/browse/NET-474
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.1
> Environment: UNIX
>Reporter: Ahmad AMIN
> Fix For: 3.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> FTPClient.getStatus() function call failed complaining about malformed
> response code.
> After tracing the code, I found the problem at following class and line:
> *org.apache.commons.net.ftp.FTP.__getReply(FTP.java:333)*
> The issue is that this method always expects reply code at position 0 of the
> returned reply string. If the reply string has some leading spaces, it fails
> to parse the reply code and returns malformed reply string.
> Example of such a reply string:
> {noformat}
> 211-nhpssltest Ipswitch FTP Server
> Version 5.0.2
> Connected to 184.70.132.130
> Logged in as massba
> TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM
> No data connection
> 211 End of status
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-811) StringUtils.stripStart strips out too many characters
[
https://issues.apache.org/jira/browse/LANG-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410472#comment-13410472
]
Matt Benson commented on LANG-811:
--
To be helpful: I think the functionality you're looking for is expressed by
{{StringUtils#removeStart()}} :)
> StringUtils.stripStart strips out too many characters
> --
>
> Key: LANG-811
> URL: https://issues.apache.org/jira/browse/LANG-811
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 2.5, 2.6, 3.0, 3.1
> Environment: N/A
>Reporter: Chris Kelly
> Labels: api-change
>
> I have a String "Tag-TransactionId" for which I want to remove the leading
> "Tag-" leaving only "TransactionId". I thought I could use
> StringUtils.stripStart for this but when I do I get the string "ransactionId"
> instead.
> Below is a short method indicating the issue.
> public static void main(String[] args) {
>
> String key = "Tag-TransactionId";
> String keyWithoutTag = StringUtils.stripStart(key, "Tag-");
>
> String expected = "TransactionId";
> System.out.println("Expected: " + expected + " but got: " +
> keyWithoutTag);
>
> }
> I have tried repeating test on commons-lang from 2.5 upwards to the latest
> release all with the same behaviour. It looks like if the string to be
> removed has characters similar to the remaining string, the stripStart
> methods works incorrectly. It seems to be a case problem as well. If I use
> "Tag-transactionId" with stripStart it successfully returns "transactionId"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-474) Problem, in __getReply method, parsing reply code with leading space
[
https://issues.apache.org/jira/browse/NET-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410473#comment-13410473
]
Ahmad AMIN commented on NET-474:
Anyways, I think this is a silly bug which can be fixed pretty easily. Besides,
the server belongs to a government agency, I can't tell them to retire it just
like that.
> Problem, in __getReply method, parsing reply code with leading space
>
>
> Key: NET-474
> URL: https://issues.apache.org/jira/browse/NET-474
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.1
> Environment: UNIX
>Reporter: Ahmad AMIN
> Fix For: 3.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> FTPClient.getStatus() function call failed complaining about malformed
> response code.
> After tracing the code, I found the problem at following class and line:
> *org.apache.commons.net.ftp.FTP.__getReply(FTP.java:333)*
> The issue is that this method always expects reply code at position 0 of the
> returned reply string. If the reply string has some leading spaces, it fails
> to parse the reply code and returns malformed reply string.
> Example of such a reply string:
> {noformat}
> 211-nhpssltest Ipswitch FTP Server
> Version 5.0.2
> Connected to 184.70.132.130
> Logged in as massba
> TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM
> No data connection
> 211 End of status
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-196) show how one large of e.g. 8MB can be zipped into 3 zip-parts of e.g. compressed 1 MB each
Ralf Hauser created COMPRESS-196: Summary: show how one large of e.g. 8MB can be zipped into 3 zip-parts of e.g. compressed 1 MB each Key: COMPRESS-196 URL: https://issues.apache.org/jira/browse/COMPRESS-196 Project: Commons Compress Issue Type: Improvement Reporter: Ralf Hauser examples like http://stackoverflow.com/questions/243992/how-to-split-a-huge-zip-file-into-multiple-volumes only show how multiple small files can be zipped into a few compressed parts -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-811) StringUtils.stripStart strips out too many characters
[
https://issues.apache.org/jira/browse/LANG-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved LANG-811.
---
Resolution: Invalid
>From the Javadoc for stripStart():
Strips any of a *set* of characters from the start of a String.
It treats the "Tag-" as the set of characters 'T' 'a' 'g' '-' and removes any
it finds from the start of the the string. 'T' appears twice, so is removed
both times.
> StringUtils.stripStart strips out too many characters
> --
>
> Key: LANG-811
> URL: https://issues.apache.org/jira/browse/LANG-811
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 2.5, 2.6, 3.0, 3.1
> Environment: N/A
>Reporter: Chris Kelly
> Labels: api-change
>
> I have a String "Tag-TransactionId" for which I want to remove the leading
> "Tag-" leaving only "TransactionId". I thought I could use
> StringUtils.stripStart for this but when I do I get the string "ransactionId"
> instead.
> Below is a short method indicating the issue.
> public static void main(String[] args) {
>
> String key = "Tag-TransactionId";
> String keyWithoutTag = StringUtils.stripStart(key, "Tag-");
>
> String expected = "TransactionId";
> System.out.println("Expected: " + expected + " but got: " +
> keyWithoutTag);
>
> }
> I have tried repeating test on commons-lang from 2.5 upwards to the latest
> release all with the same behaviour. It looks like if the string to be
> removed has characters similar to the remaining string, the stripStart
> methods works incorrectly. It seems to be a case problem as well. If I use
> "Tag-transactionId" with stripStart it successfully returns "transactionId"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-811) StringUtils.stripStart strips out too many characters
Chris Kelly created LANG-811:
Summary: StringUtils.stripStart strips out too many characters
Key: LANG-811
URL: https://issues.apache.org/jira/browse/LANG-811
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.1, 3.0, 2.6, 2.5
Environment: N/A
Reporter: Chris Kelly
I have a String "Tag-TransactionId" for which I want to remove the leading
"Tag-" leaving only "TransactionId". I thought I could use
StringUtils.stripStart for this but when I do I get the string "ransactionId"
instead.
Below is a short method indicating the issue.
public static void main(String[] args) {
String key = "Tag-TransactionId";
String keyWithoutTag = StringUtils.stripStart(key, "Tag-");
String expected = "TransactionId";
System.out.println("Expected: " + expected + " but got: " +
keyWithoutTag);
}
I have tried repeating test on commons-lang from 2.5 upwards to the latest
release all with the same behaviour. It looks like if the string to be removed
has characters similar to the remaining string, the stripStart methods works
incorrectly. It seems to be a case problem as well. If I use
"Tag-transactionId" with stripStart it successfully returns "transactionId"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-813) SimplexSolver bug?
[
https://issues.apache.org/jira/browse/MATH-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raghu Rangarajan updated MATH-813:
--
Attachment: Commons_Solver.java
> SimplexSolver bug?
> --
>
> Key: MATH-813
> URL: https://issues.apache.org/jira/browse/MATH-813
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Windows 7, JDK 1.7.0_03
>Reporter: Raghu Rangarajan
> Attachments: Commons_Solver.java
>
>
> I am trying to use the SimplexSolver in commons-math3-3.0 and am getting
> unpredictable results. I am pasting the problem code below. Basically
> swapping the sequence of the last two constraints results in two different
> results (of which one is pure sub-optimal). Am I not using the solver
> correctly?
> --
> import java.util.ArrayList;
> import java.util.Collection;
> import org.apache.commons.math3.optimization.*;
> import org.apache.commons.math3.optimization.linear.*;
> public class Commons_Solver {
> public static void main(String[] args) {
> // describe the optimization problem
>
> LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1,
> 1, 1, 1, 1, 1, 0, 0 }, 0);
> Collection constraints = new
> ArrayList();
>
> //variables upper bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 38));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 34));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.LEQ, 1));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.LEQ, 6));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.LEQ, 17));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.LEQ, 11));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.LEQ, 101));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.LEQ, 1e10));
> //variables lower bounds
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1,
> 0 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0,
> 1 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1,-1, -1, -1, -1,
> -1, 1, 0 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { -1, -1, -1, -1, -1,
> -1,0 , 1 }, Relationship.EQ, 0));
> constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
> -0.2841121495327103 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
> -0.25420560747663556 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
> -0.04485981308411215 }, Relationship.GEQ, 0));
>
> /*---
> Swapping the sequence of the below two constraints produces two different
> results
> --*/
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
> -0.12710280373831778 }, Relationship.GEQ, 0));
> constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
> -0.08224299065420561 }, Relationship.GEQ, 0));
> /*--*/
>
> PointValuePair solution = new SimplexSolver().optimize(f, constraints,
> GoalType.MAXIMIZE, false);
> // get the solution
> for (int i = 0 ; i < solution.getPoint().length; i++)
> System.out.println("x[" + i + "] = " + solution.getPoint()[i]);
>
> System.out.println("value = " + solution.getValue());
> }
> }
> --
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-813) SimplexSolver bug?
Raghu Rangarajan created MATH-813:
-
Summary: SimplexSolver bug?
Key: MATH-813
URL: https://issues.apache.org/jira/browse/MATH-813
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: Windows 7, JDK 1.7.0_03
Reporter: Raghu Rangarajan
I am trying to use the SimplexSolver in commons-math3-3.0 and am getting
unpredictable results. I am pasting the problem code below. Basically swapping
the sequence of the last two constraints results in two different results (of
which one is pure sub-optimal). Am I not using the solver correctly?
--
import java.util.ArrayList;
import java.util.Collection;
import org.apache.commons.math3.optimization.*;
import org.apache.commons.math3.optimization.linear.*;
public class Commons_Solver {
public static void main(String[] args) {
// describe the optimization problem
LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { 1,
1, 1, 1, 1, 1, 0, 0 }, 0);
Collection constraints = new
ArrayList();
//variables upper bounds
constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0, 0
}, Relationship.LEQ, 38));
constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0, 0
}, Relationship.LEQ, 34));
constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0, 0
}, Relationship.LEQ, 1));
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0, 0
}, Relationship.LEQ, 6));
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0, 0
}, Relationship.LEQ, 17));
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0, 0
}, Relationship.LEQ, 11));
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1, 0
}, Relationship.LEQ, 101));
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0, 1
}, Relationship.LEQ, 1e10));
//variables lower bounds
constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0, 0
}, Relationship.GEQ, 0));
constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0, 0
}, Relationship.GEQ, 0));
constraints.add(new LinearConstraint(new double[] { 0, 0, 1, 0, 0, 0, 0, 0
}, Relationship.GEQ, 0));
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0, 0
}, Relationship.GEQ, 0));
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0, 0
}, Relationship.GEQ, 0));
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0, 0
}, Relationship.GEQ, 0));
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 1, 0
}, Relationship.GEQ, 0));
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 0, 0, 1
}, Relationship.GEQ, 0));
constraints.add(new LinearConstraint(new double[] { -1,-1, -1, -1, -1, -1,
1, 0 }, Relationship.EQ, 0));
constraints.add(new LinearConstraint(new double[] { -1, -1, -1, -1, -1,
-1,0 , 1 }, Relationship.EQ, 0));
constraints.add(new LinearConstraint(new double[] { 1, 0, 0, 0, 0, 0, 0,
-0.2841121495327103 }, Relationship.GEQ, 0));
constraints.add(new LinearConstraint(new double[] { 0, 1, 0, 0, 0, 0, 0,
-0.25420560747663556 }, Relationship.GEQ, 0));
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 1, 0, 0, 0,
-0.04485981308411215 }, Relationship.GEQ, 0));
/*---
Swapping the sequence of the below two constraints produces two different
results
--*/
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 1, 0, 0,
-0.12710280373831778 }, Relationship.GEQ, 0));
constraints.add(new LinearConstraint(new double[] { 0, 0, 0, 0, 0, 1, 0,
-0.08224299065420561 }, Relationship.GEQ, 0));
/*--*/
PointValuePair solution = new SimplexSolver().optimize(f, constraints,
GoalType.MAXIMIZE, false);
// get the solution
for (int i = 0 ; i < solution.getPoint().length; i++)
System.out.println("x[" + i + "] = " + solution.getPoint()[i]);
System.out.println("value = " + solution.getValue());
}
}
--
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-425) FibonacciHeap enters in an infinite loop when applying SpannigTree algorithms
Simone Tripodi created SANDBOX-425:
--
Summary: FibonacciHeap enters in an infinite loop when applying
SpannigTree algorithms
Key: SANDBOX-425
URL: https://issues.apache.org/jira/browse/SANDBOX-425
Project: Commons Sandbox
Issue Type: Bug
Components: Graph
Affects Versions: Nightly Builds
Reporter: Simone Tripodi
Fix For: Nightly Builds
Just replacing the {{PriorityQueue}} with the {{FibonacciHeap}} in spanning
tree algorithms, looks like procedures enter in an infinite loop.
There is something wrong in the data structure - what is really strange is that
shortest path algorithms are not affected by the same issue...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
