Hi,
Thanks for your response.
Do you think it makes sense to disallow cube+cube operations and only
allow cube+point or point+point instead? Dot and cross products would be
similarly only defined for point+point if someone were to implement them.
I'll submit a v2 if this is an acceptable solution.
Regards,
Kirill
On 7/2/25 13:57, Dean Rasheed wrote:
> On Thu, 15 May 2025 at 16:16, Kirill Panin <kipanin@edu.hse.ru> wrote:
>>
>> Hi hackers!
>>
>> The "cube" extention is frequently used for vectors, but the current
>> implementation lacks support for binary operators, such as +, -, *, /.
>> The attached (fairly trivial) patch adds support for these with the
>> required documentation and test changes.
>>
>
> I don't think that your definition of addition and subtraction makes
> sense for type cube. The docs say:
>
> It does not matter which order the opposite corners of a cube are
> entered in. The cube functions automatically swap values if needed to
> create a uniform “lower left — upper right” internal representation.
>
> Thus, for example, the following 2 cubes are equal:
>
> SELECT '(0,0), (10,10)'::cube = '(10,0), (0,10)'::cube;
>
> ?column?
> ----------
> t
> (1 row)
>
> However, with your definition of addition in terms of simple pointwise
> addition of coordinates, the results of adding this cube to another
> are different, depending on the order of the corners:
>
> SELECT '(0,0), (10,10)'::cube + '(1,2), (3,4)'::cube,
> '(10,0), (0,10)'::cube + '(1,2), (3,4)'::cube;
>
> ?column? | ?column?
> -----------------+-----------------
> (1, 2),(13, 14) | (11, 2),(3, 14)
> (1 row)
>
> which are not equal. It's a pretty odd form of addition in which a+c
> differs from b+c when a and b are the equal.
>
> One could define point+point and point+cube addition to be translation
> by the values from the point, and then it would work correctly if the
> corners of the cube were reversed. That makes a certain amount of
> geometrical sense, since then multiplication and addition are just
> scale and translate.
>
> I imagine that people using the cube extension for vectors are using
> zero-volume cubes (points), so translation-addition would work the
> same as normal vector addition in that case. However, I doubt that
> cube is ever going to make a good general-purpose type for vectors. It
> would be somewhat odd to allow dot and cross products of cubes, for
> example.
>
> Regards,
> Dean
