This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-07
Channels
- # aleph (15)
- # beginners (186)
- # boot (11)
- # bristol-clojurians (1)
- # clara (1)
- # cljdoc (2)
- # cljs-dev (5)
- # clojure (57)
- # clojure-austin (1)
- # clojure-dev (87)
- # clojure-italy (7)
- # clojure-spec (5)
- # clojure-uk (56)
- # clojurescript (18)
- # cursive (29)
- # data-science (10)
- # datomic (84)
- # duct (83)
- # figwheel-main (4)
- # fulcro (42)
- # jobs (3)
- # lambdaisland (2)
- # off-topic (28)
- # parinfer (3)
- # portkey (3)
- # re-frame (28)
- # reitit (7)
- # remote-jobs (8)
- # shadow-cljs (29)
- # spacemacs (30)
- # specter (6)
- # sql (8)
- # tools-deps (60)
@alexmiller these got dang markov chain spambots are getting harder to dismiss at a casual glance https://dev.clojure.org/jira/browse/TCHECK-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50481#comment-50481
I spent thousands of milliseconds feeling guilty about test.check not having async support
> The fruition callback must be summoned when all affirmations have run. That sounds fun
agreed
looking forward to figuring out what concepts rich chose these words to describe
@gfredericks Not sure if you are the right person to ask, but thought of you first. Apologies if you have heard the question N times already, and there is a nicely written summary I don't know about. Have you considered changing test.check's default data generators to never generate ##NaN "values", because they are not equal to themselves?
@andy.fingerhut definitely thought about it -- the downside is that you could use that same justification to say it ought to generate NaNs, to expose bugs based on that very edge case
I'd love it to be easier to control; one idea is reforming the generators API so that all generators (at least all the ones that are functions) take a generic opts
parameter that lets options flow down to contained generators, so that you could somehow blanketly {:NaN? false}
OTOH, thinking about this more, do you think it's just an issue with gen/any
in particular?
I think that's the only place that the choice is made for you in a way you can't easily control
The main issue that people have with automatic checking is that any collection that there is a ##NaN buried somewhere inside of is not equal to something that looks like it should be equal. Thus they have to write extra code to generate but then not do = checks on anything with ##NaN inside.
So it might be gen/any
in particular that most people hit that issue with.
I can see people wanting sometimes to opt in to ##NaN, but maybe a default of opting out for gen/any
might be more useful.
it goes counter to the "test.check finds bugs you weren't even thinking of because it defaults to generating all these edge cases" approach
moving toward "test.check finds the bugs you were thinking of and built the generators to find"
Asking on #clojure-spec channel for people's pain points is probably better than asking me, since I'm sure some others who frequent that channel have used property testing in anger much more than I have.
there are softer versions of this in other generators
e.g., should default string generators be full of unicode garbage?
IMO, yes 🙂 But those are = to themselves in Clojure.
in an ideal world, users aren't going to assume that two values are equal to themselves unless they've spec'd things in a way that specifies no NaNs
##NaN might be in a unique position here. Even mutable Java objects are usually = / equals to themselves.
But property-based / generative testing using spec uses = for you, right?
I could be confused on that last statement.
I can't think of how that's true
the last statement I mean
agreed that NaN is unique -- I don't think that contradicts my previous statement
Yeah, I am probably guessing something about the scenarios where others have come across this (that clojure.core/= is involved) when in fact it isn't. Now I'm confused 🙂
I may ask in that channel how it is that others are hitting this ##NaN issue.
I'd guess users of any?
which is probably a lot of people
The part I'd like clarity on (for my understanding) is which step they are doing that checks = on the collections.
it might be more prone to happen when writing your own properties rather than just using spec's automatic properties
Probably hand-written checks of fn return values vs. their args.
yeah I think putting them in map keys can also be weird:
$ clojure -e '(assoc {} [##NaN] 12 [##NaN] 13)'
{[##NaN] 12, [##NaN] 13}
this is a rare case where I think having a dynamic var like *generate-NaNs*
defaulted to false would be a reasonable choice
they are particular weird objects and have caused me to waste far more time than they have saved me
yeah, I don't doubt something along those lines is the right answer; I just feel like the argument from the maximal-mathematical-correctness-and-completeness-and-all-that-nonsense side is undertold and underappreciated
I can see a library dealing with floats/doubles and arrays of them would be the most likely case to want them in there explicitly. Even then they would require custom checking of fn ret values against args, if that spec feature was used.
I mean, I guess another approach would be to change clojure.core/= so that ##NaN was = to itself (quickly ducks for cover)
yeah I was wondering who best to blame in this situation, and that was my best theory 🙂
I don't have a horse in that race -- just calling the race here.
I don't think clojure equality is defined in terms of java equality in such a way that binds it to this behavior; but I generally assume that'd be too maybe-breaking and maybe-enslowening of a change to ever get considered
And anyone who coins words like 'enslowening' might enjoy not only this A Bit of Fry and Laurie sketch, but a bunch of others: https://www.youtube.com/watch?v=Z3515_x8R9c
agreed, hence my ducking for cover in even daring to say such a thing out loud. Come to think of it, there has been a rash recently of bots impersonating long time Slack users and putting words in their mouth they would never ever say.
the pain of NaN with test.check hasn't come up with spec for me, but when using test.check directly. for complicated properties I really like the approach of finding a simplified model of the system being tested and generating operations that are run both against the system being tested and the model, and then the results are compared. for example the model for a distributed key value store might be a hash map. the NaN problem arises at the end when comparing results from the real system and the model
so the system can tolerate NaNs because what it's doing doesn't make equality assumptions, but you can't easily verify the results of things?
yeah, for the key/value store case I think I am using the any-printable generator, and checking at the end that all keys exist in both the hash map and the kv store, and have equal values
seems like an alternate =
that works with NaNs could be a generally useful function
clojure.core/===
, of course
and what I ended up doing, after looking at what I would have to do to replace any-printable was define a custom comparison that looked at the pr-str of the values and returned true if it contained a NaN
(defn === [a b] (or (= a b) (and (re-find #"##NaN" (pr-str a)) (re-find #"##NaN" (pr-str b)))))
@alexmiller do you think such a dynamic var would be read when creating the generator or when generating?
(the fact that the answer's not obvious bothers me, and would be a usability issue regardless of the answer)
What are the trade offs? Make a table
(channeling Rich)
maybe a generic dynamic var like *generator-configuration*
would allow for configuring deeply nested generators without altering the current api
@hiredman do you have an opinion on which time the var would be read?
Strongly tempted to make a table of "channeling Rich" sayings ...
There’s only like 3… - what problem are you trying to solve? - do you have a table of tradeoffs? - where’s the picture of your design?
If it would not be considered offensive or irksome to create such shirts ... That sounds like it might be an interesting little project to create a simple shirt design. 🙂 I would consider adding maybe some things he might not often say, but are great things to keep in mind: "state complects everything it touches"
not sure how Rich would feel about that
FYI, no actual physical shirts have been made yet.
If it turns out he likes the idea and wouldn't mind making a few $$ from it, happy to donate the design to the http://clojure.org Swag shop.
Clojure - The Least Worst Programming Language(TM)
Not really joking there -- one value of a good teacher, and/or books like Polya's "How To Solve It", is to get a person's mind in the habit of asking themselves good questions.
I think creation time makes the most sense, at least for me, a lot use time is inside things like defspec
and I am not even sure what you would put the binding around for use time checking for spec instrumentation
but there are still plenty of wrinkles with creation time, like spec's generators are actually thunks which return generators, so creation time may not be where you would expect
We don't have a predicate for testing a value is ##NaN
?
(and (double? x) (.isNaN x))
... that's probably reflective ... ?
it isn't a matter of testing a scalar, it is a matter of generating some big tree where there is a NaN somewhere in a leaf
Ah, and you need a version of =
to work "automatically" for the whole data structure?
@seancorfield yes, which is also theoretically more useful than changing the generator
is it really true that nobody ever needs to compare data structures with NaNs in them unless they're doing PBT?
If anyone today needs to compare data structures with NaNs in them, like maps, sets, and vectors, then they are today unhappy with clojure.core/= (or they are ok with = returning false when data structures contain one or more NaNs)
or they implemented your proposed === for themselves already
my proposed ===
was a joke; it'd have to be rather more sophisticated
Not sure, but if anyone has done such a thing, I would think core.matrix would have hit this issue, or Dragan with his GPU code.
does core.matrix use a java lib's matrices? if so then they probably already have custom equality baked in
perhaps so. That would make sense for it to do, for performance, but I haven't dug into its code.