HP Forums

Full Version: What is the best way to store coordinates
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I would like to write some coordinate geometry programs but don't know where to start. I would like to start with a simple program to store and recall points. I would like to be able to store point number, northing, easting, elevation, and a apha-numeric code. Would it be better to store these as vectors or coordinates? Is it better to use a list or a matrix or is there something I'm overlooking.


points are 2 real numbers (assuming 3D)... This gives you a couple of possibility for storage:
- 2 numbers
- in a list
- in a matrice (as a single line, as a single column, as 2 elements side by side with other elements)
- 1 complex number
- in a list
- in a matrice (in a vector or a real matrice?)
- other solutions are possible (such as a string), but are unlikely to be the best solution...

The storage that you will use will depend on what you are trying to do whith the object and which build in functions are available to handle them.
Are the points that you are going to store part of a point grid? if yes, then a matrix might be a good solution. If on the onctrary, you have an arbitrary number of points, a list might be more adapted.

A matrice tend to be faster than a list and takes less memory (because 1 matrice is just 1 block of memory with all the data in it, 8 bytes per numbers). while a list is an array of pointers on objects (one per number), yeilding much more memory used and memory allocations (which are slow)...

remember, list processing is your friend! for example, assuming that you are storing points as complex numbers in a list. a rotation by 90° is just a multiplicaiton of the list of complex nubmers by (0, 1) as in:
local l:= { My List of points };
l:= l*(0,1); // rotates all points by 90°

(12-16-2013 06:45 AM)cyrille de brébisson Wrote: [ -> ]Hello,

points are 2 real numbers (assuming 3D)... This gives you a couple of possibility for storage:

Hello cyrille de brébisson!
3D points require THREE real numbers each (x,y,z), or am I mistaken?
Well, this is bringing back memories. :-)

If you really would like to keep them grouped and since you are dealing with real numbers, I'd recommend doing a { #PN, [ N,E,EL], " " } type of structure. Note that there are not really 2d/3d vectors, but I believe you'll find grouping them like such will prove convenient. The first number I'd keep as an integer just for clarity's sake, but sticking it into the vector would reduce the size slightly. Compared with the 48 series, lists are going to be VERY fast because sizing information is encoded in the list and you don't have to scan everything to know the list size or get to the next object.

Alternatively, you could have 1 list of point numbers, 1 list of your vectored N,E,EL, and then 1 list for your codes. This would definitely be the fastest as you can do quicker searches for the PN or matching codes, but you have to be certain nothing can get out of sync else everything is messed up.

(12-16-2013 03:04 PM)Tim Wessman Wrote: [ -> ]I'd recommend doing a { #PN, [ N,E,EL], " " }

This structure might work for you, but it has 1 drawback you can not use list processing on it.

if you were to use something around the lines of l:={ [x,y,z],[x,y,z]...} then you would be able to do something like:
l:=l*rotation_matrice and stuff like that...
but if you need to keep meta data on points (such as numbers, names....) you could keep them in a separate list somewhere else...

Quote:you can not use list processing on it.

Yup, except that will #never# be done for any surveying related calculation except the possibility of least squares regression.
Reference URL's