Thread: Multiply and Divide operators for geometry types
Can any one explain what the * and / operators are supposed to do?
For example, what does it mean to multiply a box * a point?
The documentation says that multiply and divide are supposed to perform translation and scaling, but it doesn't really go much beyond that.
Any good URL's out there that might explain this? Thanks.
-- Murphy
"Murphy Pope" <pope_murphy@hotmail.com> writes:
> Can any one explain what the * and / operators are supposed to do?
> For example, what does it mean to multiply a box * a point?
I think your best bet is to look at the source code and see what it
does.
If you extract some improved docs, please contribute 'em!
regards, tom lane
> Can any one explain what the * and / operators are supposed to do?
> For example, what does it mean to multiply a box * a point?
It is equivalent to a translation and a rotation. If you have worked
with complex arithmetic, the analogy is with the real and complex axis,
and the operations which can be done in those two dimensions.
For example, a box consists of four points. Multiplying a box by another
point does the equivalent of a complex math operation on each of those
four points. Multiplying by (1.0,0) has no effect, multiplying by
(0.0,1.0) rotates by 90 degrees, and multiplying by something other than
a unit vector scales also.
Look for stuff on complex math, or perhaps someone has another
suggestion for a reference. Maybe some GIS references would say
something?
- Thomas
En Wed, 10 Apr 2002 17:56:02 -0700
Thomas Lockhart <lockhart@fourpalms.org> escribió:
> > Can any one explain what the * and / operators are supposed to do?
> > For example, what does it mean to multiply a box * a point?
>
> It is equivalent to a translation and a rotation. If you have worked
> with complex arithmetic, the analogy is with the real and complex axis,
> and the operations which can be done in those two dimensions.
There's something I don't quite understand here. If I do
SELECT box '((2,3),(4,5))' * point '(3,4)';
?column?
-----------------
(-6,31),(-8,17)
But my complex aritmethic gives me
(-6,17),(-8,31)
As I read in your mail, each point in the box gets multiplied by the
other point, but this is not the case in the current code (CVS as of
earlier today... well, yesterday). Is this a bug, or am I understanding
something wrong?
--
Alvaro Herrera (<alvherre[a]atentus.com>)
"On the other flipper, one wrong move and we're Fatal Exceptions"
(T.U.X.: Term Unit X - http://www.thelinuxreview.com/TUX/)
En Thu, 11 Apr 2002 02:36:30 -0400
Alvaro Herrera <alvherre@atentus.com> escribió:
> There's something I don't quite understand here. If I do
>
> SELECT box '((2,3),(4,5))' * point '(3,4)';
> ?column?
> -----------------
> (-6,31),(-8,17)
>
> But my complex aritmethic gives me
>
> (-6,17),(-8,31)
>
> As I read in your mail, each point in the box gets multiplied by the
> other point, but this is not the case in the current code (CVS as of
> earlier today... well, yesterday). Is this a bug, or am I understanding
> something wrong?
Well, I don't know whether it's a bug or not, but the code has been like
this since at least 6.3, so if somebody uses this operator he surely
must be used to it being this way by this time.
Anyway, the code is (src/backend/utils/adt/geo_ops.c)
high = DatumGetPointP(DirectFunctionCall2(point_mul,
PointPGetDatum(&box->high),
PointPGetDatum(p)));
low = DatumGetPointP(DirectFunctionCall2(point_mul,
PointPGetDatum(&box->low),
PointPGetDatum(p)));
result = box_construct(high->x, low->x, high->y, low->y);
which gives a nice swap in the variables, since box_construct is
prototyped as
static BOX *box_construct(double x1, double x2, double y1, double y2);
Maybe it's _supposed_ to be like this...
--
Alvaro Herrera (<alvherre[a]atentus.com>)
Officer Krupke, what are we to do?
Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke")
Alvaro Herrera <alvherre@atentus.com> writes:
> which gives a nice swap in the variables,
Doesn't matter, because box_construct will take its own counsel as to
what order to store the corners in, anyway.
regards, tom lane