[erlang-questions] List comprehension puzzler
ok@REDACTED
ok@REDACTED
Wed Sep 21 13:23:09 CEST 2016
By now I expect you've all seen my code which computes the
check sums and has no calls to length/1 at all.
I'd like to point out that it's straightforward to write
length_is([_|Xs], N) when N > 0 ->
length_is(Xs, N-1);
length_is([], 0) ->
true;
length_is(_, _) ->
false.
which answers the question "is my first argument a list
whose length matches my second argument" in
O(min(|Xs|,N) time and to do
f(..., Xs, ...) ->
f(..., Xs, length_is(Xs, 137), ...).
f(..., Xs, true, ...) ->
% Xs is known to be a list of 137 elements
...
It's not much harder to write
length_between([_|Xs], L, U) when L > 0 ->
length_between(Xs, L-1, U-1);
length_between([], L, U) ->
L =< 0, 0 =< U;
length_between(_, _, _) ->
false.
and use it the same way. And of course, while it's
*nice* to do pattern matching in the head, we *do* have 'case'.
I was just marking some student code this afternoon
which called a Java method f(N) five times with the
same (large) value of N, the method having been
implemented to take O(N) time instead of the easily
achievable O(sort(N)). A very slow program. Yet
not, mathematically considered, a stupid one. If
Java had (or for that matter, *could* have) the
notion of a "pure" method, constant subexpression
elimination could have helped. (But not with O(N)
vs O(sort(N)).)
More information about the erlang-questions
mailing list