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
<[email protected]> 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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
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
____________________
Racket Users list:
http://lists.racket-lang.org/users
