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

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
>