Multimethods for sub, add, div, expt need some attention re structures about sicmutils HOT 6 CLOSED

Similarly for the unary functions, trig needs no be implemented

As it should be:

[sicmutils.env] > (- (up 'a 'b))
(up (* -1 a) (* -1 b))

needs implementation

[sicmutils.env] > (sin (up 'a 'b))

IllegalArgumentException No method in multimethod 'sin' for dispatch value: :sicmutils.structure/up  clojure.lang.MultiFn.getFn (MultiFn.java:156)

from sicmutils.

I should add that MIT scmutils does not actually define these generic operations, so if you have any objections, I am happy if they are left out for now, although I think they should be defined since they are simply scalar operations on a vector, albeit a "structure". Someone wanting to get a taster of structures as vectors would find it a whole lot more acceptable if they behaved predictably where one would expect them to do so.

In any case a user could simply

> (apply up (map (partial + 'c) (up 'a 'b)))  ==>  (up (+ c a) (+ c b))
       ;; or
> (vector->up (vec (map (partial + 'c) (up 'a 'b))))

So we are merely saving them the syntactic hassle.

from sicmutils.

I think we're scmutils-compatible here for the moment. My inclination is to leave it alone. (There's a tiny shortcut available, (s/mapr #(+ % 'c) (down 1 2 3)) to get (down (+ c 1) (+ c 2) (+ c 3)) (the advantage of mapr is you don't have to remember to wrap the structure back up after the mapping. Although it is recursive and will flood the operation down to all levels of the struct if it is deeper than a vector. Sometimes you want that, sometimes you don't; I should expose s/map as well). You can save one step in your second example by using (mapv) instead of (vec (map)). Or we could allow the arithmetic operations on things like you suggest. The downside of that is that adding a scalar to a vector might mean you are doing something wrong that you might like to know about rather than be surprised by a complicated expression somewhere down the line. So I lean toward letting the user write one of these snippets if that is what she wants.

from sicmutils.

Another trick from the undocumented realm:

(def u (up 1 2))
(s/same u (map #(+ % 'c) u))

from sicmutils.

OK.
I'll close for now.

from sicmutils.

I think a shimmed definition for map somewhere along these lines would be perfect:

(defn s/map [op struct] (sicmutils.structure/same struct (map op struct)))

Then the user would have both s/map and s/mapr to play with, nice, consistent and easily documentable...
Or you could call it "struct-map" or similar if you don't like "map", although I think "map" is perfect, it extends Clojure's map over sicmutils structures, just as one would expect.

from sicmutils.