[erlang-questions] Trying to learn the Erlang Way

Joe Armstrong erlang@REDACTED
Wed Feb 12 15:04:53 CET 2014


On Tue, Feb 11, 2014 at 11:17 PM, kraythe . <kraythe@REDACTED> wrote:

> Richard,
>
> 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.
>
> 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.
>

Isn't this what octrees are for? - You'd have to use a "cube of influence"
- but as far as I know octrees
can be used to rapidly partition objects in a 3-d space

Take a look at this http://en.wikipedia.org/wiki/Octree

/Joe


>
> 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.
>
> Anyway thanks for the reply, definitely some information that I can use in
> there.
>
> *Robert Simmons Jr. MSc.*
>
> On Sun, Feb 9, 2014 at 10:59 PM, Richard A. O'Keefe <ok@REDACTED>wrote:
>
>>
>> On 8/02/2014, at 4:53 AM, kraythe . wrote:
>> > 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.
>>
>> The word "cull" really grates.
>>
>> And all those negations *really* confused me *all over again*.
>> I wrote a lengthy and helpful description of how to get the
>> points that were accepted and the points that were rejected
>> as two lists, because that was the only way I could interpret
>> your question to make sense in Erlang.  But on repeated re-reading
>> it became clear that you were asking for something else.
>>
>> There is no such thing in Erlang as object identity.
>> The distinction you are drawing between the "points" and the
>> "objects" simply doesn't exist.
>>
>> It so happens that if you use a list comprehension like
>>         [P || P <- Points, some_predicate(P)]
>> the elements of the result *will* be (references to) the same
>> implementation-level webs of chunks of memory that were in the
>> original list, not copies.  But nothing other than performance
>> depends on this.
>>
>> A list of integers such as you ask for could be obtained, but it
>> would be very little use to you, because Erlang lists are *LINKED
>> LISTS*, not *INDEXED ARRAYS*.   Finding the nth element of a list
>> takes O(n) time, and that could not be changed without making
>> lists much less useful.
>>
>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140212/96d2a6bc/attachment.htm>


More information about the erlang-questions mailing list