dvanhorn

Memoization is fundamentally a top-down computation and dynamic
programming is fundamentally bottom-up.  In memoization, we observe
that a computational *tree* can actually be represented as a
computational *DAG* (the single most underrated data structure in
computer science); we then use a black-box to turn the tree into a
DAG.  But it allows the top-down description of the problem to remain
unchanged.

In dynamic programming, we make the same observation, but construct
the DAG from the bottom-up.  That means we have to rewrite the

ninjudd

fallout:~ master$ time lein version
Leiningen 2.0.0-SNAPSHOT on Java 1.6.0_29 Java HotSpot(TM) 64-Bit Server VM

real	0m2.041s
user	0m5.020s
sys	0m0.189s

fallout:~ master$ time LEIN_JAVA_CMD=decaf lein version
Leiningen 2.0.0-SNAPSHOT on Java 1.6.0_29 Java HotSpot(TM) 64-Bit Server VM

Pet3ris

% Two dices are thrown and the results added up.
% We sample when the sum is conditioned on the first dice landing on 2.

output(S) :-
  randvar(a, dice(X), X),
  dice(Y),
  S is X + Y.

dice(X) :-
  X is random(6) + 1.

dvanhorn

#lang racket

;; 0CFA in the AAM style on some hairy Church numeral churning

;; + compilation phase
;; + lazy non-determinism
;; + specialized step & iterator 0m34.248s vs 0m16.339s
;; + compute store ∆s 0m16.339s vs 0m1.065s (!!!)

;; An Exp is one of:

lynaghk

(rewrite-layer
 {:mapping {:y :mpg}
  :stat (stat/quantiles)})

;; =>

{:mapping {:upper :q75, :min :min, :lower :q25, :max :max, :middle :q50, :y :mpg}
 :stat #com.keminglabs/c2po$stat$quantiles {:dimension :mpg}
 :geom #com.keminglabs/c2po$geom$boxplot {}}

swannodette

;;I'd like to use core.logic to rewrite "colloquial" plot specifications into full, correct specs from which the C2PO compiler can generate graphics.
;;A full C2PO plot spec looks like:

{:data [...] ;;A seq of maps
 :group :identity
 :stat :identity
 :mapping {} ;;A map from a geom's aesthetic to a key in the data maps, e.g., {:x :weight, :y :miles-per-gallon}
 :geom :point
 :scales {} ;;A map of aesthetic keywords to scales, e.g., {:x :linear}
 }

swannodette

--- src/clj/cljs/analyzer.clj	2012-11-17 01:01:55.712323358 -0500
+++ src/cljs/cljs/analyzer.cljs	2012-11-17 11:51:47.030558150 -0500
@@ -6,14 +6,23 @@
 ;   the terms of this license.
 ;   You must not remove this notice, or any other, from this software.
 
-(set! *warn-on-reflection* true)
+;; (set! *warn-on-reflection* true)
 
 (ns cljs.analyzer

lynaghk

;;Support for simple constraints on lvars during unification was added in 76fd4d7c:
;;
;;    https://github.com/clojure/core.logic/commit/76fd4d7c155161d74ad5cd8d87955148eece1fe0
;;
;;but these constraints apply to a single lvar only.
;;The unifier could support more general constraints if it accepted an explicit predicate function.

;;For instance, given this `data-numeric?` predicate and `spec` data:

(defn data-numeric? [data dimension]

daveray

; clojure 1.4.0, core.logic 0.8.0-beta2

user=> (use 'clojure.core.logic)
nil
user=> (defn list?o
        [v]
        (conde
          [(emptyo v)]
          [(fresh [f] (firsto v f))]))
#'user/list?o

jamii

; 'in returns seq
; 'lte returns (reduce join seq)
; 'in? filters by pattern
; 'lte? tests value by lattice ordering
; 'is? matches by pattern (non-monotonic)

; path membership
(d/deduct (in :path [a c])
          (in? :edge [?a ?b])
          (in? :path [?b ?c]))