How would I create a BigDecimal generator?

Is there a good workaround for keeping NaN out of your spec-generated test data? Filtering at the top level doesn't keep them out of nested data structures, and they break all kinds of equality tests when they show up.

@cap10morgan I thought the double-in generator had options to suppress that?

I'm working with any?

Ah, then you'll get "anything" 🙂

yep. there just doesn't seem to be a way to define any-but-nan. my code handles NaNs just fine, it's the specs that barf on them (since the equality tests in my predicates choke on them).

makes spec'ing fns that can handle any value tricky

I have tested it locally and it seems to solve the problem.

this is a sticky issue because merely removing NaN from everywhere isn't obviously the best thing, since NaN is an important edge case to test in a lot of situations

it's obviously hard to opt-out of at the moment

Agreed but the concept of removing it from the any? generator seemed at least tacitly endorsed by the core team.

If they instead requested a way to toggle it, I’d be happy to work on that too.

pedantically, if you accept any value, you better do the right thing if the value is NaN right?

Yes. And the code does. Only the spec has a problem. And it is not easy to work around.

(In my use case)

A NaN at any level of nesting blows up equality checks in predicates.

and you said your code gracefully handles that, right?

> do the right thing if the value is NaN right?

Yes, the code handles it just fine.

It’s not doing any equality checking.

I think my ideal solution might be a spec-specific equality function that handled NaN, but I don't know where the core team stands on that.

Just driving by here - would much rather prevent the NaN from occurring in the first place. Custom equality has never gone well imho :)

@alexmiller That's fair. 🙂 Does that patch ^^^ seem OK to attach to the JIRA ticket?

No time to look atm but it’s ok either way :)

OK, attaching it then.

the downside to that is that the list of generators that gen/any is composed of is now in two places

@gfredericks Not sure I follow. Where are the 2 places?

Didn't you paste & tweak that code from test.check?

yes, but it is the one and only code for the any? generator now. and test.check itself largely repeats that one-of form between the any and any-printable generators.

Yes, I was pointing out that if test.check added anything to its gen/any, that wouldn't propogate to spec anymore

If test.check defined the vector separately I definitely would have just re-used it though. Not sure there's a good way to re-use it as is.

Probably not

Even if test.check changed you couldn't take advantage of that without introducing a stricter version requirement between the two. I'm not sure if that's acceptable or not

Not