Is there any special structure in your data that could be exploited?
On Sat, Sep 1, 2012 at 6:17 PM, Gershom Bazerman gersh...@gmail.com wrote:
In my experience, doing much better than the naive algorithm for median is
surprisingly hard, and involves a choice from a range of trade-offs. Did
On 01/09/12 04:00, timothyho...@seznam.cz wrote:
I'd have to say that there is one(and only one) issue in Haskell that
bugs me to the point where I start to think it's a design flaw:
It's much easier to type things over generally than it is to type
things correctly.
Say we have a
data
The problem with the last example I gave is evident in your statement It
appears you need to distinguish between Bars and Frogs. I have written
quite a number of largish code bases, and I've run into the following
problem every time:
case largeMultiConstructorTypedValue of
On 02/09/12 20:35, timothyho...@seznam.cz wrote:
It seems to be a probability approaching law, that I run into this for
a given multi-constructor type. Regardless of it's purpose.
Maybe your large multi-constructor types are too monolithic? Again it's
hard to know given a fabricated
All,
For some code I need to alter an (unboxed or storable) vector by
blit'ing (copying) data from another (smaller) vector into it,
overwriting the existing data. I couldn't find a function for this in
the vector API, so I hacked something up which cuts the jobs (see
below), but it feels really
timothyho...@seznam.cz writes:
case largeMultiConstructorTypedValue of
Foo{blah=blah,brg=brg} - Some large block...
Bar{lolz=lolz,foofoo=foofoo} - ...Another large block...
Frog{legs=legs,heads=heads} - Yet another large block...
Where the obvious re-factor is:
case
The thing is, that one ALWAYS wants to create a union of types, and not
merely an ad-hock list of data declarations. So why does it take more code
to do the right thing(tm) than to do the wrong thing(r)? Lets take an
example from Conor McBride's she https://github.com/timthelion/her-lexer/
On Sun, Sep 2, 2012 at 9:40 AM, timothyho...@seznam.cz wrote:
The thing is, that one ALWAYS wants to create a union of types, and not
merely an ad-hock list of data declarations. So why does it take more code
to do the right thing(tm) than to do the wrong thing(r)?
Because a union type is a
Like many of us, I've suffered from cabal dependency hell and sought relief.
I wasn't exactly happy with sandboxes - because using per-project ones
meant package duplication and shared sandboxes suffer from the same
issues as the GHC package database itself, i.e. reinstalls can break
other
Hell yeah!
Looks like a nice approach.
On Sun 02 Sep 2012 19:25:08 BST, Danny B wrote:
Like many of us, I've suffered from cabal dependency hell and sought relief.
I wasn't exactly happy with sandboxes - because using per-project ones
meant package duplication and shared sandboxes suffer
On Sun, Sep 2, 2012 at 12:06 PM, Alexander Solla alex.so...@gmail.com wrote:
On Sun, Sep 2, 2012 at 9:40 AM, timothyho...@seznam.cz wrote:
The thing is, that one ALWAYS wants to create a union of types, and not
merely an ad-hock list of data declarations. So why does it take more code
to
awesome! I look forward to playing with this and hopefully saying hell
yeah when i'm done :)
-Carter
On Sun, Sep 2, 2012 at 2:51 PM, Niklas Hambüchen m...@nh2.me wrote:
Hell yeah!
Looks like a nice approach.
On Sun 02 Sep 2012 19:25:08 BST, Danny B wrote:
Like many of us, I've suffered
On Sun, Sep 2, 2012 at 9:40 AM, timothyho...@seznam.cz wrote:
The thing is, that one ALWAYS wants to create a union of types, and not
merely an ad-hock list of data declarations. So why does it take more code
to do the right thing(tm) than to do the wrong thing(r)?
You've said this a few
Looks like I failed to reply all
-- Původní zpráva --
Od: timothyho...@seznam.cz
Datum: 2. 9. 2012
Předmět: Re: Re: [Haskell-cafe] Over general types are too easy to make.
Care to link me to a code repository that doesn't have this problem? The
only Haskell program that I have
I was thinking it should offer a randomized version (taking a generator),
since randomized median algorithms provide the best expected performance.
It could also offer a deterministic version using some variant of
median-of-medians, intended for long lists. I guess it probably should
retain the
On 09/01/2012 12:13 AM, Farid Neshat wrote:
So I'm trying to follow [this blog][1]. So I tried the code, couldn't
compile the haskell part, probably due to the fact the guide uses
version 6, but I have version 7 of ghc. By changing the paramaters I
could compile it with the following:
ghc
It really depends on how you are reading in the data and what you plan to do
with it besides taking the median. Obviously, if you read in your data as
an ordered list things can be done O(n) without any trouble.
In another case, if you already know the range, you can make a hash table
and
Sorry, I am horribly mistaken. Hash table is O(n)+O(numbuckets)+O
(middlebucketsize log(middlebucketsize))... It's too late for this stuff...
Tim
-- Původní zpráva --
Od: timothyho...@seznam.cz
Datum: 3. 9. 2012
Předmět: Re: [Haskell-cafe] hstats median algorithm
It really
# uname -a
Linux hosename 2.6.32-220.2.1.el6.centos.plus.x86_64 #1 SMP Thu Dec 22
23:32:31 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux
# cat /proc/version
Linux version 2.6.32-220.2.1.el6.centos.plus.x86_64 (
mockbu...@c6b18n3.bsys.dev.centos.org) (gcc version 4.4.6 20110731 (Red Hat
4.4.6-3) (GCC)
On Sun, Sep 2, 2012 at 9:26 PM, Manish Trivedi trivman...@gmail.com wrote:
[root@qa-engine1 haskell-platform-2012.2.0.0]# yum install gmp
This is just the runtime library; you will also need the compile/link-time
library provided by gmp-devel. That said, the contents of the config.log
Hi Brandon,
Appreciate your reply. some more info. I just confirmed that gmp-devel is
installed too. yum message shows Package gmp-devel-4.3.1-7.el6_2.2.x86_64
already installed and latest version.
I am attaching the config.log in the email.
Thanks in advance!
-Manish
On Sun, Sep 2, 2012 at
On Sun, Sep 2, 2012 at 10:49 PM, Manish Trivedi trivman...@gmail.comwrote:
I am attaching the config.log in the email.
You didn't install ghc properly, or you did and you then added its internal
directory to your $PATH. The executables in /usr/local/lib/ghc-7.4.1 should
not be run directly, as
I like the approach so far. But hellno itself seems to have several
dependencies itself. So installing with cabal pulls these in as
fixed libraries (text, mtl, transformers, and parsec). Any
plans to make these not have to be fixed? Or is there a trick I'm
missing?
On Sun, Sep 2, 2012 at 11:25
perhaps the *right* solution is to view that as a bootstrap build, and then
have hellno build itself? :)
That said, its also an executable rather than library, so its not quite the
same problem.
On Sun, Sep 2, 2012 at 11:15 PM, Richard Wallace
rwall...@thewallacepack.net wrote:
I like the
On Mon, Sep 3, 2012 at 3:15 PM, Richard Wallace
rwall...@thewallacepack.net wrote:
I like the approach so far. But hellno itself seems to have several
dependencies itself. So installing with cabal pulls these in as
fixed libraries (text, mtl, transformers, and parsec). Any
plans to make
25 matches
Mail list logo
