[racket-dev] nan?, infinite? and regular-real? [Was: Latest Plot Package]

On 11/18/2011 12:34 PM, Neil Toronto wrote:
> On 11/18/2011 12:22 PM, Ryan Culpepper wrote:
>> On 11/18/2011 12:13 PM, Neil Toronto wrote:
>>> I've moved this to dev from a private discussion with Doug, who has just
>>> tried the nightly build.
>>>
>>> On 11/18/2011 11:43 AM, Williams, Doug wrote:
>>>> 2) The plot/utils has nan? and infinite?, which are also exported from
>>>> the science collection and I had to explicitly exclude them in the
>>>> require. Can we talk to the powers that be and see about getting them
>>>> (and finite?) moved to racket/math? Then we can both remove them from
>>>> our code. [I'm not sure about any interaction with the r6rs functions.]
>>>
>>> Powers That Be, Doug and I would like `nan?' and `infinite?' to be in
>>> `racket/math'.
>>>
>>> I made an exact equivalent of Doug's `finite?', but called it
>>> `regular-real?'. I use it in all kinds of function contracts (it returns
>>> #f for non-reals). We would also like that one, with either name, in
>>> `racket/math'.
>>
>> How does 'finite?' differ from 'rational?'?
>
> Whoa! It doesn't!
>
>> If we're making a wishlist, I'd really like
>> '{positive,nonnegative}-{real,rational}?'.
>
> For use or for contracts? For contracts, we already have `>/c', `</c',
> `>=/c' and `<=/c', which can do the same as `positive-real?',
> `negative-real?', `nonnegative-real?' and `nonpositive-real?' if applied
> to 0, and are arguably easier to read.

I'd argue that they're less easy to read. Also, despite their 
availability, I've still seen contracts that say 'real?' even when they 
mean '(>=/c 0)', etc. (Or possibly 'nonnegative-rational?'.)

> For the `*-rational?' ones, would they identify only exact rationals?
> Because that would be inconsistent with `rational?'.

No, they should be consistent with 'rational?' and accept inexacts.

> If we *are* making a wishlist, I'd like to add exact-round, exact-floor,
> exact-truncate and exact-ceiling. I rarely need to chop off fractional
> parts without also making the result exact.

+1

Ryan