(doseq/lazy/interop)? problem, different behaviour when adding a println

[Lucas Wiener]

Hi all,

I'm working on solving the problem http://adventofcode.com/2016/day/11 , and ran into some weird behaviour. I have solved the actual problem, so let's not focus on it.

Here's my code:

(defn compute3

  {:test (fn []

           (is= (compute3 (create-state "F4 .  .  .  .  .  "

                                        "F3 .  .  .  LG .  "

                                        "F2 .  HG .  .  .  "

                                        "F1 E  .  HM .  LM "))

                11))}

  [state]

  (let [done-simple-state (state->simple-state (construct-finished-state state))

        inner-fn (fn [states steps java-memory-map]

                   (println "On step" steps)

                   (println "Number of states" (count states))

                   (let [next-states (->> states

                                          (map (fn [state]

                                                 (->> (get-next-states state)

                                                      (filter (fn [s] (nil? (.get java-memory-map (state->simple-state s))))))))

                                          (flatten))]

                     ;; (println (count next-states)) <- Uncomment this line to change the behavior

                     (if (.get java-memory-map done-simple-state)

                       steps

                       (do (doseq [next-state next-states]

                             (.put java-memory-map (state->simple-state next-state) steps))

                           (recur next-states (inc steps) java-memory-map)))))]

    (inner-fn [state] 0 (java.util.HashMap.))))

When running this in the repl I get the following output:

On step 0

Number of states 1

On step 1

Number of states 1

On step 2

Number of states 3

On step 3

Number of states 11

On step 4

Number of states 14

On step 5

Number of states 22

On step 6

Number of states 37

On step 7

Number of states 48

On step 8

Number of states 35

On step 9

Number of states 22

On step 10

Number of states 17

On step 11

Number of states 7

However, if I uncomment the println statement I get the following output in the REPL:

On step 0

Number of states 1

1

On step 1

Number of states 1

3

On step 2

Number of states 3

11

On step 3

Number of states 11

15

On step 4

Number of states 15

28

On step 5

Number of states 28

63

On step 6

Number of states 63

107

On step 7

Number of states 107

90

On step 8

Number of states 90

82

On step 9

Number of states 82

115

On step 10

Number of states 115

81

On step 11

Number of states 81

110

Please note that "On step 4" prints "Number of states 14" and "Number of states 15"  differently.

Any thoughts?

[Alan Thompson]

Having not gone through your code in detail, I would suggest replacing `map` -> `mapv` to make it an eager operation so that state updates (i.e. `next-states`) occur right away.  The presence of laziness where it is not needed or expected (especially in Java interop code) can cause problems with the (implicit) assumptions of other code.

Alan

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alan Thompson]

Unless prevented by outside considerations, it might also be cleaner/simpler to copy all inputs from Java -> Clojure, do all the algorithm work in Clojure, then copy all outputs back from Clojure -> Java. I'm looking specifically at `java-memory-map`, but would also replace native java stuff like `java.util.HashMap` with Clojure versions whenever possible.  Again, the goal is to avoid clashes in the hidden assumptions of the two models.

Alan

[Leon Grapenthin]

Hi Lucas,

 lazy sequences, as the one produced by the map/filter construct, aren't realized at once. I. e. they are returned as a sequence, but your map and filter lambdas are only invoked once somebody looks at whats in the sequence. Usually, steps are evaluated in chunks of size 32.

Your filter lambda is depending on mutable Java map.

When you count a lazy sequence, all elements are realized. 

So depending on whether you invoke count, the lambda will be invoked with a different version of the Java map.

You should solve this by eliminating the mutable state Java map - it makes your filter lambda impure. Lazy evaluation does not work with impure functions.

I'd recommend to learn about reduce, which will help you to write this much more concisely.

Kind regards, 

 Leon.