ojalgo-user Mailing List for oj! Algorithms (Page 8)
Mathematics, linear algebra and optimisation
Brought to you by:
apete
Menu
▾
▴
ojalgo-user — For ojAlgo users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(1) |
Mar
|
Apr
(14) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2005 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2006 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
(5) |
Sep
|
Oct
(3) |
Nov
(4) |
Dec
(2) |
| 2007 |
Jan
(8) |
Feb
(1) |
Mar
(2) |
Apr
(11) |
May
(6) |
Jun
|
Jul
(10) |
Aug
(2) |
Sep
|
Oct
(4) |
Nov
|
Dec
(11) |
| 2008 |
Jan
(22) |
Feb
(4) |
Mar
(2) |
Apr
(4) |
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(17) |
Dec
(5) |
| 2009 |
Jan
(15) |
Feb
(2) |
Mar
(2) |
Apr
(3) |
May
(4) |
Jun
(5) |
Jul
(9) |
Aug
(2) |
Sep
|
Oct
(5) |
Nov
(14) |
Dec
|
| 2010 |
Jan
(3) |
Feb
(5) |
Mar
(2) |
Apr
(19) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2011 |
Jan
|
Feb
(1) |
Mar
(7) |
Apr
(10) |
May
(1) |
Jun
(15) |
Jul
(1) |
Aug
|
Sep
|
Oct
(13) |
Nov
(9) |
Dec
(11) |
| 2012 |
Jan
|
Feb
(1) |
Mar
(9) |
Apr
(23) |
May
(16) |
Jun
(9) |
Jul
(13) |
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2013 |
Jan
|
Feb
(12) |
Mar
(7) |
Apr
(24) |
May
|
Jun
(7) |
Jul
(4) |
Aug
|
Sep
(3) |
Oct
(16) |
Nov
(7) |
Dec
(3) |
| 2014 |
Jan
(22) |
Feb
(1) |
Mar
(1) |
Apr
|
May
(2) |
Jun
(3) |
Jul
(4) |
Aug
(4) |
Sep
(1) |
Oct
(2) |
Nov
(6) |
Dec
(2) |
| 2015 |
Jan
(11) |
Feb
(10) |
Mar
(1) |
Apr
(9) |
May
|
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(6) |
Oct
(3) |
Nov
(15) |
Dec
(4) |
| 2016 |
Jan
(6) |
Feb
|
Mar
(18) |
Apr
(5) |
May
(9) |
Jun
(3) |
Jul
(5) |
Aug
(2) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
(5) |
| 2017 |
Jan
(4) |
Feb
(3) |
Mar
|
Apr
|
May
(12) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2018 |
Jan
(5) |
Feb
|
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(4) |
Aug
(1) |
Sep
(8) |
Oct
|
Nov
|
Dec
(1) |
| 2019 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Uli S. <Uli...@In...> - 2015-01-27 13:10:28
|
Hi, Am 27.01.2015 um 12:23 schrieb Anders Peterson: > Running your program with the latest development version of ojAlgo (requires Java 8) I get this output and no exceptions; Sorry that I didn't mention it, but I am using ojAlgo 37. I did not try with the latest development version and sadly my project cannot switch from Java 7 to Java 8. > x = 21.0 ~ 21 > y = -1.0 ~ -1 > > Is that what you want? x = 21 and y = -1 is indeed one of my desired solution. > There are a number of configurable options in ExpressionsBasedModel.options that control accuracy and rounding. Some of > these are a bit sensitive and changing them is not generally recommended, but he "integer" and "solution" number > contexts should be relatively safe to tweak. I don't have much time right now, but I will look more closely into this later. From what I understand right now, "solution" affects how the solution is turned into a BigDecimal. However, I don't see how rounding "19.999.." can get help me here, since the desired value would be 21. The member "integer" sounds more promising. I guess I want something like a new NumberContext(largish-value-e.g.-10, RoundingMode.HALF_UP). I will experiment with this later. Thanks for the hint. > If you call minimise() rather than solve() does it make a difference? None that matters, but the values in the result change a little. solve(): x = 19.999999999999993 ~ 20 y = -0.9950000000000006 ~ -1 minimise(): x = 20.00000000000000 ~ 20 y = -0.99500000000000 ~ -1 > /Anders Thanks for looking into this. Uli >> On 27 jan 2015, at 10:10, Uli Schlachter <Uli...@In...> wrote: >> >> Hi everyone, >> >> the attached Java program solves a relatively simple ILP with ojAlgo. However, the solution calculates is invalid. Can somehow shed some light into why this is? >> >> Hopefully the program explains itself, but here is some more text: >> >> The function getCoefficients() returns the coefficients for 202 inequalities of the form coef[0]*x + coef[1]*y < 0. The main function creates an ExpressionsBasedModel from this, transformimg the "< 0" into "<= -1" (which is valid since this is about integer values). It prints the solution calculated and then checks if all the inequalities really are satisfied. >> >> However, this fails since the solution calculated doesn't solve all inequalities: >> >> x = 19.999999999999993 ~ 20 >> y = -0.9950000000000006 ~ -1 >> Exception in thread "main" java.lang.Exception: -10*x + -200*y = 0 must be negative (exact: -0.9999999999998100) >> at Solve.main(Solve.java:60) >> >> The program also prints the exact solutions calculated from the BigDecimals that ojAlgo produced. This is the "exact" value you see in the error message above and, as you see, this value (almost) satisfies the condition "<= -1". >> >> Valid solutions to this inequality systems would be x=21, y=-1 or x=201, y=-10. >> >> Obviously, this seems to be a rounding issue. Is there anything that can be done about it? >> >> Cheers, >> Uli >> -- >> - Buck, when, exactly, did you lose your mind? >> - Three months ago. I woke up one morning married to a pineapple. >> An ugly pineapple... But I loved her. >> <Solve.java>------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming. The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net/_______________________________________________ >> ojAlgo-user mailing list >> ojA...@li... >> https://lists.sourceforge.net/lists/listinfo/ojalgo-user > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > ojAlgo-user mailing list > ojA...@li... > https://lists.sourceforge.net/lists/listinfo/ojalgo-user > -- - Buck, when, exactly, did you lose your mind? - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her. |
|
From: Anders P. <an...@op...> - 2015-01-27 11:23:59
|
Running your program with the latest development version of ojAlgo (requires Java 8) I get this output and no exceptions; x = 21.0 ~ 21 y = -1.0 ~ -1 Is that what you want? There are a number of configurable options in ExpressionsBasedModel.options that control accuracy and rounding. Some of these are a bit sensitive and changing them is not generally recommended, but he "integer" and "solution" number contexts should be relatively safe to tweak. If you call minimise() rather than solve() does it make a difference? /Anders > On 27 jan 2015, at 10:10, Uli Schlachter <Uli...@In...> wrote: > > Hi everyone, > > the attached Java program solves a relatively simple ILP with ojAlgo. However, the solution calculates is invalid. Can somehow shed some light into why this is? > > Hopefully the program explains itself, but here is some more text: > > The function getCoefficients() returns the coefficients for 202 inequalities of the form coef[0]*x + coef[1]*y < 0. The main function creates an ExpressionsBasedModel from this, transformimg the "< 0" into "<= -1" (which is valid since this is about integer values). It prints the solution calculated and then checks if all the inequalities really are satisfied. > > However, this fails since the solution calculated doesn't solve all inequalities: > > x = 19.999999999999993 ~ 20 > y = -0.9950000000000006 ~ -1 > Exception in thread "main" java.lang.Exception: -10*x + -200*y = 0 must be negative (exact: -0.9999999999998100) > at Solve.main(Solve.java:60) > > The program also prints the exact solutions calculated from the BigDecimals that ojAlgo produced. This is the "exact" value you see in the error message above and, as you see, this value (almost) satisfies the condition "<= -1". > > Valid solutions to this inequality systems would be x=21, y=-1 or x=201, y=-10. > > Obviously, this seems to be a rounding issue. Is there anything that can be done about it? > > Cheers, > Uli > -- > - Buck, when, exactly, did you lose your mind? > - Three months ago. I woke up one morning married to a pineapple. > An ugly pineapple... But I loved her. > <Solve.java>------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/_______________________________________________ > ojAlgo-user mailing list > ojA...@li... > https://lists.sourceforge.net/lists/listinfo/ojalgo-user |
|
From: Uli S. <Uli...@In...> - 2015-01-27 09:10:11
|
Hi everyone, the attached Java program solves a relatively simple ILP with ojAlgo. However, the solution calculates is invalid. Can somehow shed some light into why this is? Hopefully the program explains itself, but here is some more text: The function getCoefficients() returns the coefficients for 202 inequalities of the form coef[0]*x + coef[1]*y < 0. The main function creates an ExpressionsBasedModel from this, transformimg the "< 0" into "<= -1" (which is valid since this is about integer values). It prints the solution calculated and then checks if all the inequalities really are satisfied. However, this fails since the solution calculated doesn't solve all inequalities: x = 19.999999999999993 ~ 20 y = -0.9950000000000006 ~ -1 Exception in thread "main" java.lang.Exception: -10*x + -200*y = 0 must be negative (exact: -0.9999999999998100) at Solve.main(Solve.java:60) The program also prints the exact solutions calculated from the BigDecimals that ojAlgo produced. This is the "exact" value you see in the error message above and, as you see, this value (almost) satisfies the condition "<= -1". Valid solutions to this inequality systems would be x=21, y=-1 or x=201, y=-10. Obviously, this seems to be a rounding issue. Is there anything that can be done about it? Cheers, Uli -- - Buck, when, exactly, did you lose your mind? - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her. |
|
From: Anders P. <an...@op...> - 2015-01-14 15:45:00
|
This is now fixed. https://code.google.com/p/ojalgo/wiki/UsingMPS > On 27 feb 2013, at 21:52, Anders Peterson <an...@op...> wrote: > > I asume you call maximise() or minimise() directly on the MathProgSysModel... and, yes that wont work well. The solution is not written back to the columns. > > MathProgSysModel tmpMPSM = MathProgSysModel.makeFromFile(...); > ExpressionsBasedModel tmpEBM = ExpressionsBasedModel.make(tmpMPSM); > State tmpState = tmpEBM.minimise().getState(); > List<Variable> tmpVariables = tmpEBM.getVariables(); > > The variables have names and the solution values are written back to them. > > Suppose there should be code that writes those solution values to the columns of the MathProgSysModel. Until someone writes that code you have to do as described above. > > /Anders > > > On 27 feb 2013, at 19:00, "Steffen Borgwardt" <bor...@ma...> wrote: > >> Hello! >> >> I'm solving a linear program using ojalgo. To do so, i write an MPS file >> and call 'MathProgSysModel.makeFromFile'. The solving process works just >> fine, but in the 'Optimisation.Result' i cannot tell which value is >> associated to which variable. Their order is not preserved, so i cannot >> simply iterate over the 'or.doubleValues'. >> >> How do i connect variable names with the solution? >> >> Thanks for a reply! >> >> Best >> Steffen >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> ojAlgo-user mailing list >> ojA...@li... >> https://lists.sourceforge.net/lists/listinfo/ojalgo-user >> >> > |
|
From: Nico P. <Nic...@gm...> - 2014-11-21 20:09:14
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>Alright, thanks again.</div> <div> </div> <div> </div> <div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Gesendet:</b> Freitag, 21. November 2014 um 19:42 Uhr<br/> <b>Von:</b> "Anders Peterson" <an...@op...><br/> <b>An:</b> "ojAlgo ojAlgo" <oja...@li...><br/> <b>Betreff:</b> Re: [ojAlgo-user] Use of Result</div> <div name="quoted-content">The getValue() method of Optimisation.Result should return the objective function value - is that not the case?<br/> <br/> The fact that you create an Expression and name it "Objective" has no specific meaning. It's just an expression like any other. It's the fact that you give it a weight that makes it part of the objective function, and the weight specifies how much this particular expression (or variable) contributes the objective function.<br/> <br/> > "Objective: 0.0 (1.000000)".<br/> <br/> This expression evaluates to 0.0 and contributes to the objective function with weight 1.0<br/> <br/> As far as I can see you've created 4 expressions (constraint0, constraint1, Normalization and Objective) and each of them has weight 1.0. This means there are 4 equally weighted "things" that together make up the objective function.<br/> <br/> > 0 <= constraint1: 0.0 (1.000000) <= 0<br/> > 1.000000 <= Normalization: 1.0 (1.000000) <= 1.000000<br/> > 0 <= constraint0: 0.0 (1.000000) <= 0<br/> > Objective: 0.0 (1.000000)<br/> <br/> When you call getValue() you should get 0.0*1.000000 + 1.0*1.000000 + 0.0*1.000000 + 0.0*1.000000 that equals 1.0, and that's what you stated is returned.<br/> <br/> I'm guessing you did not intend constraint0, constraint1 or Normalization to be part of the objective function - then you should not give them weights...<br/> <br/> <br/> /Anders<br/> <br/> <br/> > On 21 nov 2014, at 14:10, Nico Potyka <Nic...@gm...> wrote:<br/> ><br/> > Hi Anders,<br/> ><br/> > sorry to bother you again, but I have another problem. I just optimized a problem and the solution seems perfectly fine (I attach the state of the ExpressionBasedModel below).<br/> > The variable assignment (w0 = w16 = 0.5) is indeed a minimal solution and the value of the objective is 0, as I would expect. However, the getValue() method yields 1 for the<br/> > result object and I do not understand why. In fact, the objective state in the ExpressionBasedModel says "Objective: 0.0 (1.000000)". So, I guess, getValue() yields the second<br/> > value. But what do these values actually mean? The only reasonable explanation for me is that I optimize the objective a + c' w where w is my variable vector, c' the transposed<br/> > objective vector and a an offset. So maybe 0 is the solution of the linear part (c' w) and 1 the solution of the complete objective? Then, I guess, I set an offset of 1 by accident.<br/> > I initialize the objective with<br/> ><br/> > Expression tmpExpr = tmpModel.addExpression("Objective");<br/> > tmpExpr.setLinearFactor(noWorlds, BigMath.ONE); //noworlds=32<br/> > tmpExpr.weight(BigMath.ONE);<br/> ><br/> > So maybe weight corresponds to the offset? I tried to set it to zero, but this does not seem to be the solution. Do you see my mistake? Below you find the complete state<br/> > of the ExpressionBasedModel (constraint0 and constraint1 are some linear constraints that are indeed satisfied).<br/> ><br/> > ############################################<br/> > 0 <= w0: 0.500000<br/> > 0 <= w1: 0<br/> > 0 <= w2: 0<br/> > 0 <= w3: 0<br/> > 0 <= w4: 0<br/> > 0 <= w5: 0<br/> > 0 <= w6: 0<br/> > 0 <= w7: 0<br/> > 0 <= w8: 0<br/> > 0 <= w9: 0<br/> > 0 <= w10: 0<br/> > 0 <= w11: 0<br/> > 0 <= w12: 0<br/> > 0 <= w13: 0<br/> > 0 <= w14: 0<br/> > 0 <= w15: 0<br/> > 0 <= w16: 0.500000<br/> > 0 <= w17: 0<br/> > 0 <= w18: 0<br/> > 0 <= w19: 0<br/> > 0 <= w20: 0<br/> > 0 <= w21: 0<br/> > 0 <= w22: 0<br/> > 0 <= w23: 0<br/> > 0 <= w24: 0<br/> > 0 <= w25: 0<br/> > 0 <= w26: 0<br/> > 0 <= w27: 0<br/> > 0 <= w28: 0<br/> > 0 <= w29: 0<br/> > 0 <= w30: 0<br/> > 0 <= w31: 0<br/> > 0 <= w32: 0<br/> > 0 <= constraint1: 0.0 (1.000000) <= 0<br/> > 1.000000 <= Normalization: 1.0 (1.000000) <= 1.000000<br/> > 0 <= constraint0: 0.0 (1.000000) <= 0<br/> > Objective: 0.0 (1.000000)<br/> > ############################################<br/> ><br/> > Best regards<br/> > Nico<br/> > ------------------------------------------------------------------------------<br/> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server<br/> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards<br/> > with Interactivity, Sharing, Native Excel Exports, App Integration & more<br/> > Get technology previously reserved for billion-dollar corporations, FREE<br/> > <a href="http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk_______________________________________________" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk_______________________________________________</a><br/> > ojAlgo-user mailing list<br/> > ojA...@li...<br/> > <a href="https://lists.sourceforge.net/lists/listinfo/ojalgo-user" target="_blank">https://lists.sourceforge.net/lists/listinfo/ojalgo-user</a><br/> <br/> <br/> ------------------------------------------------------------------------------<br/> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server<br/> from Actuate! Instantly Supercharge Your Business Reports and Dashboards<br/> with Interactivity, Sharing, Native Excel Exports, App Integration & more<br/> Get technology previously reserved for billion-dollar corporations, FREE<br/> <a href="http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk</a><br/> _______________________________________________<br/> ojAlgo-user mailing list<br/> ojA...@li...<br/> <a href="https://lists.sourceforge.net/lists/listinfo/ojalgo-user" target="_blank">https://lists.sourceforge.net/lists/listinfo/ojalgo-user</a></div> </div> </div> </div></div></body></html> |
|
From: Anders P. <an...@op...> - 2014-11-21 18:42:40
|
The getValue() method of Optimisation.Result should return the objective function value - is that not the case?
The fact that you create an Expression and name it "Objective" has no specific meaning. It's just an expression like any other. It's the fact that you give it a weight that makes it part of the objective function, and the weight specifies how much this particular expression (or variable) contributes the objective function.
> "Objective: 0.0 (1.000000)".
This expression evaluates to 0.0 and contributes to the objective function with weight 1.0
As far as I can see you've created 4 expressions (constraint0, constraint1, Normalization and Objective) and each of them has weight 1.0. This means there are 4 equally weighted "things" that together make up the objective function.
> 0 <= constraint1: 0.0 (1.000000) <= 0
> 1.000000 <= Normalization: 1.0 (1.000000) <= 1.000000
> 0 <= constraint0: 0.0 (1.000000) <= 0
> Objective: 0.0 (1.000000)
When you call getValue() you should get 0.0*1.000000 + 1.0*1.000000 + 0.0*1.000000 + 0.0*1.000000 that equals 1.0, and that's what you stated is returned.
I'm guessing you did not intend constraint0, constraint1 or Normalization to be part of the objective function - then you should not give them weights...
/Anders
> On 21 nov 2014, at 14:10, Nico Potyka <Nic...@gm...> wrote:
>
> Hi Anders,
>
> sorry to bother you again, but I have another problem. I just optimized a problem and the solution seems perfectly fine (I attach the state of the ExpressionBasedModel below).
> The variable assignment (w0 = w16 = 0.5) is indeed a minimal solution and the value of the objective is 0, as I would expect. However, the getValue() method yields 1 for the
> result object and I do not understand why. In fact, the objective state in the ExpressionBasedModel says "Objective: 0.0 (1.000000)". So, I guess, getValue() yields the second
> value. But what do these values actually mean? The only reasonable explanation for me is that I optimize the objective a + c' w where w is my variable vector, c' the transposed
> objective vector and a an offset. So maybe 0 is the solution of the linear part (c' w) and 1 the solution of the complete objective? Then, I guess, I set an offset of 1 by accident.
> I initialize the objective with
>
> Expression tmpExpr = tmpModel.addExpression("Objective");
> tmpExpr.setLinearFactor(noWorlds, BigMath.ONE); //noworlds=32
> tmpExpr.weight(BigMath.ONE);
>
> So maybe weight corresponds to the offset? I tried to set it to zero, but this does not seem to be the solution. Do you see my mistake? Below you find the complete state
> of the ExpressionBasedModel (constraint0 and constraint1 are some linear constraints that are indeed satisfied).
>
> ############################################
> 0 <= w0: 0.500000
> 0 <= w1: 0
> 0 <= w2: 0
> 0 <= w3: 0
> 0 <= w4: 0
> 0 <= w5: 0
> 0 <= w6: 0
> 0 <= w7: 0
> 0 <= w8: 0
> 0 <= w9: 0
> 0 <= w10: 0
> 0 <= w11: 0
> 0 <= w12: 0
> 0 <= w13: 0
> 0 <= w14: 0
> 0 <= w15: 0
> 0 <= w16: 0.500000
> 0 <= w17: 0
> 0 <= w18: 0
> 0 <= w19: 0
> 0 <= w20: 0
> 0 <= w21: 0
> 0 <= w22: 0
> 0 <= w23: 0
> 0 <= w24: 0
> 0 <= w25: 0
> 0 <= w26: 0
> 0 <= w27: 0
> 0 <= w28: 0
> 0 <= w29: 0
> 0 <= w30: 0
> 0 <= w31: 0
> 0 <= w32: 0
> 0 <= constraint1: 0.0 (1.000000) <= 0
> 1.000000 <= Normalization: 1.0 (1.000000) <= 1.000000
> 0 <= constraint0: 0.0 (1.000000) <= 0
> Objective: 0.0 (1.000000)
> ############################################
>
> Best regards
> Nico
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk_______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
|
|
From: Nico P. <Nic...@gm...> - 2014-11-21 13:10:38
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>Hi Anders,</div> <div> </div> <div>sorry to bother you again, but I have another problem. I just optimized a problem and the solution seems perfectly fine (I attach the state of the ExpressionBasedModel below).</div> <div>The variable assignment (w0 = w16 = 0.5) is indeed a minimal solution and the value of the objective is 0, as I would expect. However, the getValue() method yields 1 for the</div> <div>result object and I do not understand why. In fact, the objective state in the ExpressionBasedModel says "Objective: 0.0 (1.000000)". So, I guess, getValue() yields the second</div> <div>value. But what do these values actually mean? The only reasonable explanation for me is that I optimize the objective a + c' w where w is my variable vector, c' the transposed</div> <div>objective vector and a an offset. So maybe 0 is the solution of the linear part (c' w) and 1 the solution of the complete objective? Then, I guess, I set an offset of 1 by accident. </div> <div>I initialize the objective with</div> <div><br/> Expression tmpExpr = tmpModel.addExpression("Objective");<br/> tmpExpr.setLinearFactor(noWorlds, BigMath.ONE); //noworlds=32 <br/> tmpExpr.weight(BigMath.ONE);</div> <div> </div> <div>So maybe weight corresponds to the offset? I tried to set it to zero, but this does not seem to be the solution. Do you see my mistake? Below you find the complete state</div> <div>of the ExpressionBasedModel (constraint0 and constraint1 are some linear constraints that are indeed satisfied).</div> <div> </div> <div>############################################<br/> 0 <= w0: 0.500000<br/> 0 <= w1: 0<br/> 0 <= w2: 0<br/> 0 <= w3: 0<br/> 0 <= w4: 0<br/> 0 <= w5: 0<br/> 0 <= w6: 0<br/> 0 <= w7: 0<br/> 0 <= w8: 0<br/> 0 <= w9: 0<br/> 0 <= w10: 0<br/> 0 <= w11: 0<br/> 0 <= w12: 0<br/> 0 <= w13: 0<br/> 0 <= w14: 0<br/> 0 <= w15: 0<br/> 0 <= w16: 0.500000<br/> 0 <= w17: 0<br/> 0 <= w18: 0<br/> 0 <= w19: 0<br/> 0 <= w20: 0<br/> 0 <= w21: 0<br/> 0 <= w22: 0<br/> 0 <= w23: 0<br/> 0 <= w24: 0<br/> 0 <= w25: 0<br/> 0 <= w26: 0<br/> 0 <= w27: 0<br/> 0 <= w28: 0<br/> 0 <= w29: 0<br/> 0 <= w30: 0<br/> 0 <= w31: 0<br/> 0 <= w32: 0<br/> 0 <= constraint1: 0.0 (1.000000) <= 0<br/> 1.000000 <= Normalization: 1.0 (1.000000) <= 1.000000<br/> 0 <= constraint0: 0.0 (1.000000) <= 0<br/> Objective: 0.0 (1.000000)<br/> ############################################</div> <div> </div> <div>Best regards</div> <div>Nico</div> </div></div></body></html> |
|
From: Nico P. <Nic...@gm...> - 2014-11-20 21:31:53
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Yes, sorry, this should solve my problem ;)</div>
<div> </div>
<div>Best regards</div>
<div>Nico</div>
<div> </div>
<div>
<div> </div>
<div> </div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Donnerstag, 20. November 2014 um 21:41 Uhr<br/>
<b>Von:</b> "Anders Peterson" <an...@op...><br/>
<b>An:</b> "ojAlgo ojAlgo" <oja...@li...><br/>
<b>Betreff:</b> Re: [ojAlgo-user] Possible bug in ExpressionBasedModel: setMinimisation/setMaximisation</div>
<div name="quoted-content">I haven't tried your code (yet) but I see something strange:<br/>
<br/>
> tmpModel.setMinimisation(false);<br/>
> tmpModel.setMaximisation(true);<br/>
> Result result = tmpModel.minimise();<br/>
<br/>
<br/>
Essentially you should just do either<br/>
<br/>
Result result = tmpModel.minimise();<br/>
<br/>
or<br/>
<br/>
Result result = tmpModel.maximise();<br/>
<br/>
<br/>
If you look inside those methods they do:<br/>
<br/>
{<br/>
this.setMinimisation(true);<br/>
final Result tmpSolverResult = this.solve();<br/>
return this.handleResult(tmpSolverResult);<br/>
}<br/>
<br/>
and<br/>
<br/>
{<br/>
this.setMaximisation(true);<br/>
final Result tmpSolverResult = this.solve();<br/>
return this.handleResult(tmpSolverResult);<br/>
}<br/>
<br/>
<br/>
Is this something that would explain/solve your problem?<br/>
<br/>
<br/>
/Anders<br/>
<br/>
<br/>
<br/>
<br/>
> On 20 nov 2014, at 13:18, Nico Potyka <Nic...@gm...> wrote:<br/>
><br/>
> Hi,<br/>
><br/>
> I use the newest version of ojAlgo (v37.0) and just tried the ExpressionBasedModel for linear optimization.<br/>
> The solver seems to minimize independently of the configuration via setMinimisation/setMaximisation.<br/>
> Here's a simple example:<br/>
><br/>
><br/>
> int n = 4;<br/>
> Variable[] tmpVariables = new Variable[n];<br/>
> for(int i=0; i<n; i++) {<br/>
> tmpVariables[i] = new Variable("x"+i).lower(BigMath.ZERO);<br/>
> }<br/>
><br/>
><br/>
> ExpressionsBasedModel tmpModel = new ExpressionsBasedModel(tmpVariables);<br/>
><br/>
><br/>
> Expression tmpExpr = tmpModel.addExpression("Objective");<br/>
> tmpExpr.setLinearFactor(0, 10);<br/>
> tmpExpr.setLinearFactor(1, 1);<br/>
> tmpExpr.setLinearFactor(2, 1);<br/>
> tmpExpr.setLinearFactor(3, 1);<br/>
> tmpExpr.weight(BigMath.ONE);<br/>
><br/>
><br/>
> tmpExpr = tmpModel.addExpression("Normalization").level(BigMath.ONE);<br/>
> for(int i=0; i<n; i++) {<br/>
> tmpExpr.setLinearFactor(i, BigMath.ONE);<br/>
> }<br/>
><br/>
> tmpModel.setMinimisation(false);<br/>
> tmpModel.setMaximisation(true);<br/>
> Result result = tmpModel.minimise();<br/>
> System.out.println("optimal value: "+result.getValue());<br/>
> for(int i=0; i<n; i++) {<br/>
> System.out.println("x"+i+": "+result.get(i));<br/>
> }<br/>
><br/>
><br/>
><br/>
> We maximize 10*x0 + x1 + x2 +x3 subject to non-negativity and normalization to 1. The output is<br/>
><br/>
> optimal value: 1.0<br/>
> x0: 0<br/>
> x1: 1.00000000000000<br/>
> x2: 0<br/>
> x3: 0<br/>
><br/>
><br/>
> but in fact the optimal value is 10 and x0 should be 1 instead of x1. It seems that the solver always minimizes<br/>
> the function. Do I use the solver in a wrong way or is there a bug?<br/>
><br/>
> Best,<br/>
> Nico<br/>
> ------------------------------------------------------------------------------<br/>
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server<br/>
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards<br/>
> with Interactivity, Sharing, Native Excel Exports, App Integration & more<br/>
> Get technology previously reserved for billion-dollar corporations, FREE<br/>
> <a href="http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk_______________________________________________" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk_______________________________________________</a><br/>
> ojAlgo-user mailing list<br/>
> ojA...@li...<br/>
> <a href="https://lists.sourceforge.net/lists/listinfo/ojalgo-user" target="_blank">https://lists.sourceforge.net/lists/listinfo/ojalgo-user</a><br/>
<br/>
<br/>
------------------------------------------------------------------------------<br/>
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server<br/>
from Actuate! Instantly Supercharge Your Business Reports and Dashboards<br/>
with Interactivity, Sharing, Native Excel Exports, App Integration & more<br/>
Get technology previously reserved for billion-dollar corporations, FREE<br/>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk</a><br/>
_______________________________________________<br/>
ojAlgo-user mailing list<br/>
ojA...@li...<br/>
<a href="https://lists.sourceforge.net/lists/listinfo/ojalgo-user" target="_blank">https://lists.sourceforge.net/lists/listinfo/ojalgo-user</a></div>
</div>
</div>
</div></div></body></html>
|
|
From: Anders P. <an...@op...> - 2014-11-20 20:41:21
|
I haven't tried your code (yet) but I see something strange:
> tmpModel.setMinimisation(false);
> tmpModel.setMaximisation(true);
> Result result = tmpModel.minimise();
Essentially you should just do either
Result result = tmpModel.minimise();
or
Result result = tmpModel.maximise();
If you look inside those methods they do:
{
this.setMinimisation(true);
final Result tmpSolverResult = this.solve();
return this.handleResult(tmpSolverResult);
}
and
{
this.setMaximisation(true);
final Result tmpSolverResult = this.solve();
return this.handleResult(tmpSolverResult);
}
Is this something that would explain/solve your problem?
/Anders
> On 20 nov 2014, at 13:18, Nico Potyka <Nic...@gm...> wrote:
>
> Hi,
>
> I use the newest version of ojAlgo (v37.0) and just tried the ExpressionBasedModel for linear optimization.
> The solver seems to minimize independently of the configuration via setMinimisation/setMaximisation.
> Here's a simple example:
>
>
> int n = 4;
> Variable[] tmpVariables = new Variable[n];
> for(int i=0; i<n; i++) {
> tmpVariables[i] = new Variable("x"+i).lower(BigMath.ZERO);
> }
>
>
> ExpressionsBasedModel tmpModel = new ExpressionsBasedModel(tmpVariables);
>
>
> Expression tmpExpr = tmpModel.addExpression("Objective");
> tmpExpr.setLinearFactor(0, 10);
> tmpExpr.setLinearFactor(1, 1);
> tmpExpr.setLinearFactor(2, 1);
> tmpExpr.setLinearFactor(3, 1);
> tmpExpr.weight(BigMath.ONE);
>
>
> tmpExpr = tmpModel.addExpression("Normalization").level(BigMath.ONE);
> for(int i=0; i<n; i++) {
> tmpExpr.setLinearFactor(i, BigMath.ONE);
> }
>
> tmpModel.setMinimisation(false);
> tmpModel.setMaximisation(true);
> Result result = tmpModel.minimise();
> System.out.println("optimal value: "+result.getValue());
> for(int i=0; i<n; i++) {
> System.out.println("x"+i+": "+result.get(i));
> }
>
>
>
> We maximize 10*x0 + x1 + x2 +x3 subject to non-negativity and normalization to 1. The output is
>
> optimal value: 1.0
> x0: 0
> x1: 1.00000000000000
> x2: 0
> x3: 0
>
>
> but in fact the optimal value is 10 and x0 should be 1 instead of x1. It seems that the solver always minimizes
> the function. Do I use the solver in a wrong way or is there a bug?
>
> Best,
> Nico
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk_______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
|
|
From: Nico P. <Nic...@gm...> - 2014-11-20 12:19:10
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi,</div>
<div> </div>
<div>I use the newest version of ojAlgo (v37.0) and just tried the ExpressionBasedModel for linear optimization.</div>
<div>The solver seems to minimize independently of the configuration via setMinimisation/setMaximisation.</div>
<div>Here's a simple example:</div>
<div> </div>
<div name="quoted-content">
<div><br/>
int n = 4;<br/>
Variable[] tmpVariables = new Variable[n];<br/>
for(int i=0; i<n; i++) {<br/>
tmpVariables[i] = new Variable("x"+i).lower(BigMath.ZERO);<br/>
}<br/>
<br/>
<br/>
ExpressionsBasedModel tmpModel = new ExpressionsBasedModel(tmpVariables);<br/>
<br/>
<br/>
Expression tmpExpr = tmpModel.addExpression("Objective");<br/>
tmpExpr.setLinearFactor(0, 10); <br/>
tmpExpr.setLinearFactor(1, 1); <br/>
tmpExpr.setLinearFactor(2, 1); <br/>
tmpExpr.setLinearFactor(3, 1);<br/>
tmpExpr.weight(BigMath.ONE);<br/>
<br/>
<br/>
tmpExpr = tmpModel.addExpression("Normalization").level(BigMath.ONE);<br/>
for(int i=0; i<n; i++) {<br/>
tmpExpr.setLinearFactor(i, BigMath.ONE);<br/>
}<br/>
</div>
<div> tmpModel.setMinimisation(false);<br/>
tmpModel.setMaximisation(true);<br/>
Result result = tmpModel.minimise();<br/>
System.out.println("optimal value: "+result.getValue());<br/>
for(int i=0; i<n; i++) {<br/>
System.out.println("x"+i+": "+result.get(i));<br/>
}</div>
<div> </div>
<div> </div>
<div> </div>
<div>We maximize 10*x0 + x1 + x2 +x3 subject to non-negativity and normalization to 1. The output is</div>
<div>
<div> </div>
<div>
<div> optimal value: 1.0<br/>
x0: 0<br/>
x1: 1.00000000000000<br/>
x2: 0<br/>
x3: 0</div>
<div> </div>
<div> </div>
<div>but in fact the optimal value is 10 and x0 should be 1 instead of x1. It seems that the solver always minimizes</div>
<div>the function. Do I use the solver in a wrong way or is there a bug?</div>
<div> </div>
<div>Best,</div>
<div>Nico</div>
</div>
</div>
</div>
</div></div></body></html>
|
|
From: Anders P. <an...@op...> - 2014-10-27 09:40:11
|
I haven't written/published such examples, and as far as I know no one else has either. The MarkowitzModel, and related, have been discussed several times before on this list. Browsing through the list archives should give you some examples. Another alternative is to study the junit tests. Among other places they can be viewed here: https://github.com/optimatika/ojAlgo/tree/master/test/org/ojalgo/finance/portfolio /Anders > On 24 okt 2014, at 10:27, Giordano Agostini <gio...@ya...> wrote: > > Hi to all, > > I am new to this mailing list and to the ojAlgo libraries in general, so please bear with me :-) > Not an expert on Financial Maths, I am trying to start a soft approach with MPT Java Library functionality by learning from a few very simple examples. > > Unfortunately I cannot find simple/toy MPT examples using the MarkowitzModel and BlackLittermanModel classes. > Could anyone please provide some illuminating example or point me towards some clear usage example? > > Thank you in advance, > > Giordano > > ------------------------------------------------------------------------------ > _______________________________________________ > ojAlgo-user mailing list > ojA...@li... > https://lists.sourceforge.net/lists/listinfo/ojalgo-user |
|
From: Giordano A. <gio...@ya...> - 2014-10-24 08:27:58
|
Hi to all, I am new to this mailing list and to the ojAlgo libraries in general, so please bear with me :-) Not an expert on Financial Maths, I am trying to start a soft approach with MPT Java Library functionality by learning from a few very simple examples. Unfortunately I cannot find simple/toy MPT examples using the MarkowitzModel and BlackLittermanModel classes. Could anyone please provide some illuminating example or point me towards some clear usage example? Thank you in advance, Giordano |
|
From: Anders P. <an...@op...> - 2014-09-07 13:44:35
|
v36 is out! I've just discovered that running the tests using Java 8 (on a Mac) causes a few failures that otherwise aren't there. Currently I have no idea about exactly what goes wrong or why it happens. I'll look into this before actually making the code Java 8 dependent. /Anders On 31 aug 2014, at 13:11, Anders Peterson <an...@op...> wrote: > Just uploaded a new snapshot release to SourceForge (v35.21). It is very close to what will be v36, and that will be released soon. > > As soon as v36 has been released two things will happen: > > 1) QuadraticSolver will be deleted, and ConvexSolver will start to diverge its feature set and api. > > 2) Will start to add Java 8 dependent code. > > > If switching to Java 8 is a problem for you and/or if you for some reason prefer to continue using QuadricSolver over ConvexSolver; then v36 is the "final" version for you. In this case it is very much in YOUR INTEREST to test v35.21 - and do it NOW. > > > There will be a Java 7 branch in CVS or at GitHub (possibly both) but Optimatika will not sponsor development or maintenance of that branch. Future development will target the Java 8 version/branch only. > > > /Anders > |
|
From: Anders P. <an...@op...> - 2014-08-31 11:12:08
|
Just uploaded a new snapshot release to SourceForge (v35.21). It is very close to what will be v36, and that will be released soon. As soon as v36 has been released two things will happen: 1) QuadraticSolver will be deleted, and ConvexSolver will start to diverge its feature set and api. 2) Will start to add Java 8 dependent code. If switching to Java 8 is a problem for you and/or if you for some reason prefer to continue using QuadricSolver over ConvexSolver; then v36 is the "final" version for you. In this case it is very much in YOUR INTEREST to test v35.21 - and do it NOW. There will be a Java 7 branch in CVS or at GitHub (possibly both) but Optimatika will not sponsor development or maintenance of that branch. Future development will target the Java 8 version/branch only. /Anders |
|
From: Anders J. <and...@gm...> - 2014-08-25 06:55:00
|
Unfortunately I don't have executable code that isolates this issue, it was built as a part of a larger system and is not easily extracted. As said, the issue and the model was just something that I managed to observe sometimes, and tried to dump sufficiently to make it reproducible. It is not something I will be actively using (the problems are way to hard for MIP, even Gurobi had troubles with small instances), so it is not an issue for me. Kind regards, Anders On Tue, Aug 19, 2014 at 10:19 PM, Anders Peterson <an...@op...> wrote: > Thanks for reporting the problem. Can you send me executable code that > (sometimes) reproduce the problem - something that I can easily turn into a > junit test. > > I believe this is a concurrency related problem with the integer solver. > > /Anders > > > On 19 aug 2014, at 13:48, Anders Johansson <and...@gm...> > wrote: > > > Hello, > > > > I would like to report a small MIP-model that OjAlgo had trouble solving > correctly that I found. > > > > The model is over 16 integer variables x0..x15 with domain [0..414]. > There are four constraints as follows: > > > > 117 <= 30 30 30 30 0 4 0 0 0 4 0 0 0 4 0 0 <= 14868 > > 36 <= 0 4 0 0 40 40 40 40 0 0 4 0 0 0 4 0 <= 170569 > > 341 <= 0 0 8 0 0 0 8 0 68 68 68 68 0 0 0 5 <= 140833 > > 413 <= 0 0 0 8 0 0 0 9 0 0 0 6 59 59 59 59 <= 48321 > > > > The weights for the variables are > > > [2691.5357279536333,2600.760150603986,2605.8958795795374,2606.7208332501104,2715.0757845953835,2602.194912040238,2606.0069468717575,2609.0385816244316,2750.0520522057927,2602.048261785581,2600.507229973181,2602.046307869504,2721.343937605796,2601.7367414553805,2600.595318433882,2599.405979211142] > > and the solution mode is to minimize the value. > > > > Sometimes, but not always, OjAlgo will report a solution as both > feasible and optimal, even though some of the constraints are actually > violated. The invalid solution produced is > > x = 1 2 0 0 0 0 0 1 0 4 0 0 2 3 0 2 > > > > Here is a printout of the model when that happens: > > ############################################ > > 0 <= x0: 1.000000 (2691.535728) <= 414.000000 > > 0 <= x1: 2.000000 (2600.760151) <= 414.000000 > > 0 <= x2: 0 (2605.895880) <= 414.000000 > > 0 <= x3: 0 (2606.720833) <= 414.000000 > > 0 <= x4: 0 (2715.075785) <= 414.000000 > > 0 <= x5: 0 (2602.194912) <= 414.000000 > > 0 <= x6: 0 (2606.006947) <= 414.000000 > > 0 <= x7: 1.000000 (2609.038582) <= 414.000000 > > 0 <= x8: 0 (2750.052052) <= 414.000000 > > 0 <= x9: 4.000000 (2602.048262) <= 414.000000 > > 0 <= x10: 0 (2600.507230) <= 414.000000 > > 0 <= x11: 0 (2602.046308) <= 414.000000 > > 0 <= x12: 2.000000 (2721.343938) <= 414.000000 > > 0 <= x13: 3.000000 (2601.736741) <= 414.000000 > > 0 <= x14: 0 (2600.595318) <= 414.000000 > > 0 <= x15: 2.000000 (2599.405979) <= 414.000000 > > 36.000000 <= constraint 1: 48.0 <= 14868.000000 > > 413.000000 <= constraint 3: 422.0 <= 170569.000000 > > 341.000000 <= constraint 2: 282.0 <= 140833.000000 > > 117..000000 <= constraint 0: 118.0 <= 48321.000000 > > ############################################ > > > > > > As can be seen, constraint 2 is clearly violated by this solution. > > > > This was just found during some testing using some generated models, but > I thought that you might be interested. > > > > Kind regards, > > Anders > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > ojAlgo-user mailing list > > ojA...@li... > > https://lists.sourceforge.net/lists/listinfo/ojalgo-user > > > > ------------------------------------------------------------------------------ > _______________________________________________ > ojAlgo-user mailing list > ojA...@li... > https://lists.sourceforge.net/lists/listinfo/ojalgo-user > |
|
From: Anders P. <an...@op...> - 2014-08-19 20:20:10
|
Thanks for reporting the problem. Can you send me executable code that (sometimes) reproduce the problem - something that I can easily turn into a junit test. I believe this is a concurrency related problem with the integer solver. /Anders On 19 aug 2014, at 13:48, Anders Johansson <and...@gm...> wrote: > Hello, > > I would like to report a small MIP-model that OjAlgo had trouble solving correctly that I found. > > The model is over 16 integer variables x0..x15 with domain [0..414]. There are four constraints as follows: > > 117 <= 30 30 30 30 0 4 0 0 0 4 0 0 0 4 0 0 <= 14868 > 36 <= 0 4 0 0 40 40 40 40 0 0 4 0 0 0 4 0 <= 170569 > 341 <= 0 0 8 0 0 0 8 0 68 68 68 68 0 0 0 5 <= 140833 > 413 <= 0 0 0 8 0 0 0 9 0 0 0 6 59 59 59 59 <= 48321 > > The weights for the variables are > [2691.5357279536333,2600.760150603986,2605.8958795795374,2606.7208332501104,2715.0757845953835,2602.194912040238,2606.0069468717575,2609.0385816244316,2750.0520522057927,2602.048261785581,2600.507229973181,2602.046307869504,2721.343937605796,2601.7367414553805,2600.595318433882,2599.405979211142] > and the solution mode is to minimize the value. > > Sometimes, but not always, OjAlgo will report a solution as both feasible and optimal, even though some of the constraints are actually violated. The invalid solution produced is > x = 1 2 0 0 0 0 0 1 0 4 0 0 2 3 0 2 > > Here is a printout of the model when that happens: > ############################################ > 0 <= x0: 1.000000 (2691.535728) <= 414.000000 > 0 <= x1: 2.000000 (2600.760151) <= 414.000000 > 0 <= x2: 0 (2605.895880) <= 414.000000 > 0 <= x3: 0 (2606.720833) <= 414.000000 > 0 <= x4: 0 (2715.075785) <= 414.000000 > 0 <= x5: 0 (2602.194912) <= 414.000000 > 0 <= x6: 0 (2606.006947) <= 414.000000 > 0 <= x7: 1.000000 (2609.038582) <= 414.000000 > 0 <= x8: 0 (2750.052052) <= 414.000000 > 0 <= x9: 4.000000 (2602.048262) <= 414.000000 > 0 <= x10: 0 (2600.507230) <= 414.000000 > 0 <= x11: 0 (2602.046308) <= 414.000000 > 0 <= x12: 2.000000 (2721.343938) <= 414.000000 > 0 <= x13: 3.000000 (2601.736741) <= 414.000000 > 0 <= x14: 0 (2600.595318) <= 414.000000 > 0 <= x15: 2.000000 (2599.405979) <= 414.000000 > 36.000000 <= constraint 1: 48.0 <= 14868.000000 > 413.000000 <= constraint 3: 422.0 <= 170569.000000 > 341.000000 <= constraint 2: 282.0 <= 140833.000000 > 117..000000 <= constraint 0: 118.0 <= 48321.000000 > ############################################ > > > As can be seen, constraint 2 is clearly violated by this solution. > > This was just found during some testing using some generated models, but I thought that you might be interested. > > Kind regards, > Anders > ------------------------------------------------------------------------------ > _______________________________________________ > ojAlgo-user mailing list > ojA...@li... > https://lists.sourceforge.net/lists/listinfo/ojalgo-user |
|
From: Anders J. <and...@gm...> - 2014-08-19 11:48:22
|
Hello,
I would like to report a small MIP-model that OjAlgo had trouble solving
correctly that I found.
The model is over 16 integer variables x0..x15 with domain [0..414]. There
are four constraints as follows:
117 <= 30 30 30 30 0 4 0 0 0 4 0 0 0 4 0 0 <= 14868
36 <= 0 4 0 0 40 40 40 40 0 0 4 0 0 0 4 0 <= 170569
341 <= 0 0 8 0 0 0 8 0 68 68 68 68 0 0 0 5 <= 140833
413 <= 0 0 0 8 0 0 0 9 0 0 0 6 59 59 59 59 <= 48321
The weights for the variables are
[2691.5357279536333,2600.760150603986,2605.8958795795374,2606.7208332501104,2715.0757845953835,2602.194912040238,2606.0069468717575,2609.0385816244316,2750.0520522057927,2602.048261785581,2600.507229973181,2602.046307869504,2721.343937605796,2601.7367414553805,2600.595318433882,2599.405979211142]
and the solution mode is to minimize the value.
Sometimes, but not always, OjAlgo will report a solution as both feasible
and optimal, even though some of the constraints are actually violated. The
invalid solution produced is
x = 1 2 0 0 0 0 0 1 0 4 0 0 2 3 0 2
Here is a printout of the model when that happens:
############################################
0 <= x0: 1.000000 (2691.535728) <= 414.000000
0 <= x1: 2.000000 (2600.760151) <= 414.000000
0 <= x2: 0 (2605.895880) <= 414.000000
0 <= x3: 0 (2606.720833) <= 414.000000
0 <= x4: 0 (2715.075785) <= 414.000000
0 <= x5: 0 (2602.194912) <= 414.000000
0 <= x6: 0 (2606.006947) <= 414.000000
0 <= x7: 1.000000 (2609.038582) <= 414.000000
0 <= x8: 0 (2750.052052) <= 414.000000
0 <= x9: 4.000000 (2602.048262) <= 414.000000
0 <= x10: 0 (2600.507230) <= 414.000000
0 <= x11: 0 (2602.046308) <= 414.000000
0 <= x12: 2.000000 (2721.343938) <= 414.000000
0 <= x13: 3.000000 (2601.736741) <= 414.000000
0 <= x14: 0 (2600.595318) <= 414.000000
0 <= x15: 2.000000 (2599.405979) <= 414.000000
36.000000 <= constraint 1: 48.0 <= 14868.000000
413.000000 <= constraint 3: 422.0 <= 170569.000000
341.000000 <= constraint 2: 282.0 <= 140833.000000
117.000000 <= constraint 0: 118.0 <= 48321.000000
############################################
As can be seen, constraint 2 is clearly violated by this solution.
This was just found during some testing using some generated models, but I
thought that you might be interested.
Kind regards,
Anders
|
|
From: Anders P. <an...@op...> - 2014-07-30 19:05:39
|
Just updated that page with new results. On 13 jan 2010, at 14:50, Anders Peterson wrote: > http://ojalgo.org/performance_ejml.html |
|
From: Anders P. <an...@op...> - 2014-07-30 07:26:45
|
I believe this message I sent to the list the other is the "answer" to your question: Begin forwarded message: > From: Anders Peterson > Subject: Re: [ojAlgo-user] QuadraticSolver returns different results for the exact same problem > Date: 28 juli 2014 11:41:07 CEST > To: ojAlgo ojAlgo <oja...@li...> > > There is now a new solver org.ojalgo.optimisation.convex.ConvexSolver intended to replace and extend the functionality of org.ojalgo.optimisation.quadratic.QuadraticSolver. The new solver currently/still has exactly the same api as the old one - it's easy to switch between them. > > If you're using ExpressionsBasedModel (or MarkowitzModel in the org.ojalgo.finance.portfolio package) you should make sure that the method getDefaultSolver() contains this: > > //return QuadraticSolver.make(this); > return ConvexSolver.make(this); > > > The intention is that the new solver should handle more problems/cases, get rid of some odd behavior and scale better. > > If you're currently using ojAlgo to solve quadratic optimisation problems please try this new solver and report problems to this mailing list. > > Get the latest source code either from > > http://sourceforge.net/p/ojalgo/code/ > > or > > https://github.com/optimatika/ojAlgo I'm still working on getting rid of the last failing test cases. Very interested in getting feedback on what happens with larger models and models with integer constraints. 1) Get the latest source code 2) Make sure ExpressionsBasedModel uses the new ConvexSolver 3) Continue testing as before /Anders On 29 jul 2014, at 21:33, Edward Tolson <et...@gm...> wrote: > Hello, > > I am investigating ojalgo in the context of portfolio/investment optimization. Unlike the typical Markowitz case, our use case contains real-world complications including shorting assets, transaction costs, and limiting gross and net exposure. The problem can still be modeled as a quadratic optimization, but the number of variables increases quite a bit. I was gradually increasing the number of variables into ojalgo and got stopped pretty quickly. At around 200 variables I receive results that are "Approximate" and in fact the result provided did not match the simple constraints of the problem. I found this quite strange as finding a solution matching the constraints is very simple (and such a starting point was provided to the optimizer). Why would the optimizer return me an "Approximate" solution that doesn't match the constraints at all rather than returning me the best solution meeting the constraints that it could find (including the one I provided as the starting point)? > > The problem as I'm currently setting it up is relatively straightforward other than the large-ish number of variables. Each variable has a min and max constraint, which are the only constraints I'm providing so far. The objective is then a standard quadratic objective to be minimized. > > I'm setting up the problem by constructing an ExpressionsBasedModel, providing it the variables (each with a lower, upper, and starting value), and then providing the model the quadratic and linear expressions to be minimized. > > Any feedback or assistance would be appreciated. > > Here is a toString of the model after being minimized in case it helps. You can see that most of the variables are wildly outside of their bounds. > > ############################################ > 0.000047 <= v0: 0.000047 <= 0.002593 > 0 <= v1: 12.399095 <= 0.002180 > -0.002822 <= v2: -1.639345 <= 0 > -0.002617 <= v3: 9.242242 <= 0 > -0.002228 <= v4: -6.685084 <= 0 > -0.002006 <= v5: 7.002208 <= 0 > 0.000099 <= v6: 0.001492 <= 0.001492 > 0 <= v7: -15.831819 <= 0.001120 > 0.000154 <= v8: -0.654343 <= 0.004867 > 0 <= v9: -0.654343 <= 0.003971 > 0.000004 <= v10: 0.004626 <= 0.004626 > 0 <= v11: -3.352390 <= 0.004041 > 0 <= v12: 10.393662 <= 0.003149 > 0 <= v13: 10.393662 <= 0.002781 > -0.002782 <= v14: -0.002782 <= -0.000033 > -0.002372 <= v15: 14.427516 <= 0 > -0.013213 <= v16: -0.013213 <= -0.000521 > -0.010585 <= v17: -19.335598 <= 0 > -0.002088 <= v18: -9.886252 <= 0 > -0.001852 <= v19: 7.130217 <= 0 > 0.000840 <= v20: 0.000840 <= 0..009390 > 0 <= v21: 24.037796 <= 0.006642 > 0.000016 <= v22: -3.275853 <= 0.002073 > 0 <= v23: -3.275853 <= 0.001784 > 0 <= v24: -0.926375 <= 0.002628 > 0 <= v25: -0.926375 <= 0.002318 > 0.000014 <= v26: 4.944956 <= 0.002697 > 0 <= v27: 4.944956 <= 0.002334 > 0.000727 <= v28: -0.801618 <= 0.007707 > 0 <= v29: -0.801618 <= 0.005381 > 0.000168 <= v30: 0.000168 <= 0.006497 > 0 <= v31: 0 <= 0.005370 > -0.003646 <= v32: -0.000007 <= -0.000007 > -0.003178 <= v33: -9.548069 <= 0 > -0.006960 <= v34: -30.222010 <= 0 > -0.006120 <= v35: 9.120492 <= 0 > -0.002726 <= v36: -0.002726 <= -0.000039 > -0.002313 <= v37: 10.738876 <= 0 > 0 <= v38: 15.791419 <= 0.006325 > 0 <= v39: 15.791419 <= 0.005569 > -0.003546 <= v40: -0.000007 <= -0.000007 > -0.003090 <= v41: 10.877754 <= 0 > 0.000017 <= v42: 0.001999 <= 0.001999 > 0 <= v43: -12.511306 <= 0.001718 > 0.000172 <= v44: 0.000172 <= 0.010036 > 0 <= v45: 11.863053 <= 0..008460 > 0.000116 <= v46: -0.196284 <= 0.005268 > 0 <= v47: -0.196284 <= 0.004392 > 0.000310 <= v48: 1.026073 <= 0.004785 > 0 <= v49: 1.026073 <= 0.003606 > 0.000027 <= v50: 0.003538 <= 0.003538 > 0 <= v51: -13.694850 <= 0.003045 > 0.000314 <= v52: -2.658083 <= 0.012414 > 0 <= v53: -2.658083 <= 0.010274 > 0.000031 <= v54: 0.007608 <= 0.007608 > 0 <= v55: 3.578124 <= 0.006599 > 0 <= v56: 5.966903 <= 0.004941 > 0 <= v57: 5.966903 <= 0.004518 > 0 <= v58: -10.980529 <= 0.019227 > -0.019227 <= v59: 8.256236 <= 0 > -0.008174 <= v60: -22.822929 <= 0 > -0.007344 <= v61: 8.710203 <= 0 > 0 <= v62: 5.836502 <= 0.001974 > 0 <= v63: 5.836502 <= 0.001759 > 0 <= v64: -31.361763 <= 0.001513 > -0.001513 <= v65: 38.911668 <= 0 > -0.005145 <= v66: -13.969862 <= 0 > -0.004651 <= v67: 8.621640 <= 0 > 0.000003 <= v68: 0.007058 <= 0.007058 > 0 <= v69: -23.345131 <= 0.006170 > -0.009407 <= v70: -9.911777 <= 0 > -0.008307 <= v71: -2.999295 <= 0 > 0 <= v72: -6.330518 <= 0.006093 > 0 <= v73: -6.330518 <= 0.005362 > 0.000024 <= v74: 0.001785 <= 0.001785 > 0 <= v75: -24.557506 <= 0..001516 > -0.002806 <= v76: -0.002806 <= -0.000017 > -0.002424 <= v77: 25.120967 <= 0 > -0.004065 <= v78: -12.482007 <= 0 > -0.003562 <= v79: 18.072430 <= 0 > 0.000014 <= v80: 7.902697 <= 0.001913 > 0 <= v81: 7.902697 <= 0.001647 > -0.004862 <= v82: -23.278184 <= 0 > -0.004341 <= v83: 15.855152 <= 0 > -0.003301 <= v84: -7.672005 <= -0.000074 > -0.002750 <= v85: 4.081453 <= 0 > -0.011429 <= v86: -9.231121 <= 0 > -0.010169 <= v87: 20.433090 <= 0 > 0.000044 <= v88: 0.003628 <= 0.003628 > 0 <= v89: -20.725597 <= 0.003091 > -0.003857 <= v90: -8.605115 <= 0 > -0.003523 <= v91: 4.038718 <= 0 > 0 <= v92: -3.002273 <= 0.006223 > -0.006223 <= v93: 40.654612 <= 0 > -0.004187 <= v94: -0.004187 <= -0.000001 > -0.003662 <= v95: 2.308138 <= 0 > -0.005387 <= v96: -50.121281 <= 0 > -0.005080 <= v97: 6.731258 <= 0 > -0.005095 <= v98: -8.260419 <= -0.000143 > -0.004190 <= v99: 2.691277 <= 0 > -0.004629 <= v100: -20.052445 <= 0 > -0.004078 <= v101: 6.520501 <= 0 > -0.002092 <= v102: -6.164178 <= 0 > -0.001843 <= v103: 36.442212 <= 0 > -0.001778 <= v104: -0.001778 <= -0.000071 > -0.001423 <= v105: 9.796041 <= 0 > -0.008854 <= v106: 4.812977 <= 0 > 0 <= v107: 4.812977 <= 0.002873 > -0.011727 <= v108: 12.051375 <= 0 > -0.002280 <= v109: -0.002280 <= -0.000027 > -0.001945 <= v110: 11.204495 <= 0 > 0 <= v111: -9.731284 <= 0.010427 > 0 <= v112: -9.731284 <= 0.009155 > -0.004582 <= v113: -0.004582 <= -0.000051 > -0.003913 <= v114: 17.815327 <= 0 > 0 <= v115: -0.268223 <= 0.001641 > 0 <= v116: -0.268223 <= 0.001472 > 0.000177 <= v117: -2.271096 <= 0.002321 > 0 <= v118: -2.271096 <= 0.001699 > -0.003382 <= v119: -0.000008 <= -0.000008 > -0.002945 <= v120: -11.239441 <= 0 > -0.001377 <= v121: -11.528363 <= 0 > -0.001250 <= v122: -3.873247 <= 0 > 0.000077 <= v123: 2.934028 <= 0.003083 > 0 <= v124: 2.934028 <= 0.002552 > 0 <= v125: 14.661636 <= 0.003678 > 0 <= v126: 14.661636 <= 0.003312 > 0.000042 <= v127: -1.802925 <= 0.006800 > 0 <= v128: -1.802925 <= 0.005871 > 0 <= v129: 11.250457 <= 0.002385 > 0 <= v130: 11.250457 <= 0.002122 > 0.000008 <= v131: 0.002320 <= 0.002320 > 0 <= v132: -10.798308 <= 0.002015 > -0.002007 <= v133: -15.310603 <= -0.000087 > -0.001592 <= v134: 3.336150 <= 0 > 0 <= v135: -13.208688 <= 0.004539 > 0 <= v136: -13.208688 <= 0.004055 > 0.000004 <= v137: 0.000004 <= 0.002534 > 0 <= v138: 14.884312 <= 0.002211 > -0.003423 <= v139: -4.819391 <= 0 > -0.003064 <= v140: 7.298642 <= 0 > -0.011636 <= v141: -24.667288 <= 0 > 0 <= v142: 0 <= 0.000553 > -0.011218 <= v143: 9.120121 <= 0 > 0.000007 <= v144: 0.000007 <= 0.006453 > 0 <= v145: 8.706559 <= 0.005633 > 0.000011 <= v146: 0.000011 <= 0.002405 > 0 <= v147: 5.452150 <= 0.002083 > -0.007417 <= v148: -0.000105 <= -0.000105 > -0.006293 <= v149: -4.366268 <= 0 > 0.000015 <= v150: 0.002860 <= 0.002860 > 0 <= v151: -8.083382 <= 0.002475 > -0.004296 <= v152: -12.277851 <= 0 > -0.003764 <= v153: 8.536914 <= 0 > 0 <= v154: -1.525872 <= 0.000283 > 0 <= v155: -1.525872 <= 0.009001 > -0.008718 <= v156: 3.101125 <= 0 > 0.000272 <= v157: 3.384421 <= 0.007179 > 0 <= v158: 3.384421 <= 0.005772 > -0.011396 <= v159: -5.275025 <= -0.000223 > -0.009553 <= v160: 5.121074 <= 0 > -0.005891 <= v161: -5.439854 <= -0.000071 > -0.005021 <= v162: 3.615476 <= 0 > 0 <= v163: -3.953251 <= 0.003710 > 0 <= v164: -3.953251 <= 0.003428 > -0.002616 <= v165: -30.472951 <= 0 > -0.002310 <= v166: -12.734294 <= 0 > -0.003079 <= v167: -0.003079 <= -0.000012 > -0.002671 <= v168: 36.036856 <= 0 > -0.002525 <= v169: 4.658318 <= 0 > -0.002276 <= v170: 23.741247 <= 0 > -0.004125 <= v171: -0.004125 <= -0.000030 > -0.003554 <= v172: -4.883884 <= 0 > -0.004381 <= v173: -27.223216 <= 0 > -0.003908 <= v174: 0.373790 <= 0 > -0.002665 <= v175: -10.326246 <= 0 > -0.002350 <= v176: 20.589187 <= 0 > 0.000129 <= v177: 3.901199 <= 0.002780 > 0 <= v178: 3.901199 <= 0.002191 > 0 <= v179: 4.868897 <= 0.001489 > 0 <= v180: 4.868897 <= 0.001310 > 0 <= v181: -2.307442 <= 0.003723 > 0 <= v182: -2.307442 <= 0.003519 > secondOrderMinimization: 0.766253 (1.000000) > linearMinimization: -1.532517 (1.000000) > ############################################ > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk_______________________________________________ > ojAlgo-user mailing list > ojA...@li... > https://lists.sourceforge.net/lists/listinfo/ojalgo-user |
|
From: Edward T. <et...@gm...> - 2014-07-29 19:33:35
|
Hello, I am investigating ojalgo in the context of portfolio/investment optimization. Unlike the typical Markowitz case, our use case contains real-world complications including shorting assets, transaction costs, and limiting gross and net exposure. The problem can still be modeled as a quadratic optimization, but the number of variables increases quite a bit. I was gradually increasing the number of variables into ojalgo and got stopped pretty quickly. At around 200 variables I receive results that are "Approximate" and in fact the result provided did not match the simple constraints of the problem. I found this quite strange as finding a solution matching the constraints is very simple (and such a starting point was provided to the optimizer). Why would the optimizer return me an "Approximate" solution that doesn't match the constraints at all rather than returning me the best solution meeting the constraints that it could find (including the one I provided as the starting point)? The problem as I'm currently setting it up is relatively straightforward other than the large-ish number of variables. Each variable has a min and max constraint, which are the only constraints I'm providing so far. The objective is then a standard quadratic objective to be minimized. I'm setting up the problem by constructing an ExpressionsBasedModel, providing it the variables (each with a lower, upper, and starting value), and then providing the model the quadratic and linear expressions to be minimized. Any feedback or assistance would be appreciated. Here is a toString of the model after being minimized in case it helps. You can see that most of the variables are wildly outside of their bounds. ############################################ 0.000047 <= v0: 0.000047 <= 0.002593 0 <= v1: 12.399095 <= 0.002180 -0.002822 <= v2: -1.639345 <= 0 -0.002617 <= v3: 9.242242 <= 0 -0.002228 <= v4: -6.685084 <= 0 -0.002006 <= v5: 7.002208 <= 0 0.000099 <= v6: 0.001492 <= 0.001492 0 <= v7: -15.831819 <= 0.001120 0.000154 <= v8: -0.654343 <= 0.004867 0 <= v9: -0.654343 <= 0.003971 0.000004 <= v10: 0.004626 <= 0.004626 0 <= v11: -3.352390 <= 0.004041 0 <= v12: 10.393662 <= 0.003149 0 <= v13: 10.393662 <= 0.002781 -0.002782 <= v14: -0.002782 <= -0.000033 -0.002372 <= v15: 14.427516 <= 0 -0.013213 <= v16: -0.013213 <= -0.000521 -0.010585 <= v17: -19.335598 <= 0 -0.002088 <= v18: -9.886252 <= 0 -0.001852 <= v19: 7.130217 <= 0 0.000840 <= v20: 0.000840 <= 0.009390 0 <= v21: 24.037796 <= 0.006642 0.000016 <= v22: -3.275853 <= 0.002073 0 <= v23: -3.275853 <= 0.001784 0 <= v24: -0.926375 <= 0.002628 0 <= v25: -0.926375 <= 0.002318 0.000014 <= v26: 4.944956 <= 0.002697 0 <= v27: 4.944956 <= 0.002334 0.000727 <= v28: -0.801618 <= 0.007707 0 <= v29: -0.801618 <= 0.005381 0.000168 <= v30: 0.000168 <= 0.006497 0 <= v31: 0 <= 0.005370 -0.003646 <= v32: -0.000007 <= -0.000007 -0.003178 <= v33: -9.548069 <= 0 -0.006960 <= v34: -30.222010 <= 0 -0.006120 <= v35: 9.120492 <= 0 -0.002726 <= v36: -0.002726 <= -0.000039 -0.002313 <= v37: 10.738876 <= 0 0 <= v38: 15.791419 <= 0.006325 0 <= v39: 15.791419 <= 0.005569 -0.003546 <= v40: -0.000007 <= -0.000007 -0.003090 <= v41: 10.877754 <= 0 0.000017 <= v42: 0.001999 <= 0.001999 0 <= v43: -12.511306 <= 0.001718 0.000172 <= v44: 0.000172 <= 0.010036 0 <= v45: 11.863053 <= 0.008460 0.000116 <= v46: -0.196284 <= 0.005268 0 <= v47: -0.196284 <= 0.004392 0.000310 <= v48: 1.026073 <= 0.004785 0 <= v49: 1.026073 <= 0.003606 0.000027 <= v50: 0.003538 <= 0.003538 0 <= v51: -13.694850 <= 0.003045 0.000314 <= v52: -2.658083 <= 0.012414 0 <= v53: -2.658083 <= 0.010274 0.000031 <= v54: 0.007608 <= 0.007608 0 <= v55: 3.578124 <= 0.006599 0 <= v56: 5.966903 <= 0.004941 0 <= v57: 5.966903 <= 0.004518 0 <= v58: -10.980529 <= 0.019227 -0.019227 <= v59: 8.256236 <= 0 -0.008174 <= v60: -22.822929 <= 0 -0.007344 <= v61: 8.710203 <= 0 0 <= v62: 5.836502 <= 0.001974 0 <= v63: 5.836502 <= 0.001759 0 <= v64: -31.361763 <= 0.001513 -0.001513 <= v65: 38.911668 <= 0 -0.005145 <= v66: -13.969862 <= 0 -0.004651 <= v67: 8.621640 <= 0 0.000003 <= v68: 0.007058 <= 0.007058 0 <= v69: -23.345131 <= 0.006170 -0.009407 <= v70: -9.911777 <= 0 -0.008307 <= v71: -2.999295 <= 0 0 <= v72: -6.330518 <= 0.006093 0 <= v73: -6.330518 <= 0.005362 0.000024 <= v74: 0.001785 <= 0.001785 0 <= v75: -24.557506 <= 0.001516 -0.002806 <= v76: -0.002806 <= -0.000017 -0.002424 <= v77: 25.120967 <= 0 -0.004065 <= v78: -12.482007 <= 0 -0.003562 <= v79: 18.072430 <= 0 0.000014 <= v80: 7.902697 <= 0.001913 0 <= v81: 7.902697 <= 0.001647 -0.004862 <= v82: -23.278184 <= 0 -0.004341 <= v83: 15.855152 <= 0 -0.003301 <= v84: -7.672005 <= -0.000074 -0.002750 <= v85: 4.081453 <= 0 -0.011429 <= v86: -9.231121 <= 0 -0.010169 <= v87: 20.433090 <= 0 0.000044 <= v88: 0.003628 <= 0.003628 0 <= v89: -20.725597 <= 0.003091 -0.003857 <= v90: -8.605115 <= 0 -0.003523 <= v91: 4.038718 <= 0 0 <= v92: -3.002273 <= 0.006223 -0.006223 <= v93: 40.654612 <= 0 -0.004187 <= v94: -0.004187 <= -0.000001 -0.003662 <= v95: 2.308138 <= 0 -0.005387 <= v96: -50.121281 <= 0 -0.005080 <= v97: 6.731258 <= 0 -0.005095 <= v98: -8.260419 <= -0.000143 -0.004190 <= v99: 2.691277 <= 0 -0.004629 <= v100: -20.052445 <= 0 -0.004078 <= v101: 6.520501 <= 0 -0.002092 <= v102: -6.164178 <= 0 -0.001843 <= v103: 36.442212 <= 0 -0.001778 <= v104: -0.001778 <= -0.000071 -0.001423 <= v105: 9.796041 <= 0 -0.008854 <= v106: 4.812977 <= 0 0 <= v107: 4.812977 <= 0.002873 -0.011727 <= v108: 12.051375 <= 0 -0.002280 <= v109: -0.002280 <= -0.000027 -0.001945 <= v110: 11.204495 <= 0 0 <= v111: -9.731284 <= 0.010427 0 <= v112: -9.731284 <= 0.009155 -0.004582 <= v113: -0.004582 <= -0.000051 -0.003913 <= v114: 17.815327 <= 0 0 <= v115: -0.268223 <= 0.001641 0 <= v116: -0.268223 <= 0.001472 0.000177 <= v117: -2.271096 <= 0.002321 0 <= v118: -2.271096 <= 0.001699 -0.003382 <= v119: -0.000008 <= -0.000008 -0.002945 <= v120: -11.239441 <= 0 -0.001377 <= v121: -11.528363 <= 0 -0.001250 <= v122: -3.873247 <= 0 0.000077 <= v123: 2.934028 <= 0.003083 0 <= v124: 2.934028 <= 0.002552 0 <= v125: 14.661636 <= 0.003678 0 <= v126: 14.661636 <= 0.003312 0.000042 <= v127: -1.802925 <= 0.006800 0 <= v128: -1.802925 <= 0.005871 0 <= v129: 11.250457 <= 0.002385 0 <= v130: 11.250457 <= 0.002122 0.000008 <= v131: 0.002320 <= 0.002320 0 <= v132: -10.798308 <= 0.002015 -0.002007 <= v133: -15.310603 <= -0.000087 -0.001592 <= v134: 3.336150 <= 0 0 <= v135: -13.208688 <= 0.004539 0 <= v136: -13.208688 <= 0.004055 0.000004 <= v137: 0.000004 <= 0.002534 0 <= v138: 14.884312 <= 0.002211 -0.003423 <= v139: -4.819391 <= 0 -0.003064 <= v140: 7.298642 <= 0 -0.011636 <= v141: -24.667288 <= 0 0 <= v142: 0 <= 0.000553 -0.011218 <= v143: 9.120121 <= 0 0.000007 <= v144: 0.000007 <= 0.006453 0 <= v145: 8.706559 <= 0.005633 0.000011 <= v146: 0.000011 <= 0.002405 0 <= v147: 5.452150 <= 0.002083 -0.007417 <= v148: -0.000105 <= -0.000105 -0.006293 <= v149: -4.366268 <= 0 0.000015 <= v150: 0.002860 <= 0.002860 0 <= v151: -8.083382 <= 0.002475 -0.004296 <= v152: -12.277851 <= 0 -0.003764 <= v153: 8.536914 <= 0 0 <= v154: -1.525872 <= 0.000283 0 <= v155: -1.525872 <= 0.009001 -0.008718 <= v156: 3.101125 <= 0 0.000272 <= v157: 3.384421 <= 0.007179 0 <= v158: 3.384421 <= 0.005772 -0.011396 <= v159: -5.275025 <= -0.000223 -0.009553 <= v160: 5.121074 <= 0 -0.005891 <= v161: -5.439854 <= -0.000071 -0.005021 <= v162: 3.615476 <= 0 0 <= v163: -3.953251 <= 0.003710 0 <= v164: -3.953251 <= 0.003428 -0.002616 <= v165: -30.472951 <= 0 -0.002310 <= v166: -12.734294 <= 0 -0.003079 <= v167: -0.003079 <= -0.000012 -0.002671 <= v168: 36.036856 <= 0 -0.002525 <= v169: 4.658318 <= 0 -0.002276 <= v170: 23.741247 <= 0 -0.004125 <= v171: -0.004125 <= -0.000030 -0.003554 <= v172: -4.883884 <= 0 -0.004381 <= v173: -27.223216 <= 0 -0.003908 <= v174: 0.373790 <= 0 -0.002665 <= v175: -10.326246 <= 0 -0.002350 <= v176: 20.589187 <= 0 0.000129 <= v177: 3.901199 <= 0.002780 0 <= v178: 3.901199 <= 0.002191 0 <= v179: 4.868897 <= 0.001489 0 <= v180: 4.868897 <= 0.001310 0 <= v181: -2.307442 <= 0.003723 0 <= v182: -2.307442 <= 0.003519 secondOrderMinimization: 0.766253 (1.000000) linearMinimization: -1.532517 (1.000000) ############################################ |
|
From: Anders P. <an...@op...> - 2014-07-28 09:59:58
|
There is now a new solver org.ojalgo.optimisation.convex.ConvexSolver intended to replace and extend the functionality of org.ojalgo.optimisation.quadratic.QuadraticSolver. The new solver currently/still has exactly the same api as the old one - it's easy to switch between them.
If you're using ExpressionsBasedModel (or MarkowitzModel in the org.ojalgo.finance.portfolio package) you should make sure that the method getDefaultSolver() contains this:
//return QuadraticSolver.make(this);
return ConvexSolver.make(this);
The intention is that the new solver should handle more problems/cases, get rid of some odd behavior and scale better.
If you're currently using ojAlgo to solve quadratic optimisation problems please try this new solver and report problems to this mailing list.
Get the latest source code either from
http://sourceforge.net/p/ojalgo/code/
or
https://github.com/optimatika/ojAlgo
/Anders
On 22 maj 2014, at 23:09, Anders Peterson <an...@op...> wrote:
> The algorithm incorporates an element of randomness to break out of cyclic behavior that sometimes occurs. I guess some combination of inequality constraints produce a numerically difficult subproblem, and it appears repeatedly.
>
> I've added your test case to ojAlgo's, but haven't had time to study the problem in detail yet so I don't know what else to say.
>
> You may try to permutate the problem - change the order of the inequality constraints or even introduce som tiny error on some problem parameter.
>
> /Anders
>
>
> On 22 maj 2014, at 15:24, Oddvar Grønning <od...@pr...> wrote:
>
>> Hi all,
>>
>> I’ve been using the QuadraticSolver for a while, and suddenly stumbled over an unexpected failure to solve a problem. The solution state was APPROXIMATE and the solution was not correct. I tested the same system with another QP-solver and got the result I expected. I then condensed the problem as much as I could and made a test out of it (see below). To my surprise the test sometimes fails and sometimes passes(!). I’ve been running this test (alone) in TestNG. I’m using Ojalgo v35 and Java 1.7.55. The Q matrix is positive definite.
>>
>> Does anyone understand what is going on?
>>
>> Br
>> Oddvar
>>
>> @Test(singleThreaded=true)
>> public void Ojalgo_QuadraticSolver_Test() {
>>
>>
>> double[][] q = new double[][] {{49.0, 31.0, 17.0, 6.0},
>> {31.0, 25.0, 13.0, 5.0},
>> {17.0, 13.0, 11.0, 3.5},
>> {6.0, 5.0, 3.5, 4..0}};
>>
>> JamaMatrix JamaQ = JamaMatrix.FACTORY.rows(q);
>>
>> double[] c = new double[] {195.0, 59.0, -1.8, -11.7};
>>
>> JamaMatrix JamaC = JamaMatrix.FACTORY.columns(c);
>>
>> double[][] ai = new double[][] {{1.0, 0.0, 0.0, 0.0},
>> {-1.0, 0.0, 0..0, 0.0},
>> {1.0, 1.0, 0.0, 0.0},
>> {-1.0, -1.0, 0..0, 0.0},
>> {1.0, 1.0, 1.0, 0.0},
>> {-1.0, -1.0, -1.0, 0.0},
>> {0.1, 0.0, 0.0, 0.0},
>> {0.01, 0.0, 0..0, 0.0},
>> {0.18, 0.1, 0..0, 0.0},
>> {-0.01, 0.0, 0..0, 0.0},
>> {-0.183, -0.1, 0.0, 0..0},
>> {0.0283, 0.01, 0.0, 0..0},
>> {0.25, 0.183, 0.1, 0.0}};
>>
>> JamaMatrix JamaAI = JamaMatrix.FACTORY.rows(ai);
>>
>> double[] bi = new double[] {0.13, 0.87, 0.18, 0.82, 0.23, 0..77, -0.04, 99.67, -0.06, 100.33, 1.06, 99.62, -0.08};
>>
>> JamaMatrix JamaBI = JamaMatrix.FACTORY.columns(bi);
>>
>> org.ojalgo.optimisation.Optimisation.Result result = null;
>>
>> try {
>> QuadraticSolver.Builder qsBuilder = new QuadraticSolver.Builder(JamaQ, JamaC);
>> qsBuilder.inequalities(JamaAI, JamaBI);
>>
>> QuadraticSolver qSolver = qsBuilder.build();
>> result = qSolver.solve();
>> }
>> catch(Exception e) {
>> e.printStackTrace();
>> assert false;
>> }
>>
>> State state = result.getState();
>>
>> assert state == State.OPTIMAL;
>>
>> int numElm = (int) result.count();
>> double[] solution = new double[numElm];
>>
>> for(int i = 0; i < numElm; i++) {
>> solution[i] = result.doubleValue(i);
>> }
>>
>> double[] expectedSolution = new double[]{ -0.4, 0.12, -0.0196, -2.45785};
>>
>> for(int i = 0; i < numElm; i++) {
>> assert Math.abs(solution[i] - expectedSolution[i]) < 1e-4;
>> }
>>
>> }
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs_______________________________________________
>> ojAlgo-user mailing list
>> ojA...@li...
>> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>
>
|
|
From: Anders P. <an...@op...> - 2014-06-17 11:45:29
|
There is also org.ojalgo.matrix.MatrixUtils.setAllOperationThresholds(int) Setting this to something very large will effectively turn off multithreading for the linear algebra part of ojAlgo, but does not affect other parts (like the IntegerSolver). /Anders On 17 jun 2014, at 11:47, Anders Peterson <an...@op...> wrote: > One thing you can do is to set > > org.ojalgo.OjAlgoUtils.ENVIRONMENT > > to a "fake" value that suits your needs. You have to this before org.ojalgo.concurrent.DaemonPoolExecutor.INSTANCE is initialized. > > > Or, you can modify ojAlgo so that > > org.ojalgo.concurrent.DaemonPoolExecutor.INSTANCE > > is initialized with something different. Use something like ManagedExecutorService ... (don't know exactly) > > > Is that enough? What are your requirements? > > > /Anders > > > On 17 jun 2014, at 11:03, Christian Wirth <cw...@ke...> wrote: > >> I want to limit the amount of threads/cores ojAlgo can use. How to do that ? >> This is required because of HPC usage in an shared environment. >> >> best, Christian >> >> >> >> ------------------------------------------------------------------------------ >> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions >> Find What Matters Most in Your Big Data with HPCC Systems >> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. >> Leverages Graph Analysis for Fast Processing & Easy Data Exploration >> http://p.sf.net/sfu/hpccsystems >> _______________________________________________ >> ojAlgo-user mailing list >> ojA...@li... >> https://lists.sourceforge.net/lists/listinfo/ojalgo-user >> >> > |
|
From: Anders P. <an...@op...> - 2014-06-17 09:47:47
|
One thing you can do is to set org.ojalgo.OjAlgoUtils.ENVIRONMENT to a "fake" value that suits your needs. You have to this before org.ojalgo.concurrent.DaemonPoolExecutor.INSTANCE is initialized. Or, you can modify ojAlgo so that org.ojalgo.concurrent.DaemonPoolExecutor.INSTANCE is initialized with something different. Use something like ManagedExecutorService ... (don't know exactly) Is that enough? What are your requirements? /Anders On 17 jun 2014, at 11:03, Christian Wirth <cw...@ke...> wrote: > I want to limit the amount of threads/cores ojAlgo can use. How to do that ? > This is required because of HPC usage in an shared environment. > > best, Christian > > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > ojAlgo-user mailing list > ojA...@li... > https://lists.sourceforge.net/lists/listinfo/ojalgo-user > > |
|
From: Christian W. <cw...@ke...> - 2014-06-17 09:16:27
|
I want to limit the amount of threads/cores ojAlgo can use. How to do that ? This is required because of HPC usage in an shared environment. best, Christian |
|
From: Anders P. <an...@op...> - 2014-05-22 21:27:22
|
The algorithm incorporates an element of randomness to break out of cyclic behavior that sometimes occurs. I guess some combination of inequality constraints produce a numerically difficult subproblem, and it appears repeatedly.
I've added your test case to ojAlgo's, but haven't had time to study the problem in detail yet so I don't know what else to say.
You may try to permutate the problem - change the order of the inequality constraints or even introduce som tiny error on some problem parameter.
/Anders
On 22 maj 2014, at 15:24, Oddvar Grønning <od...@pr...> wrote:
> Hi all,
>
> I’ve been using the QuadraticSolver for a while, and suddenly stumbled over an unexpected failure to solve a problem. The solution state was APPROXIMATE and the solution was not correct. I tested the same system with another QP-solver and got the result I expected. I then condensed the problem as much as I could and made a test out of it (see below). To my surprise the test sometimes fails and sometimes passes(!). I’ve been running this test (alone) in TestNG. I’m using Ojalgo v35 and Java 1.7.55. The Q matrix is positive definite.
>
> Does anyone understand what is going on?
>
> Br
> Oddvar
>
> @Test(singleThreaded=true)
> public void Ojalgo_QuadraticSolver_Test() {
>
>
> double[][] q = new double[][] {{49.0, 31.0, 17.0, 6.0},
> {31.0, 25.0, 13.0, 5.0},
> {17.0, 13.0, 11.0, 3.5},
> {6.0, 5.0, 3.5, 4.0}};
>
> JamaMatrix JamaQ = JamaMatrix.FACTORY.rows(q);
>
> double[] c = new double[] {195.0, 59.0, -1.8, -11.7};
>
> JamaMatrix JamaC = JamaMatrix.FACTORY.columns(c);
>
> double[][] ai = new double[][] {{1.0, 0.0, 0.0, 0.0},
> {-1.0, 0.0, 0.0, 0.0},
> {1.0, 1.0, 0.0, 0.0},
> {-1.0, -1.0, 0.0, 0.0},
> {1.0, 1.0, 1.0, 0.0},
> {-1.0, -1.0, -1.0, 0.0},
> {0.1, 0.0, 0.0, 0.0},
> {0.01, 0.0, 0.0, 0.0},
> {0.18, 0.1, 0.0, 0.0},
> {-0.01, 0.0, 0.0, 0.0},
> {-0.183, -0.1, 0.0, 0..0},
> {0.0283, 0.01, 0.0, 0..0},
> {0.25, 0.183, 0.1, 0.0}};
>
> JamaMatrix JamaAI = JamaMatrix.FACTORY.rows(ai);
>
> double[] bi = new double[] {0.13, 0.87, 0.18, 0.82, 0.23, 0.77, -0.04, 99.67, -0.06, 100.33, 1.06, 99.62, -0.08};
>
> JamaMatrix JamaBI = JamaMatrix.FACTORY.columns(bi);
>
> org.ojalgo.optimisation.Optimisation.Result result = null;
>
> try {
> QuadraticSolver.Builder qsBuilder = new QuadraticSolver.Builder(JamaQ, JamaC);
> qsBuilder.inequalities(JamaAI, JamaBI);
>
> QuadraticSolver qSolver = qsBuilder.build();
> result = qSolver.solve();
> }
> catch(Exception e) {
> e.printStackTrace();
> assert false;
> }
>
> State state = result.getState();
>
> assert state == State.OPTIMAL;
>
> int numElm = (int) result.count();
> double[] solution = new double[numElm];
>
> for(int i = 0; i < numElm; i++) {
> solution[i] = result.doubleValue(i);
> }
>
> double[] expectedSolution = new double[]{ -0.4, 0.12, -0.0196, -2.45785};
>
> for(int i = 0; i < numElm; i++) {
> assert Math.abs(solution[i] - expectedSolution[i]) < 1e-4;
> }
>
> }
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs_______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
|
13 messages has been excluded from this view by a project administrator.
