On Mon, Apr 29, 2013 at 8:40 PM, Dan Doel wrote:
> On Mon, Apr 29, 2013 at 10:05 AM, Duncan Coutts <
> duncan.cou...@googlemail.com> wrote:
>
>> On Thu, 2013-04-25 at 00:52 +0200, Gábor Lehel wrote:
>> > On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan > >wrote:
>> >
>> > > On Wed, Apr 24, 2013
On Mon, Apr 29, 2013 at 8:35 PM, Duncan Coutts wrote:
> On Mon, 2013-04-29 at 20:19 +0200, Gábor Lehel wrote:
>
> > Thanks for the explanation. I looked at your thesis previously, but only
> > read through a couple of sections (including the one about concatMap). I
> > might go through the state
On Mon, Apr 29, 2013 at 10:05 AM, Duncan Coutts <
duncan.cou...@googlemail.com> wrote:
> On Thu, 2013-04-25 at 00:52 +0200, Gábor Lehel wrote:
> > On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan >wrote:
> >
> > > On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts <
> > > duncan.cou...@googlemail.c
On Mon, 2013-04-29 at 20:19 +0200, Gábor Lehel wrote:
> Thanks for the explanation. I looked at your thesis previously, but only
> read through a couple of sections (including the one about concatMap). I
> might go through the state machine parts as well now that I know the
> significance/relevanc
On Mon, Apr 29, 2013 at 4:05 PM, Duncan Coutts wrote:
> On Thu, 2013-04-25 at 00:52 +0200, Gábor Lehel wrote:
> > On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan >wrote:
> >
> > > On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts <
> > > duncan.cou...@googlemail.com> wrote:
> > >
> > >> I addres
On Thu, 2013-04-25 at 00:52 +0200, Gábor Lehel wrote:
> On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan wrote:
>
> > On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts <
> > duncan.cou...@googlemail.com> wrote:
> >
> >> I address it briefly in my thesis [1], Section 4.8.2. I think it's a
> >> funda
On Thu, Apr 25, 2013 at 9:20 PM, Ben Lippmeier wrote:
>
> On 26/04/2013, at 2:15 PM, Johan Tibell wrote:
>
>> Hi Ben,
>>
>> On Thu, Apr 25, 2013 at 7:46 PM, Ben Lippmeier wrote:
>>> The Repa plugin will also do proper SIMD vectorisation for stream programs,
>>> producing the SIMD primops that Ge
On Thu, Apr 25, 2013 at 10:30 PM, Andrew Cowie
wrote:
> On Thu, 2013-04-25 at 21:15 -0700, Johan Tibell wrote:
>
>> {-# LANGUAGE Strict #-}
>
> God, I would love this. Obviously the plugin approach could do it, but
> could not GHC itself just _not create thunks_ for things unless told to
> be lazy
On Thu, 2013-04-25 at 21:15 -0700, Johan Tibell wrote:
> {-# LANGUAGE Strict #-}
God, I would love this. Obviously the plugin approach could do it, but
could not GHC itself just _not create thunks_ for things unless told to
be lazy in the presence of such a pragma?
[at which point, we need an an
On 26/04/2013, at 2:15 PM, Johan Tibell wrote:
> Hi Ben,
>
> On Thu, Apr 25, 2013 at 7:46 PM, Ben Lippmeier wrote:
>> The Repa plugin will also do proper SIMD vectorisation for stream programs,
>> producing the SIMD primops that Geoff recently added. Along the way it will
>> brutally convert
Hi Ben,
On Thu, Apr 25, 2013 at 7:46 PM, Ben Lippmeier wrote:
> The Repa plugin will also do proper SIMD vectorisation for stream programs,
> producing the SIMD primops that Geoff recently added. Along the way it will
> brutally convert all operations on boxed/lifted numeric data to their unbox
On 25/04/2013, at 3:47 AM, Duncan Coutts wrote:
> It looks like fold and unfold fusion systems have dual limitations:
> fold-based fusion cannot handle zip style functions, while unfold-based
> fusion cannot handle unzip style functions. That is fold-based cannot
> consume multiple inputs, while
Ah, good point.
On Thu, Apr 25, 2013 at 1:06 AM, Dan Doel wrote:
> Presumably concat also has to use skip, for the same reason as filter.
> Otherwise it has to recursively process the outer stream until it gets to a
> non-empty inner stream, which breaks the rule that only the final consumer
> i
Presumably concat also has to use skip, for the same reason as filter.
Otherwise it has to recursively process the outer stream until it gets to a
non-empty inner stream, which breaks the rule that only the final consumer
is recursive.
concat [[1,2,3],[4,5],[],[6,7]]
probably looks something
On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan wrote:
> On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts <
> duncan.cou...@googlemail.com> wrote:
>
>> I address it briefly in my thesis [1], Section 4.8.2. I think it's a
>> fundamental limitation of stream fusion.
>>
>
> See also concat, where th
On Wed, 2013-04-24 at 10:56 -0700, Bryan O'Sullivan wrote:
> On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts <
> duncan.cou...@googlemail.com> wrote:
>
> > I address it briefly in my thesis [1], Section 4.8.2. I think it's a
> > fundamental limitation of stream fusion.
> >
>
> See also concat, wh
On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts <
duncan.cou...@googlemail.com> wrote:
> I address it briefly in my thesis [1], Section 4.8.2. I think it's a
> fundamental limitation of stream fusion.
>
See also concat, where the naive fusion-based implementation has quadratic
performance:
conca
On Sun, 2013-04-21 at 18:07 -0700, Edward Z. Yang wrote:
> Hello all, (cc'd stream fusion paper authors)
>
> I noticed that the current implementation of stream fusion does
> not support "multiple-return" stream combinators, e.g.
> break :: (a -> Bool) -> [a] -> ([a], [a]). I thought a little
> b
On 22/04/2013, at 5:27 PM, Edward Z. Yang wrote:
> So, if I understand correctly, you're using the "online/offline"
> criterion to resolve non-directed cycles in pipelines? (I couldn't
> tell how the Shivers paper was related.)
The "online" criteria guarantees that the stream operator does not
So, if I understand correctly, you're using the "online/offline"
criterion to resolve non-directed cycles in pipelines? (I couldn't
tell how the Shivers paper was related.)
Cheers,
Edward
Excerpts from Ben Lippmeier's message of Sun Apr 21 19:29:29 -0700 2013:
>
> On 22/04/2013, at 12:23 , "Edw
On 22/04/2013, at 12:23 , "Edward Z. Yang" wrote:
>> I've got a solution for this problem and it will form the basis of
>> Repa 4, which I'm hoping to finish a paper about for the upcoming
>> Haskell Symposium.
>
> Sounds great! You should forward me a preprint when you have something
> in pre
> I've got a solution for this problem and it will form the basis of
> Repa 4, which I'm hoping to finish a paper about for the upcoming
> Haskell Symposium.
Sounds great! You should forward me a preprint when you have something
in presentable shape. I suppose before then, I should look at
repa-
On 22/04/2013, at 11:07 , Edward Z. Yang wrote:
> Hello all, (cc'd stream fusion paper authors)
>
> I noticed that the current implementation of stream fusion does
> not support "multiple-return" stream combinators, e.g.
> break :: (a -> Bool) -> [a] -> ([a], [a]). I thought a little
> bit abo
23 matches
Mail list logo
