Yes it did: https://dev.clojure.org/jira/browse/CLJ-2054
On Tuesday, March 6, 2018 at 12:15:26 PM UTC-7, Wes Morgan wrote: > > Did this ticket get created? > > On Monday, November 7, 2016 at 3:26:15 PM UTC-7, Jim foo.bar wrote: >> >> Alright cool, I'll do that tomorrow :) >> >> Thanks, >> >> Dimitris >> >> On 07/11/16 22:07, Alex Miller wrote: >> >> I think it would be reasonable to log a jira enhancement request for the >> spec any? generator to avoid generating double NaNs. >> >> >> On Monday, November 7, 2016 at 12:30:24 PM UTC-6, Jim foo.bar wrote: >>> >>> Hi Alex, >>> >>> Oh yeah I've seen `s/double-in` but as you point out that doesn't help >>> me if I want to :ret spec a function with similar semantics as remove (a fn >>> that transforms a seq given a predicate), which I find a very common >>> indeed. I'm only starting playing with clojure.spec (in fact i've only >>> spec'ed 2 fns so far) and I've not yet had to spec specifically a >>> double-precision number. I have had however the need to spec :any? as >>> ::anything-but-NaN, in both my first 2 specs, so according to my experience >>> this is by no means a rare issue. In fact, looking at clojure.core, most >>> fns operate on seqs, and a good proportion of them processes/transforms a >>> coll according to a predicate/fn. This has nothing to do with doubles or in >>> fact numbers. We can only spec the contents of the collection as `any?` >>> right? anything more specific, and the gen-surface area is reduced. So yeah >>> it's great that we have `s/double-in`, but ideally I'd also like a reliable >>> way to say that the output coll from a fn is equal to the input coll, while >>> having specified the contents of that coll with `any?`, and without having >>> to jump through hoops in the :ret spec. My workaround is actually working >>> nicely for me, and i can certainly live without NaNs in the tests, but it >>> still feels a bit hacky. >>> >>> Thanks, >>> >>> Dimitris >>> >>> On 07/11/16 18:14, Alex Miller wrote: >>> >>> Please also take a look at s/double-in, which allows you to exclude NaN >>> (and Infinity/-Infinity) as valid values. >>> >>> (I realize this does not address the any? question, but that seems like >>> a rarer issue to me than cases where I'm explicitly spec'ing a double but >>> don't want to allow NaN.) >>> >>> On Monday, November 7, 2016 at 11:37:08 AM UTC-6, Jim foo.bar wrote: >>>> >>>> Hi all, >>>> >>>> clojure.spec helped me realise that NaNs totally break [1] equality >>>> (per >>>> `clojure.core/=`). Even though in real production code this might not >>>> be >>>> an issue due to how infrequently one deals with NaNs, but during >>>> gen-testing I've found them extremely annoying, and I've essentially >>>> worked around this by spec-ing things I'd normally specify via `any?`, >>>> via `(s/and any? (complement double-NaN?))` instead. I have to do this >>>> for any spec, where in the :ret spec i need to be able to confirm that >>>> the input coll is equal to the output coll (e.g. `clojure.core/remove` >>>> returns the same coll it was passed in when nothing has been removed), >>>> which is a possibility in a lot of functions. Have other people >>>> encountered this as well, and if yes, how are you guys dealing with it? >>>> Thanks in advance... >>>> >>>> Kind regards, >>>> >>>> Dimitris >>>> >>>> [1]: (= [:a Double/NaN] [:a Double/NaN]) => false >>>> >>>> >>>> >>>> -- >>> 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+u...@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+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >> 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+u...@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+u...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- 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 unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
