[erlang-questions] Trying to learn the Erlang Way

[kraythe .]

Yeah there needed to be some abs calls, I have added them since I posted.

*Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
*Author of: Hardcore Java (2003) and Maintainable Java (2012)*
*LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
<http://www.linkedin.com/pub/robert-simmons/40/852/a39>*


On Fri, Feb 7, 2014 at 12:31 PM, Erik Søe Sørensen <eriksoe@REDACTED>wrote:

> I think I'd use lists:filter there, at least until I had indications that
> it cost speed.
> Also, I suspect there are some abs() calls missing in the
> has_coordinate_greater_than() function - or have I misunderstood?
> Den 07/02/2014 17.45 skrev "kraythe ." <kraythe@REDACTED>:
>
>> So now the fixed code is:
>>
>> %% Subtract the second vector from the first
>> subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}.
>>
>> %% Compute the magnitude of the vector
>> magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)).
>>
>> %% Compute whether the vector with components X, Y and Z has greater
>> magnitude then the passed scalar M.
>> %% Note that this method avoids the expensive sqrt operation.
>> is_magnitude_greater(M, {X, Y, Z}) when is_number(M), is_number(X),
>> is_number(Y), is_number(Z) ->
>>   Msq = M * M,
>>   Magsq = (X * X) + (Y * Y) + (Z * Z),
>>   Msq > Magsq.
>>
>> %% Determines if any coordinate in the given vector is bigger than the
>> passed in value M
>> has_coordinate_greater_than(V, {X, Y, Z}) when X > V; Y > V; Z > V ->
>> true;
>> has_coordinate_greater_than(V, Coordinate) when is_number(V),
>> is_tuple(Coordinate) -> false.
>>
>> %% Culls the list of vectors X to only those that are in the sphere
>> devined by vector C as a center and R as a radius.
>> cull(C, R, Vectors) when is_number(R), is_tuple(C), is_list(Vectors) ->
>> cull(C, R, Vectors, []).
>> cull(C, R, [], Culled) -> Culled;
>> cull(C, R, [Head|Tail], Culled) ->
>>   D = subtract(C, Head),
>>   case has_coordinate_greater_than(R, Head) of
>>     true -> cull(C, R, Tail, Culled);
>>     false -> cull(C, R, D, Head, Tail, Culled)
>>   end.
>> cull(C, R, D, Head, Tail, Culled) when is_tuple(D), is_number(R) ->
>>   case is_magnitude_greater(R, D) of
>>      true -> cull(C, R, Tail, [Head | Culled]);
>>      false -> cull(C, R, Tail, Culled)
>>   end.
>>
>> Now the question is the resolution of the followup question of how to
>> integrate this in a solution. Do we return a list of trues and falses and
>> zip that with the objects to form a candidate list? How would you do it?
>>
>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
>> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
>> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
>> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>>
>>
>> On Fri, Feb 7, 2014 at 9:53 AM, kraythe . <kraythe@REDACTED> wrote:
>>
>>> Well I am not a programming newbie. ;-) Just an erlang newbie. If I had
>>> a dollar for every silly "is" mistake I have made, Id be rich. At any rate
>>> thanks for the advice. I think naming is not necessarily a religious thing,
>>> or it shouldn't be. It is very valid to adapt the standards of the source
>>> language. Thats what annoys me when people write Java code like C code.
>>>
>>> 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. I.e:
>>>
>>> List<Integer> survivors = cull(C, R, Candidates);
>>> for(final Integer index : survivors)
>>> handleSurvivor(Candidates.get(index));
>>>
>>> Now the question is what is the erlang way to do this?
>>>
>>> Thanks in advance.
>>>
>>> *Robert Simmons Jr. MSc.*
>>> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
>>> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
>>> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>>>
>>>
>>> On Fri, Feb 7, 2014 at 9:35 AM, Garrett Smith <g@REDACTED> wrote:
>>>
>>>> On Fri, Feb 7, 2014 at 8:47 AM, kraythe . <kraythe@REDACTED> wrote:
>>>> > Man I feel silly. but then I am fighting a chest cold. I guess this
>>>> happens
>>>> > easier when you don't have completion or highlighting that I am used
>>>> to in
>>>> > an IDE.
>>>>
>>>> Viva Eclipse!
>>>>
>>>> But seriously, every programmer knows the feeling of at once being
>>>> certain something's wrong with the compiler/VM and then realizing the
>>>> obviousness of his or her mistake. You'll pick up quickly where to
>>>> look for the common sources of these.
>>>>
>>>> Fred's comments on function naming are spot on - lower camel case is
>>>> almost never ever seen in Erlang and really stands out in a bad and
>>>> distracting way. I know this sounds religious, and it is, but it's the
>>>> True Religion, so it's fine.
>>>>
>>>> Having very, very focused functions helps a lot both in writing a
>>>> program (it forces the programmer to make things obvious in code,
>>>> which is very hard to do but an excellent way to prove you understand
>>>> exactly what problems you're solving) and to debug a program (it's
>>>> hard for problems to lurk in obvious code).
>>>>
>>>> This blog post says what I mean:
>>>>
>>>>
>>>> http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html
>>>>
>>>> It's also True Religion, so it's fine. [1]
>>>>
>>>> In cases where you really need to step through code (I think these are
>>>> rare, especially if you follow the obviousness rule) the function
>>>> tracing tools in Erlang are fantastic. Reid Draper happened to have
>>>> just presented a great tracing tool called redbug at the Chicago
>>>> Erlang User Group this Wednesday:
>>>>
>>>> https://github.com/massemanet/eper/blob/master/src/redbug.erl
>>>>
>>>> I've historically used e2's e2_debug module:
>>>>
>>>> https://github.com/gar1t/e2/blob/master/src/e2_debug.erl
>>>>
>>>> I'll might switch to redbug because it stops tracing automatically
>>>> after a period of time or number of traces, which is super great for
>>>> use in production systems. e2_debug is fine for local dev however --
>>>> and it's output is IMO much easier to read.
>>>>
>>>> While you can use the Erlang visual debugger to step through code, I
>>>> personally find this time consuming and awkward and prefer to trace.
>>>> Problems in Erlang often come down to unexpected patterns that sneak
>>>> into a call chain, which are easy to spot through tracing.
>>>>
>>>> Best of luck!
>>>>
>>>> Garrett
>>>>
>>>> [1] There is one stylistic change that I would recommend, vis-a-vis
>>>> that blog post, which is to *selectively* use variables to pull
>>>> important, side effecty operations out of nested function calls so
>>>> that they appear earlier in the function (western style top-down,
>>>> left-right reading) and get named results (via variable binding). So,
>>>> e.g.
>>>>
>>>>     do_something_next(do_something_first())
>>>>
>>>> Becomes:
>>>>
>>>>    FirstResult = do_something_first()
>>>>    do_something_next(FirstResult)
>>>>
>>>> God names are essential - these are terrible names, but you get the
>>>> idea.
>>>>
>>>> Do this only when it makes the code more obvious.
>>>>
>>>> Richard O'Keefe pointed this out to me originally and, of course, he's
>>>> right.
>>>>
>>>
>>>
>>
>> _______________________________________________
>> 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/20140207/179202c1/attachment.htm>