Thanks for the suggestions.<div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>let's say I want to do a different action for one of three cases.</div><div><br></div><div>(cond (caseA?) (actionA)</div><div> (caseB?) (actionB)</div><div> (caseC?) (actionC))</div>
<div><br></div><div>which is very elegant and clean. This is conceptually how the library should be organized.</div><div><br></div><div>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:</div>
<div><br></div><div><div>(let* ((result.shared-computation (caseAorC?))</div><div> (result (car result.shared-computation))</div><div> (shared-computation (cdr result.shared-computation)))</div><div> (if result</div>
<div> (cond (caseA? shared-computation) (actionA))</div><div> (cond (caseB? shared-computation) (actionB))</div><div> (if (caseC?) (actionC))))</div></div><div><br></div><div>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.</div>
<div> -Patrick</div><div><br><div class="gmail_quote">On Tue, Aug 31, 2010 at 11:43 AM, Neil Van Dyke <span dir="ltr"><<a href="mailto:neil@neilvandyke.org">neil@neilvandyke.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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":<br>
<br>
(matrixy (multiply (transpose A) B))<br>
<br>
If you want something that doesn't require operations to be structured like this syntactically to optimize them, then two more options:<br>
<br>
* 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.<br>
<br>
* Implement a language that translates to Scheme after reasoning about data flow.<br>
<br>
These are off-the-cuff. I'm sure there are more ideas out there.<br><font color="#888888">
<br>
-- <br>
<a href="http://www.neilvandyke.org/" target="_blank">http://www.neilvandyke.org/</a><br>
</font></blockquote></div><br></div>