search

mroughan / LinePicking

Numerical code for geometric probability problems, in particular density functions for the "line picking" problem.
0 stars 1 forks source link

Changing name #10

Closed jonotuke closed 12 years ago

jonotuke commented 12 years ago

OK for me to change this void LinePickingAllmodes(void) to void LinePickingAllModes(void) so consistent with other function names?

mroughan commented 12 years ago

Fine with me, but should we be changing all instances of "mode" to "geometry"

On 27/08/12 18:29, jonotuke wrote:

OK for me to change this void LinePickingAllmodes(void) to void LinePickingAllModes(void) so consistent with other function names?

— Reply to this email directly or view it on GitHub https://github.com/mroughan/LinePicking/issues/10.

jonotuke commented 12 years ago

Yes, but that is real-men's work so I am leaving it to you two.

lamestllama commented 12 years ago

I was about to change to geometry then realised that we need something better. Geometry is confusing from the point of view we can have the same geometry but different measures or metrics. In the paper Matty wrote about a triple. Can we use a name that reflects that?

possibly ensemble? I will give you guys a couple of hours to get back to me with some consensus.

jonotuke commented 12 years ago

What about point space as we are describing the space that the point must lie within.

Jonathan Tuke Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Tuesday, 28 August 2012 at 10:37 AM, Eric Parsonage wrote:

I was about to change to geometry then realised that we need something better. Geometry is confusing from the point of view we can have the same geometry but different measures or metrics. In the paper Matty wrote about a triple. Can we use a name that reflects that?
possibly ensemble? I will give you guys a couple of hours to get back to me with some consensus.

— Reply to this email directly or view it on GitHub (https://github.com/mroughan/LinePicking/issues/10#issuecomment-8076385).

mroughan commented 12 years ago

There is really a triple the region the measure (by which points are generated) the distance metric

I think the term geometry is OK for encompassing these, though it might be nice to have a triple = (region, measure, metric) with region = {square, disk, ...} measure = {uniform, ...} metric = {Euclidean, Manhattan, Geodesic, ...} but (i) that then creates quite a large space of possible cases, of which we are only ever going to fill in a subset

(ii) it means there is more to remember to get a simple case going,

and as the simple cases are likely to be the common ones, maybe the above just makes the problem more difficult. Maybe we can deal with this with defaults for the second two?

Anyway, that's just my thoughts, not a conclusion.

Cheers, Matt

On 28/08/12 10:37, Eric Parsonage wrote:

I was about to change to geometry then realised that we need something better. Geometry is confusing from the point of view we can have the same geometry but different measures or metrics. In the paper Matty wrote about a triple. Can we use a name that reflects that?

possibly ensemble? I will give you guys a couple of hours to get back to me with some consensus.

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

lamestllama commented 12 years ago

Implementing triple = (region, measure, metric) would only be worth considering if there was going to be shared code between different triples. I can see this for a package that did numerical integration to work out all the vales but there is nothing we can share between triples with our algebraic implementation other than the parameters that describe the geometry.

I don't like geometry simply because the parameters we pass i.e., parameter[0] - dimension hyper ball and parameter [1] = radius of hyper-ball are really about the geometry.

I will accept anything that gives us the idea that we are selecting a triple.

mroughan commented 12 years ago

We could just call it a "problem" or "problem_type" or "problem_instance"

On 28/08/12 12:30, Eric Parsonage wrote:

Implementing triple = (region, measure, metric) would only be worth considering if there was going to be shared code between different triples. I can see this for a package that did numerical integration to work out all the vales but there is nothing we can share between triples with our algebraic implementation other than the parameters that describe the geometry.

I don't like geometry simply because the parameters we pass i.e., parameter[0] - dimension hyper ball and parameter [1] = radius of hyper-ball are really about the geometry.

I will accept anything that gives us the idea that we are selecting a triple.

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

lamestllama commented 12 years ago

I am happy with that. What about Jono?

jonotuke commented 12 years ago

I'm happy. Preference is problem_type.

Jono

On 28 August 2012 16:24, Eric Parsonage notifications@github.com wrote:

I am happy with that. What about Jono?

— Reply to this email directly or view it on GitHubhttps://github.com/mroughan/LinePicking/issues/10#issuecomment-8081021.

Jonathan Tuke Associate Lecturer in Statistics School of Mathematical Sciences The University of Adelaide SA 5005 Australia

Ph: +61 8 83133028

mroughan commented 12 years ago

Should we go with "ProblemType" to make naming functions consistent?

lamestllama commented 12 years ago

yes I think so

On 28/08/2012, at 6:09 PM, Matthew Roughan wrote:

Should we go with "ProblemType" to make naming functions consistent?

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

lamestllama commented 12 years ago

I have done a rename across R, C and Matlab code.

Please pull before you do anything else or you are in for a life of pain.