In the branch-and-cut framework of SCIP, is it possible to solve a particular node of the tree with the same parameters (like presolving, restarts, etc.) as root node?
I want to get better bounds for particular nodes, and I think treating the problem at a node as root node can help. It will also lead to a different tree than the one I had gotten otherwise.
If yes, how can I do it?
This is not possible out-of-the-box. You could implement a relaxator plugin that copies the MIP at the current node into a new SCIP instance (use SCIPcopy() with global = FALSE), solves it, and reports the result back to your main SCIP.
Related
The problem:
I am currently working on a file tree, more specifically on a "Selected Folder" functionality. I'm doing this to have a specific target for creating new files and folders, other that the root folder. (I'm using Vue within Electron, but this is not really relevant to the question)
Selection happens on click. Due to the nature of file trees, I use recursive components (and this limits my 'easy' access to some components).
While achieving this on the back-end is trivial, my exact problem is that while marking the selected folder with, say a different background color or bold text (by binding an id or class that has some corresponding style on my stylesheet), I need to unmark the previously selected directory.
So, how do I gain access to an indirect (due to the recursive components) child component?
What I've tried, and looked into:
Now, I know that within JS you can't store pointers or references in variables (otherwise this would've been easily achieved by storing a reference to the previous DOM element).
I have some solutions up my sleeve, but they're really tedious and not very straightforward. Previously, I had to re-render (by re-reading) specific sub-directories, based on file system updates. I achieved this partial re-rendering by propagating child function calls from the root directory until I reached the directory that needed to be re-rendered. I had to do this since the FS watcher was created on the root component.
Similarly, I could do this with the un-marking task. When I select the new folder, I start by propagating child function calls until I reach the previously selected folder, and un-mark it by un-binding the style id. Having done this previously, I know it's not a pleasant method.
Since I can get the click event target, I wondered if I could somehow store any kind of reference to the previously 'selected' DOM element and just use that reference later when I need to 'deselect' it.
Here's what my folder component looks like. I tried giving self-explanatory names to the properties, but if there's any confusion, I'll answer any question.
<folder-comp
#openFile="openFile"
v-for="folder of folders"
:key="`folder-${folder.shortFolderName}`"
:folder-name="folder.shortFolderName"
:ref="folder.shortFolderName"
:full-folder-path="folder.fullFolderPath"
:local-directory="recursiveScanDir"
:indentation-level="indentationLevel + 1">
</folder-comp>
The propagation method I used was necessary previously since all I had was an event File System path, unrelated to my Vue structures, and so I needed to somehow translate traversing that path. Here, though, everything happens only within the Vue environment, so I thought there would be some sort of way to deal with this easily.
EDIT: Well, as it happened with me in the past, just writing about the problem itself on stackoverflow helped me reach a solution.
I have a Global Event Bus set up on my Vue project, so I can bind an event listener on the currently selected folder. Once another folder is clicked (thus selected), it emits an event in the Global Event Bus, triggering the previously selected folder. This is followed by the un-marking and the unbinding of the event listener.
This is only one solution though, so the question still stands. Is this a good solution? Are there any drawbacks to this approach? Is there a better solution?
Instead of a global event bus, you can also use state management such as Vuex. When you change folders, you simply dispatch an action. This uses an command pattern, as opposed the the mentioned listener pattern. You have the choice to make this action asynchronous or synchronous as well.
There are several ways to register your listeners/watchers, from within components, or outside of them.
Using this architecture will allow you to easily add undo/redo capabilities, and also be able to navigate back and forth through your history of mutations.
You also gain the integrated debug features provided by the Vue tools in your browser.
In fact, Vuex was built exactly for situations like this, when components need to communicate with each other but the parent/child prop/emit/inject mechanisms start to become tedious and and fall apart.
There is a high probability that once you starting using Vuex, you will never look back.
I would like to partially solve a MIP, clone the problem and have that copy of the problem continue optimization but with a different strategy (node selection rule, variable selection rule, etc), and keeping the current branch-and-bound tree. I know that this can't be done with either CPLEX or Gurobi, since they would start optimization from scratch in the copy.
Is there any way of doing this with SCIP?
I would really appreciate any help.
Best,
Rodolfo
If you don't insist on having a copy/clone, you always have the possibility to code your stopping criterion in terms of an event handler. I am sure you know our How to on adding event handlers.
There is also an event handler in the scip source code, the so-called soft time limit event handler src/scip/event_softtimelimit.c. There you can find sample code that changes the time limit after the first solution has been found. Parameters can be fed one by one by using the SCIPchg{Real,Bool,Int,Longint,Char,String}Param() methods in the code, or passed as a settings file, which might be easier if you want to change lots of parameters without adapting the code each time.
It is good practice to use settings files saved via the set diffsave command, which saves only the nondefault-settings. Otherwise, using a complete settings file, you might run into troubles because a time limit or memory limit gets changed without control.
A copy that includes data structures such as the tree used during the branch-and-bound solving process is currently not possible. The copy-mechanism of SCIP only allows to copy the problem as a whole and adjust the formulation by changing variable domains and/or objective coefficients.
Previous research:
As webpack's wiki says, it is possible to use the analyse tool to optimize build performance:
from: https://github.com/webpack/docs/wiki/build-performance#hints-from-build-stats
Hints from build stats
There is an analyse tool which visualise your build and also provides
some hint how build size and build performance can be optimized.
You can generate the required JSON file by running webpack --profile
--json > stats.json
I generate the stats file (available here)
uploaded it to webpack's analize tool and under Hints tab
I told to use the prefetchPlugin:
from: http://webpack.github.io/analyse/#hints
Long module build chains
Use prefetching to increase build performance.
Prefetch a module from the middle of the chain.
I digged the web inside out to find the only documentation available on prefechPlugin is this:
from: https://webpack.js.org/plugins/prefetch-plugin/
PrefetchPlugin
new webpack.PrefetchPlugin([context], request)
A request for a normal module, which is resolved and built even before
a require to it occurs. This can boost performance. Try to profile the
build first to determine clever prefetching points.
My questions:
How to properly use prefetchPlugin?
What is the right workflow to use it with the Analyse tool?
How do I know if the prefetchPlugin works? how can I measure it?
What it means to Prefetch a module from the middle of the chain?
I'll really appreciate some examples
Please help me make this question a valuable resource for the next developer who wants to use the prefechPlugin and the Analyse tools.
Thank you.
Yeah, The pre-fetch plugin documentation is pretty much non-existent. After figuring it out for myself, its pretty simple to use, and there's not much flexibility to it. Basically, it takes two arguments, the context (optional) and the module path (relative to context). The context in your case would be /absolute/path/to/your/project/node_modules/react-transform-har/ assuming that the tilde in your screenshot is referring to node_modules as per webpack's node_module resolution.
The actual prefetch module should be ideally no more than three module dependencies deep. So in your case isFunction.js is the module with the long build chain and ideally it should be pre-fetched at getNative.js
However, I suspect there's something funky in your config, because your build chain dependencies are referring to module dependencies, which should be automatically optimized by webpack. I'm not sure how you got that, but in our case, we don't see any warnings about long build chains in node_modules. Most of our long build chains are due to deeply nested react components which require scss. ie:
Regardless, you'll want to add a new plugin for each of the warnings, like so:
plugins: [
new webpack.PrefetchPlugin('/web/', 'app/modules/HeaderNav.jsx'),
new webpack.PrefetchPlugin('/web/', 'app/pages/FrontPage.jsx')
];
The second argument must be a string to the relative location of the module. Hope this makes sense.
The middle of your chain there is probably react-transform-hmr/index.js as it starts about half way through. You could try PrefetchPlugin('react-transform-hmr/index') and rerun your profile to see if it helps speed up your total time to build.
My case is the following:
a. I've got some GWT library: extGWT or SmartGWT, for instance;
b. I've got a tree with lazy loading;
c. On expansion I load node children;
d. I've got millions of children nodes so I don't want them to load at one go on node expansion.
I would like to know if it's possible to use lazy loading not only on node expansion but also on tree scroll, for instance.
I'm considering the use of extGWT / smartGWT for my project (never worked with them actually), so don't know if my question is kind of obvious. But I wasn't able to find the answer myself yet.
Thank you in advance
There is a topic http://forums.smartclient.com/showthread.php?t=16946 on the smartclient forum about pagination of smartGWT treegrids that isn't old. As I understand, pagination is not implemented for treegrids as "it's just not a very good UI".
I'm not an expert in smartGWT treegrids but I think you can use "lazy loading" on node expansion with the datasource, but not on tree scroll.
As for extGWT, I really don't know. Hope it can help you a little bit.
I installed Darcs a few days ago and have a doubt.
I am the only programmer and I usually work on two or three instances of the application, making new feautures. The problems cames because this instances modify the same source code file, so when I finished them and send to main repository they make a conflict.
Is there any way to deal with this? Can I write the same file in multiple instances without making conflict when pushing to main repository?
thanks
First of all when changes occurs at different places of the file there is generally no conflicts when merging. When two patches can be merged without conflicts one says that they commute. In your case it happens that you've modified the same part of the file in two different branches. In this case darcs don't allow you to "push" the second patch that makes the conflict.
There is two ways to resolve such a confilct, but you have to start to locally merge the both patches to get the conflict in your working repo. To do this just pull the patches from the main repository. Then you have to edit the offended file and resolve the conflict.
The first way is simple and the prefered solution, you have to "amend-record" the patch that is not yet on the main repository (look at the usage of the "darcs amend-record" command).
The other solution is to record a resolution patch, by calling "darcs record" and then pushing both the conflicting patch and the resolution patch. This solution tends to complicate the history and can make some later operations longer. However when the branch has been heavily distributed this solution becomes needed.