[racket] Plot is voracious

Based on experience using Plot, I believe allowing all errors is a 
terrible default.

Jay's suggestion would make it easier to ignore only some errors, 
especially if it were a parameter. I could see doing

   (plot-swallow-exception? exn:fail:contract:divide-by-zero?)

To make it as backwards-compatible as possible while being precise, it 
would be nice if it could swallow only math domain errors by default. 
But again, there's no way to distinguish those from other errors.

Is there a problem with adding `exn:fail:contract:math` and making 
`exn:fail:contract:divide-by-zero` a subtype?

Neil ⊥

On 05/21/2014 11:25 AM, Jay McCarthy wrote:
> Or
>
> #:catch-these-exns-plot! [catch-exn? void]
>
> Jay
>
> On Wed, May 21, 2014 at 11:22 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> How about adding yet another argument to plot #:errors-go-to-nan or
>> something like that, such that plot's default behavior is to let the
>> errors thru, but that, if you turn that flag on, then it just swallows
>> all errors?
>>
>> Robby
>>
>> On Wed, May 21, 2014 at 12:18 PM, Neil Toronto <neil.toronto at gmail.com> wrote:
>>> Division by zero and other math domain errors, primarily. There are two good
>>> reasons to ignore these.
>>>
>>> 1. Plotting is for visualizing functions. Users shouldn't have to ensure to
>>> Plot that the function they're plotting is total when all they want is to
>>> *see* it, not use it for some critical calculation.
>>>
>>> More concretely, raising all exceptions means that this:
>>>
>>>    (plot3d (surface3d / -1 1 -1 1))
>>>
>>> has to be this instead:
>>>
>>>    (plot3d (surface3d
>>>             (λ (x y) (with-handlers ([exn?  (λ (e) +nan.0)])
>>>                        (/ x y)))
>>>             -1 1 -1 1))
>>>
>>> or it has to use an explicit domain test (i.e. test (= y 0)). That's a lot
>>> of work just to visualize the division function.
>>>
>>> 2. Plotting necessarily approximates. Plot's behavior should be as
>>> consistent as possible regardless of exactly how it approximates.
>>>
>>> Currently, plotting the division function in any subdomain or with any
>>> sampling interval just works. Suppose Plot allowed errors to be raised. Then
>>> this would plot just fine:
>>>
>>>    (plot3d (surface3d / -2 1 -2 1))
>>>
>>> because sampling 41 points (the default) within [-2,1] skips over 0. But
>>> this would raise an error:
>>>
>>>    (plot3d (list (surface3d / -2 1 -2 1)
>>>                  (surface3d + -1 2 -1 2)))
>>>
>>> because the bounds are extended to [-2,2]x[-2,2] accommodate the `+` surface
>>> renderer, so 0 would be sampled.
>>>
>>> ----
>>>
>>> In a sense, what I really want is impossible. With any exception-swallowing
>>> rule I make, someone could write a function that raises an exception that
>>> Plot eats when it shouldn't, or re-raises when it shouldn't. Someone could
>>> try plotting a function that, for some reason, tries to compute (gamma 0) if
>>> a `vector-ref` goes out of bounds.
>>>
>>> But I think it could behave properly in the most common cases if it were
>>> possible to tell the difference between the errors raised by (gamma 0) and
>>> (vector-ref vs (length vs)). Right now, there's no way to do that.
>>>
>>> Neil ⊥
>>>
>>>
>>> On 05/21/2014 10:16 AM, Robby Findler wrote:
>>>>
>>>> I meant to suggest that plot should raise any error that a function it
>>>> calls raises. Is there something wrong with doing that?
>>>>
>>>> Robby
>>>>
>>>> On Wed, May 21, 2014 at 11:09 AM, Neil Toronto <neil.toronto at gmail.com>
>>>> wrote:
>>>>>
>>>>> Referencing an identifier before its definition raises an
>>>>> `exn:fail:contract:variable`. So that would put Plot in the weird
>>>>> position
>>>>> of having to distinguish different kinds of contract errors, but not by
>>>>> using subtypes or any other simple rule.
>>>>>
>>>>> Maybe we should have an `exn:fail:contract:math` or
>>>>> `exn:fail:contract:domain` or `exn:fail:contract:argument` and make
>>>>> `exn:fail:contract:divide-by-zero` a subtype of it. I'd gladly change
>>>>> Plot
>>>>> to ignore just those, and change the math library to raise more specific
>>>>> errors.
>>>>>
>>>>> (log 0) raises an `exn:fail:contract:divide-by-zero`, which is a
>>>>> terminology
>>>>> stretch that suggests we need a bit of refactoring anyway.
>>>>>
>>>>> Neil ⊥
>>>>>
>>>>>
>>>>> On 05/21/2014 09:51 AM, Robby Findler wrote:
>>>>>>
>>>>>>
>>>>>> IMO, plot should raise that exception.
>>>>>>
>>>>>> Robby
>>>>>>
>>>>>> On Wed, May 21, 2014 at 10:37 AM, Laurent <laurent.orseau at gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> ... it eats everything! (particularly exceptions)
>>>>>>> For example, it is perfectly happy with the following:
>>>>>>>
>>>>>>> % racket
>>>>>>> Welcome to Racket v6.0.1.7.
>>>>>>>>
>>>>>>>>
>>>>>>>> (require plot)
>>>>>>>> (plot (function (lambda(x)(+ x n)))
>>>>>>>
>>>>>>>
>>>>>>>      #:x-min 0 #:x-max 10 #:y-min 0 #:y-max 10)
>>>>>>> (object:2d-plot-snip% ...)
>>>>>>>
>>>>>>> ... although n is clearly undefined. Presumably this is to avoid
>>>>>>> breaking
>>>>>>> on
>>>>>>> math errors like `(/ 0)` ?
>>>>>>>
>>>>>>> Would it make sense to have an `exn:fail:arithmetic` exception struct
>>>>>>> so
>>>>>>> that `function` would only catch those?
>>>>>>>
>>>>>>> Laurent
>>>>>>>
>>>>>>>
>>>>>>> ____________________
>>>>>>>      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
>>>
>>>
>>
>> ____________________
>>    Racket Users list:
>>    http://lists.racket-lang.org/users
>
>
>