On the topic of http://forums.informationbuild...1057331/m/1087018186 I am almost where I need to be, but I'm hitting another issue...

Basically, I need to create a TABLE request where (X,Y)-coordinates are grouped based on the result of a COMPUTEd field value, like so:

DEFINE FUNCTION DISTANCE(DX/D20.4, DY/D20.4)
	DISTANCE/D20.8 = SQRT(DX * DX + DY * DY);
END

DEFINE FILE PLOTDATA
	DUMMY/I1	= 1;
	R/D20.4		= 9.4;
END
TABLE FILE PLOTDATA
PRINT
	COMPUTE GROUP_LEFT/D20.4	= IF LAST DUMMY NE 1 THEN X ELSE LAST GROUP_LEFT;
	COMPUTE GROUP_BOTTOM/D20.4	= IF LAST DUMMY NE 1 THEN Y ELSE LAST GROUP_BOTTOM;
	COMPUTE D/D20.8			= DISTANCE(X - GROUP_LEFT, Y - GROUP_BOTTOM);

	-* Here I need to update BOTH GROUP_LEFT and GROUP_BOTTOM if D GT R
	COMPUTE GROUP_LEFT/D20.4	= IF D GT R THEN X ELSE LAST GROUP_LEFT;
	COMPUTE GROUP_BOTTOM/D20.4	= IF D GT R THEN Y ELSE LAST GROUP_BOTTOM;

BY SEQUENCE
END

But, redefining GROUP_LEFT or GROUP_BOTTOM just creates a new field of the same name in the internal matrix. The calculation of D keeps using the earlier computations for those field, calculating an ever increasing value of D instead of resetting it.

Is this not possible in FOCUS???

[UPDATE: The initial two conditions previously (erroneously) contained IF DUMMY NE 1, which is always true of course. In reality the check is meant to differentiate between the first result row and any subsequent rows: IF LAST DUMMY NE 1]

This message has been edited. Last edited by: Wep5622,

Wouldn't this work?

TABLE FILE PLOTDATA
PRINT
	COMPUTE GROUP_LEFT_TEMP/D20.4	= IF DUMMY NE 1 THEN X ELSE LAST GROUP_LEFT_TEMP; NOPRINT
	COMPUTE GROUP_BOTTOM_TEMP/D20.4	= IF DUMMY NE 1 THEN Y ELSE LAST GROUP_BOTTOM_TEMP; NOPRINT
	COMPUTE D/D20.8			= DISTANCE(X - GROUP_LEFT_TEMP, Y - GROUP_BOTTOM_TEMP);

	-* Here I need to update BOTH GROUP_LEFT and GROUP_BOTTOM if D GT R
	COMPUTE GROUP_LEFT/D20.4	= IF D GT R THEN X ELSE LAST GROUP_LEFT_TEMP;
	COMPUTE GROUP_BOTTOM/D20.4	= IF D GT R THEN Y ELSE LAST GROUP_BOTTOM_TEMP;
END

Well, closer, I guess... The distance D needs to be calculated from the updated GROUP_LEFT and GROUP_BOTTOM fields, not from the temporary ones.

That's pretty much the same issue that I was running into already with my above implementation, just with separately named fields now. Unless I'm missing something at the end of the working day?

The idea is that as soon as the distance D overflows a certain threshold (R), we base our calculations on a new (GROUP_LEFT, GROUP_BOTTOM) coordinate - namely the first coordinate that exceeded the threshold.

The next coordinate is then inspected relative to those new coordinates, until we again find a point that overflows the threshold and repeat the procedure.

It didn't seem that difficult when I came up with the idea, but actually implementing it turned up this little gotcha...

Wep, to me it sounds like all you need to do is aggregate by boxx and boxy and remember the max.seq for each box. In the code below, I draw a circle with 20000 different angles going around the circle from the x axis counter clockwise. Each resulting record is an xy point in a line sequentially creating a circle. After aggregating these points into a 100*100 square, we get about 380 new xy points that can also sequentially draw the circle.

-* create squares (boxes) for the xy plane from -1 to 1 (100 square length)
-* calculate over a circle (2pi) 20000 xy values
-* The ORDERKEY is just an ascending integer from 1 to 20000 in the small file
DEFINE FILE SMALL
ANG/D8.6 = ORDERKEY/20000 * 2.0 * 3.14159265358979323846;
SINA/D8.6 = MYSIN(ANG,SINA) ;
COSA/D8.6 = MYCOS(ANG,COSA) ;
BOXX/D8.6 = (INT(COSA*50))/50 ;
BOXY/D8.6 = (INT(SINA*50))/50 ;
END
-RUN

-* aggregate all 20000 records into the boxes, remembering
-* max.orderkey (seq num) for each box
TABLE FILE SMALL
SUM AVE.SINA AVE.COSA MAX.ORDERKEY
BY BOXX
BY BOXY
IF ORDERKEY LT 20000
ON TABLE HOLD
END
-RUN

-* now, sort the aggregated xy records by orderkey (seq num)
TABLE FILE HOLD
PRINT SINA COSA
BY ORDERKEY
END
-RUN

 

Edward,

I think you replied to the wrong thread, but that's exactly how we already solved that side of the problem (including naming the fields BOX_X and BOX_Y respectively).

The problem here stems from a side-trip from that solution that made me curious if there is some kind of standard solution for dealing with fields that have dependencies on each other.

I suppose the common case is fields that are all dimensions of the same entity, in this case coordinates of a point in 3-D space (with the 3rd dimension being the order of the points relative to each other).

Hello,

I spoke with a colleague about this issue, and he advises you try changing the COMPUTES to a DEFINE, since you are using PRINT. Changing them to DEFINEs using the LAST calculations should solve the issue of creating a new field in the internal matrix.

Emily McAllister
Focal Point Moderator

Wouldn't that break the check on LAST DUMMY though, thus changing the behaviour? Plus, that would likely ignore the ordering on sequence.

I realise neither of those were present in my original example, I stripped it down a little bit too much apparently...