On Tue, 24 Feb 2004, Hal Daume III wrote:
> > It seems like updates could be very fast because I
> > assume // is implemented with a fast memcpy
> (//) is very slow
Is that inherent in Haskell (or laziness) or is it
just an artifact of the current GHC
implementation? Would the problem be sol
[Rewrote prior code to be cleaner]
Isn't the following more efficient than Data.FiniteMap?
class Ix a=>Radix a where maxRange::(a,a)
class Radix a => HashKey b a where hashKey::b->[a]
instance Radix Char where maxRange=(chr 0,chr 255)
instance Radix a=> HashKey [a] a where hashKey x=x
> It seems like updates could be very fast because I
> assume // is implemented with a fast memcpy
(//) is very slow
> _
> S. Alexander Jacobson mailto:[EMAIL PROTECTED]
> tel:917-770-6565 h
Ok. I just looked more carefully at FiniteMap and
the Data.HashTable documentation and coded what I
had incorrectly imagined would be there. Isn't
the following more efficient than FiniteMap
without requiring the IO Monad?
-
class M
as a tangent, for absurdly fast and optimal (optimized to the cache
line) maps see
http://judy.sourceforge.net/
the algorithms behind them are very cool.
see http://judy.sourceforge.net/downloads/10minutes.htm
for a quick discussion of why they are fast (there is a fewhundred page
book too)
heh.
> I believe FiniteMap works by representing the data
> in binary trees. It is therefore O(log2(n)) to
> read and update.
>
> However, if my application reads many more times
> than it writes, then perhaps I can get a
> substantial performance boost by increasing the
> branch factor on the tree.
On Tue, Feb 24, 2004 at 09:01:46AM +, Graham Klyne wrote:
> I recently ran into some problems porting some Haskell code to Windows
> because it used the Text.Regex library, which is dependent on a Unix-only
> system. If Haskell is to embrace the use of Regexes to a level comparable
> with (
I have updated my code as well as made a simple template haskell
version.
A Wikified homepage can be found at
http://haskell.org/hawiki/RegexSyntax
I have found that the syntax combines really really really well with
pattern guards.
f s | Just 3 <- s =~~ "i/john" = print "exactly 3 johns found
Hal Daume III wrote:
> p.s., certainly this is at least somewhat unique to me, but almost all of
> the data i work with is unstructured text for two reasons. first, that's
> how it naturally comes. second, to throw xml or some other scheme on to
> it will balloon the data sizes to unmanagabl
Further to problems reported in [1].
I've made a small step forward on this. I'm nearly out of time for now, so
this is a partial report.
I've created a pair of simple C programs:
+ EchoShiftLetters.c
Reads from standard input and writes to standard output, converting all
letters to upper cas
> At 18:07 23/02/04 -0800, John Meacham wrote:
> >It provides regular and monadic versions, a very overloaded
> and useful
> >interface, as well as extensibility. although currently the only
> >instance is based on Text.Regex, it generalizes to matching lists of
> >arbitrary type, not just stri
"S. Alexander Jacobson" <[EMAIL PROTECTED]> writes:
> However, if my application reads many more times than it writes,
> then perhaps I can get a substantial performance boost by increasing
> the branch factor on the tree. For example, if each node was an
> array of 256 elements, reads would be O
S. Alexander Jacobson wrote:
Does FiniteMap used Arrays, Lists, or Algebraic Types?
when in doubt, RTFC:
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/Data/FiniteMap.hs?rev=1.17
data FiniteMap key elt
= EmptyFM
| Branch key elt -- Key and elt stored here
IF
I believe FiniteMap works by representing the data
in binary trees. It is therefore O(log2(n)) to
read and update.
However, if my application reads many more times
than it writes, then perhaps I can get a
substantial performance boost by increasing the
branch factor on the tree. For example, if
At 16:33 24-2-04 +0100, Johannes Waldmann wrote:
Per Larsson wrote:
But I can't see why the haskell user shouldn't also have access to
concise text processing notations, e.g. regular expressions and printf,
I was not implying it should be forbidden,
rather I meant to give a reason why text proces
Per Larsson wrote:
But I can't see why the haskell user shouldn't also have access to concise
text processing notations, e.g. regular expressions and printf,
I was not implying it should be forbidden,
rather I meant to give a reason why text processing
seems to be less common in typical Haskell
just as another sample point...
i write 99% of my code in either haskell or perl. haskell tends to be for
the longer programs, perl tends to be for the shorter ones, though the
decision is primarily made for only one reason:
- if the overhead to write the string processing code in haskell
On Tuesday 24 February 2004 15.25, Johannes Waldmann wrote:
> Per Larsson wrote:
> > .. I have since long missed some
> >
> > typical text processing functionality in haskell.
>
> it is often the case that people process "text"
> only because they have no better (structured and typed) way of
> rep
Per Larsson wrote:
> .. I have since long missed some
typical text processing functionality in haskell.
it is often the case that people process "text"
only because they have no better (structured and typed) way of
representing their data...
--
-- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 64
On Tuesday 24 February 2004 03.07, John Meacham wrote:
> Inspired by an idea by Andrew Pang and an old project of mine, I decided
> to fill out a reusable regular expression library which is similar to
> Perl's, but much more expressive.
> ...
Hi,
Thanks! I am grateful of your efforts because I h
On Thu, Feb 19, 2004 at 07:50:30PM +0100, Frank Atanassow wrote:
> In the near future I expect to have need of an implementation of some
> basic term rewriting system algorithms, most notably:
>
> - term matching and unification
> - same, modulo associativity
> - same, modulo associativity
At 18:07 23/02/04 -0800, John Meacham wrote:
It provides regular and monadic versions, a very overloaded and useful
interface, as well as extensibility. although currently the only
instance is based on Text.Regex, it generalizes to matching lists of
arbitrary type, not just strings, and also leave
22 matches
Mail list logo
