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 clojure@googlegroups.com
    <mailto: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
    <mailto:clojure+unsubscr...@googlegroups.com>
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
    <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
    <mailto:clojure+unsubscr...@googlegroups.com>.
    For more options, visit https://groups.google.com/d/optout
    <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 <mailto:clojure+unsubscr...@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.

Reply via email to