I had expected flvectors to be more efficient at the time, too. And was surprised when they weren&#39;t. But I did have the wrong mental model of flvector versus fl64vector. Thanks for explaining it.<br><br><div class="gmail_quote">
On Mon, May 17, 2010 at 3:36 AM, Noel Welsh <span dir="ltr">&lt;<a href="mailto:noelwelsh@gmail.com">noelwelsh@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Mon, May 17, 2010 at 4:22 AM, Doug Williams<br>
&lt;<a href="mailto:m.douglas.williams@gmail.com">m.douglas.williams@gmail.com</a>&gt; wrote:<br>
&gt; 1) Would we expect the flvector (or fl64vector) implementations to be more<br>
&gt; efficient now? Or, at sometime in the (near) future?<br>
<br>
</div>That&#39;s odd. I would expect flvectors to be more efficient than vectors of reals.<br>
<div class="im"><br>
&gt; 2) I assume flvectors are 32-bit floats and fl64vectors are 64-bit floats.<br>
&gt; Is this correct? Is there any significant difference in efficiency of one<br>
&gt; over the other - particularly wrt unsafe operations?<br>
<br>
</div>flvectors are doubles -- they store inexact reals, which by default<br>
are doubles (64-bits) but can be floats (32-bits) if you compile<br>
MzScheme with the right flags. flvectors should be faster than<br>
fl64vectors -- they avoid an indirection according to the docs.<br>
<br>
HTH,<br>
<font color="#888888">N.<br>
</font></blockquote></div><br>