<br><br><div class="gmail_quote">On Tue, Jul 8, 2008 at 3:47 AM, Richard A. O'Keefe <<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
An answer to the puzzle _could_ be something as simple as<br>
<br>
        io:format("VIER = 6241, NEUN = 9409\n")<br>
<br>
*Some* amount of human judgement will be needed to convert<br>
the problem specification to executable code.  For example,<br>
one way to find candidates is to enumerate integers in a<br>
certain range, square them, and check whether the squares<br>
have a suitable digit pattern.  But what range of integers?<br>
Looking at it, _we_ see that the range need not be any more<br>
than 32..99, but given that, the rest is pretty much<br>
trivial.  (sqrt(VIER) = 79, sqrt(NEUN) = 97, which is quite<br>
pretty.)  You can get a short list for NEUN thus:<br>
<br>
neun_candidates() -><br>
     [{N,E,U,NEUN} ||<br>
        X <- lists:seq(32, 99),<br>
        NEUN <- [X*X],<br>
        [N,E,U,N] <- [integer_to_list(NEUN)],<br>
        N /= E, N /= U, E /= U].<br>
which returns the list<br>
[{$1,$5,$2,1521}, {$1,$6,$8,1681}, {$4,$6,$2,4624},<br>
  {$5,$6,$2,5625}, {$9,$4,$0,9409}].<br>
The code for vier_candidates() is similar.<br>
Pasting them together is just<br>
<br>
vier_neun_candidates() -><br>
    A = vier_candidates(),<br>
    B = neun_candidates(),<br>
    [{VIER,NEUN} ||<br>
        {V,I,E,R,VIER} <- A,<br>
        {N,E,U,  NUEN} <- B,<br>
        % some testing goes here<br>
        ].<br>
<br>
Then it's simply a matter of checking the last condition<br>
<br>
answer() -><br>
     C <- vier_neun_candidates(),<br>
     [{VIER,NEUN} ||<br>
         {VIER,NEUN} <- C,<br>
         X <- [[OOPS || {VIER,OOPS} <- C, OOPS /= NEUN]],<br>
         X == [],<br>
         Y <- [[JUNK || {JUNK,NEUN} <- C, JUNK /= VIER]],<br>
        Y == []].<br>
<br>
Finishing the details left for anyone interested.<br>
One comment I _will_ make is that there is a rather pointless<br>
restriction in Erlang syntax: the generator of a list<br>
comprehension *may* include "X <- [expr]" but may *not*<br>
include "X = expr", which means exactly the same thing.<br>
<br>
neun_candidates() -><br>
     [{N,E,U,NEUN} ||<br>
        X <- lists:seq(32, 99),<br>
        NEUN = X*X,<br>
        [N,E,U,N] = integer_to_list(NEUN),<br>
        N /= E, N /= U, E /= U].</blockquote><div><br> 
neun_candidates() -><br>
     [{N,E,U,NEUN} ||<br>
        X <- lists:seq(32, 99),<br>
        begin<br>          NEUN = X*X,<br>
           [N,E,U,N1] = integer_to_list(NEUN),<br>
           N =:= N1 andalso N /= E andalso N /= U andalso E /= U<br>      end].<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
would have been much clearer.<br>
<br>
More precisely, Erlang *does* allow these expressions<br>
BUT WITH THE WRONG MEANING!  A qualifier that is<br>
        <pattern> = <expression><br>
should SUCCEED or FAIL, and if it succeeds, the<br>
value it returns is quite irrelevant and should by NO<br>
means be restricted to 'true' or 'false'.<br>
<br>
Another way to hack around this is to rewrite<br>
        Pat = Expr<br>
as      (Pat = Expr, true)<br>
but that has the wrong semantics too, because when<br>
the value of Expr doesn't match Pat, we simply want<br>
that iteration of the list comprehension to fail,<br>
not to produce an exception in the whole thing.<br>
<br>
What could break if this part of Erlang syntax were fixed?<br>
Let us suppose that nobody writes list comprehensions<br>
containing<br>
        Nonvar = Expr<br>
because they could and should be rewritten to use == or<br>
=:=.  Would<br>
        _ = Expr<br>
make sense?  No, because it would be equivalent to<br>
        Expr.<br>
Would<br>
        X = Expr<br>
make sense?  No, because it would be equivalent to<br>
        Expr, X = true<br>
and what would be the point of that?<br>
<br>
It really is past time that something was done about this.<br>
If the current badly broken semantics cannot be changed,<br>
then at least a compile-time warning for any list<br>
comprehension containing Pat = Expr that it is almost<br>
certainly incorrect would be helpful.<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>--Hynek (Pichi) Vychodil