Comments (12)
I need to put an update out, since there are quite a few bugs fixed since the last release (thanks to you, @lukashergt, in a bug part!).
I am leaving 5d
, but making sure reducing it to d
is suggested for exploratory run, and making d=d_block
, which I think makes sense.
Thanks all!
from cobaya.
That is a pretty important bug to be fixed (I am using an old version of cobaya where all grade_frac < 1) for my relief.
from cobaya.
Hi both,
I take note and will try to fix it this week.
Thanks for the report!
from cobaya.
Hi both,
Having given it a little more thought, I agree, of course, that num_repeats
should not be ignored (I hadn't notice it was in this case, sorry!). I am making the number of steps in the slow block are at least its dimension times num_repeats
in 2.0 (released later today, or tomorrow) and in the archived 1.X version.
Once that has been taken into account, so one has direct control on the number of repeats, I'd say there is no need to remove the division by the highest common denominator (otherwise, #repeats may be kept too high just because of small changes in speeds). Do you agree? (I'll keep this issue open until at least one of you has answered, but we can of course keep discussing this here).
from cobaya.
Yes, if num_repeats
is no longer ignored but applied to all speeds then that should be fine. However, the default value num_repeats: 5d
might be problematic.
If we have 6 slow parameters and say 21 parameters overall, then we wouldn't want 5 * 21
repeats for the slow parameters, but 5 * 6
or maybe even just 2 * 6
repeats. We definitely need > 6
but since they are slow parameters we don't want the number to get unreasonably large either.
Obviously num_repeats
can be set by hand, but maybe it would make sense to have this automatically adapt to blocking
input. Or does it already work like that?
from cobaya.
It it (at least), dimension of slow params times num_repeats
from cobaya.
If I don't specify num_repeats
then it is automatically set to 5*nDims
which in the case of Planck TTlowTEB amounts to 5*21=105
. If I am now to set speed blocking
to say [1, 10, 20]
this produces:
[polychord] grade_dims: [6, 1, 14]
[polychord] grade_frac: [630, 1050, 29400]
[polychord] num_repeats: 105
where grade_frac
is now much too high. It was produced by
grade_frac = grade_dims * num_repeats = grade_dims * 5 * nDims
If blocking
is specified it would make more sense for num_repeats
to default to 5
instead of 5*nDims
. It might be worth considering changing this default behaviour in the long run. Currently, if one is to set blocking
manually, then num_repeats
needs to be adjusted manually as well.
from cobaya.
I've been thinking a little bit about this, and propose to do the following:
-
Change default
num_repeats
from5d
(PolyChord default, recommended for high-precision evidences) tod
(enough for MC sampling). -
When blocking is manually specified, make it so that the
d
for dimension innum_repeats
means the dimension of each particular block, to avoid inflating the number of slice steps if there are a lot of fast directions.
What do you think?
@williamjameshandley do you have an opinion about the 2nd point?
from cobaya.
Change default num_repeats from 5d (PolyChord default, recommended for high-precision evidences) to d (enough for MC sampling).
This would make the runs 5x faster, which is a good thing, although in my experience that is a little low to ensure proper decorrelation.
When blocking is manually specified, make it so that the d for dimension in num_repeats means the dimension of each particular block, to avoid inflating the number of slice steps if there are a lot of fast directions.
In the fast directions there shouldn't be any serious slow-down even for the 'inflated case'. Perhaps a good compromise would be the sum of the dimensions up to that block, so that if you have say 6 slow, 4 semi-slow and 20 fast, you would have d=[6,10,30]
from cobaya.
This would make the runs 5x faster, which is a good thing, although in my experience that is a little low to ensure proper decorrelation.
Would 2d
be a safer option?
In the fast directions there shouldn't be any serious slow-down even for the 'inflated case'. Perhaps a good compromise would be the sum of the dimensions up to that block, so that if you have say 6 slow, 4 semi-slow and 20 fast, you would have d=[6,10,30]
I don't find the cumulative dimensions very intuitive. This is for the situation where someone specifies blocking
which defines the oversampling, i.e. the desired oversampling should be taken care of by blocking
and does not need to enter into d
.
The problem that I was facing previously was that d
used to be 6+4+20
(using numbers from example mentioned above) making num_repeats = 5d = 150
which then got multiplied with each block in blocking
causing extremely high grade_frac
(i.e. 150 slow repeats...).
I think there are 2 options that would make sense here:
-
As @JesusTorrado suggests: Have
d
equal tograde_dims: [6, 4, 20]
(when blocking is specified!) which is then used fornum_repeats: 2d
. This multiplied byblocking: [1, 10, 20]
will givegrade_frac: [12, 80, 800]
.
(Note: Need to be careful that this doesn't interfere with thed
in25d
fornlive
...) -
Keep
d
as is for use withnlive: 25d
. Havenum_repeat: 2
not2d
(when blocking is specified!) and calculategrade_frac: [12, 80, 800]
fromnum_repeat * grade_dims * blocking
(withgrade_dims: [6, 4, 20]
andblocking: [1, 10, 20]
).
Not sure which one fits better or is easier to implement.
from cobaya.
There are pros and cons for either option regarding change of defaults on the one hand and consistency of the use of d
in the yaml file on the other hand...
from cobaya.
Sorry for taking so long to come back to this.
@williamjameshandley do you think 2d
is enough for proper decorrelation? 3d
maybe?
Defining d
cumulatively has the problem, as @lukashergt points out, that the fast directions are already oversampled according to their speed, it would be too much oversampling, probably. So I'd keep the d=block_dimension
.
In any case, @williamjameshandley, I guess it's clear that this interpretation of num_repeats
is applied by Cobaya, while for now PolyChord
's behaviour is ignoring for integer grade_frac
, right? Or are you thinking of doing something with it inside PolyChord
for integer grade_frac
?
from cobaya.
Related Issues (20)
- Backward Compatibility with python 3.9 HOT 4
- "The sum of logpriors in the sample is not consistent." when resuming chains HOT 3
- Something went wrong when looking for a covmat HOT 1
- Script invocation is broken on Python 3.9 HOT 4
- Python invocation not doing anything HOT 4
- FutureWarning
- Interpolation error creating a delta chi2 = 20 on DESI likelihood HOT 7
- Installing DESI data: could not be found error HOT 4
- cobaya-install cannot name '__obsolete__' from 'cobaya' (unknown location) HOT 4
- cobaya-install planck_2018_highl_plik.TTTEEE fails HOT 2
- bao.generic likelihood not working for the distances of type Dv_over_rs HOT 6
- Error with the .yaml file generated from cosmo generator HOT 3
- *ERROR* Requested fast/slow separation, but all parameters have the same speed HOT 3
- NPIPE likelihood HOT 2
- Cobaya 3.5.1 and ACT HOT 2
- Sampling over HMCode params HOT 2
- module 'clik' has no attribute 'lkl' HOT 5
- pytest-forked HOT 2
- numpy 2 in tests HOT 1
- Github actions
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cobaya.