[erlang-questions] Trying to learn the Erlang Way

[Erik Søe Sørensen]

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/20c03c21/attachment.htm>