Re: [math] Recover final tableau values from SimplexSolver
Yes, I did a blind "git add ." and messed the codebase a bit at first. Ole: Thanks for the tip, I'll check it out. Great! My plan is to implement a few simple end-to-end tests first, based on Applied Mathematical Programming (http://web.mit.edu/15.053/www/), and then refactor, implement more fine-grained tests, and finally implement some heavy end-to-end tests. About the current interface, I changed the LinearConstraintSet back to using a simple ArrayList. I'll reread our discussion about this and change it to some sort of Set again. In the SimplexSolution class, I'll change the HashMap to the Map interface. Also, the CoefficientBounds class that I created is nothing more than a range, and I think that there's already such class in the library. Looking at the SolutionCallback, the way things stand, the sensitivity info will not be available to the callback. You can query the SimplexTableu for the (current) optimal solution, but only SimplexSolver knows how to parse the sensitivity info from the tableau. Maybe we could refactor this later? []s Renato C. On Wed, Nov 20, 2013 at 5:40 PM, Thomas Neidhart wrote: > On 11/20/2013 07:16 PM, Thomas Neidhart wrote: > > On 11/20/2013 05:43 PM, Renato Cherullo wrote: > >> Ok, I just pushed my code to the fork at > >> https://github.com/cherullo/commons-math. > >> Merging with SolutionCallback was straightforward, and the standard > tests > >> passed. > >> I already saw issues in the new code, but right now I'd like your > opinion > >> on the current interface (ie. public SimplexSolution > >> optimizeExtra(OptimizationData...)). > >> It doesn't seem to fit well with the rest. Thoughts? > > > > I think you committed a bit too much - try to remove the target > directory. > > Sorry, I missed that you already cleaned up the codebase after the first > commit. > > Regarding the additional optimize method: I think this would also be > acceptable to add such a method as additional information about this > specific optimization algorithm is returned, which is not available for > others. > > The actual interface and data returned needs to be further discussed, > and unit tests will be necessary, but take your time and continue with > your approach. > > Thomas > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [math] Recover final tableau values from SimplexSolver
On 11/20/2013 07:16 PM, Thomas Neidhart wrote: > On 11/20/2013 05:43 PM, Renato Cherullo wrote: >> Ok, I just pushed my code to the fork at >> https://github.com/cherullo/commons-math. >> Merging with SolutionCallback was straightforward, and the standard tests >> passed. >> I already saw issues in the new code, but right now I'd like your opinion >> on the current interface (ie. public SimplexSolution >> optimizeExtra(OptimizationData...)). >> It doesn't seem to fit well with the rest. Thoughts? > > I think you committed a bit too much - try to remove the target directory. Sorry, I missed that you already cleaned up the codebase after the first commit. Regarding the additional optimize method: I think this would also be acceptable to add such a method as additional information about this specific optimization algorithm is returned, which is not available for others. The actual interface and data returned needs to be further discussed, and unit tests will be necessary, but take your time and continue with your approach. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Recover final tableau values from SimplexSolver
I found this .gitignore info helpful when I first started with git: http://www.vogella.com/articles/Git/article.html#d264321e1029 On 11/20/2013 12:16 PM, Thomas Neidhart wrote: On 11/20/2013 05:43 PM, Renato Cherullo wrote: Ok, I just pushed my code to the fork at https://github.com/cherullo/commons-math. Merging with SolutionCallback was straightforward, and the standard tests passed. I already saw issues in the new code, but right now I'd like your opinion on the current interface (ie. public SimplexSolution optimizeExtra(OptimizationData...)). It doesn't seem to fit well with the rest. Thoughts? I think you committed a bit too much - try to remove the target directory. Thomas []s Renato C. On Wed, Nov 20, 2013 at 1:21 PM, Renato Cherullo wrote: Hi guys, It's been a while since I raised this issue. I actually solved this and I want to contribute it back. I implemented a new public method in SimplexSolver called optimizeExtra, that returns a SimplexSolution containing: 1) PointValuePair solution; The optimal solution. 2) HashMap extraConstraintInfo; A mapping of the user created LinearConstraints to a class containing the constraint's RHS sensitivity and shadow price. 3) CoefficientBounds[] coefficientSensitivity; The sensitivity of each coefficient in the objective function. I believe that the code is good, mathematically speaking, because I checked the results (both manually and automatically) against another library. But, since this was done in a certain problem domain, there may still be bugs in untested scenarios. Unfortunately, I can't bring those automated tests without bringing a lot of code related to that domain. We also checked the results after some post-processing that could mask some very palpable errors, making those tests unsuitable for general testing. I'll implement new end-to-end tests. I just created a fork at https://github.com/cherullo/commons-math. I'll email you guys as soon as I finish merging my changes so we can discuss this further. I saw that the SolutionCallback was implemented. Since my approach also has it's merits, I'll try my best to merge both. Comments are welcome :-) []s Renato C. On Tue, Sep 10, 2013 at 2:42 AM, Thomas Neidhart < thomas.neidh...@gmail.com> wrote: On 09/09/2013 10:37 PM, Thomas Neidhart wrote: On 09/09/2013 09:02 PM, Renato Cherullo wrote: Hi all, I need to implement a way to recover some important information from SimplexSolver's final tableau. I'll start by the shadow price, which seems very straight forward. If I understand it correctly, I must: 1- Store the original LinearConstraints in the same order as the normalized constraints. The LinearConstraintSet stores the constraints in a HashSet, so care must be taken to ensure ordering. 2- After the optimization, given a constraint, I must determine the tableau's column relative to the constraint's slack variable and return the value on the objective function row. The column index should be getSlackVariableOffset() plus the number of LEQ and GEQ constraints present in the original constraints list before the given constraint. I'm kinda new to the Simplex method, so this may be wrong too. Looking at the code, I think that the logic in (2) should be implemented in SimplexSolver, but I'm not sure about (1), since: A- SimplexSolver doesn't store the SimplexTableau instance used during optimization. Since SS is immutable, it really shouldn't. So I must return the shadow price of every constraint along the optimal PointValuePair, creating another overload of the doOptimize method (or some other new method). There are related requests from other users (see MATH-970), which want to retrieve the best solution found so far in case the optimization reaches the iteration limit. Right now it is not possible to retrieve the last computed tableau but we will need to change that in some way. When we have this, adding a method to retrieve the index of the slack variable should be trivial. One way to achieve this without breaking the current API would be to define a separate OptimizationData object that acts as a callback: e.g. SolutionCallback, with an interface like this: updateTableau(SimplexTableau t) this callback will be called every iteration step and can be provided in the call to optimize. The last solution can be retrieved from the tableau via getSolution(). Thomas B- I'm not confident enough that iterating a HashSet is fully deterministic, nothing in the contracts says so. If it's really not deterministic, then I'd have to copy the original constraints in the same foreach-loop that builds the normalized constraints list inside SimplexTableau (from the HashSet in LinearConstraintSet). Normalization happens in the normalizeConstraints method, and it returns a List right into the final "constraints" field. To have both lists populated in the same loop and placed in final fields, the loop would have to be in the constructor.
Re: [math] Recover final tableau values from SimplexSolver
On 11/20/2013 05:43 PM, Renato Cherullo wrote: > Ok, I just pushed my code to the fork at > https://github.com/cherullo/commons-math. > Merging with SolutionCallback was straightforward, and the standard tests > passed. > I already saw issues in the new code, but right now I'd like your opinion > on the current interface (ie. public SimplexSolution > optimizeExtra(OptimizationData...)). > It doesn't seem to fit well with the rest. Thoughts? I think you committed a bit too much - try to remove the target directory. Thomas > []s Renato C. > > > On Wed, Nov 20, 2013 at 1:21 PM, Renato Cherullo wrote: > >> Hi guys, >> >> It's been a while since I raised this issue. I actually solved this and I >> want to contribute it back. >> I implemented a new public method in SimplexSolver called optimizeExtra, >> that returns a SimplexSolution containing: >> >> 1) PointValuePair solution; >>The optimal solution. >> >> 2) HashMap extraConstraintInfo; >>A mapping of the user created LinearConstraints to a class containing >> the constraint's RHS sensitivity and shadow price. >> >> 3) CoefficientBounds[] coefficientSensitivity; >>The sensitivity of each coefficient in the objective function. >> >> I believe that the code is good, mathematically speaking, because I >> checked the results (both manually and automatically) against another >> library. >> But, since this was done in a certain problem domain, there may still be >> bugs in untested scenarios. >> Unfortunately, I can't bring those automated tests without bringing a lot >> of code related to that domain. We also checked the results after some >> post-processing that could mask some very palpable errors, making those >> tests unsuitable for general testing. >> I'll implement new end-to-end tests. >> >> I just created a fork at https://github.com/cherullo/commons-math. I'll >> email you guys as soon as I finish merging my changes so we can discuss >> this further. >> >> I saw that the SolutionCallback was implemented. Since my approach also >> has it's merits, I'll try my best to merge both. >> Comments are welcome :-) >> >> []s Renato C. >> >> >> >> >> >> >> >> >> On Tue, Sep 10, 2013 at 2:42 AM, Thomas Neidhart < >> thomas.neidh...@gmail.com> wrote: >> >>> On 09/09/2013 10:37 PM, Thomas Neidhart wrote: On 09/09/2013 09:02 PM, Renato Cherullo wrote: > Hi all, > > I need to implement a way to recover some important information from > SimplexSolver's final tableau. > I'll start by the shadow price, which seems very straight forward. If I > understand it correctly, I must: > 1- Store the original LinearConstraints in the same order as the >>> normalized > constraints. >The LinearConstraintSet stores the constraints in a HashSet, so care > must be taken to ensure ordering. > 2- After the optimization, given a constraint, I must determine the > tableau's column relative to the constraint's slack variable and >>> return the > value on the objective function row. >The column index should be getSlackVariableOffset() plus the number >>> of > LEQ and GEQ constraints present in the original constraints list >>> before the > given constraint. > > I'm kinda new to the Simplex method, so this may be wrong too. Looking >>> at > the code, I think that the logic in (2) should be implemented in > SimplexSolver, but I'm not sure about (1), since: > > A- SimplexSolver doesn't store the SimplexTableau instance used during > optimization. Since SS is immutable, it really shouldn't. So I must >>> return > the shadow price of every constraint along the optimal PointValuePair, > creating another overload of the doOptimize method (or some other new > method). There are related requests from other users (see MATH-970), which want to retrieve the best solution found so far in case the optimization reaches the iteration limit. Right now it is not possible to retrieve the last computed tableau but we will need to change that in some way. When we have this, adding a method to retrieve the index of the slack variable should be trivial. >>> >>> One way to achieve this without breaking the current API would be to >>> define a separate OptimizationData object that acts as a callback: >>> >>> e.g. SolutionCallback, with an interface like this: >>> >>> updateTableau(SimplexTableau t) >>> >>> this callback will be called every iteration step and can be provided in >>> the call to optimize. >>> >>> The last solution can be retrieved from the tableau via getSolution(). >>> >>> Thomas >>> > B- I'm not confident enough that iterating a HashSet is fully > deterministic, nothing in the contracts says so. If it's really not > deterministic, then I'd have to copy the original constraints in the >>> same > foreach-loop that builds the normalized constraints list inside > SimplexTableau (from the HashSet in LinearConst
Re: [math] Recover final tableau values from SimplexSolver
Ok, I just pushed my code to the fork at https://github.com/cherullo/commons-math. Merging with SolutionCallback was straightforward, and the standard tests passed. I already saw issues in the new code, but right now I'd like your opinion on the current interface (ie. public SimplexSolution optimizeExtra(OptimizationData...)). It doesn't seem to fit well with the rest. Thoughts? []s Renato C. On Wed, Nov 20, 2013 at 1:21 PM, Renato Cherullo wrote: > Hi guys, > > It's been a while since I raised this issue. I actually solved this and I > want to contribute it back. > I implemented a new public method in SimplexSolver called optimizeExtra, > that returns a SimplexSolution containing: > > 1) PointValuePair solution; >The optimal solution. > > 2) HashMap extraConstraintInfo; >A mapping of the user created LinearConstraints to a class containing > the constraint's RHS sensitivity and shadow price. > > 3) CoefficientBounds[] coefficientSensitivity; >The sensitivity of each coefficient in the objective function. > > I believe that the code is good, mathematically speaking, because I > checked the results (both manually and automatically) against another > library. > But, since this was done in a certain problem domain, there may still be > bugs in untested scenarios. > Unfortunately, I can't bring those automated tests without bringing a lot > of code related to that domain. We also checked the results after some > post-processing that could mask some very palpable errors, making those > tests unsuitable for general testing. > I'll implement new end-to-end tests. > > I just created a fork at https://github.com/cherullo/commons-math. I'll > email you guys as soon as I finish merging my changes so we can discuss > this further. > > I saw that the SolutionCallback was implemented. Since my approach also > has it's merits, I'll try my best to merge both. > Comments are welcome :-) > > []s Renato C. > > > > > > > > > On Tue, Sep 10, 2013 at 2:42 AM, Thomas Neidhart < > thomas.neidh...@gmail.com> wrote: > >> On 09/09/2013 10:37 PM, Thomas Neidhart wrote: >> > On 09/09/2013 09:02 PM, Renato Cherullo wrote: >> >> Hi all, >> >> >> >> I need to implement a way to recover some important information from >> >> SimplexSolver's final tableau. >> >> I'll start by the shadow price, which seems very straight forward. If I >> >> understand it correctly, I must: >> >> 1- Store the original LinearConstraints in the same order as the >> normalized >> >> constraints. >> >>The LinearConstraintSet stores the constraints in a HashSet, so care >> >> must be taken to ensure ordering. >> >> 2- After the optimization, given a constraint, I must determine the >> >> tableau's column relative to the constraint's slack variable and >> return the >> >> value on the objective function row. >> >>The column index should be getSlackVariableOffset() plus the number >> of >> >> LEQ and GEQ constraints present in the original constraints list >> before the >> >> given constraint. >> >> >> >> I'm kinda new to the Simplex method, so this may be wrong too. Looking >> at >> >> the code, I think that the logic in (2) should be implemented in >> >> SimplexSolver, but I'm not sure about (1), since: >> >> >> >> A- SimplexSolver doesn't store the SimplexTableau instance used during >> >> optimization. Since SS is immutable, it really shouldn't. So I must >> return >> >> the shadow price of every constraint along the optimal PointValuePair, >> >> creating another overload of the doOptimize method (or some other new >> >> method). >> > >> > There are related requests from other users (see MATH-970), which want >> > to retrieve the best solution found so far in case the optimization >> > reaches the iteration limit. Right now it is not possible to retrieve >> > the last computed tableau but we will need to change that in some way. >> > >> > When we have this, adding a method to retrieve the index of the slack >> > variable should be trivial. >> >> One way to achieve this without breaking the current API would be to >> define a separate OptimizationData object that acts as a callback: >> >> e.g. SolutionCallback, with an interface like this: >> >> updateTableau(SimplexTableau t) >> >> this callback will be called every iteration step and can be provided in >> the call to optimize. >> >> The last solution can be retrieved from the tableau via getSolution(). >> >> Thomas >> >> >> B- I'm not confident enough that iterating a HashSet is fully >> >> deterministic, nothing in the contracts says so. If it's really not >> >> deterministic, then I'd have to copy the original constraints in the >> same >> >> foreach-loop that builds the normalized constraints list inside >> >> SimplexTableau (from the HashSet in LinearConstraintSet). Normalization >> >> happens in the normalizeConstraints method, and it returns a List right >> >> into the final "constraints" field. To have both lists populated in the >> >> same loop and placed in final fields, the
Re: [math] Recover final tableau values from SimplexSolver
Hi guys, It's been a while since I raised this issue. I actually solved this and I want to contribute it back. I implemented a new public method in SimplexSolver called optimizeExtra, that returns a SimplexSolution containing: 1) PointValuePair solution; The optimal solution. 2) HashMap extraConstraintInfo; A mapping of the user created LinearConstraints to a class containing the constraint's RHS sensitivity and shadow price. 3) CoefficientBounds[] coefficientSensitivity; The sensitivity of each coefficient in the objective function. I believe that the code is good, mathematically speaking, because I checked the results (both manually and automatically) against another library. But, since this was done in a certain problem domain, there may still be bugs in untested scenarios. Unfortunately, I can't bring those automated tests without bringing a lot of code related to that domain. We also checked the results after some post-processing that could mask some very palpable errors, making those tests unsuitable for general testing. I'll implement new end-to-end tests. I just created a fork at https://github.com/cherullo/commons-math. I'll email you guys as soon as I finish merging my changes so we can discuss this further. I saw that the SolutionCallback was implemented. Since my approach also has it's merits, I'll try my best to merge both. Comments are welcome :-) []s Renato C. On Tue, Sep 10, 2013 at 2:42 AM, Thomas Neidhart wrote: > On 09/09/2013 10:37 PM, Thomas Neidhart wrote: > > On 09/09/2013 09:02 PM, Renato Cherullo wrote: > >> Hi all, > >> > >> I need to implement a way to recover some important information from > >> SimplexSolver's final tableau. > >> I'll start by the shadow price, which seems very straight forward. If I > >> understand it correctly, I must: > >> 1- Store the original LinearConstraints in the same order as the > normalized > >> constraints. > >>The LinearConstraintSet stores the constraints in a HashSet, so care > >> must be taken to ensure ordering. > >> 2- After the optimization, given a constraint, I must determine the > >> tableau's column relative to the constraint's slack variable and return > the > >> value on the objective function row. > >>The column index should be getSlackVariableOffset() plus the number > of > >> LEQ and GEQ constraints present in the original constraints list before > the > >> given constraint. > >> > >> I'm kinda new to the Simplex method, so this may be wrong too. Looking > at > >> the code, I think that the logic in (2) should be implemented in > >> SimplexSolver, but I'm not sure about (1), since: > >> > >> A- SimplexSolver doesn't store the SimplexTableau instance used during > >> optimization. Since SS is immutable, it really shouldn't. So I must > return > >> the shadow price of every constraint along the optimal PointValuePair, > >> creating another overload of the doOptimize method (or some other new > >> method). > > > > There are related requests from other users (see MATH-970), which want > > to retrieve the best solution found so far in case the optimization > > reaches the iteration limit. Right now it is not possible to retrieve > > the last computed tableau but we will need to change that in some way. > > > > When we have this, adding a method to retrieve the index of the slack > > variable should be trivial. > > One way to achieve this without breaking the current API would be to > define a separate OptimizationData object that acts as a callback: > > e.g. SolutionCallback, with an interface like this: > > updateTableau(SimplexTableau t) > > this callback will be called every iteration step and can be provided in > the call to optimize. > > The last solution can be retrieved from the tableau via getSolution(). > > Thomas > > >> B- I'm not confident enough that iterating a HashSet is fully > >> deterministic, nothing in the contracts says so. If it's really not > >> deterministic, then I'd have to copy the original constraints in the > same > >> foreach-loop that builds the normalized constraints list inside > >> SimplexTableau (from the HashSet in LinearConstraintSet). Normalization > >> happens in the normalizeConstraints method, and it returns a List right > >> into the final "constraints" field. To have both lists populated in the > >> same loop and placed in final fields, the loop would have to be in the > >> constructor. Kinda ugly... > > > > the iteration order for a HashSet is still deterministic (as long as you > > do not modify the set itself of course), but only inside a running vm. > > Running the same example might lead to different results for different > > vms, thus I was proposing to change the LinearConstraintSet to use a > > LinkedHashSet internally as it will simplify analyzing and debugging > > problems reported by users. > > > > btw. the constraints were provided as a plain list prior to the > > refactoring that resulted in the current API available in the optim > package. > > > >
Re: [math] Recover final tableau values from SimplexSolver
On 09/09/2013 10:37 PM, Thomas Neidhart wrote: > On 09/09/2013 09:02 PM, Renato Cherullo wrote: >> Hi all, >> >> I need to implement a way to recover some important information from >> SimplexSolver's final tableau. >> I'll start by the shadow price, which seems very straight forward. If I >> understand it correctly, I must: >> 1- Store the original LinearConstraints in the same order as the normalized >> constraints. >>The LinearConstraintSet stores the constraints in a HashSet, so care >> must be taken to ensure ordering. >> 2- After the optimization, given a constraint, I must determine the >> tableau's column relative to the constraint's slack variable and return the >> value on the objective function row. >>The column index should be getSlackVariableOffset() plus the number of >> LEQ and GEQ constraints present in the original constraints list before the >> given constraint. >> >> I'm kinda new to the Simplex method, so this may be wrong too. Looking at >> the code, I think that the logic in (2) should be implemented in >> SimplexSolver, but I'm not sure about (1), since: >> >> A- SimplexSolver doesn't store the SimplexTableau instance used during >> optimization. Since SS is immutable, it really shouldn't. So I must return >> the shadow price of every constraint along the optimal PointValuePair, >> creating another overload of the doOptimize method (or some other new >> method). > > There are related requests from other users (see MATH-970), which want > to retrieve the best solution found so far in case the optimization > reaches the iteration limit. Right now it is not possible to retrieve > the last computed tableau but we will need to change that in some way. > > When we have this, adding a method to retrieve the index of the slack > variable should be trivial. One way to achieve this without breaking the current API would be to define a separate OptimizationData object that acts as a callback: e.g. SolutionCallback, with an interface like this: updateTableau(SimplexTableau t) this callback will be called every iteration step and can be provided in the call to optimize. The last solution can be retrieved from the tableau via getSolution(). Thomas >> B- I'm not confident enough that iterating a HashSet is fully >> deterministic, nothing in the contracts says so. If it's really not >> deterministic, then I'd have to copy the original constraints in the same >> foreach-loop that builds the normalized constraints list inside >> SimplexTableau (from the HashSet in LinearConstraintSet). Normalization >> happens in the normalizeConstraints method, and it returns a List right >> into the final "constraints" field. To have both lists populated in the >> same loop and placed in final fields, the loop would have to be in the >> constructor. Kinda ugly... > > the iteration order for a HashSet is still deterministic (as long as you > do not modify the set itself of course), but only inside a running vm. > Running the same example might lead to different results for different > vms, thus I was proposing to change the LinearConstraintSet to use a > LinkedHashSet internally as it will simplify analyzing and debugging > problems reported by users. > > btw. the constraints were provided as a plain list prior to the > refactoring that resulted in the current API available in the optim package. > >> So, any comments about the Simplex method and coding will be greatly >> appreciated. >> I'm a mathematician and programmer (much more the later than the former), >> but I'm not well versed in Java's idiosyncrasies, and I'm new to >> participating in the FOSS community. I want to do this, and so any guidance >> will be appreciated :-) > > Welcome to the commons community! > > Before starting to create patches, you might want to read the developers > guide: > > http://commons.apache.org/proper/commons-math/developers.html > > If you other questions, do not hesitate to raise them on the mailinglist. > > Thomas > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Recover final tableau values from SimplexSolver
On 09/09/2013 09:02 PM, Renato Cherullo wrote: > Hi all, > > I need to implement a way to recover some important information from > SimplexSolver's final tableau. > I'll start by the shadow price, which seems very straight forward. If I > understand it correctly, I must: > 1- Store the original LinearConstraints in the same order as the normalized > constraints. >The LinearConstraintSet stores the constraints in a HashSet, so care > must be taken to ensure ordering. > 2- After the optimization, given a constraint, I must determine the > tableau's column relative to the constraint's slack variable and return the > value on the objective function row. >The column index should be getSlackVariableOffset() plus the number of > LEQ and GEQ constraints present in the original constraints list before the > given constraint. > > I'm kinda new to the Simplex method, so this may be wrong too. Looking at > the code, I think that the logic in (2) should be implemented in > SimplexSolver, but I'm not sure about (1), since: > > A- SimplexSolver doesn't store the SimplexTableau instance used during > optimization. Since SS is immutable, it really shouldn't. So I must return > the shadow price of every constraint along the optimal PointValuePair, > creating another overload of the doOptimize method (or some other new > method). There are related requests from other users (see MATH-970), which want to retrieve the best solution found so far in case the optimization reaches the iteration limit. Right now it is not possible to retrieve the last computed tableau but we will need to change that in some way. When we have this, adding a method to retrieve the index of the slack variable should be trivial. > B- I'm not confident enough that iterating a HashSet is fully > deterministic, nothing in the contracts says so. If it's really not > deterministic, then I'd have to copy the original constraints in the same > foreach-loop that builds the normalized constraints list inside > SimplexTableau (from the HashSet in LinearConstraintSet). Normalization > happens in the normalizeConstraints method, and it returns a List right > into the final "constraints" field. To have both lists populated in the > same loop and placed in final fields, the loop would have to be in the > constructor. Kinda ugly... the iteration order for a HashSet is still deterministic (as long as you do not modify the set itself of course), but only inside a running vm. Running the same example might lead to different results for different vms, thus I was proposing to change the LinearConstraintSet to use a LinkedHashSet internally as it will simplify analyzing and debugging problems reported by users. btw. the constraints were provided as a plain list prior to the refactoring that resulted in the current API available in the optim package. > So, any comments about the Simplex method and coding will be greatly > appreciated. > I'm a mathematician and programmer (much more the later than the former), > but I'm not well versed in Java's idiosyncrasies, and I'm new to > participating in the FOSS community. I want to do this, and so any guidance > will be appreciated :-) Welcome to the commons community! Before starting to create patches, you might want to read the developers guide: http://commons.apache.org/proper/commons-math/developers.html If you other questions, do not hesitate to raise them on the mailinglist. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Recover final tableau values from SimplexSolver
Hi. [...] B- I'm not confident enough that iterating a HashSet is fully deterministic, nothing in the contracts says so. If ordering is needed, we can change to a "TreeSet". Gilles [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
