<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 11, 2014 at 11:17 PM, kraythe . <span dir="ltr"><<a href="mailto:kraythe@gmail.com" target="_blank">kraythe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Richard, <div><br></div><div>I appreciate your response and the effort you put into it. And I learned a lot from it. In this case I am learning the thinking mode of Erlang as it is different a bit from what I do to pay the bills. I have yet to get into list comprehensions in Erlang so that is on my ... well ... list. :) You have provided valuable insight. </div>
<div><br></div><div>The main focus of the method is if I have a number of objects with a vector position in a simulation and I want to exclude considerations of interactions with objects outside the sphere of influence, I have to quickly discard the candidates that are not inside the sphere of influence. I originally thought to write a method that did just the vector math because I was wondering if that kind of math would have to ultimately be turned into something native. Even a delay of 1 second would be fatal to the simulation. </div>
</div></blockquote><div><br></div><div>Isn't this what octrees are for? - You'd have to use a "cube of influence" - but as far as I know octrees</div><div>can be used to rapidly partition objects in a 3-d space</div>
<div><br></div><div>Take a look at this <a href="http://en.wikipedia.org/wiki/Octree">http://en.wikipedia.org/wiki/Octree</a></div><div><br></div><div>/Joe </div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div>The algorithm, however, shouldnt have to consider all candidates as the world is broken into spacial segments (cubes) such that the sphere could intersect with at maximum 8 neighboring cubes so I would only need to consider simulation objects within those 8 cube spaces when determining which elements were actually within the sphere of influence. I have been trying to devise a method of reducing the candidate set even further and am still working on that. Perhaps edge detection and cube boundary calculations but I don't want to spend more math doing that then I would simply excluding objects vector by vector. </div>
<div><br></div><div>Anyway thanks for the reply, definitely some information that I can use in there. </div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div style="font-family:arial;font-size:small"><b>Robert Simmons Jr. MSc.</b></div>
</div></div><div><div><br><div class="gmail_quote">On Sun, Feb 9, 2014 at 10:59 PM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
On 8/02/2014, at 4:53 AM, kraythe . wrote:<br>
> Anyway back to the subject at hand. The algorithm is set but now I am at another quandary Lets say these vectors represent a position in space of particular objects in a simulation. The process of culling the vectors based on the sphere is entirely a vector problem but what the user calling cull/3 really needs to know is which objects are not culled from the list, not just which vectors are not culled. Now in Java I could do a number of things if I wanted to keep the cull algorithm as it is. I could return the list of integers containing the original indexes of the vectors in the list that were culled and use that to filter out which objects need to be considered for the simulation step.<br>
<br>
</div>The word "cull" really grates.<br>
<br>
And all those negations *really* confused me *all over again*.<br>
I wrote a lengthy and helpful description of how to get the<br>
points that were accepted and the points that were rejected<br>
as two lists, because that was the only way I could interpret<br>
your question to make sense in Erlang. But on repeated re-reading<br>
it became clear that you were asking for something else.<br>
<br>
There is no such thing in Erlang as object identity.<br>
The distinction you are drawing between the "points" and the<br>
"objects" simply doesn't exist.<br>
<br>
It so happens that if you use a list comprehension like<br>
[P || P <- Points, some_predicate(P)]<br>
the elements of the result *will* be (references to) the same<br>
implementation-level webs of chunks of memory that were in the<br>
original list, not copies. But nothing other than performance<br>
depends on this.<br>
<br>
A list of integers such as you ask for could be obtained, but it<br>
would be very little use to you, because Erlang lists are *LINKED<br>
LISTS*, not *INDEXED ARRAYS*. Finding the nth element of a list<br>
takes O(n) time, and that could not be changed without making<br>
lists much less useful.<br>
<br>
<br>
</blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div></div>