Tutorial: add scaling of fitter.fitWithModelPSF

[Mikea1985]

Since you said nWalkers=nBurn=nStep=40 was overkill, and since that took waaay too long on my laptop on which I've done most of this testing, I figured out the relationship between the values of nWalkers, nBurn, nStep and how long the fitter.fitWithModelPSF step takes:

time \propto nWalkers*(2+nBurn+nStep)

It might be worth adding this to the tutorial; people might be interested in knowing for various reasons.

[fraserw]

Yep. That's the correct relationship. I take it you haven't familiarised yourself with emcee?

While it's only one line, your breaching something idolise to avoid which is teaching people how to use other tools. For example, I think it reasonable that people already know how to use numpy, scipy, matplotlib. Bit what about sextractor? That's a pretty standard astronomy tool. And yet some people in our collaboration want me to put up a sextractor tutorial alongside the trippy stuff. Which I think is silly because all I've done is write wrapper functions for the steps you'd normally take to use sextractor :copy par files, run, open... And they know that if they were truly familiar with sextractor.

Same goes with emcee which is now the standard mcmc machine for python. Should I be responsible for teaching noobs how to use these things? I don't think so. But at the same time, it'd be nice wouldn't it? But I don't have the time or the patience to deal with this beyond my few buddies, if you know what I mean.

So what do you think? I'm genuinely curious.

Wes On 16 Jan 2016 8:47 am, "Mike Alexandersen" notifications@github.com wrote:

Since you said nWalkers=nBurn=nStep=40 was overkill, and since that took waaay too long on my laptop on which I've done most of this testing, I figured out the relationship between the values of nWalkers, nBurn, nStep and how long the fitterfitWithModelPSF step takes:

time \propto nWalkers*(2+nBurn+nStep)

It might be worth adding this to the tutorial; people might be interested in knowing for various reasons

— Reply to this email directly or view it on GitHub https://github.com/fraserw/trippy/issues/8.

[Mikea1985]

Note: This was just a suggestion based on the fact that I did not know. If this relation is common knowledge, then it would probably be superfluous to add it.

I somewhat agree with you. It's not your job to teach people how to use all other tools that you make use of; it's unfeasible to do so. However, when the well-known tools are hidden inside a wrapper, you should at least point out that this is what it is (as someone might not necessarily recognise it) and explain the usage of the wrapper in brief summary, then possibly have a link to information about the external tool. Maybe with a sentence like "parameters foo and bar are package parameters; learn more about package at ".

I for example did not realise that fitWithModelPSF was a wrapper of emcee, having never used it (in fact, I don't recall having ever used MCMC outside a computing class). I did recognise that scamp.runSex was a SExtractor wrapper, but probably only because I've used SExtractor before. Someone who hasn't used SExtractor before might not realise that a lot of the parameters defined in the tutorial are SExtractor parameters, and thus not know to look in the SExtractor documentation (rather than the trippy documentation) for details.

I think if you're hoping for your package to get wide usage, you need to not assume that only experienced astronomers will be using it; in fact, I suspect it most likely that it'll be the grunts (students and postdocs) that'll end up as your main demographic. Students don't know anything; I myself only just started knowing stuff recently. :-P

So in conclusion: Don't make tutorials for SExtractor and emcee, but make the tutorial of your software as user friendly as possible.