comp.lang.functional Google Group

Re: real fp vs. scheme/lisp implicit ordering

rao...@gmail.com (raould) — Fri, 12 Dec 2009 00:22:17 UT

[while i (sincerely, as another critic) appreciate you like any chance
to dog haskell, my original point was not about getting side-tracked
into talking about bugs in ghc; note how i never even mentioned
haskell, and was in particular talking about lisps. my point right now
being that i get the feeling it is hard to start up and continue a

Thanks you autror

hylert...@gmail.com (asdasd asdasd) — Wed, 12 Dec 2009 12:16:03 UT

Thanks you autror
[link]
[link]
[link]

Call for Papers: The 2010 International Conference on Computer Graphics and Virtual Reality, USA, July 2010

amgs...@yahoo.com (A. M. G. Solo) — Wed, 12 Dec 2009 05:34:15 UT

It would be greatly appreciated if this announcement could be
shared with individuals whose research interests include
computer graphics and virtual reality. Thanks.
-------
CALL FOR PAPERS
and
Call For Workshop/Session Proposals
CGVR'10

Call for Papers Reminder (extended): International MultiConference of Engineers and Computer Scientists IMECS 2010

imecs_2...@iaeng.org (IMECS 2008) — Tue, 12 Dec 2009 10:22:51 UT

CFP Reminder (extended): International MultiConference of Engineers
and Computer Scientists IMECS 2010
Draft Manuscript submission deadline (extended): 30 December, 2009
Camera-Ready papers & registration deadline: 10 January, 2010
IMECS 2010: 17-19 March, 2010
[link]
All submitted papers will be under peer review and accepted papers

Re: real fp vs. scheme/lisp implicit ordering

j...@ffconsultancy.com (Jon Harrop) — Mon, 12 Dec 2009 22:03:27 UT

In Haskell because the fast solution would be O(n^4) due to that perf bug in
the GC, yes.
I wrote both versions in F#, benchmarked them and assumed the performance
ratio would be similar in Haskell if it could express the programs (i.e. if
that perf bug in the GC were fixed). That seems reasonable because this

Re: real fp vs. scheme/lisp implicit ordering

m...@privacy.net (Florian Kreidler) — Mon, 12 Dec 2009 17:14:24 UT

Jon Harrop <j...@ffconsultancy.com> schrieb:
You said that the straightforward solution was impossible to
implement. And now you have measured it? How did you do that?
That sounds interesting. Is it possible with ordinary STUArrays?

Re: real fp vs. scheme/lisp implicit ordering

j...@ffconsultancy.com (Jon Harrop) — Mon, 12 Dec 2009 17:07:17 UT

4.6x slower according to my measurements.
I have been told before that different threads can already modify separate
subarrays of the same array in Haskell. The person who told me that failed
to provide any working Haskell code though.

Re: real fp vs. scheme/lisp implicit ordering

m...@privacy.net (Florian Kreidler) — Mon, 12 Dec 2009 12:55:22 UT

Jon Harrop <j...@ffconsultancy.com> schrieb:
Maybe, maybe not.
No, fixing that bug will not allow different threads to modify the same
array simultaneously.

Re: real fp vs. scheme/lisp implicit ordering

j...@ffconsultancy.com (Jon Harrop) — Sun, 12 Dec 2009 17:07:08 UT

Easy but can still be several times slower than necessary.
Yes. Better to fix that bug in GHC though...

Re: real fp vs. scheme/lisp implicit ordering

m...@privacy.net (Florian Kreidler) — Sun, 12 Dec 2009 09:30:47 UT

Jon Harrop <j...@ffconsultancy.com> schrieb:
Hold the elements in an immutable boxed array and sort indices
that point into that array. Easy, isn't it?
Yes, just break the mutable array of indices into smaller parts.

Re: real fp vs. scheme/lisp implicit ordering

j...@ffconsultancy.com (Jon Harrop) — Sun, 12 Dec 2009 03:50:25 UT

How? What happens when your user wants to sort strings with your
unboxed-array sort but Haskell's unboxed arrays prohibit string elements?
Can you parallelize it?

Re: real fp vs. scheme/lisp implicit ordering

m...@privacy.net (Florian Kreidler) — Sat, 12 Dec 2009 23:43:04 UT

Jon Harrop <j...@ffconsultancy.com> schrieb:
I have 'implied' to write an all-purpose quicksort. That's quite
easy with an unboxed mutable array.
(It is not so easy to retain the advantages of the 'naive' quicksort
implementation.)
Indeed.

Re: real fp vs. scheme/lisp implicit ordering

j...@ffconsultancy.com (Jon Harrop) — Sun, 12 Dec 2009 01:11:37 UT

The "generic" was the essence of my statement. There are workarounds for
special cases like rolling your own hash table using malloc as Manlio said
or writing a sort that works on specific types as you've implied but these
are obviously undesirable. You want to just write a generic definition,
have it work and get on with your life.

Re: real fp vs. scheme/lisp implicit ordering

m...@privacy.net (Florian Kreidler) — Sat, 12 Dec 2009 20:15:39 UT

Jon Harrop <j...@ffconsultancy.com> schrieb:
I don't want to discuss the meaning of "generic".
But why should boxed mutable arrays be needed for an in-place Quicksort?

Re: real fp vs. scheme/lisp implicit ordering

j...@ffconsultancy.com (Jon Harrop) — Sat, 12 Dec 2009 20:25:37 UT

Johannes made a statement about a special case:
"It is O(1) for unboxed arrays." -
[link]
That does not disprove my statement about the generic case, which was
correct.