Обсуждение: Getting float8 data into cube?

For 7.4 I would like to add a function for importing float8 values
into cube. But because the cube data type is variable length I am
not sure what a good approach would be.

Currently this can be poorly done using text as an intermediate type.
As far as I can tell functions can't take sets as arguments. Arrays
seem to suffer from similar problems as the cube type, so that preloading
an array with the output of a few calculations isn't particularly easy
unless you use text as an intermediate type.

One possibility would be to have a function that adds one dimension
on to an existing cube. This could be used recursively to build up a
cube with desired number of dimensions. It may not gain much in speed, but
would be more accurrate without having to adjust extra_float_digits.

Is there some better approach that I have overlooked?

Bruno Wolff III <bruno@wolff.to> writes:
> For 7.4 I would like to add a function for importing float8 values
> into cube. But because the cube data type is variable length I am
> not sure what a good approach would be.

I'm not clear on what you want to accomplish.  How are you expecting
the source data to be structured?
        regards, tom lane

On Sun, Nov 17, 2002 at 15:19:54 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruno Wolff III <bruno@wolff.to> writes:
> > For 7.4 I would like to add a function for importing float8 values
> > into cube. But because the cube data type is variable length I am
> > not sure what a good approach would be.
> 
> I'm not clear on what you want to accomplish.  How are you expecting
> the source data to be structured?
> 
>             regards, tom lane

I would like to get the results of floating point calculations into a cube
without losing precision because float output is trunctated at 15 digits.
In 7.4 I will have the option to change extra_float_digits while loading
data into cubes, but that seems like a hack.

My particular case will be converting latitude and longitude to 3D
cartesian coordinates. With the calculations truncated at 15 digits,
I can sometimes see round off error after going back to latitude
and longitude. The accurracy itself isn't a big deal, it is more seeing
the .0000001 or .999999 at the end of the numbers that is annoying. This
could also be handled by further rounding.

It also seems like there should be a way to get floating point data into
cube without losing precision.

I have a specific proposal for allowing for building cube values from
float8 values with building strings (which will typically lose information).
I want to add the following 4 overloaded functions:

cube(float8) cube(1) returns '(1),(1)'::cube

cube(float8,float8) cube(1,2) returns '(1),(2)'::cube

cube(cube,float8) cube('(1),(2)',3) returns '(1,3),(2,3)'::cube

cube(cube,float8,float8) cube('(1),(2)',3,4) returns '(1,3),(2,4)'::cube

This is useful when the input needs to be transformed before being stored.
For example when the input is in polar coordinates.

For polar input of R and O, you then could do something like:
cube(cube(R*sin(O)),R*cos(O))
instead of
cube('('||R*sin(O)||','||R*cos(O)||')')
The latter will normally be less accurrate than the former.

If the above is acceptable, I will come up with a patch versus the 7.4
version of the cube contrib package.