[racket] Inconsistency of `in-range` and numerical issues

In addition to Sam's suggestion: add an in-float-range.

/Jens Axel


2015-02-27 14:39 GMT+01:00 Sam Tobin-Hochstadt <samth at cs.indiana.edu>:
> At a minimum, we could (a) log a warning and (b) put a note in the
> docs suggesting that people use Neil's library for floats.
>
> Sam
>
> On Fri, Feb 27, 2015 at 8:33 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> Should we consider making in-range signal an error for floats? I guess
>> backwards compatibility says "no" but maybe in a future racket? With a note
>> in the error message that points people in the right direction?
>>
>> Robby
>>
>>
>> On Friday, February 27, 2015, Konrad Hinsen <konrad.hinsen at fastmail.net>
>> wrote:
>>>
>>> On 26/02/2015 15:13, Neil Toronto wrote:
>>>
>>>> The second alternative is a little harder to get right because of
>>>> fencepost errors [1]. Fortunately, Racket has a library function for it.
>>>> Unfortunately, it's buried in `plot/utils`. Here it is in action:
>>>>
>>>>  > (require (only-in plot/utils linear-seq))
>>>>
>>>>  > (linear-seq 0.0 1.0 4)
>>>> '(0.0 0.3333333333333333 0.6666666666666666 1.0)
>>>
>>>
>>> That's the best solution in my opinion.
>>>
>>>> I should really move this function into `math/base`.
>>>
>>>
>>> Yes!
>>>
>>>> If you must use a flonum step size, do something like this:
>>>>
>>>>    (define (flonum-range start end step)
>>>>      (define n (exact-ceiling (/ (- end start) step)))
>>>>      (for/list ([i  (in-range 0 n)])
>>>>        (+ start (* i step))))
>>>>
>>>> To get points with 0.5 ulp error each, which is the best you can do, add
>>>> (require math/flonum) to your program and change the loop body to (flfma
>>>> step (fl i) start).
>>>>
>>>> Arguably, `in-range` should do something like the above when given
>>>> floating-point step lengths. I don't know how feasible that is, though.
>>>
>>>
>>> It would obviously break backward compatibility. And it would complicate
>>> the rather simple mental model one can have of in-range.
>>>
>>> More fundamentally, I am not sure it would be much of an advantage. Think
>>> of the two kinds of users:
>>>
>>> 1) Those who are not aware of the problem. They will still fall into the
>>> trap, only a bit later, and the cause of the problem will be even more
>>> hidden. It's a bit like languages that do decimal rounding of float output.
>>>
>>> 2) Those who are aware of the problem. They would use linear-seq, but
>>> might prefer the modified in-range in specific situations for compactness.
>>>
>>> I suspect group 1) is the bigger one, so the most important measure is to
>>> promote linear-seq instead of in-range for floats.
>>>
>>> Konrad.
>>>
>>> ____________________
>>>  Racket Users list:
>>>  http://lists.racket-lang.org/users
>>
>>
>> ____________________
>>   Racket Users list:
>>   http://lists.racket-lang.org/users
>>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users



-- 
--
Jens Axel Søgaard