Re: [GENERAL] Geometric, getting x and y co-ordinates GOING MAD!!!!!

On Fri, 4 Jun 1999, Stuart Rison wrote:

[snipped -- a float return type drama with a happy end]

> I guess the bottom lines is that you can't really 'bluff' your way in 'C'
> that easy and that I'll have to actually learn some if I want to get 'C'
> functions to work!

That wasn't so much about C as it was about how postgres handles
return values. Here's the relevant doc page:

http://www.postgresql.org/docs/programmer/xfunc414.htm

As far as 'bluffing', that is what perl was intentionally built for. C
is remarkably simple, but it assumes you know not only WHAT it does
but also HOW. It's easy to get shot if you forget about the how part
for a moment.

> This all steemed from me trying to write a standard deviation/variance set
> of aggregate function.  This was just because a point seemed -at the time-
> like quite a 'cute' way of storing to floats in one base type eliminating
> the need for arrays (the two floats being the sum of elements and the sum
> of the elements squared stored as the x and y coords of a point
> respectively).

Although point type is a cute way of storing float pairs, it may
become extremely inefficient in case of mega-tables. What are you
going to do with your points? Do you build indices on them? How are the
points distributed in 2-D? The type of distribution and order of
points affect the performance of R-trees.

Also, if you were looking to store the (mean, SD) values in one
column, you would be better off with the whole new type. If your
science/confession would allow you to represent random distributions
as intervals, such as (mean - SD/2, mean + SD/2), the intervals could
be stored as a 1-D geometric type and indexed with R-tree, with some
caution. If that makes sense, welcome to my segment type:

http://wit.mcs.anl.gov/~selkovjr/seg-type.tgz

It already has some provision for the (mean, SD) syntax, but that
needs debugging. It works great with 'lower .. upper' syntax, where
either 'lower' or 'upper' can be omitted. Besides, it is a variable
precision type: your query returns exactly as many significant digits
as you have inserted. (I couldn't stand frustration it gives you when it
returns 1.2000000 for the value you stored as 1.20. Even 1.20 and 1.2
make a huge difference when you deal with measurements)

--Gene