Where by "nearly double", of course, I really mean "nearly triple".
I'm a little tired.
David
On Sun, Aug 5, 2012 at 5:37 AM, David Feuer wrote:
> Unfortunately, I doubt it can. That algorithm reduces the number of
> comparisons a good bit, but the asymptotic complexity of its other
> operations
Unfortunately, I doubt it can. That algorithm reduces the number of
comparisons a good bit, but the asymptotic complexity of its other
operations remains the same, with apparently bad constant factors
(according to the article). Also, that article describes the algorithm
in terms of sorting [a+b| a
Hi David,
can this help you?
http://www.scribd.com/doc/81029312/5/Sorting-pairwise-sums
Heinrich
Am 04.08.2012 20:47, schrieb David Feuer:
I realized my algorithm is insane. The correct way to sort [a*b|a<-A,
b<-B] is clearly to sort A and B, then for each a in A construct
either map (a*) B
I realized my algorithm is insane. The correct way to sort [a*b|a<-A, b<-B]
is clearly to sort A and B, then for each a in A construct either map (a*)
B or map (a*) (reverse B), depending on the sign of a, then merge all these
results together with a merge that collapses duplicates. I was multiplyi
It's generally not advisable to use Data.List for performance-sensitive
parts of an application.
Try using Data.Vector instead: http://hackage.haskell.org/package/vector
On Sat, Aug 4, 2012 at 11:23 AM, David Feuer wrote:
> I'm writing a toy program (for a SPOJ problem--see
> https://www.spoj.p
I'm writing a toy program (for a SPOJ problem--see
https://www.spoj.pl/problems/ABCDEF/ ) and the profiler says my
performance problem is that I'm spending too much time sorting. I'm
using Data.List.sort on [Int32] (it's a 32-bit architecture). Others,
using other languages, have managed to solve t
