On Wed, Jan 11, 2012 at 4:55 AM, Ben Gorte - LR <b.g.h.go...@tudelft.nl> wrote:
> Thanks a lot to all for enlightening me!
>
>> DATA=: ".;._2]0 :0 0 0 1 1 1 1 2 2 2 2 2 4 4 4 5 5 5 0 7 8 9 2 2 5 5 5 3 8
>> 0 0 5 6)
Note that this line is bugged.
It was supposed to look like this (I hope this looks right):
DATA=: ".;._2]0 :0
0 0 1 1 1 1 2 2 2 2 2 4 4 4 5 5
5 0 7 8 9 2 2 5 5 5 3 8 0 0 5 6
)
In other words, four lines, with a line break between the first two
adjacent zeros, a line break between the second pair of adjacent fives
and a line break before the closing right parenthesis.
Unfortunately, gmail will not let me declare that all copy and paste
into a plaintext email composing region should be plain texts copy and
paste. And, worse, the default paste mechanism does not show me how
it will be represented when the email is sent. So I am composing
blind, and using a mechanism which is confusing.
>> 6 (</./@] #inv~ i.@[ e. {.@] ) DATA
>> 6 {. (</./ #inv~ (e.~ i.@(1 + >./))@{. ) DATA
>> I could not choose between these options without better understanding
>> your application.
>
> Well, my application ... continue reading at your own risk.
>
> I have (say) a million points (x,y,z) and I use software that makes a
> Delaunay triangulation (http://www.cs.cmu.edu/~quake/triangle.html):
> approximately two million triangles. Each triangle consists of three point
> numbers. Although my points are 3D, the triangulation is 2D and z is merely
> an attribute (it is terrain height, but it could also be temperature).
>
> With each point I want to do "something" , which also depends on the point's
> neighbours: those points that are together with the considered point in a
> triangle. This is going to happen very often (different things that I want
> to do), and therefore I wondered whether it makes sense to find each point's
> set of neighbours only once and store that. Since the number of neighbours is
> not the same for each point (on average it is six), I was thinking of a boxed
> list. Occasionally an (x,y) occurs twice in the input data. Then only one of
> these points is used in the triangulation and for the other I get an empty
> slot in my list.
I would be careful about using boxed lists for this application.
Consider, for example:
size=: #@(3!:1)
size i. 4 4
176
size (<:/~ i.4) <@#"1 i.4 4
312
(I hope I pasted that in properly... I will find out when I send the message.)
Here, by saving only the data elements in the upper triangle, I have
increased the amount of space needed to represent the data. I have
also increased the complexity of any code that would process the data,
and I have increased how much time would be needed to process the
data.
Anyways, I try and save boxing for big, measurable advantages and
major code simplifications.
Zeros are nice for many of the remaining cases. Zero may be old
fashioned, but it's a good mechanism.
> I sort it from left to right according to the top row and then something like
> </. comes in. After that it gets again a bit complicated since I want the
> neighbours to be ordered (counter-clockwise). Fortunately all input triangles
> have the same orientation.
This might be a good candidate for boxing -- boxes that hold a lot of
stuff tend to amortize the cost of the box itself.
> Another envisaged use for storing the neighbours with each point is answering
> the question: which triangle contains a given (x,y). Normally this requires
> visiting half of the triangles on average (one million), or using a spatial
> index. Now it will be possible to start at an arbitrary location, step
> through a sequence of adjacent triangles in the right direction, and arrive
> after one thousand steps or so.
I do not know enough about this issue to make any useful suggestions.
However, this sounds like it might be a candidate for an index vector
or a selection mask.
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
