On Tue, Jun 4, 2013 at 7:35 AM, Richard A. O'Keefe wrote:
>
> On 3/06/2013, at 6:58 PM, Carter Schonwald wrote:
> > If the Int type had either of these semantics by default, many many
> performance sensitive libraries would suddenly have substantially less
> compelling performance. Every single o
On Mon, 3 Jun 2013 23:19:38 -0400
Clark Gaebel wrote:
> That's absolutely true. Wrappers around vector for your multidimensional
> access is probably best, but Vectors of Vectors are usually easier.
>
> But again, you're right. Multidimensional access is a pain. If it's a
> "matrix" of numerical
That's absolutely true. Wrappers around vector for your multidimensional
access is probably best, but Vectors of Vectors are usually easier.
But again, you're right. Multidimensional access is a pain. If it's a
"matrix" of numerical values, you could take a look at 'hmatrix'.
- Clark
On Monday
On Mon, Jun 3, 2013 at 7:45 PM, Clark Gaebel wrote:
> How is this a problem?
>
> If you're representing text, use 'text'.
> If you're representing a string of bytes, use 'bytestring'.
> If you want an "array" of values, think c++ and use 'vector'.
> If you want to mutate arrays, first, make sure y
How is this a problem?
If you're representing text, use 'text'.
If you're representing a string of bytes, use 'bytestring'.
If you want an "array" of values, think c++ and use 'vector'.
If you want to mutate arrays, first, make sure you do. You probably don't.
If you're sure, use MVector.
Don't u
On Mon, 03 Jun 2013 19:16:08 +
silvio wrote:
> Hi everyone,
>
> Every time I want to use an array in Haskell, I find myself having to
> look up in the doc how they are used, which exactly are the modules I
> have to import ... and I am a bit tired of staring at type signatures
> for 10 mi
On 3/06/2013, at 6:58 PM, Carter Schonwald wrote:
> If the Int type had either of these semantics by default, many many
> performance sensitive libraries would suddenly have substantially less
> compelling performance. Every single operation that was branchless before
> would have a branch *ev
Artyom Kazak writes:
> silvio писал(а) в своём письме Mon, 03 Jun 2013
> 22:16:08 +0300:
>
>> Hi everyone,
>>
>> Every time I want to use an array in Haskell, I find myself having to
>> look up in the doc how they are used, which exactly are the modules I
>> have to import ... and I am a b
silvio писал(а) в своём письме Mon, 03 Jun 2013
22:16:08 +0300:
Hi everyone,
Every time I want to use an array in Haskell, I find myself having to
look up in the doc how they are used, which exactly are the modules I
have to import ... and I am a bit tired of staring at type signatures
Dear all,
I'm happy to announce that the Haskell-Paris group will meet on June 25th
in Paris. Please register (free) at
http://www.meetup.com/haskell-paris/events/122515522/ .
Program is not decided yet (contributions are welcome). We'll update once
we know the lineup.
I don't like to send spamm
On 3 Jun 2013, at 20:38, Corentin Dupont wrote:
> I'd like to transform a .hs file into a .html file.
> The objective is that the .html file, when rendered, looks exactly the same
> that the .hs, with the exeption that every function in the code is a link to
> its haddock documentation.
> Is th
Hello everybody,
I'd like to transform a .hs file into a .html file.
The objective is that the .html file, when rendered, looks exactly the same
that the .hs, with the exeption that every function in the code is a link
to its haddock documentation.
Is that possible? The result would look like that:
write :: MVector a -> Int -> a -> ST s a
This should have been:
write :: MVector s a -> Int -> a -> ST s a
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Hi everyone,
Every time I want to use an array in Haskell, I find myself having to
look up in the doc how they are used, which exactly are the modules I
have to import ... and I am a bit tired of staring at type signatures
for 10 minutes to figure out how these arrays work every time I use the
GHC is not the spec, I am talking about GHC Haskell, not Haskell the
standard that I don't use.
On 32bit machines, GHC Int is 32bits. On 64bit GHC on 64bit machines Int is
64 bits.
If you have another well engineered suitable for wide use Haskell compiler
in mind, I'd love to try it out, but with
On Jun 3, 2013, at 00:23 , Carter Schonwald wrote:
> Int is "native register sized integer"
Actually it's not. Read the definition. Int is only guaranteed to be 29 bits.
Here's *one* _actual_ data point (from a 2.8 GHz i7, 64-bit code):
time ./fib
fib(43) = 701408733
3.27 real
It looks like I left a DLL out of the installer.
Fixed versions are here...
http://leksah.org/packages/leksah-0.13.2.3-ghc-7.0.3.exe
http://leksah.org/packages/leksah-0.13.2.3-ghc-7.0.4.exe
http://leksah.org/packages/leksah-0.13.2.3-ghc-7.4.1.exe
http://leksah.org/packages/leksah-0.13.2.3-ghc-7.4.
Tommy, respectfully,
I have quite a few bits of code where a bad branch predictor in a tight
inner loops makes code 10x slower.
you are welcome to do your own experimentation so that you too can learn by
branches are bad in tight loops. (even if the branch predictor is doing
its job, there will
On Jun 2, 2013, at 23:58 , Carter Schonwald wrote:
> Indeed, as Dan says, theres the safeint library and the Integer type.
>
> If the Int type had either of these semantics by default, many many
> performance sensitive libraries would suddenly have substantially less
> compelling performance.
as the others have said, if you want to have text data go between ghc and
c++, please use Text or Bytestring,
String... would get weird.
If you seriously want to experiment with writing low level code
manipulating the String type, it *MIGHT* be possible using the GHC C minus
minus (CMM). This wou
Indeed, as Dan says, theres the safeint library and the Integer type.
If the Int type had either of these semantics by default, many many
performance sensitive libraries would suddenly have substantially less
compelling performance. Every single operation that was branchless before
would have a b
21 matches
Mail list logo
