[racket] Optimizations at the library level.

From: Patrick Li (patrickli.2001 at gmail.com)
Date: Tue Aug 31 16:01:15 EDT 2010

Thanks for the suggestions.
I'm interested in the suggestion about reasoning about data flow actually.
I'm interested in a systematic way for users to program these optimizations.
Do you know of any readings that might be helpful to me?

I presented the matrix problem as an example, but here's another example of
(what I think) is an optimization that should be handled by the implementor,
and should not be a concern of the user.

let's say I want to do a different action for one of three cases.

(cond (caseA?) (actionA)
         (caseB?) (actionB)
         (caseC?) (actionC))

which is very elegant and clean. This is conceptually how the library should
be organized.

But let's say, that (caseA) and (caseC) just happen to have some
computations that they can share, so that it's a waste to evaluate them
twice. Then to take advantage of that, the user must do something like this:

(let* ((result.shared-computation (caseAorC?))
       (result (car result.shared-computation))
       (shared-computation (cdr result.shared-computation)))
  (if result
      (cond (caseA? shared-computation) (actionA))
      (cond (caseB? shared-computation) (actionB))
      (if (caseC?) (actionC))))

My personal opinion is that optimization isn't so terrible because it messes
up the code. It's terrible because it mangles how the user interacts with
the library.

On Tue, Aug 31, 2010 at 11:43 AM, Neil Van Dyke <neil at neilvandyke.org>wrote:

> One option is to define a 'minilanguage' for matrix manipulations, and
> implement it as a new bit of syntax that you can implement with
> "syntax-rules" or "syntax-case":
> (matrixy (multiply (transpose A) B))
> If you want something that doesn't require operations to be structured like
> this syntactically to optimize them, then two more options:
> * Make your matrix objects be 'lazy' about the operations.  So, for
> example, instead of actually performing the transpose, you represent the
> input to the transpose and the fact that a transpose operation should be
> applied.  Then you represent that a multiply should be applied.  Then, when
> you finally want access actual numbers within a matrix object, you see the
> sequence of transformations at once and can choose an efficient algorithm.
>  The user of the matrix object does not need to know that this is happening.
> * Implement a language that translates to Scheme after reasoning about data
> flow.
> These are off-the-cuff.  I'm sure there are more ideas out there.
> --
> http://www.neilvandyke.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20100831/0afc2d6f/attachment.html>

Posted on the users mailing list.