Little Design Decisions in the Modeling of a Location

November 30, 2008

Alternate title: Procastination Sunday Afternoon

Let’s say you want your computer program to know about locations.

What are you building?

A simulation for an assignment.

What programming language should I use?

Python. I want to learn Python better and I’ll visualize the simulation in Nodebox, which I’ve used before.

What location format should you use?

Latitudes and longitudes. The real application would involve mapping these; the mapping tools I’ve used understand latitudes and longitudes. Six decimal places gives me 1 metre accuracy.

Should I make a class to represent locations, or just use something simple like tuples of floats?

Use a class. You can do some simple validations and unit tests. Good defensive programming. 

What should the class be called?

‘location’. It’s not important enough for me to go learn Python naming conventions right now.

How should the class represent the data?

Python properties seem to be the “new” way of doing basic data in Python, I’ll use those. Lesson learned the hard way: Must remember to inherit from ‘object’ when using Python properties or else they silently don’t work.

Should arbitrary numbers be allowed as latitudes and longitudes or should they be restricted to the degree ranges that maps actually use?

Restrict. I might as well have the class guarantee latitudes between -90 and 90, longitudes between -180 and 180. 

Should the class validate its inputs and reject bad input or fix them up to be valid? 

Validate and reject. “Be liberal in what you accept” is bunk.

Should you test your validations?

Might as well. I want to learn how unit testing works in Python.

Should you include an operation to move a location?

I guess so. 

Should it be named or should you overload addition?

Lat/lng pairs act like vectors in some ways, but I don’t want to go there. I’m not curious to know about Python operator overloading right now. I’ll keep it simple and just call the operation moveBy.

Should there be one moveBy for Latitudes and one for Longitudes, or keep them together?

I’ll keep them together, the alternative would be annoying.

Should both arguments be mandatory?

No, I’ll make them optional named arguments.

What happens when moveBy wants to move a location outside the range of valid latitudes and longitudes?

If I validate, then one call to moveBy could be valid while another identical call was invalid based on internal state of the location. That’s undesirable. I guess I’d better have moveBy fix up the location. It’s not that complicated: I just move the current lat or long into the positive domain, add the parameter modulo the range of allowed values, and adjust the new lat or long back to being centred on 0. This will be error prone, though, I’ll want to test it thoroughly.

You’re using floating point numbers internally; successive small moveBy calls could introduce numerical inaccuracies. Should you take steps to remedy this?

No, I don’t care enough about numerical stability here and I would have to work hard to learn what needs to be done.

Should you really have made a mutable data container? Are locations really mutable? It’s weird to use them as hash keys now, maybe you should have used an immutable pattern. If you make it immutable, operations like moveBy just become factories for new immutable locations.

I’ve already built and tested this class. It’s not worth changing over now. Besides, mutable is probably more efficient.

——-

I don’t know why I was so unusually introspective of my own thoughts during this time, but there it is.

(43.7, 79.4)

Advertisements

2 Responses to “Little Design Decisions in the Modeling of a Location”

  1. Ian Says:

    Great … I was starting to think, hey, maybe it’s time I learned one of these cool new languages… you’ve completely scared me off.

    Where’s my Rexx manual 😉

  2. George Says:

    Wheee! Python!

    If only I could get away with writing all my code in python, but the feeling of dread at the pit of my stomach says the time will soon come when I have to use one of:
    swig
    boost.python
    pyrex
    ctypes
    weave.blitz or weave.inline
    or even something strange and ad hoc to get data from my python code using numpy into some C++ crap I have yet to write.

    And C++ means UGH.


Comments are closed.

%d bloggers like this: