<br><div>this is where I've gotten to. <a href="http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=5120#a5120">http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=5120#a5120</a></div><div>strangely enough Ive gotten no speedup at all from the substitution cost UArray (though I had to make it Int, Int to deal with digits.). But still I wonder if there's something else I missed. Im really curious what lazyness you used to go from 60 to 1.6? I always thought lazyness was automatic and seq made strictness possible.</div>
<div>thanks</div><div>Vishnu</div><div><br></div><div class="gmail_quote">On Sat, Nov 28, 2009 at 7:41 AM, Daniel Fischer <span dir="ltr"><<a href="mailto:daniel.is.fischer@web.de">daniel.is.fischer@web.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Am Samstag 28 November 2009 02:04:31 schrieb Daniel Fischer:<br>
<div class="im">> Make it<br>
><br>
> distance orig new = f m n<br>
><br>
> and no thunks need be written at all in this case.<br>
> Cuts down running time by nearly half :)<br>
><br>
> I think you could speed it up significantly by calculating the distance<br>
> more lazily.<br>
<br>
</div>Yup :D<br>
<br>
Timings here:<br>
Your last ByteString code: 128s<br>
That with corrected index calculation: 172s<br>
Correct indices and distance orig new = f m n instead of memf m n: 99s<br>
That and an array for the substitution cost: 64s<br>
<br>
String IO, substitution cost array and a suitably lazy break-early distance function: 1.7s<br>
That and a lazier surcharge function: 1.5s<br>
The same with ByteString IO: 1.4s<br>
<br>
Yes, I'd say that qualifies as a significant speedup.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br>