Re: Data.FiniteMap
On Wed, Sep 20, 2006 at 02:54:57PM +0200, Christian Maeder wrote: > This patch does not have the functions: >foldFM_GE, fmToList_GE, keysFM_GE, eltsFM_GE, >foldFM_LE, fmToList_LE, keysFM_LE, eltsFM_LE, It should be quite easy to do with split or splitLookup. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.FiniteMap
I've copied the old code from Data.FiniteMap and only implemented: foldFM_LE f v k = Map.foldWithKey (\ i w c -> if i > k then c else f i w c) v Christian Maeder schrieb: > Malcolm Wallace schrieb: >>> I think there is a wrapper somewhere that provides the old >>> Data.FiniteMap in terms of the Data.Map implementation. >> Darcs patch attached, if it is of interest. > > This patch does not have the functions: >foldFM_GE, fmToList_GE, keysFM_GE, eltsFM_GE, >foldFM_LE, fmToList_LE, keysFM_LE, eltsFM_LE, > > Currently I need to replace fmToList_LE and keysFM_LE. Does someone have > code for these (in terms of Data.Map)? > > Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.FiniteMap
Malcolm Wallace schrieb: >> I think there is a wrapper somewhere that provides the old >> Data.FiniteMap in terms of the Data.Map implementation. > > Darcs patch attached, if it is of interest. This patch does not have the functions: foldFM_GE, fmToList_GE, keysFM_GE, eltsFM_GE, foldFM_LE, fmToList_LE, keysFM_LE, eltsFM_LE, Currently I need to replace fmToList_LE and keysFM_LE. Does someone have code for these (in terms of Data.Map)? Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.FiniteMap
Duncan Coutts <[EMAIL PROTECTED]> wrote: > Is it too late to ask that Data.FiniteMap not die just yet? FWIW, I'm in favour of retaining Data.FiniteMap for ghc-6.6, to be removed only in 6.8. > There are a number of progs/libs that this affects. It's not that > people do not want to use the new Data.Map, but people are worried > about having to drop support for earlier compilers. I'll add my support to this argument. > I think there is a wrapper somewhere that provides the old > Data.FiniteMap in terms of the Data.Map implementation. Darcs patch attached, if it is of interest. Regards, Malcolm 20060904134021-6871e-359d97db8563acc3a2868666494b8f52a9c3a7f1.gz Description: Binary data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.FiniteMap
On Mon, Sep 04, 2006 at 02:32:34PM +0200, Duncan Coutts wrote: > > * 6.4.1 is not even marked stable in debian yet (only 6.2.2 is > stable) Debian doesn't have a concept of "marked stable". 6.4.1 didn't exist when sarge was released, so it has not yet had a chance to be included in a stable release. FWIW, I'm in favour of removing FiniteMap. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.FiniteMap
On Mon, 2006-09-04 at 14:06 +0200, Duncan Coutts wrote: > Is it too late to ask that Data.FiniteMap not die just yet? > > There are a number of progs/libs that this affects. It's not that people > do not want to use the new Data.Map, but people are worried about having > to drop support for earlier compilers. Data.Map only appeared in 6.4 > iirc. So this forces packages to drop support for 5.04, 6.0 and 6.2. > Perhaps 5.04 and 6.0 are not so important, but many people still use > 6.2.2, particularly institutions, which tend to be slow to upgrade. Just a couple other data points: * 6.4 was never stable * 6.4.1 is not even marked stable in debian yet (only 6.2.2 is stable) * 6.4.1 was only marked stable in gentoo in March of this year (6.4.2 was marked stable in August) It's true that packages could use an external compat Data.FiniteMap but that causes problems too of course. The Cabal conditional configurations feature is not available yet. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.FiniteMap
I would advise against using a wrapper, because that will probably change the behaviour of FiniteMap in subtle ways (recall the left-bias stuff), laying the pavement for future headaches. Cheers, JP. On 9/4/06, Duncan Coutts <[EMAIL PROTECTED]> wrote: Is it too late to ask that Data.FiniteMap not die just yet? There are a number of progs/libs that this affects. It's not that people do not want to use the new Data.Map, but people are worried about having to drop support for earlier compilers. Data.Map only appeared in 6.4 iirc. So this forces packages to drop support for 5.04, 6.0 and 6.2. Perhaps 5.04 and 6.0 are not so important, but many people still use 6.2.2, particularly institutions, which tend to be slow to upgrade. I think there is a wrapper somewhere that provides the old Data.FiniteMap in terms of the Data.Map implementation. Could we use something like that in base for at least one more release? By the time of 6.8 I think people will be less concerned as 6.2 will be quite old by that time. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Data.FiniteMap
Is it too late to ask that Data.FiniteMap not die just yet? There are a number of progs/libs that this affects. It's not that people do not want to use the new Data.Map, but people are worried about having to drop support for earlier compilers. Data.Map only appeared in 6.4 iirc. So this forces packages to drop support for 5.04, 6.0 and 6.2. Perhaps 5.04 and 6.0 are not so important, but many people still use 6.2.2, particularly institutions, which tend to be slow to upgrade. I think there is a wrapper somewhere that provides the old Data.FiniteMap in terms of the Data.Map implementation. Could we use something like that in base for at least one more release? By the time of 6.8 I think people will be less concerned as 6.2 will be quite old by that time. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] performance tuning Data.FiniteMap
Hi Simon! On Fri, Feb 27, 2004 at 09:20:40AM -, Simon Peyton-Jones wrote: > There are several things that aren't research issues: notably, faster > copying, fewer intermediate lists, fewer state-monad-induced > intermediate closures. These are things that would move sharply up our > priority list if you had a real application that was stumbling on them. From the context, it is not clear to me, if you are writing about arrays or FiniteMap. Regarding FiniteMap: I would want it to be as good as possible and advertised more. If you see how pervasive dictionarys are eg in Python, finite maps should be our counterpart, and they should be so good that nobody would ever think about using a plain list for storing items that have to be looked up later. However, they me already be that good, I do not have any complaints, I just wanted to state that I think them important. Just my humble opinion... Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. pgp0.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] performance tuning Data.FiniteMap
MR K P SCHUPKE <[EMAIL PROTECTED]> writes: > I was thinking about improving array performance, and was wondering > if a transactional model would work well. > > I would be interested in any comments... I suspect somebody has done this > before, but I havent looked for any papers yet. O'Neill and Burton, "A New Method for Functional Arrays", JFP 7(5), 1997. http://citeseer.ist.psu.edu/328736.html Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] performance tuning Data.FiniteMap
I was thinking about improving array performance, and was wondering if a transactional model would work well. You would keep a base copy of the array, and any writes would be written to a delta style transaction list. A reference to the array would be the list plus the base array. Different references to the same array would just reference different points in the delta list. The garbage colector would eat the delta list from the tail, merging writes into the base array once references to that part of the list are discarded. Writes would be very fast - just the time to add a delta to the transaction list. Reads would slow down as the transaction list grows, but the list would only be as long as the oldest reference, so providing references to very old copies of the array are not required, the transaction list would remain short. It would be even more efficient if the 'liveness' of references could be checked when writing the array - at the cost of a slight slowdown in write performance. I would be interested in any comments... I suspect somebody has done this before, but I havent looked for any papers yet. Regards Keean Schupke. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] performance tuning Data.FiniteMap
[Moving to GHC users list] There are several things that aren't research issues: notably, faster copying, fewer intermediate lists, fewer state-monad-induced intermediate closures. These are things that would move sharply up our priority list if you had a real application that was stumbling on them. What I obviously can't promise is that improving these things would solve your problem -- if, indeed, you turn out to have one! Simon | -Original Message- | From: S. Alexander Jacobson [mailto:[EMAIL PROTECTED] | Sent: 26 February 2004 23:27 | To: Simon Peyton-Jones | Cc: [EMAIL PROTECTED] | Subject: RE: [Haskell] performance tuning Data.FiniteMap | | Is fixing GHC arrays a big research job or is it | something that someone can straightforwardly | handle if my site actually gets enough traffic to | warrant it? | | -Alex- | | On Thu, 26 Feb 2004, Simon Peyton-Jones wrote: | | > | But in managing this tradeoff, what is faster: | > | * constructing/destructing e.g. 16 trees (for a 65000 item table) | > | * 2 memcpy of 256 item arrays (perhaps after you primop?) | > | | > | If the later is not dramatically slower than I | > | will bias towards more arrayness. | > | > I doubt the latter is dramatically slower, but you'd have to experiment | > to find out. And GHC is not doing as well as it should on arrays just | > now. (One of the things on our to-do list.) Might vary between | > implementations too. | > | > Simon | > | | _ | S. Alexander Jacobson mailto:[EMAIL PROTECTED] | tel:917-770-6565 http://alexjacobson.com ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
