InverseCDF

[mroughan]

Hi,

after talking to Jono about testing, I thought an inverse CDF function would be useful. And inverse CDFs are useful for simulating from a distribution. It makes it very easy to generate random numbers just by taking d = CDF^{-1} (u), where u ~ U(0,1) Though this probably isn't as fast as our direct simulation code, it may appeal to some users more or give us alternative testing strategies.

Its, in there now, with function prototypes very similar to those for the CDF. Its just based on a simple binary search, so I'm sure it could be made faster, but my simple Matlab testing seems to show it working fine.

We need an R wrapper for it now. Then Jono can use it in testing.

[mroughan]

BTW, I deliberately implemented it in terms of our existing pointers to functions, so it doesn't require new code for each problem, it just requires the CDF to have been implemented for that problem. When the CDF hasn't been implemented, I am returning -1 as usual, but we can probably do better than that based on the PDF.

[lamestllama]

"BTW, I deliberately implemented it in terms of our existing pointers to functions" well done code reuse is good.

I would have been interested to see what the alternative would have been.

I have implemented this in R. I didnt like the way you swapped the order of input and output arguments in LinePickingInverseCDF function so I swapped it back input first output second.

[mroughan]

On 17/09/12 16:26, Eric Parsonage wrote:

"BTW, I deliberately implemented it in terms of our existing pointers to functions" well done code reuse is good.

I would have been interested to see what the alternative would have been.

Alternatives include:

-- working out the inverses, which isn't too hard for some, but 

isn't too easy for others.

-- writing problem dependent numerical code, with some potential 

then for speeding it up if we know more about the problem.

I have implemented this in R. I didnt like the way you swapped the order of input and output arguments in LinePickingInverseCDF function so I swapped it back input first output second.

Was just trying to minimize the amount of chopping an changing. It probably does make sense to change the order, but it didn't seem to matter too much as long as the meaning was clear.

[lamestllama]

I meant the alternatives to code reuse.

On 17/09/2012, at 5:22 PM, Matthew Roughan wrote:

On 17/09/12 16:26, Eric Parsonage wrote:

"BTW, I deliberately implemented it in terms of our existing pointers to functions" well done code reuse is good.

I would have been interested to see what the alternative would have been.

Alternatives include:

-- working out the inverses, which isn't too hard for some, but isn't too easy for others.

-- writing problem dependent numerical code, with some potential then for speeding it up if we know more about the problem.

I have implemented this in R. I didnt like the way you swapped the order of input and output arguments in LinePickingInverseCDF function so I swapped it back input first output second.

Was just trying to minimize the amount of chopping an changing. It probably does make sense to change the order, but it didn't seem to matter too much as long as the meaning was clear. — Reply to this email directly or view it on GitHub.

[mroughan]

They wouldn't reuse the same code.

On 17/09/12 19:25, Eric Parsonage wrote:

I meant the alternatives to code reuse.

On 17/09/2012, at 5:22 PM, Matthew Roughan wrote:

On 17/09/12 16:26, Eric Parsonage wrote:

"BTW, I deliberately implemented it in terms of our existing pointers to functions" well done code reuse is good.

I would have been interested to see what the alternative would have been.

Alternatives include:

-- working out the inverses, which isn't too hard for some, but isn't too easy for others.

-- writing problem dependent numerical code, with some potential then for speeding it up if we know more about the problem.

I have implemented this in R. I didnt like the way you swapped the order of input and output arguments in LinePickingInverseCDF function so I swapped it back input first output second.

Was just trying to minimize the amount of chopping an changing. It probably does make sense to change the order, but it didn't seem to matter too much as long as the meaning was clear. — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/mroughan/LinePicking/issues/35#issuecomment-8609257.

[lamestllama]

My point exactly, remember how this conversation started?

On 18/09/2012, at 11:58 AM, Matthew Roughan wrote:

They wouldn't reuse the same code.

On 17/09/12 19:25, Eric Parsonage wrote:

I meant the alternatives to code reuse.

On 17/09/2012, at 5:22 PM, Matthew Roughan wrote:

On 17/09/12 16:26, Eric Parsonage wrote:

"BTW, I deliberately implemented it in terms of our existing pointers to functions" well done code reuse is good.

I would have been interested to see what the alternative would have been.

Alternatives include:

-- working out the inverses, which isn't too hard for some, but isn't too easy for others.

-- writing problem dependent numerical code, with some potential then for speeding it up if we know more about the problem.

I have implemented this in R. I didnt like the way you swapped the order of input and output arguments in LinePickingInverseCDF function so I swapped it back input first output second.

Was just trying to minimize the amount of chopping an changing. It probably does make sense to change the order, but it didn't seem to matter too much as long as the meaning was clear. — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/mroughan/LinePicking/issues/35#issuecomment-8609257.

— Reply to this email directly or view it on GitHub.