GNOME Bugzilla – Bug 620368
Solver issues
Last modified: 2015-12-23 01:11:30 UTC
1. Solvers (at least nlsolve) ignore the time limit. 2. When the solver dialog comes up, the range selector doesn't work. Change to a different field and back. Then it does work. 3. nlsolve's step size is reset in every iteration. Even though we change coordinates, we must be able to do better than that. 4. nlsolve needs to have the actual algorithm packed into an object of some kind. GnmSolverIterative maybe. 5. nlsolve mostly ignores constraints. 6. We should be able to produce some kind of message as to why the solver stopped. (Local minimum, iteration limit, ...) 7. We might want to rate-limit updates to the solver result dialog. 8. Do we want ENABLE_SOLVER? If so, use it.
8 fixed. For now.
2 fixed.
Andreas: your fix to 2 broke something badly. gnumeric .../samples/solver/blend.mps Tools->Solver Target is now "$A$1B5" instead of the correct "B5".
Then it worked just by accident. My fix is http://git.gnome.org/browse/gnumeric/commit/?id=bcb34f4da3efd454479f35a3b1cbb747e381f3d7 which is what we do for every other dialog. I suspect that reading .../samples/solver/blend.mps just appends to the text entry rather than loading the range correctly.
Here's what it does (and did): target_cell = gnm_solver_param_get_target_cell (param); if (target_cell) gnm_expr_entry_load_from_text (state->target_entry, cell_name (target_cell)); When the solver target has a value -- as it will have after loading an mps file or after you set it manually the first time -- then loading anything else into it is wrong. Removing + first = selection_first_range + (wb_control_cur_sheet_view + (WORKBOOK_CONTROL (state->wbcg)), NULL, NULL); + if (first != NULL) { + gnm_expr_entry_load_from_range (state->target_entry, + state->sheet, first); + } seems to fix the issue. We just need the wbcg_set_entry.
Bt if there is no target cell we should set the target entry from the selection to be consistent with every other of our tool like dialogs.
We could, but it actually only makes sense if a single cell is selected.
so in that case we should be preloading it with the current edit position not the selection.
*** Bug 629880 has been marked as a duplicate of this bug. ***
Note that #5 is also debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631411
Hello, I have been using Gnumeric for a few days for my quants class but I find that the solver will not permit me to modify left-hand or right-hand values, example: x5 is var for production quantity; x2 is var for one of the items produced. Product x2 must account for half of the production quantity. I would say "x2 = 0.5 * x5" in Excel solver and this would be accepted (have to make right side look like cell calc, eg =0.5*$b$4 or similar) no problem. Neither Gnumeric nor Open/Libre can do this at present. To really gild this lily it would be nice to have the reports piece as well! I am very new to Gnumeric and new to Linux in general so if this is a lot, just tell me and I'll shut it. Thanks! Oh also if this should be submitted as new I can do that if you tell me how. B-) johnb
johnb: new bug, please. Preferably with an example containing everything except what you're unable to enter.
johnb, to submit this as new go to https://bugzilla.gnome.org/enter_bug.cgi and click on Applications, then Gnumeric. Did you try to use another cell in the worksheet with the formula =0.5*$b$4 so that you can just use cell addresses in the constraints?
Item 3 fixed. That leaves, by my count, items 3-7.
Item 6 partially fixed. We now have the framework and we display a reason when we stop due to timeout.
*** Bug 679027 has been marked as a duplicate of this bug. ***
#5 fixed. nlsolve now takes constraints into account, although constraining an optimizer is not necessarily a good idea.
We have some kind of a solver report again.
What do you mean by 'some kind of a solver report'? What is reported exactly? (I am still interested by the values of the second derivatives at the minimum)
Created attachment 219243 [details] Sample report This is what you get. While changes are certainly possible, I don't think getting second derivatives are likely. We might one day get first derivatives (which makes sense when there are constraints).
Created attachment 264996 [details] nlsolve does not take constraints into account This is simple nlsolve test. The function in the C2 is the volume of the cylinder. There is constraint that A4 <= B4. When I try to solve it, gnumeric's nlsolve does not take that constraint into account.
My Gnumeric version is 1.12.8
The constraint situation has been improved.
7 was done a while ago. I think we're done here. If there is anything else, fresh bugs are needed.