### Random Post

### Recent Posts

### Recent Comments

### Archives

### Categories

- article (11)
- enigma (1,123)
- misc (2)
- project euler (2)
- puzzle (31)
- site news (43)
- tantalizer (31)
- teaser (3)

### Site Stats

- 168,282 hits

Programming Enigma Puzzles

31 July 2017

Posted by on **From New Scientist #2260, 14th October 2000** [link]

In the following statement digits have been consistently replaced by capital letters, different letters being used for different digits:

ONE and NINE are odd perfect squares, FOUR is an even perfect square.

Find the numerical value of the square root of (NINE × FOUR × ONE).

[enigma1104]

Advertisements

%d bloggers like this:

See also:

Enigma 1123,Enigma 1175,Enigma 1291,Enigma 1368,Enigma 1476,Enigma 1544.This puzzle can be solved using the

SubstitutedExpression()solver from theenigma.pylibrary.This run file executes in 82ms.

Solution:The square root of (NINE × FOUR × ONE) is 73872.This Python programme ran in 46 msec.

No. 1425 is an expanded version of this one.

Here’s a Picat model that takes about 10ms to solve. Note that the square root calculation is done after solve. Hence all variables are assigned and we can use the non-CP variant sqrt/1. (One can also use a square_root/1 constraint similar to perfect_square/1, but it’s not needed.)

A comment about perfect_square/1: the domains for Y is restricted by fd_min_max/3 which simplifies the model.

(A similar MiniZinc model is slower: about 100ms.)

@hakank: Thanks for posting your Picat model. For some reason I don’t get any output when I try and run it, but if I replace the

modconstraints at lines 14-16 with:then I do get the expected answer.

@jim. Ah. I assume that you are running Picat v 2.1#3 (the latest official release). It has a bug regarding larger domains in certain cases. I happen to run the forthcoming version where this bug is fixed. 🙂 Sorry about that. I hope the new version will be released soon.

I used Hakank’s square predicate and it ran in 64 msec, but ’round’ did not work for me in the output.

@geoffrounce Nice! For my own MiniZinc model I didn’t use sqrt like that.

Regarding round: There is no support for “round(var int)” in MiniZinc. However, when using values in the output like this, one can use “fix(…)” to convert to a non-var parameter and then use “round()”. So this works: