Re: Transitive spec generation

-extension ::extension) > (s/def ::client-extension ::extension) > > I'm doing this in an attempt to trying to reduce my nesting levels. > > This is what the weird subject is about: I'm trying to take advantage of > the transitive property of specs. > > > >> but when

Re: Transitive spec generation

::server-extension ::extension) (s/def ::client-extension ::extension) I'm doing this in an attempt to trying to reduce my nesting levels. This is what the weird subject is about: I'm trying to take advantage of the transitive property of specs. > but when you run test.check, it seems t

Re: Transitive spec generation

ust in case), I usually get > the "Couldn't satisfy such-that predicate after 100 tries." > > To be a little more specific about this: > > Calling (manual-check) failed 49/50 times. > > Calling (transitive-indirect) passed 50 times in a row. If you haven't > bother

Re: Transitive spec generation

and the boot CLI, just in case), I usually get the "Couldn't satisfy such-that predicate after 100 tries." To be a little more specific about this: Calling (manual-check) failed 49/50 times. Calling (transitive-indirect) passed 50 times in a row. If you haven't bothered looking at the

Transitive spec generation

I have a spec for an array of 16 bytes: (s/def ::extension (s/and bytes? #(= (count %) 16)) Then I have a couple of other specs that are really just renaming it: (s/def ::client-extension ::extension) (s/def ::server-extension ::extension) I started doing

Re: :npm-deps and transitive dependencies

in the project X builds. This is not > very elegant since the union of all dependencies now cascade to the top > level projects. Also, this approach would fail when transitive dependencies > need different versions of the same dependency. > 2) Compile Y into a bundle. Then

Re: :npm-deps and transitive dependencies

s now cascade to the top > level projects. Also, this approach would fail when transitive dependencies > need different versions of the same dependency. > 2) Compile Y into a bundle. Then X would depend on the prebuilt bundle of > Y (which already includes Z). This is not perfect sinc

:npm-deps and transitive dependencies

all dependencies now cascade to the top level projects. Also, this approach would fail when transitive dependencies need different versions of the same dependency. 2) Compile Y into a bundle. Then X would depend on the prebuilt bundle of Y (which already includes Z). This is not perfect si

Re: Clojure CLI tool fails to resolve weird transitive dependencies.

Yep, that looks like what I'm seeing. Thanks! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To

Re: Clojure CLI tool fails to resolve weird transitive dependencies.

Hm, looks like this is an open issue: https://dev.clojure.org/jira/browse/TDEPS-12 -- David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are

Re: Clojure CLI tool fails to resolve weird transitive dependencies.

Ha, I think that must’ve snuck in there during editing. Fixing that particular typo didn’t help any. :D > On Dec 11, 2017, at 12:22 PM, David Bürgin wrote: > > On 11/12/17 20:47, Jonathan Fischer wrote: >> com.badlogicgames.gdx/gdx {:mvn/versin "1.9.6"} > > Typo? > > > --

Re: Clojure CLI tool fails to resolve weird transitive dependencies.

On 11/12/17 20:47, Jonathan Fischer wrote: > com.badlogicgames.gdx/gdx {:mvn/versin "1.9.6"} Typo? -- David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new

Clojure CLI tool fails to resolve weird transitive dependencies.

I apologize, I'm not certain of the right name for this. I'm pulling in libgdx and its dependencies. In Leiningen, my dependencies vector looks like this: :dependencies [[org.clojure/clojure "1.8.0"] [com.badlogicgames.gdx/gdx "1.9.6"]

core.logic - explaining transitive relationships

Hello, With the code below you can query transitive relationships between entities successfully. Is there any way to use core.logic explain the relationship? Specifically, is there any way to write a function explain so that: (explain :pitbull :chordate) will give you: [:pitbull :dog

Re: core.logic - explaining transitive relationships

Stathis Sideris side...@gmail.com writes: Hi Stathis, With the code below you can query transitive relationships between entities successfully. Is there any way to use core.logic explain the relationship? Specifically, is there any way to write a function explain so that: (explain :pitbull

Re: core.logic - explaining transitive relationships

. However the following simple solution should give you some ideas: (defrel is-a Entity Parent) (fact is-a :pitbull :dog) (fact is-a :dog :mammal) (fact is-a :mammal :chordate) (fact is-a :chordate :animal) (defn transitive [r] (fn t ([x z] (t x z (lvar))) ([x z path

Re: core.logic - explaining transitive relationships

Thanks for this. I didn't think about that! On Tuesday, 18 December 2012 15:51:55 UTC, Tassilo Horn wrote: Stathis Sideris sid...@gmail.com javascript: writes: Hi Stathis, With the code below you can query transitive relationships between entities successfully. Is there any way to use

Re: core.logic - explaining transitive relationships

;; there is a transitive relationship between x z if there is a ;; relationship between x some y and some y z (defn transitive [r] (fn t ;; if passed only two args create the path logic var ([x z] (t x z (lvar))) ;; take an x, z, and a path from x to z ([x z path

Re: == is not transitive?

On Friday, October 5, 2012 7:17:50 PM UTC+2, Ben wrote: I'm not sure what you mean by this. Transitivity means that for all x, y, and z, (Fxy Fyz) = Fxz. But there are values of x, y, and z for which that does not hold. Yeah, sorry. What I meant was that == is only commutative if you

Re: == is not transitive?

On Friday, October 5, 2012 2:39:05 AM UTC+2, Ben wrote: user [(== 0 0.0) (== 0.0 0.0M) (== 0.0M 0)] [true true false] When passing two arguments to ==, == will be transitive. user [(== 0 0.0 0.0M) (== 0 0.0M 0.0) (== 0.0 0 0.0M) (== 0.0 0.0M 0) (== 0.0M 0.0 0) (== 0.0M 0 0.0

Re: == is not transitive?

On Fri, Oct 5, 2012 at 11:08 AM, Jean Niklas L'orange jeann...@hypirion.com wrote: On Friday, October 5, 2012 2:39:05 AM UTC+2, Ben wrote: user [(== 0 0.0) (== 0.0 0.0M) (== 0.0M 0)] [true true false] When passing two arguments to ==, == will be transitive. user [(== 0 0.0 0.0M) (== 0

Re: == is not transitive?

I was bitten by this a year ago and posted here: http://groups.google.com/group/clojure/browse_frm/thread/9091ad790fc96b24 My workaround is to call BigDecimal#stripTrailingZeros before passing it to code that might compare it to some other number. user (== 1 (.stripTrailingZeros 1.0M)) true

Re: == is not transitive?

On Fri, Oct 5, 2012 at 2:08 AM, Jean Niklas L'orange jeann...@hypirion.com wrote: On Friday, October 5, 2012 2:39:05 AM UTC+2, Ben wrote: user [(== 0 0.0) (== 0.0 0.0M) (== 0.0M 0)] [true true false] When passing two arguments to ==, == will be transitive. I'm not sure what you mean

== is not transitive?

user [(== 0 0.0) (== 0.0 0.0M) (== 0.0M 0)] [true true false] user [(== 0 0.0 0.0M) (== 0 0.0M 0.0) (== 0.0 0 0.0M) (== 0.0 0.0M 0) (== 0.0M 0.0 0) (== 0.0M 0 0.0)] [true false false false true false] -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be

Re: == is not transitive?

The only reason for this that I can think of is incomplete rules for casting numbers. On Thursday, 4 October 2012 20:39:05 UTC-4, Ben wrote: user [(== 0 0.0) (== 0.0 0.0M) (== 0.0M 0)] [true true false] user [(== 0 0.0 0.0M) (== 0 0.0M 0.0) (== 0.0 0 0.0M) (== 0.0 0.0M 0) (== 0.0M 0.0 0)

Re: == is not always transitive

false 1.00M == 1.0M false 1.00M == 1.00M true I propose we change the method to be: public boolean equiv(Number x, Number y){ return toBigDecimal(x).compareTo(toBigDecimal(y)) == 0; } This makes the previous expression return all true, and == should also be transitive. In particular, (== 1.0M

Re: == is not always transitive

Leif leif.poor...@gmail.com writes: I'd also like to make sure people are aware of this oddity. I discovered this after reading an article about the bad design of PHP. I read that in PHP, == is not transitive. I thought Ha ha ha, that ridiculous PHP! Then I checked c.c/== ; Imagine my

Re: == is not always transitive

Yes, that is one reason why I tend to use BigDecimal instead of float or double. The thing that seems wrong to me is (not (== 1 1.0M)), since these are both exact representations of the value one and the doc for == says that it tests for equivalent value (type- independent). On Apr 11, 10:00 pm,

Re: == is not always transitive

I'd also like to make sure people are aware of this oddity. I discovered this after reading an article about the bad design of PHP. I read that in PHP, == is not transitive. I thought Ha ha ha, that ridiculous PHP! Then I checked c.c/== ; Imagine my reaction when I learned that Clojure

Re: == is not always transitive

IME, it's almost never useful to perform equality tests on floating point values. Generally you want to know if they're near enough to one another without necessarily being exactly equal. For that something like (defn f= [f1 f2 threshold] ( (Math/abs (- f1 f2)) threshold)) is probably the sort of

Re: == is not always transitive

On Wed, Apr 11, 2012 at 5:46 PM, Leif leif.poor...@gmail.com wrote: Then I checked c.c/== ;  Imagine my reaction when I learned that Clojure had something in common with PHP.  o_O,  :'[ It's instructive to look at the result of: (let [ones [1 1.0 1N 1M 1.0M] ] (for [a ones b ones] (== a b)))

== is not always transitive

Greetings, I think that I've encountered a bug in ==. user= (and (== 1 1.0) (== 1.0 1.0M) (not (== 1 1.0M))) true This happens with 1.2.1 and 1.3-beta2. I think it has to do with the precision of the BigDecimal. user= (== 1 1.0M) false user= (== 1 1M) true I think a solution would be to use