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
<thomas.neidh...@gmail.com>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
>
>

Reply via email to