Johan Tibell wrote:
Hi,
I did quite a bit of work to make sure copyArray# and friends get
unrolled if the number of elements to copy is a constant. Does this
still work with the extra branch?
I would expect it to but I don't know. Does the testsuite check for this?
Roman
Herbert Valerio Riedel wrote:
Roman Leshchinskiy r...@cse.unsw.edu.au writes:
[...]
If I'm right then I would suggest not to use copyArray# and
copyMutableArray# for GHC 7.8.
I've grepped today's
http://hackage.haskell.org/cgi-bin/hackage-scripts/archive.tar
for occurences of those
Simon Marlow wrote:
On 06/10/2012 22:41, Roman Leshchinskiy wrote:
I've been chasing a segfault in the dev version of vector and I think I
finally traced it to a bug in the implementation of copyArray# and
copyMutableArray#. More specifically, I think emitSetCards in
StgCmmPrim.hs
I've been chasing a segfault in the dev version of vector and I think I
finally traced it to a bug in the implementation of copyArray# and
copyMutableArray#. More specifically, I think emitSetCards in
StgCmmPrim.hs (and CgPrimOp.hs) will sometimes fail to mark the last
card as dirty because in
Simon Peyton-Jones wrote:
| I remember a similar discussion a few years ago. The question of
whether
| or not overloading list literals a good idea notwithstanding, the
problem
| with this is that fromList for vectors is highly inefficient. So if
| something like this gets implemented
Simon Peyton-Jones wrote:
| pointer to the actual data somewhere in memory and use that. This is
| more or less what happens for strings at the moment, even though you
| have to use rewrite rules to get at the pointer which, in my opinion, is
| neither ideal nor really necessary. IMO, the
Michael Snoyman wrote:
The simplest example I can think of is allowing easier usage of Vector:
[1, 2, 3] :: Vector Int
In order to allow this, we could use a typeclass approach similar to
how OverloadedStrings works:
class IsList a where
fromList :: [b] - a b
Myles C. Maxfield wrote:
Aha there it is! Thanks so much. I didn't see it because it's under the
Unfolding section instead of the Construction section.
You're quite right, having a separate Unfolding section isn't the best
idea. I'll fix this.
Roman
On Mon, Sep 17, 2012 at 6:07 AM, Roman
Myles C. Maxfield wrote:
Overall, I'm looking for a function, similar to Data.Vector's 'generate'
function, but instead of the generation function taking the destination
index, I'd like it to take the elements that have previously been
constructed. Is there such a function? If there isn't
On 12 Jun 2012, at 12:52, Dmitry Dzhus d...@dzhus.org wrote:
12.06.2012, 01:08, Roman Leshchinskiy r...@cse.unsw.edu.au:
perhaps the state hack is getting in the way.
I don't quite understand the internals of this yet, but `-fno-state-hack`
leads to great performance in both cases!
How
On 11/06/2012, at 18:52, Evan Laforge wrote:
On Tue, May 29, 2012 at 12:52 PM, Roman Leshchinskiy r...@cse.unsw.edu.au
wrote:
Vector should definitely fuse this, if it doesn't it's a bug. Please report
if it doesn't for you. To verify, just count the number of letrecs in the
optimised
On 11/06/2012, at 10:38, Dmitry Dzhus wrote:
Consider this simple source where we generate an unboxed vector with million
pseudo-random numbers:
8 -
import qualified Data.Vector.Unboxed as VU
import System.Random.MWC
import System.Random.MWC.Distributions (standard)
count =
On 29/05/2012, at 19:49, Evan Laforge wrote:
Good question.. I copied both to a file and tried ghc-core, but it
inlines big chunks of Data.Vector and I can't read it very well, but
it looks like the answer is no, it still builds the the list of sums.
I guess the next step is to benchmark and
Johan Tibell wrote:
Hi all,
I've been thinking about this some more and I think we should
definitely unpack primitive types (e.g. Int, Word, Float, Double,
Char) by default.
The worry is that reboxing will cost us, but I realized today that at
least one other language, Java, does this
Jean-Marie Gaillourdet wrote:
Hi,
On 17.02.2012, at 09:52, Roman Leshchinskiy wrote:
Johan Tibell wrote:
The worry is that reboxing will cost us, but I realized today that at
least one other language, Java, does this already today and even
though it hurts performance in some cases
On 17/02/2012, at 17:51, Johan Tibell wrote:
On Fri, Feb 17, 2012 at 12:52 AM, Roman Leshchinskiy r...@cse.unsw.edu.au
wrote:
I'm not convinced that this is a good idea because it doesn't treat all
types equally. The comparison with Java is problematic, IMO, because in
Java 'int' is always
On 13/02/2012, at 11:10, Simon Peyton-Jones wrote:
| Should there perhaps be a NewTypeable module which could then be renamed
| into Typeable once it is sufficiently well established?
I started with that idea, but there would be a 2-stage process:
* Step 1: (when PolyTypable becomes
On 12/02/2012, at 03:21, Iavor Diatchki wrote:
PS: I wouldn't worry too much about breaking existing code, as long as
derived Typeable instances continue to work---I never provide custom
ones and, in fact, I think that GHC should no allow them or, at least,
give a stern warning when it sees
On 12/02/2012, at 02:39, Greg Weber wrote:
This proposal stands on its own
* the dot operator is inconsistent with Module function selection.
* we are allowed the option of expanding the usage of the dot without
spaces if this proposal goes forward.
The point is that we will decide whether
On 12/02/2012, at 02:42, Isaac Dupree wrote:
Does it help your concern about breaking existing code to make sure this
proposal has a LANGUAGE flag? (-XDotSpaces or such)
(I'm guessing that helps somewhat but not very satisfactorily; the more
default and standard it becomes, the more often
On 10/02/2012, at 23:30, John Meacham wrote:
something I have thought about is perhaps a special syntax for Proxy, like
{:: Int - Int } is short for (Proxy :: Proxy (Int - Int)). not sure whether
that is useful enough in practice though, but could be handy if we are
throwing
around types a
On 10/02/2012, at 02:41, Greg Weber wrote:
There are 2 compelling reasons I know of to prefer dot for record access
1) follows an almost universal convention in modern programming languages
2) is consistent with using the dot to select functions from module
name-spaces
I don't understand
On 12/02/2012, at 01:29, Nate Soares wrote:
If - was introduced for accessing fields, we'd have to discuss whether it
should have spaces around it. I'd lean towards requiring that it have no
spaces when used for field access, for symmetry with . when used for module
access.
I'm not spaces
On 12/02/2012, at 02:04, Greg Weber wrote:
I am sorry that I made the huge mistake in referencing future possible
proposals. If this proposal passes, that has no bearing on whether the
other proposals would pass, it just makes them possible.
Please help me fix my error by stopping all
Marc Weber wrote:
Replying to all replies at once:
Malcolm Wallace
At work, we have a strict version of Haskell
:-) which proofs that it is worth thinking about it.
But doesn't necessarily prove that it's a good idea.
Just (Item id ua t k v) -
Marc Weber wrote:
Replying to all replies at once:
Malcolm Wallace
At work, we have a strict version of Haskell
:-) which proofs that it is worth thinking about it.
But doesn't necessarily prove that it's a good idea.
Just (Item id ua t k v) -
On 12/01/2012, at 21:01, Artyom Kazak wrote:
Yves Parès limestr...@gmail.com писал(а) в своём письме Thu, 12 Jan 2012
13:14:16 +0200:
uvector is deprecated, its functionnalities has been ported into vector.
Yes, but a Ratio a instance hasn't been ported.
FWIW, vector isn't a port of
On 11/01/2012, at 17:00, Artyom Kazak wrote:
In fact, I am surprised that Data.Vector doesn't have a Ratio
instance, but has a Complex instance. Any ideas, why?
Nobody has asked for it so far.
Roman
___
Haskell-Cafe mailing list
Johan Tibell wrote:
map (\ v - undefined) == undefined
mapKeys (\ k - undefined) == undefined
Not really related to the question but I don't really understand how these
properties can possibly hold. Shouldn't it be:
map (\v - undefined) x = undefined
And even then, does
Yves Parès wrote:
While re-reading RealWorldHaskell, chapter 25, I saw that -- unlike I
believed -- loop fusion wasn't activated by default under GHC for lists
(but that module Data.List.Stream from package stream-fusion could provide
it).
Note that stream fusion is only one way to do
Joachim Breitner wrote:
Hi,
Iâm consdering to change some performance critical code from Vector to
MVector, hopefully avoiding a lot of copying and garbage collecting. But
it seems that the Data.Vector.Mutable interface at
Conrad Parker wrote:
On 15 October 2011 23:18, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 16 October 2011 01:15, Bas van Dijk v.dijk@gmail.com wrote:
I agree that you shouldn't use ByteStrings or Vectors of Word8s for
Unicode strings. However I can imagine that for quick
Ivan Lazar Miljenovic wrote:
On 19 October 2011 22:09, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
So it seems that (1) people have very different requirements and (2) the
Show instance only really matters for debugging in ghci. Here is a
thought. What if ghci allowed Show instances
Michael Snoyman wrote:
On Mon, Oct 17, 2011 at 12:14 PM, Bas van Dijk v.dijk@gmail.com
wrote:
My idea is that when vector-bytestring is as fast as bytestring, it
can replace it. When that happens it doesn't matter if users use the
vector interface. I would even recommend it over using
On 14/10/2011, at 12:37, Bas van Dijk wrote:
If there's need for a specific Show instance for Vectors of Word8s we
can always add one directly to vector. (Roman, what are your thoughts
on this?)
Personally, I think that ByteString and especially Vector Word8 aren't strings
and shouldn't be
On 15/10/2011, at 12:26, Roman Leshchinskiy wrote:
On 14/10/2011, at 12:37, Bas van Dijk wrote:
If there's need for a specific Show instance for Vectors of Word8s we
can always add one directly to vector. (Roman, what are your thoughts
on this?)
Personally, I think that ByteString
Bas van Dijk wrote:
Hello,
I'm trying to make the following faster:
Data.Vector.Generic.fromList list
where 'list' is some expression yielding a list.
Unfortunately, I don't think that's possible. The problem is that you
'list' will be expressed in terms of foldr/build and fromList would
Manuel M T Chakravarty wrote:
Roman Leshchinskiy:
What data structures other than lists do we want to construct using list
literals? I'm not really sure what the use cases are.
Parallel arrays! (I want to get rid of our custom syntax.)
Why? Don't you think it is useful to have a visual
Simon Peyton-Jones wrote:
I'm not sure if this plan would support [(fred,45), (bill,22)] :: Map
String Int. Probably not. Maybe that's a shortcoming... but such Maps
are a rather surprising use of list literals.
What data structures other than lists do we want to construct using list
George Giorgidze wrote:
This extension could also be used for giving data-parallel array literals
instead of the special syntax used currently.
Unfortunately, it couldn't. DPH array literals don't (and can't really) go
through lists.
In general, if we are going to overload list literals then
Yitzchak Gale wrote:
Roman Leshchinskiy wrote:
In general, if we are going to overload list literals then forcing the
desugaring to always go through lists seems wrong to me. There are
plenty
of data structures where that might result in a significant performance
hit.
These are literals
On 25/09/2011, at 18:20, Chris Smith wrote:
class Ord a = Range a where
rangeFromTo :: a - a - [a] -- subsumes Ix.range / Enum.enumFromTo
rangeFromThenTo :: a - a - a - [a]
inRange :: (a, a) - a - Bool
-- Does have instances for Float/Double. List ranges desugar to this.
-- Also
On 28/09/2011, at 23:23, Ivan Lazar Miljenovic wrote:
On 29 September 2011 07:56, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
On 25/09/2011, at 18:20, Chris Smith wrote:
class Ord a = Range a where
rangeFromTo :: a - a - [a] -- subsumes Ix.range / Enum.enumFromTo
rangeFromThenTo
Jon Fairbairn wrote:
Roman Leshchinskiy r...@cse.unsw.edu.au writes:
No, arrays were not considered to be bad, they were designed
with parallelism in mind.
I'm not sure how this can be the case if, as discussed below, most array
operations have to go through lists, an inherently sequential
Roman Cheplyaka wrote:
{-# LANGUAGE TypeFamilies, FlexibleContexts, UndecidableInstances,
FlexibleInstances #-}
import Data.Fixpoint
newtype Expr = Expr { unExpr :: Pre Expr Expr }
instance Functor (Pre Expr) = Fixpoint Expr where
data Pre Expr a
= Add
On 03/09/2011, at 03:04, Ivan Lazar Miljenovic wrote:
On 3 September 2011 11:38, Evan Laforge qdun...@gmail.com wrote:
The result is that my first contact with haskell
arrays left me with the impression that they were complicated, hard to
use, and designed for someone with different
Gregory Collins wrote:
On Tue, Jun 28, 2011 at 6:20 PM, Eric Rasmussen ericrasmus...@gmail.com
wrote:
It runs quickly, but I naively thought I could outperform it by
reworking many to build a vector directly, instead of having to build
a list first and then convert it to a vector:
manyVec
Hi all,
GHC defines ForeignPtr as:
data ForeignPtr a = ForeignPtr Addr# ForeignPtrContents
-- we cache the Addr# in the ForeignPtr object, but attach
-- the finalizer to the IORef (or the MutableByteArray# in
-- the case of a MallocPtr). The aim of the representation
On 30/05/2011, at 00:55, dm-list-haskell-pr...@scs.stanford.edu wrote:
I'm absolutely not advocating making overlapping instances (or, worse,
overlapping types) part of Haskell', nor under the impression that the
committee would ever consider doing so. I'm just pointing out that
right now
Roman Cheplyaka wrote:
Of course I don't claim that fusion is useless -- just trying to
understand the problem it solves. Are we saving a few closures and cons
cells here?
In addition to what everyone else said, fusion can be a big win when it
allows further optimisations. For instance,
Daniel Fischer wrote:
Further investigation of the sorting code in vector-algorithms revealed
no bugs there, and if the runtime was forced to keep a keen eye on the
indices, by replacing unsafeRead/Write/Swap with their bounds-checked
counterparts or by 'trace'ing enough of their uses, the
Simon Marlow wrote:
For small arrays like this maybe we should have a new array type that
leaves out all the card-marking stuff too (or just use tuples, as Roman
suggested).
Would it, in theory, be possible to have an unpacked array type? That
is, could we have constructors for which the
Simon Marlow wrote:
On 01/03/2011 11:55, Roman Leshchinskiy wrote:
Would it, in theory, be possible to have an unpacked array type? That
is, could we have constructors for which the length of the closure is
determined dynamically at runtime?
Certainly, but the amount of effort
Johan Tibell wrote:
I'm working on a patch that provides O(1) size right now. The trick is
to define HashMap as:
data HashMap k v = HM {-# UNPACK #-} !Int !(Tree k v)
Another possibility is:
data HashMap k v = HM Int !(Tree k v)
hashMap t = HM (treeSize t) t
That way size is O(n) on first
Max Bolingbroke wrote:
On 18 February 2011 01:18, Johan Tibell johan.tib...@gmail.com wrote:
It seems like a sufficient solution for your needs would be for us to
use the LTO support in LLVM to inline across module boundaries - in
particular to inline primop implementations into their call
Johan Tibell wrote:
* Could we use built-in compiler rules to catch array copies of known
length and replace them with e.g. unrolled loops? My particular use case
involves copying small arrays (size: 1-32). Ideally this should be as fast
as copying a tuple of the corresponding size but I'm
On 14/02/2011, at 21:28, Conal Elliott wrote:
Is there a way to declare a type family to be injective?
I have
data Z
data S n
type family n :+: m
type instance Z :+: m = m
type instance S n :+: m = S (n :+: m)
You could prove it :-)
class Nat n where
induct :: p Z -
Max Bolingbroke wrote:
2011/2/15 Simon Peyton-Jones simo...@microsoft.com:
but currently any pragmas in a class decl are treated as attaching to
the *default method*, not to the method selector:
I see. I didn't realise that that was what was happening. Personally I
find this a bit
Max Bolingbroke wrote:
On 15 February 2011 11:23, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
I wouldn't necessarily expect this to guarantee inlining for the same
reason that the following code doesn't guarantee that foo gets rewritten
to big:
foo = bar
{-# INLINE bar #-}
bar = big
Max Bolingbroke wrote:
On 15 February 2011 15:12, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
Ah, but you assume that bar won't be inlined into foo first. Consider
that it is perfectly acceptable for GHC to generate this:
foo = big {-# INLINE bar #-}
bar = big
We did ask to inline bar
Max Bolingbroke wrote:
On 15 February 2011 16:45, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
Only if foo has an INLINE pragma. Otherwise, GHC uses whatever RHS is
available when it wants to inline.
Ah, I see! Well yes, in that case my workaround is indeed broken in
the way you describe
Pierre-Etienne Meunier wrote:
This is mostly a question for Roman : how do you use your vector library
with multi-dimensional arrays ? I mean, the array library from the
standard libraries does something more intelligent than the C-like
solution with indirections.
Vector doesn't include any
On 04/02/2011, at 10:49, Dark Lord wrote:
I thoroughly agree with this. However, in the event that this does not
happen, piecemeal fixes are better than none.
FWIW, I disagree. To put it bluntly, why is repeatedly breaking a lot of code
better than not breaking it at all? Breaking a lot of
On 04/02/2011, at 10:08, Malcolm Wallace wrote:
I suggested, and several people +1'd, that if we are making disruptive
changes to the standard libraries defined in the Language Report (especially
the Prelude), then we should aim to make a thorough job of cleaning up all
the cruft and
Have you tried adding another (dummy) method to the class? GHC used to have
problems with optimising single-method classes in the past.
Roman
On 18 Jan 2011, at 10:33, José Pedro Magalhães j...@cs.uu.nl wrote:
Hello all,
I fail to understand the behavior of the inliner in the following
On 18/01/2011, at 22:18, Johan Tibell wrote:
The docs for newArray# states:
Create a new mutable array of specified size (in bytes), in the
specified state thread, with each element containing the specified
initial value.
The docs are wrong.
I'm trying to implement
the following array
On 12 Jan 2011, at 23:31, Edward Z. Yang ezy...@mit.edu wrote:
Excerpts from Roman Leshchinskiy's message of Wed Jan 12 18:20:25 -0500 2011:
How would we get the current functionality of darcs-all pull? Is it even
possible?
Here is the rebase-y workflow.
Thank you making things clearer!
On 12/01/2011, at 09:22, Simon Marlow wrote:
On 11/01/2011 23:11, Roman Leshchinskiy wrote:
A quick look at the docs seems to indicate that we'd need to do
git pull
git submodule update
which doesn't look like a win over darcs-all. Also, I completely fail to
understand what git
On 12/01/2011, at 22:22, Iavor Diatchki wrote:
When you issue the command git submodule update, you are telling git to
advance the sub-module repo to the expected version (i.e., where the
pointer points to). The reason this does not happen automatically is that
you might have also made
On 11/01/2011, at 16:14, Tony Finch wrote:
On Mon, 10 Jan 2011, Roman Leshchinskiy wrote:
It also seems to make finding buggy patches rather hard.
Have a look at `git bisect`.
I'm aware of git bisect. It doesn't do what I want. I usually have a pretty
good idea of which patch(es) might
On 11/01/2011, at 21:41, Iavor Diatchki wrote:
If GHC and the libraries on which it depends were in git (migrated, or
mirrored), then we could use git sub-modules to track the dependencies
between changes to GHC and changes to the libraries.
Roughly, the workflow would be like this:
On 11/01/2011, at 22:20, Simon Marlow wrote:
On 11/01/11 21:57, Roman Leshchinskiy wrote:
IMO, darcs-all works pretty well. I don't think I ever really had
problems with missing library patches.
I often see problems where someone has done 'darcs pull' rather than
'./darcs-all pull
On 10/01/2011, at 13:27, Simon Marlow wrote:
On 10/01/2011 13:02, Max Bolingbroke wrote:
However, I remember the last time this came up there were some issues
that might make migration painful. From the top of my head:
1) Some people expressed concern that they would have to use two
On 14/12/2010, at 13:35, Johannes Waldmann wrote:
I want to use dph (data parallel haskell) for a presentation.
(Nothing fancy, just compile and run some demos.)
What ghc version should I use and where do I get it?
That's a tricky question. We are currently working on getting DPH to work
On 2 Dec 2010, at 21:29, Andrew Coppin andrewcop...@btinternet.com wrote:
Does anybody have any suggestions?
class Mappable t a b where
type Rebind t a b
map :: (a - b) - t - Rebind a b
This is based on an old C++ trick.
Roman
___
On 25/11/2010, at 10:33, José Pedro Magalhães wrote:
Is this a bug, or is the value of spec-constr-count being manipulated in some
way for certain passes?
spec-constr-count decreases for nested specialisations. For instance, if
spec-constr-count is 6 and SpecConstr generates 2
On 05/11/2010, at 23:22, David Peixotto wrote:
I spent some time looking at the code generated for llvm and the optimizations
it can apply. There were quite a bit of details to examine and I wrote it up
as blog post here:
On 06/11/2010, at 00:28, David Peixotto wrote:
Yes, the LLVM code has Sp, Hp, Base all annotated as noalias. I believe that
Sp, Hp, and Base should never alias, but a (boxed) R1 should always alias
with either Sp or Hp. I had a hard time determining exactly how LLVM uses the
noalias
On 06/11/2010, at 02:27, Sebastian Fischer wrote:
Interesting. This approach requires `f` to be inlined into its call site in
order to eliminate the redundant argument. This is different from the
proposal to provide a specialized version of `f` (where the arguments are
combined) which
On 3 Nov 2010, at 10:45, Christian Hoener zu Siederdissen
choe...@tbi.univie.ac.at wrote:
Thanks, I'll do some measurements on this with ghc7.
Gruss,
Christian
On 11/02/2010 01:23 PM, Simon Marlow wrote:
On 02/11/2010 08:17, Christian Höner zu Siederdissen wrote:
Hi,
is the
LLVM doesn't eliminate the counters. FWIW, fixing this would improve
performance of stream fusion code quite a bit. It's very easy to do in Core.
Roman
On 3 Nov 2010, at 10:45, Christian Hoener zu Siederdissen
choe...@tbi.univie.ac.at wrote:
Thanks, I'll do some measurements on this with
DPH doesn't provide SIMD primitives. Both DPH and vector could greatly benefit
from having them available, though. It would be fantastic if you could add them.
Roman
On 26 Oct 2010, at 10:00, Alexander McPhail haskell.vivian.mcph...@gmail.com
wrote:
Hi,
Does DPH resolve this issue or are
On 16/10/2010, at 12:36, Max Bolingbroke wrote:
On 16 October 2010 12:16, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
eta :: Stream a - Stream a
eta s = Stream s next
where
next (Stream s next') = case next' s of
Just (x,s') - Just (x,Stream s' next
On 16/10/2010, at 12:00, Max Bolingbroke wrote:
Hi Cafe,
I've run across a problem with my use of existential data types,
whereby programs using them are forced to become too strict, and I'm
looking for possible solutions to the problem.
I'm going to explain what I mean by using a
On 11/07/2010, at 22:49, Bryan O'Sullivan wrote:
On Sun, Jul 11, 2010 at 12:59 AM, Dan Doel dan.d...@gmail.com wrote:
You're using GHC 6.12.x presumably?
That's right.
There are known performance problems with
using abstract PrimMonads in that version (and, actually, just using IO as
On 25/06/2010, at 06:41, Alexey Khudyakov wrote:
Then constructor like one below arise naturally. And I don't know how to write
them properly. It's possible to use fromList but then list could be allocated
which is obviously wasteful.
vector2 :: Double - Double - Vec2D
vector2 x y = ...
On 27/06/2010, at 19:54, Max Bolingbroke wrote:
Q: What is the mother of all X, where X is some type class?
A: It is a data type D such that:
1. There exist total functions:
lift :: X d = d a - D a
lower :: X d = D a - d a
Are those universally quantified over d? If so, then none of
On 19/05/2010, at 19:24, Dmitry Olshansky wrote:
Prelude [1,1+2/3..10]
On 19/05/2010, at 20:36, Ivan Lazar Miljenovic wrote:
Roman Leshchinskiy r...@cse.unsw.edu.au writes:
Personally, I consider the Enum class itself to be broken.
Oh? In what sense?
Firstly, the enumFrom* family of functions shouldn't be methods and the class
itself should provide enough
On 19/05/2010, at 23:44, Ben Millwood wrote:
On Wed, May 19, 2010 at 10:57 AM, Serguey Zefirov sergu...@gmail.com wrote:
PS
Rationals:
Prelude [1,1+2/3..10] :: [Rational]
[1 % 1,5 % 3,7 % 3,3 % 1,11 % 3,13 % 3,5 % 1,17 % 3,19 % 3,7 % 1,23 %
3,25 % 3,9 % 1,29 % 3,31 % 3]
Same result.
On 17/05/2010, at 05:17, Gregory Crosswhite wrote:
As an aside, while there are advantages to writing numerical analysis
routines in Haskell, it might be better strategy to instead link in something
like LAPACK and provide nice wrappers to it in Haskell, since this way you
can harness the
On 17/05/2010, at 02:52, Pierre-Etienne Meunier wrote:
You are quite right that vector only supports nested arrays but not
multidimensional ones. This is by design, however - the library's only goal
is to provide efficient one-dimensional, Int-indexed arrays. I'm thinking
about how to
On 16/05/2010, at 10:17, Pierre-Etienne Meunier wrote:
I've also just noticed a lack in the vector library : multidimensional arrays
seem to require indirections like in caml, whereas in C or in Data.Ix, there
is a way to avoid this. This is especially important for avoiding cache
misses
On 16/05/2010, at 11:54, Mark Wassell wrote:
Hi,
This possibly might go against the spirit of what Stream programming is about
but I having difficulties converting an imperative algorithm [1] into Haskell
and think it would be easier if I was able to write it in a monadic style
with
On 11/05/2010, at 05:29, Edward Z. Yang wrote:
Some of the important primitives offered by Data Parallel Haskell are
reduction primitives such as sumP and prodP, which take a data parallel
array and reduce it to a single value. I was wondering what the current
capabilities for end-users
On 07/05/2010, at 19:53, Simon Marlow wrote:
On 05/05/2010 12:24, Roman Leshchinskiy wrote:
Whenever I do cabal sdist on one of my projects, I get this warning:
Distribution quality warnings: 'ghc-options: -O2' is rarely needed.
Check that it is giving a real benefit and not just imposing
On 09/05/2010, at 07:50, Duncan Coutts wrote:
On Wed, 2010-05-05 at 21:24 +1000, Roman Leshchinskiy wrote:
Whenever I do cabal sdist on one of my projects, I get this warning:
Distribution quality warnings:
'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit
Whenever I do cabal sdist on one of my projects, I get this warning:
Distribution quality warnings:
'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit
and not just imposing longer compile times on your users.
This finally got me curious and I did a nofib run to compare
On 04/05/2010, at 11:10, Christian Höner zu Siederdissen wrote:
* Ben Lippmeier b...@ouroborus.net [04.05.2010 02:21]:
You can certainly create an array with these values, but in the provided
code it looks like each successive array element has a serial dependency on
the previous two
On 04/05/2010, at 18:37, Christian Höner zu Siederdissen wrote:
* Roman Leshchinskiy r...@cse.unsw.edu.au [04.05.2010 10:02]:
On 04/05/2010, at 11:10, Christian Höner zu Siederdissen wrote:
Here http://www.tbi.univie.ac.at/newpapers/Abstracts/98-06-009.ps.gz is
a description of a parallel
1 - 100 of 245 matches
Mail list logo
