[Haskell-cafe] Re: A few ideas about FRP and arbitrary access in time
On Mar 7, 1:01 am, Peter Verswyvelen bugf...@gmail.com wrote: On Wed, Mar 3, 2010 at 8:45 PM, sinelaw jones.noa...@gmail.com wrote: But isn't Lucid Synchrone essentially discrete-timed? Also, events Maybe reality itself can also be modeled using discrete timesteps? If so, then a discrete clock calculus might make a lot of sense. I don't know much about theoretical physics - I think general relativity still is the best model for time, and it's continuous in that model - but maybe the people with a PhD in physics know more about it :-) I don't think a deep knowledge of physics is what we lack here, at least for the question of continuous vs. discrete time. Maybe the best physical model for nature really does involve discrete time steps. However, for our everyday experiences (and maybe for anything that's not on a the tiny quantum scale?) continuous time is the most natural model to follow. And when modeling changing values such as mouse position (the perpetual example...), animations, sound, etc. continuous time seems much more natural. Don't forget to check out the link Conal posted, his short blog post about the subject: http://conal.net/blog/posts/why-program-with-continuous-time/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)
Robert Greayer wrote: There's still a lot of gray area here -- the mere existence of a dependency doesn't imply that a software package is useless without the dependency, so there are many situations in which P could depend on Q and not be a derivative of Q, because the dependency can be disabled in some way and the software would still function. As an example -- pandoc can be built with or without highlighting-kate, and is useful either way. They're both GPL and by the same author, so there's no issue, but were that not the case it would seem obvious that pandoc isn't derivative of -kate, and thus could (by this reasoning) be released independently under different terms. The same may not be true of the hakyll / pandoc situation which sparked this controversy. From what I gather, Hakyll is helper program / library for generating static websites. It uses pandoc to offer a default markdown - html converter, which means that it's also useful without it. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Books for advanced Haskell
Dan Piponi wrote: Günther, A shining example are Dan Piponis blog posts. When you get stuck, post a comment saying where so that I can learn what people find difficult. On the other hand, I understand how intangible not-understanding can be, so it can be hard to point to where the problem is. I'd wager that due to wildly different backgrounds, the difficulties are also different for each person. Lately, I've been dreaming about some kind of (online-) book that covers the missing (Haskell) prerequisites in a modular fashion. I.e. when writing a blog post, you no longer have to implicitly assume / guess something about your readers' background, you can specify it explicitly, something like this module MyBlogPost where import EverythingYouKnowAboutMonoids import MonadsAsComputation import IntuitionAboutDifferentialForms import UnderstandingCurryHowards The book itself would track internal dependencies in the same fashion. Now, tracking each and every prerequisite is impossible, but some useful approximation ought to be possible. I remember a comment about people having trouble understanding monads on #haskell that might be solved by such a book thing. Namely, the main problem was that (a subset of) people simply lacked required Haskell knowledge, like having a good grasp on the distinction between type and type constructor, or being unfamiliar with Maybe. Likewise, it appears that me that a substantial fraction of the comments on RWH are actually about missing or just recently understood prerequisites. Hence, I think that tracking prerequisites explicitly has potential. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Books for advanced Haskell
Hi All What is the state-of-the-practice in type-level programming? I know Günther started this thread about monads, but I seem to remember him having a long running problem with typeful database programming, and I wonder if some of his problems are really in the later area. Compared to monads, type-level programming seems much more a wild frontier - scattered docs, fewer definitive examples, no de-facto standard library. The HList paper provides an implementation of extensible records - have people found it palatable in practice? Roel van Dijk's Hackage rev-dependency page indicates only 1 package depends on it, and HaskellDB appears, at least from a cursory look, to support its own re-implementation of of HList. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GHC's parallel garbage collector -- what am I doing wrong?
On Mar 3, 2010, at 8:44 AM, Simon Marlow wrote: On 01/03/2010 21:20, Michael Lesniak wrote: Hello Bryan, The parallel GC currently doesn't behave well with concurrent programs that uses multiple capabilities (aka OS threads), and the behaviour you see is the known symptom of this.. I believe that Simon Marlow has some fixes in hand that may go into 6.12.2. It's more correct to say the parallel GC has difficulty when one of its threads is descheduled by the OS, because the other threads just spin waiting for it. Presumably some kernels are more susceptible than others due to differences in scheduling policy, I know they've been fiddling around with this a lot in Linux recently. You typically don't see a problem when there are spare cores, the slowdown manifests when you are trying to use all the cores in your machine, so it affects people on dual-cores quite a lot. This probably explains why I've not been particularly affected by this myself, since I do most of my benchmarking on an 8-core box. The fix that will be in 6.12.2 is to insert some yields, so that threads will yield rather than spinning indefinitely, and this seems to help a lot. Be warned that inserting yield into a spin loop is also non-portable, and may make the problem *worse* on some systems. The problem is that yield calls can be taken by the scheduler to mean See, I'm a nice thread, giving up the core when I don't need it. Please give me extra Scheduling Dubloons. Now let's say 7 of your 8 threads are doing this. It's likely that each one will yield to the next, and the 8th thread (the one you actually want on-processor) could take a long time to bubble up and get its moment. At one time on Solaris you could even livelock (because the scheduler didn't try particularly hard to be fair in the case of multiple yielding threads in a single process)---but that was admittedly a long time ago. The only recourse I know about is to tell the OS you're doing synchronization (by using OS-visible locking calls, say the ones in pthreads or some of the lightweight calls that Linux has added for the purpose). Obviously this has a cost if anyone falls out of the spin loop---and it's pretty likely some thread will have to wait a while. -Jan-Willem Maessen Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector stream fusion, inlining and compilation time
On Mar 4, 2010, at 9:05 PM, Roman Leshchinskiy wrote:
On 05/03/2010, at 04:34, stefan kersten wrote:
i've been hunting down some performance problems in DSP code using vector and
the single most important transformation seems to be throwing in INLINE
pragmas
for any function that uses vector combinators and is to be called from
higher-level code. failing to do so seems to prevent vector operations from
being fused and results in big performance hits (the good news is that the
optimized code is quite competitive)
the downside after adding the INLINE pragmas is that now some of my modules
take
_really_ long to compile (up to a couple of minutes); any ideas where i can
start looking to bring the compilation times down again?
Alas, stream fusion (and fusion in general, I guess) requires what I would
call whole loop compilation - you need to inline everything into loops. That
tends to be slow. I don't know what your code looks like but you could try to
control inlining a bit more. For instance, if you have something like this:
foo ... = ... map f xs ...
where
f x = ...
I can confirm that this is a general problem with libraries based on fusion /
deforestation (having done the independent implementation of fusion in pH back
in the day). No INLINE pragma? No fusion for you!
That said, as Roman points out it'd be nice if when GHC discovers something is
inlinable, it would inline the original definition (or perhaps the inlined,
simplified, no-rules-firing version of same). The problem is that this
duplicates a lot of the work of the optimizer a lot of the time.
you could tell GHC not to inline f until fairly late in the game by adding
{-# INLINE [0] f #-}
to the where clause. This helps sometimes.
Hands up if you can remember what things are legal in the braces, and what they
mean. :-) I suspect I'm not the only one for whom remembering this stuff is
fairly hard, in part because it doesn't come up too often.
-Jan-Willem Maessen___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal install darcs fails on Mac OS X Snow Leopard
I'm unable to install darcs using cabal. It seems to be getting an error configuring haskeline.Can anybody help? Thanks cabal -V cabal-install version 0.6.4 using version 1.6.0.3 of the Cabal library bash-3.2$ ghc -V The Glorious Glasgow Haskell Compilation System, version 6.10.4 bash-3.2$ cabal install darcs Resolving dependencies... [1 of 1] Compiling Main ( /var/folders/Gj/Gj20S2zmFESpNdOqFfUlqTI/-Tmp-/haskeline-0.6.2.26747/haskeline-0.6.2.2/Setup.hs, /var/folders/Gj/Gj20S2zmFESpNdOqFfUlqTI/-Tmp-/haskeline-0.6.2.26747/haskeline-0.6.2.2/dist/setup/Main.o ) Linking /var/folders/Gj/Gj20S2zmFESpNdOqFfUlqTI/-Tmp-/haskeline-0.6.2.26747/haskeline-0.6.2.2/dist/setup/setup ... Configuring haskeline-0.6.2.2... checking whether to use -liconv... using -liconv. *Preprocessing library haskeline-0.6.2.2...* */usr/bin/hsc2hs: line 16: unexpected EOF while looking for matching `'* */usr/bin/hsc2hs: line 17: syntax error: unexpected end of file* Configuring zlib-0.5.2.0... Preprocessing library zlib-0.5.2.0... /usr/bin/hsc2hs: line 16: unexpected EOF while looking for matching `' /usr/bin/hsc2hs: line 17: syntax error: unexpected end of file cabal: Error: some packages failed to install: darcs-2.4 depends on zlib-0.5.2.0 which failed to install. hashed-storage-0.4.7 depends on zlib-0.5.2.0 which failed to install. haskeline-0.6.2.2 failed during the building phase. The exception was: exit: ExitFailure 2 zlib-0.5.2.0 failed during the building phase. The exception was: exit: ExitFailure 2 When I installed ghc on Snow Leopard I followed the instructions at http://www.haskell.org/haskellwiki/Mac_OS_X ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal install darcs fails on Mac OS X Snow Leopard
On Sun, Mar 7, 2010 at 3:44 PM, George Colpitts george.colpi...@gmail.com wrote: /usr/bin/hsc2hs: line 16: unexpected EOF while looking for matching `' /usr/bin/hsc2hs: line 17: syntax error: unexpected end of file Sounds like a problem with hsc2hs itself. When I installed ghc on Snow Leopard I followed the instructions at http://www.haskell.org/haskellwiki/Mac_OS_X It says: Many packages need hsc2hs. To make it work correctly you need similar hackery: * Open /usr/bin/hsc2hs * Insert --cflag=-m32 --lflag=-m32 before $tflag My best guess is that you mistyped this step and dropped a double quote, or something. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell platform for GHC 6.12.1?
Is it possible to post the correct cabal binary at http://www.haskell.org/cabal/download.html ? A while ago I gave up on trying to get GHC 6.12.1 working, for I lost the battle building cabal on my windows machine It would help A LOT when cabal.exe could be downloaded somewhere... Thanks Han Joosten Neil Mitchell wrote: Have you tried compiling cabal-install with GHC 6.12.1? I got these stream errors after I compiled it with 6.10.4, but with 6.12.1 it's working flawless. Woohoo, your tip works! Thanks a lot. Neil 2010/3/6 Neil Mitchell ndmitch...@gmail.com That and all Cabal 0.8 binaries on Windows suffer from zlib corrupted stream issues. I've got cabal-install binary, but it's not worth distributing :-( There is a cabal ticket for this. Thanks, Neil On Fri, Mar 5, 2010 at 11:27 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Andrew Coppin andrewcop...@btinternet.com writes: Is there a reason why a new precompiled binary can't be put up for download? I would assume because no-one has supplied one (Duncan doesn't use Windows; don't know about the rest of the cabal-install developers). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://old.nabble.com/Haskell-platform-for-GHC-6.12.1--tp27778596p27813226.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell course, training
gue.schmidt: Hi all, all going well this year I'll be able to invest some money on becoming a better Haskeller. I think I've reached the point where I need some tutoring, so provided I've got money for travel and course fees, and time, where do I get it? I'm not a student so some courses aren't available to me. There are a number of consultants, http://haskell.org/haskellwiki/Consultants At least some of them will run training courses. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell platform for GHC 6.12.1?
Hi Han, I uploaded my latest version which works with GHC 6.12.1: http://community.haskell.org/~ndm/temp/cabal.zip Hope it helps, Thanks, Neil On Sun, Mar 7, 2010 at 5:59 PM, Han Joosten han.joos...@atosorigin.com wrote: Is it possible to post the correct cabal binary at http://www.haskell.org/cabal/download.html ? A while ago I gave up on trying to get GHC 6.12.1 working, for I lost the battle building cabal on my windows machine It would help A LOT when cabal.exe could be downloaded somewhere... Thanks Han Joosten Neil Mitchell wrote: Have you tried compiling cabal-install with GHC 6.12.1? I got these stream errors after I compiled it with 6.10.4, but with 6.12.1 it's working flawless. Woohoo, your tip works! Thanks a lot. Neil 2010/3/6 Neil Mitchell ndmitch...@gmail.com That and all Cabal 0.8 binaries on Windows suffer from zlib corrupted stream issues. I've got cabal-install binary, but it's not worth distributing :-( There is a cabal ticket for this. Thanks, Neil On Fri, Mar 5, 2010 at 11:27 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Andrew Coppin andrewcop...@btinternet.com writes: Is there a reason why a new precompiled binary can't be put up for download? I would assume because no-one has supplied one (Duncan doesn't use Windows; don't know about the rest of the cabal-install developers). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://old.nabble.com/Haskell-platform-for-GHC-6.12.1--tp27778596p27813226.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal install darcs fails on Mac OS X Snow Leopard
That was it, dropped a double quote, thanks so much ! On Sun, Mar 7, 2010 at 12:13 PM, Ben Millwood hask...@benmachine.co.ukwrote: On Sun, Mar 7, 2010 at 3:44 PM, George Colpitts george.colpi...@gmail.com wrote: /usr/bin/hsc2hs: line 16: unexpected EOF while looking for matching `' /usr/bin/hsc2hs: line 17: syntax error: unexpected end of file Sounds like a problem with hsc2hs itself. When I installed ghc on Snow Leopard I followed the instructions at http://www.haskell.org/haskellwiki/Mac_OS_X It says: Many packages need hsc2hs. To make it work correctly you need similar hackery: * Open /usr/bin/hsc2hs * Insert --cflag=-m32 --lflag=-m32 before $tflag My best guess is that you mistyped this step and dropped a double quote, or something. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GPL answers from the SFLC
Stefan Monnier monn...@iro.umontreal.ca writes: What if a new library X' released under BSD or MIT license implements the X API (making possible to compile Y against it)? Can such a new library X' be licensed under something else than the GPL (we guess Yes because we don't think it is possible to license the API itself)? Yes. So it's okay to reimplement the GPL'd API with a different license -- this is apparently not a derived work -- but making use of it is not allowed? Why should the existence of X' make any difference for the author of Y? Because the existence of X' makes it possible to use Y without using X. The order in which X and X' come to exist doesn't matter. So the ability to *use* is what is crucial here? This is very surprising to me in the context of copyright law. At any rate you'd be able to use the source code of Y for teaching, bedtime reading, or whatever. Normally, I'd expect to write some text and publish it under any license I wish, the exeption being if I incorporate somebody elses work. I also thought merely conforming to an API didn't count as such incorporation, since this would mean glibc would be GPL (using the kernel API), which in turn would make GHC GPL (linking to glibc). This exact scenario took place for the GMP library, whose API was reimplemented as fgmp, specifically so that a user of the GMP library could release their code under a different library than the GPL This sounds very interesting, but unfortunately, I am unable to google any details. Links? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A few ideas about FRP and arbitrary access in time
On Sun, Mar 7, 2010 at 10:01 AM, sinelaw jones.noa...@gmail.com wrote: I don't think a deep knowledge of physics is what we lack here, at least for the question of continuous vs. discrete time. Maybe the best physical model for nature really does involve discrete time steps. However, for our everyday experiences (and maybe for anything that's not on a the tiny quantum scale?) continuous time is the most natural model to follow. And when modeling changing values such as mouse position (the perpetual example...), animations, sound, etc. continuous time seems much more natural. Don't forget to check out the link Conal posted, his short blog post about the subject: http://conal.net/blog/posts/why-program-with-continuous-time/ Sure, using continuous time sounds obvious, but the principle What Would Reality Do feels scary, because we really don't know what Reality is when it comes to time; or anything really, all we have is mathematical models that work good enough, and sometimes we have two different models that are used depending on how we want approach a certain problem (e.g. light: wave versus particle) I'm a game developer and I don't care to much about reality. But when I'm not in hacking mode to Get Things Done, I do care about composable, maintainable, and beautiful pieces software, and the way games are developed today are IMO far from that, so hopefully FRP will solve this one day and be efficient enough to run on average hardware. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GHC's parallel garbage collector -- what am I doing wrong?
On 07/03/10 14:41, Jan-Willem Maessen wrote: On Mar 3, 2010, at 8:44 AM, Simon Marlow wrote: On 01/03/2010 21:20, Michael Lesniak wrote: Hello Bryan, The parallel GC currently doesn't behave well with concurrent programs that uses multiple capabilities (aka OS threads), and the behaviour you see is the known symptom of this.. I believe that Simon Marlow has some fixes in hand that may go into 6.12.2. It's more correct to say the parallel GC has difficulty when one of its threads is descheduled by the OS, because the other threads just spin waiting for it. Presumably some kernels are more susceptible than others due to differences in scheduling policy, I know they've been fiddling around with this a lot in Linux recently. You typically don't see a problem when there are spare cores, the slowdown manifests when you are trying to use all the cores in your machine, so it affects people on dual-cores quite a lot. This probably explains why I've not been particularly affected by this myself, since I do most of my benchmarking on an 8-core box. The fix that will be in 6.12.2 is to insert some yields, so that threads will yield rather than spinning indefinitely, and this seems to help a lot. Be warned that inserting yield into a spin loop is also non-portable, and may make the problem *worse* on some systems. The problem is that yield calls can be taken by the scheduler to mean See, I'm a nice thread, giving up the core when I don't need it. Please give me extra Scheduling Dubloons. Now let's say 7 of your 8 threads are doing this. It's likely that each one will yield to the next, and the 8th thread (the one you actually want on-processor) could take a long time to bubble up and get its moment. At one time on Solaris you could even livelock (because the scheduler didn't try particularly hard to be fair in the case of multiple yielding threads in a single process)---but that was admittedly a long time ago. How depressing, thanks for that :) The only recourse I know about is to tell the OS you're doing synchronization (by using OS-visible locking calls, say the ones in pthreads or some of the lightweight calls that Linux has added for the purpose). Obviously this has a cost if anyone falls out of the spin loop---and it's pretty likely some thread will have to wait a while. Yes, so we tried using futexes on Linux, there's an experimental patch attached to http://hackage.haskell.org/trac/ghc/ticket/3553 it was definitely slower than the spinlocks on the benchmarks I tried. I think the problem is that we're using these spinlocks to synchronise across all cores, and it's likely that these loops will have to spin for a while before exiting becuase one or more of the running cores takes a while to get to a safe point. But really giving up the core and blocking is a lot worse, becuas the wakeup time is so long (you can see it pretty clearly in ThreadScope). Anyway, I hope all this is just a temporary problem until we get CPU-independent GC working. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Recursive definition of fibonacci with Data.Vector
edgar: Hello, why I can't define a recursive vector using Data.Vector, like in the example: import qualified Data.Vector as V let fib = 0 `V.cons` (1 `V.cons` V.zipWith (+) fib (V.tail v)) There's a typo: fib = 0 `V.cons` (1 `V.cons` V.zipWith (+) fib (V.tail fib)) Which let's it typecheck. But I don't think this is a sensible use of vectors. In fact, infinite vectors make no sense, as far as I can tell -- these are fundamentally bounded structures. GHC even optimizes it to: fib = fib (literally!). $ time ./A A: loop -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Recursive definition of fibonacci with Data.Vector
On Mar 7, 2010, at 12:56 PM, Don Stewart wrote:
In fact, infinite vectors make no sense, as far as I can tell -- these
are fundamentally bounded structures.
Fourier analysis? Functional analysis? Hamel bases in Real
analysis? There are lots of infinite dimensional vector spaces out
there.
GHC even optimizes it to:
fib = fib
Sounds like an implementation bug, not an infinite dimensional vector
space bug. My guess is that strictness is getting in the way, and
forcing what would be a lazy call to fib in the corresponding list
code -- fib = 0 : 1 : (zipWith (+) fib (tail fib)) -- into a strict one.
In fact, I'm pretty sure that's what the problem is:
data Vector a = Vector {-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !(Array a)
The !'s mean strict right?___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Recursive definition of fibonacci with Data.Vector
ajs:
On Mar 7, 2010, at 12:56 PM, Don Stewart wrote:
In fact, infinite vectors make no sense, as far as I can tell -- these
are fundamentally bounded structures.
Fourier analysis? Functional analysis? Hamel bases in Real analysis? There
are lots of infinite dimensional vector spaces out there.
Sorry for the overloading, I mean 'vector' in the sense of Data.Vector.
Being strict in the length, its unclear to me that you can do much with
infinite ones :-)
Of course, all the nice optimizations will also work for lazy
structures, like lists, but that's a different library.
GHC even optimizes it to:
fib = fib
Sounds like an implementation bug, not an infinite dimensional vector space
bug. My guess is that strictness is getting in the way, and forcing what
would
be a lazy call to fib in the corresponding list code -- fib = 0 : 1 : (zipWith
(+) fib (tail fib)) -- into a strict one.
In fact, I'm pretty sure that's what the problem is:
data Vector a = Vector {-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !(Array a)
The !'s mean strict right?
That's precisely the right semantics for strict-in-the-length arrays.
And it is brilliant that GHC reduces it all down to the minimal possible
program that has the same semantics as a non-terminating strict-length
infinite array.
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector stream fusion, inlining and compilation time
On 06/03/2010, at 03:10, stefan kersten wrote: i'm still curious, though, why my three versions of direct convolution perform so differently (see attached file). in particular, i somehow expected conv_3 to be the slowest and conv_2 to perform similar to conv_1. any ideas? i haven't had a look at the core yet, mainly because i'm lacking the expertise ... Hmm, one problem is that the current definition of reverse is suboptimal to say the least. I'll fix that. Could you perhaps send me your complete benchmark? Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Recursive definition of fibonacci with Data.Vector
On 08/03/2010, at 12:17, Alexander Solla wrote:
GHC even optimizes it to:
fib = fib
Sounds like an implementation bug, not an infinite dimensional vector space
bug. My guess is that strictness is getting in the way, and forcing what
would be a lazy call to fib in the corresponding list code -- fib = 0 : 1 :
(zipWith (+) fib (tail fib)) -- into a strict one.
In fact, I'm pretty sure that's what the problem is:
data Vector a = Vector {-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !(Array a)
The problem is that you have to allocate an Array of a specific length when
creating a Vector. Arrays are finite by definition. It's not a bug, it's a
feature.
Note that in the context of package vector, vector means a 1-dimensional,
0-indexed array. This is not unusual - see, for instance, the standard C++
library.
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Recursive definition of fibonacci with Data.Vector
On Mar 7, 2010, at 5:22 PM, Don Stewart wrote: Sorry for the overloading, I mean 'vector' in the sense of Data.Vector. Being strict in the length, its unclear to me that you can do much with infinite ones :-) Yeah, fair enough. I studied mathematics, not Haskell's Data.* hierarchy. The potential for confusion is pretty strong, especially since Haskell uses other mathematical terms (functor, monad, etc) with the mathematical meaning in mind. Then again, Haskell type classes are not proper classes -- they're constructible sets of constructible types, at best. Integrals are integer-like, and Haskell derivatives are programming languages like Adga. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A few ideas about FRP and arbitrary access in time
On Mar 7, 2010, at 04:01 , sinelaw wrote: I don't think a deep knowledge of physics is what we lack here, at least for the question of continuous vs. discrete time. Maybe the best There is a discrete time quantum. But unless you're doing simulations at the quantum level, you really don't want to go there (even ignoring that one second of real time would take a really long time to calculate on current hardware :); stick to macrocosmic physics, which is statistically continuous. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: yesod 0.0.0 (web framework)
Hello all, I'm happy to announce the first release of the Yesod Web Framework[1]. This framework has been in development for over a year and is in production use on a number of websites. The project homepage[2] provides a fairly thorough rundown of features; for here, I will suffice to say that this framework aims at the following goals: * RESTful applications * Deployable anywhere (based on WAI) * Safety While this framework is still in active development and can be expected to mature over time, this release is ready for use. To get started quickly, simply install the yesod package from Hackage and type yesod init. Michael [1] http://hackage.haskell.org/package/yesod [2] http://www.yesodweb.com/code.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector stream fusion, inlining and compilation time
I've run into an issue with inlining that I'm not sure how to work around. I am instantiating some pre-existing type classes with Vector-based types. There already exist generic functions in modules I do not control that use this type class, and they are not tagged with the INLINE pragma. I am doubtful, but I figure it is worth at least asking: is there some practical workaround for this kind of situation that anybody knows about? - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector stream fusion, inlining and compilation time
jake.mcarthur: I've run into an issue with inlining that I'm not sure how to work around. I am instantiating some pre-existing type classes with Vector-based types. There already exist generic functions in modules I do not control that use this type class, and they are not tagged with the INLINE pragma. I am doubtful, but I figure it is worth at least asking: is there some practical workaround for this kind of situation that anybody knows about? I don't know of a way, other than patching the library code. If it makes a difference to you, it probably makes a difference to lots of people. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell platform for GHC 6.12.1?
Hi Neil, Thanks for the file. This helps me a great deal moving to GHC 6.12.1 on my windows machine! Cheers, Han Neil Mitchell wrote: Hi Han, I uploaded my latest version which works with GHC 6.12.1: http://community.haskell.org/~ndm/temp/cabal.zip Hope it helps, Thanks, Neil -- View this message in context: http://old.nabble.com/Haskell-platform-for-GHC-6.12.1--tp27778596p27817660.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell course, training
Hi Günther, all going well this year I'll be able to invest some money on becoming a better Haskeller. I think I've reached the point where I need some tutoring, so provided I've got money for travel and course fees, and time, where do I get it? I'm not a student so some courses aren't available to me. please consider the summer school in Applied Functional Programming that we at Utrecht University are going to offer this year for the second time: http://www.utrechtsummerschool.nl/index.php?type=coursescode=H9 While the school is mainly aimed at students (bachelor- and master-level), we have no formal requirement that participants must be students, and we will certainly consider other applications. Cheers, Andres -- Andres Loeh, Universiteit Utrecht mailto:and...@cs.uu.nl mailto:m...@andres-loeh.de http://www.andres-loeh.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
