<div dir="ltr">So now the fixed code is: <div><br></div><div><div><font face="courier new, monospace">%% Subtract the second vector from the first</font></div><div><font face="courier new, monospace">subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}.</font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">%% Compute the magnitude of the vector</font></div><div><font face="courier new, monospace">magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)).</font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">%% Compute whether the vector with components X, Y and Z has greater magnitude then the passed scalar M. </font></div><div>
<font face="courier new, monospace">%% Note that this method avoids the expensive sqrt operation. </font></div><div><font face="courier new, monospace">is_magnitude_greater(M, {X, Y, Z}) when is_number(M), is_number(X), is_number(Y), is_number(Z) -></font></div>
<div><font face="courier new, monospace"> Msq = M * M,</font></div><div><font face="courier new, monospace"> Magsq = (X * X) + (Y * Y) + (Z * Z), </font></div><div><font face="courier new, monospace"> Msq > Magsq.</font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">%% Determines if any coordinate in the given vector is bigger than the passed in value M</font></div><div><font face="courier new, monospace">has_coordinate_greater_than(V, {X, Y, Z}) when X > V; Y > V; Z > V -> true; </font></div>
<div><font face="courier new, monospace">has_coordinate_greater_than(V, Coordinate) when is_number(V), is_tuple(Coordinate) -> false.</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">%% 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. </font></div>
<div><font face="courier new, monospace">cull(C, R, Vectors) when is_number(R), is_tuple(C), is_list(Vectors) -> cull(C, R, Vectors, []).</font></div><div><font face="courier new, monospace">cull(C, R, [], Culled) -> Culled; </font></div>
<div><font face="courier new, monospace">cull(C, R, [Head|Tail], Culled) -> </font></div><div><font face="courier new, monospace"> D = subtract(C, Head),</font></div><div><font face="courier new, monospace"> case has_coordinate_greater_than(R, Head) of</font></div>
<div><font face="courier new, monospace"> true -> cull(C, R, Tail, Culled);</font></div><div><font face="courier new, monospace"> false -> cull(C, R, D, Head, Tail, Culled)</font></div><div><font face="courier new, monospace"> end.</font></div>
<div><font face="courier new, monospace">cull(C, R, D, Head, Tail, Culled) when is_tuple(D), is_number(R) -></font></div><div><font face="courier new, monospace"> case is_magnitude_greater(R, D) of </font></div><div><font face="courier new, monospace"> true -> cull(C, R, Tail, [Head | Culled]);</font></div>
<div><font face="courier new, monospace"> false -> cull(C, R, Tail, Culled)</font></div><div><font face="courier new, monospace"> end.</font></div></div><div><br></div><div>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? </div>
</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. - Lead Java Architect @ EA</b></div><div style="font-family:arial;font-size:small">
<i>Author of: Hardcore Java (2003) and Maintainable Java (2012)</i></div><div><i style="font-family:arial;font-size:small">LinkedIn: </i><font face="arial"><i><a href="http://www.linkedin.com/pub/robert-simmons/40/852/a39" target="_blank">http://www.linkedin.com/pub/robert-simmons/40/852/a39</a></i></font></div>
</div></div>
<br><br><div class="gmail_quote">On Fri, Feb 7, 2014 at 9:53 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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. <div>
<br></div><div>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 <font face="courier new, monospace">cull/3</font> 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: </div>
<div><br></div><div>List<Integer> survivors = cull(C, R, Candidates);</div><div>for(final Integer index : survivors) handleSurvivor(Candidates.get(index)); </div><div><br></div><div>Now the question is what is the erlang way to do this?</div>
<div><br></div><div>Thanks in advance. </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 class="im"><div style="font-family:arial;font-size:small">
<i>Author of: Hardcore Java (2003) and Maintainable Java (2012)</i></div><div><i style="font-family:arial;font-size:small">LinkedIn: </i><font face="arial"><i><a href="http://www.linkedin.com/pub/robert-simmons/40/852/a39" target="_blank">http://www.linkedin.com/pub/robert-simmons/40/852/a39</a></i></font></div>
</div></div></div><div><div class="h5">
<br><br><div class="gmail_quote">On Fri, Feb 7, 2014 at 9:35 AM, Garrett Smith <span dir="ltr"><<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Fri, Feb 7, 2014 at 8:47 AM, kraythe . <<a href="mailto:kraythe@gmail.com" target="_blank">kraythe@gmail.com</a>> wrote:<br>
> Man I feel silly. but then I am fighting a chest cold. I guess this happens<br>
> easier when you don't have completion or highlighting that I am used to in<br>
> an IDE.<br>
<br>
</div>Viva Eclipse!<br>
<br>
But seriously, every programmer knows the feeling of at once being<br>
certain something's wrong with the compiler/VM and then realizing the<br>
obviousness of his or her mistake. You'll pick up quickly where to<br>
look for the common sources of these.<br>
<br>
Fred's comments on function naming are spot on - lower camel case is<br>
almost never ever seen in Erlang and really stands out in a bad and<br>
distracting way. I know this sounds religious, and it is, but it's the<br>
True Religion, so it's fine.<br>
<br>
Having very, very focused functions helps a lot both in writing a<br>
program (it forces the programmer to make things obvious in code,<br>
which is very hard to do but an excellent way to prove you understand<br>
exactly what problems you're solving) and to debug a program (it's<br>
hard for problems to lurk in obvious code).<br>
<br>
This blog post says what I mean:<br>
<br>
<a href="http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html" target="_blank">http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html</a><br>
<br>
It's also True Religion, so it's fine. [1]<br>
<br>
In cases where you really need to step through code (I think these are<br>
rare, especially if you follow the obviousness rule) the function<br>
tracing tools in Erlang are fantastic. Reid Draper happened to have<br>
just presented a great tracing tool called redbug at the Chicago<br>
Erlang User Group this Wednesday:<br>
<br>
<a href="https://github.com/massemanet/eper/blob/master/src/redbug.erl" target="_blank">https://github.com/massemanet/eper/blob/master/src/redbug.erl</a><br>
<br>
I've historically used e2's e2_debug module:<br>
<br>
<a href="https://github.com/gar1t/e2/blob/master/src/e2_debug.erl" target="_blank">https://github.com/gar1t/e2/blob/master/src/e2_debug.erl</a><br>
<br>
I'll might switch to redbug because it stops tracing automatically<br>
after a period of time or number of traces, which is super great for<br>
use in production systems. e2_debug is fine for local dev however --<br>
and it's output is IMO much easier to read.<br>
<br>
While you can use the Erlang visual debugger to step through code, I<br>
personally find this time consuming and awkward and prefer to trace.<br>
Problems in Erlang often come down to unexpected patterns that sneak<br>
into a call chain, which are easy to spot through tracing.<br>
<br>
Best of luck!<br>
<br>
Garrett<br>
<br>
[1] There is one stylistic change that I would recommend, vis-a-vis<br>
that blog post, which is to *selectively* use variables to pull<br>
important, side effecty operations out of nested function calls so<br>
that they appear earlier in the function (western style top-down,<br>
left-right reading) and get named results (via variable binding). So,<br>
e.g.<br>
<br>
do_something_next(do_something_first())<br>
<br>
Becomes:<br>
<br>
FirstResult = do_something_first()<br>
do_something_next(FirstResult)<br>
<br>
God names are essential - these are terrible names, but you get the idea.<br>
<br>
Do this only when it makes the code more obvious.<br>
<br>
Richard O'Keefe pointed this out to me originally and, of course, he's right.<br>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>