[plt-dev] performance-oriented unsafe operations (v4.2.1.8)

Actually, I would probably do what Matthew did and coerce to a float with
exact->inexact, which would error instead of crashing. [Although a complex
value, for example, would get through that and still crash.] But, the idea
of having unchecked/unsafe operations is to ONLY call them when the data has
already been through some contract check already.

On Sat, Oct 3, 2009 at 12:40 PM, Robby Findler
<robby at eecs.northwestern.edu>wrote:

> If the operations in the science collection have the loops inside
> them, then it probably wouldn't hurt to add a check at boundary and
> you can make them safe, even thought the depend on the unsafe
> operations.
>
> Robby
>
> On Sat, Oct 3, 2009 at 11:33 AM, Doug Williams
> <m.douglas.williams at gmail.com> wrote:
> > And, given your post on the JIT optimizations for unsafe operations, I
> can
> > see where they are truly unsafe (in terms of possibly crashing instead of
> > just erroring.) When I make the changes to use the unsafe-fl/unsafe-fx
> > operations, I'll change to using unsafe- as a prefix for the science
> > collection operations.
> >
> > Doug
> >
> > On Sat, Oct 3, 2009 at 10:33 AM, Matthew Flatt <mflatt at cs.utah.edu>
> wrote:
> >>
> >> At Sun, 6 Sep 2009 18:59:01 -0600, Doug Williams wrote:
> >> > Would it be better to call
> >> > the operations 'unchecked-<whatever>' instead of 'unsafe-<whatever>'?
> >> > Generally, we are calling the function because we know it is safe to
> >> > avoid
> >> > some constraint check - not because it is unsafe. Just a nit.
> >>
> >> Despite the distinction between unsafety for performance and unsafety
> >> to get at new things, I like having all unsafe operations marked the
> >> same way. Also, "unchecked" doesn't sound dangerous enough to me.
> >>
> >> So, you make a good point, but I'm still in favor of "unsafe".
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20091003/7cbade95/attachment.html>