..ok, I think, I found the culprit.
Was a bit tricky (and mean):
- in JBTPreferences we find the line:
DivideAndConquerCoverage("Divide & Conquer coverage", "10"),
- in AdvancedOptionsOptimizationDialog we find
int min = 25;
int max = 1000;
divideAndConquerCoverageSlider = new JSlider(min, max);
however, value assignment only happens, if the OK button is pressed.
This means (I gather): if you do divide and conquer without EVER
visiting the advanced options dialog
the value is 10 (default). If you ever visit it and click ok, it
becomes 25 (the minimum the slider
can hold).
What I saw, was: slider is minimum, but it seems in one case I used
ok, not cancel to leave the dialog...
Later on, as I checked the other installations again and left the
dialog with ok. -> value got set to 25.
As the preferences are stored: if you ever clicked ok since
installation (even 10 weeks later), it will always
use 25.
I think, this is a minor glitch, though it led me to quite some
wondering.
However, I did not find any influence of the number of processors or
similar on the density.
I am also wondering: what is the true minimal value that should be
set?
Because, if I see sparsest, I would guess, it is the absoluate minimum
that makes sense (1?)...
(The results with 640 (value=10) runs were very similar to 2400
(value=25) runs, but required less than half the time..
So, if you harmonize the two: use the lower one (or even one smaller
than ten. I think, I will do this for my local
installation for sure..
Cheers
Klaus
On 14 Aug., 16:58, Klaus <[email protected]> wrote:
> Hm,
>
> now it starts to doubt my thinking..
> I had already cross-checked that: everything is set to the "sparsest".
> Upon trying to reproduce the initial behavior, I get as a result
> everywhere the 2401 strategies
> (even without even touching anything). I am wondering whether it could
> be that there is a difference between
> initial run (first run of JBookTrader at all).
> I just fired up Eclipse again under MacOS and Windows and got the same
> result I had on my old PC
> all along (no difference due to differences in cores).
>
> .. let's file this under mysteries as it will be hard to turn this
> into a reproducable error (fresh install of Eclipse, JBookTrader,
> etc.)
>
> Anyway. If the sources of the MacOS installation guide appear again, I
> will try to update this.
>
> Klaus
>
> On Aug 14, 4:39 pm, Eugene Kononov <[email protected]> wrote:
>
>
>
> > > ok, interesting feature, I did not think about.
> > > However, it gives 4 times as many strategies to the smaller system.
> > > (Besides being older the PC also has only two cores, while the
> > > MacBook
> > > has 2 full cores + two hyperthreading (i.e., appear as 4 cores))
> > > Shouldn't it then be the other way round?
>
> > Yes, it should be the other way around. In all likelihood, you have the
> > "Density Coverage" parameter set differently. On the "Optimization Dialog",
> > click "Advanced", and make sure that the "Coverage Density" is set the same
> > on both systems.
>
> > For the purposes of determining which system is faster to run optimizations,
> > use the "brute force" optimization option. If you want to compare your
> > results with other people, see this
> > benchmark:http://groups.google.com/group/jbooktrader/browse_thread/thread/cb5a2...
--
You received this message because you are subscribed to the Google Groups
"JBookTrader" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jbooktrader?hl=en.
