- Haskell-Cafe - Haskell.org

Google SoC
by Pepe Iborra 21 Apr '06

21 Apr '06

http://code.google.com/soc/ This is not news. SoC was presented a few days ago, and by now there are a lot of projects available, yet none(?) Haskell related :( This is a plea for Haskell FOSS project managers to apply as mentor organizations, so that we students can have a choice. Surely there are a lot of contributions that can be tackled by a motivated student in three months time. GHC related stuff, work in Visual Haskell, tasks in a given Haskell framework, Darcs stuff, you name it. Deadline for mentor organizations is May 1, but they might close it earlier if they get their hands full. pep

2 1

matrix computations based on the GSL
by Alberto Ruiz 21 Apr '06

21 Apr '06

Hello all! This is my first message to the list. In my work I often need linear algebra algorithms and other numeric computations. An option is using scientific computing systems like Matlab, Mathematica, Maple, etc. In Haskell there are several modules and bindings to matrix libraries; many of them are excellent. But I think that Haskell would be even more attractive if the basic matrix computations (what we find, for example, in the GNU Octave Quick Reference) were easily available in a standard library. We have all we need: an interactive environment, excellent graphics (HOpenGL), FFI and ForeignPtr with automatic garbage collection, QuickCheck, etc. Computations can be implemented by the GSL (GNU Scientific Library), a well designed numerical library written in C. Well... I know that I am trying to reinvent the wheel: I am working on a user friendly functional interface to matrix computations based on the GSL. I think that many numeric problems that can be solved using Octave or a similar system can be also solved more elegantly using Haskell. The library is very preliminary and incomplete but some simple problems can already be solved. The sources, haddock documentation and the draft of a tutorial can be found at: http://dis.um.es/~alberto/hmatrix/matrix.html I am not a Haskell expert, I only use the most basic programming techniques, so any suggestion will be greatly appreciated... Alberto

22 97

C++ parser in Haskell?
by Ravi Nanavati 20 Apr '06

20 Apr '06

It turns out we might find such a beast useful at Bluespec. If anyone has written a C++ parser in Haskell (or knows of one), we'd like to hear about it. Thanks, - Ravi Nanavati Bluespec, Inc.

4 4

Spawning a terminal window?
by ihope 20 Apr '06

20 Apr '06

Does Haskell have a handy way to spawn a new terminal window and give you a handle to access it with? --ihope

1 0

Re: [Haskell-cafe] 1G strings in Haskell
by dons＠cse.unsw.edu.au 20 Apr '06

20 Apr '06

dagit: > On 4/19/06, Donald Bruce Stewart <dons(a)cse.unsw.edu.au> wrote: > > Question: > > Can I manipulate 1G strings in Haskell? > > > > > > Failed due to memory exhaustion. > > Almost made it though, just need a tad more ram than I had. > > > > filter ! > > unlines ! > > unwords ! > > reverse ! -- copy > > cons ! -- copy > > snoc ! -- involves a copy > > ++ ! -- can't concat two 1G strings on this box > > I would say given the nature of the experiment that you want to feed > these functions with values that lead to 1 GB results. At least, that > makes sense in the case of ++, but maybe not the others. Yes, good point. Previous experiments with 500M strings indicated that these all worked fine: Size of test data: 531416k Fine: filter 7.264 unwords 1.715 reverse 1.980 cons 0.976 snoc 0.689 ++ 2.845 Still wouldn't work at 0.5G unlines ! concat ! > Did the machine have any available swap? If so, why was it not used? Swap was used, 1G more, but ulimits kicked in a few times (and I'm not an admin on the box). This was a bit frustrating, but the 0.5G results show what is possible. > The strings had to be in memory all at once to not skew the benchmark > by including I/O time? The strings were all in memory, yes, with some deepSeq tricks. -- Don

1 0

1G strings in Haskell
by dons＠cse.unsw.edu.au 20 Apr '06

20 Apr '06

Question: Can I manipulate 1G strings in Haskell? Short answer: Yes! Mostly. Doing some stress testing of FPS, here are some results for 1G strings. 3.2Ghz box, 2G physical mem. Size of input string: 1G N.B. 2G of physical ram is not enough when trying to benchmark functions that copy 1G strings around :) Function Time in seconds All O(1) functions: length O index 0 head 0 tail 0 last 0 init 0 O(n) , but answer found early on: compare 0 any 0 all 0 elem 0 elemIndex 0 O(n) mostly: maximum 3.855 minimum 4.666 filterChar 8.084 elemIndicies 11.504 lines 12.247 find 14.046 tails 27.328 inits 33.620 words 100.963 map toUpper 143.871 Failed due to memory exhaustion. Almost made it though, just need a tad more ram than I had. filter ! unlines ! unwords ! reverse ! -- copy cons ! -- copy snoc ! -- involves a copy ++ ! -- can't concat two 1G strings on this box sort ? taking too long, but space was ok. [Char] functions are much more costly. pack ! -- constructing 1G [Char] is not ok. unpack ! Lesssons, you can play with 1G strings in Haskell. Having more than 2G ram is useful though. Replacing higher order functions with hard coded first order equivalents can help. -- Don

1 0

Re: [Haskell-cafe] Advice needed on best way to simulate an STL vector
by Cale Gibbard 19 Apr '06

19 Apr '06

I should perhaps point out that in the development GHC (iirc), there is a library called Data.Sequence which uses 2-3 finger trees to get rather nice efficient sequences. Operations on both ends (appending or dropping) are constant time, while operations in the middle tend to be on the order of the logarithm of the distance to the closer of the two ends. For instance, concatenation and splitting at a point both have complexity proportional to the logarithm of the smaller of the two parts involved. - Cale On 19/04/06, Brian Hulley <brianh(a)metamilk.com> wrote: > Thanks. I might try this if I don't have any luck with finger trees (from > Udo's post), or if they seem too heavy for the simple thing I'm planning to > use them for (implementing the text buffer for an edit control which needs a > mutable array of lines where each line contains a mutable array of character > info). I don't need non-Int indices so your data type for Vector would be > fine. > > Best regards, Brian. > >

2 1

RE: [Haskell-cafe] Proposal for restructuring Number classes
by Andrew U. Frank 19 Apr '06

19 Apr '06

i am most grateful to henning and dylan for their effort in restructuring the number classes. there seems to be agreement, that the current classes are not optimal. the decision what goes in a class depends enormously on what axioms one is assuming for an operation symbol. should * always be commutative or is its use for non-commutative types acceptable? i will now make an effort to use the proposed classes by dylan and hennig and adapt my code to it and then come back and report how it suited my needs. thank you for the help! andrew frank

2 1

Re: Proposal for restructuring Number classes
by Serge D. Mechveliani 18 Apr '06

18 Apr '06

On Sat, Apr 08, 2006 at 02:39:39PM +0200, Andrew U. Frank wrote: > there has been discussions on and off indicating problems with the structure > of the number classes in the prelude. i have found a discussion paper by > mechveliani but i have not found a concrete proposal on the haskell' list of > tickets. > i hope i can advance the process by making a concrete proposal for > which i attach Haskell code and a pdf giving the rational. if i have not > found other contributions, i am sorry. > > i try a conservative structure, which is more conservative than the > structure we have used here for several years (or mechveliani's proposal). > It suggests classes for units (Zeros, Ones) and CommGroup (for +, -), > OrdGroup (for abs and difference), CommRing (for *, sqr), EuclideanRing (for > gdc, lcm, quot, rem, div...) and Field (for /). I think the proposed > structure could be a foundation for mathematically strict approaches (like > mechveliani's) but still be acceptable to 'ordinary users'. > > i put this proposal for discussion here and hope for suggestions how it can > be improved before i put it to haskell'! > > andrew frank > For a long time, there exist the following documents and programs * BAL library (implemented, downloadible) -- Basic Algebra Library for Haskell, which was a proposal for a new "Num"-like library. * A paper "Haskell and computer algebra" which describes the idea of BAL. * A paper "What should be an universal functional language", which describes, what are the problems of Haskell as related to algebra. These three items can be downloaded from www.botik.ru/~mechvel by clicking at BAL, and at the papers you choose. The main problem with the language can be illustrated by the following example. The domain Matrix(n, m) of matrices n by m depends on the ordinary values. These n, m can be computed in some cycle at run time. But in Haskell, we need to model a _domain_ as a _type_, with several _instances_ for this type. And these latter cannot evolve at run time. For example the domain Matrix(3, m) must have MultiplicativeSemigroup instance -- if m == 3, and must not have such instance otherwise. And m may change at run-time. This is the reason for why BAL looks so complicated -- and why the proposal has been rejected. (By the way, both these papers have been rejected by the conference referrees of the Haskell community and FP community). I think that without dependent types for a Haskell-like language, it is impossible to propose any adequate and in the same time plainly looking algebraic class system. ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Justification for Ord inheriting from Eq?
by Brian Hulley 18 Apr '06

18 Apr '06

Hi - I've been wondering for a long time if there is a reason why Ord should inherit from Eq and not vice versa, or whether in fact there is any justification for making either Ord or Eq inherit from the other one. For example, Ord and Eq could alternatively be defined as: class Ord a where (<), (<=), (>=), (>) : a -> a -> Bool x <= y = not (y < x) x >= y = not (x < y) x > y = y < x class Ord a => Eq a where (==), (/=) :: a -> a -> Bool x /= y = x < y || y < x x == y = not (x /= y) Part of the reason for my question is that it seems to me that the lesson from object oriented programming is that inheritance is usually a bad idea, since very few things (perhaps nothing?) have a single natural taxonomy (witness the efforts to reorganise the numeric hierarchy that have been alluded to on this list). In languages such as C++ the only "good" use of inheritance seems to be when you have an abstract base class representing an interface and multiple concrete derived classes (as immediate children of it) representing the implementations, but in Haskell, this is the class/instance distinction, so I can't see a strong reason why Haskell classes should be allowed to inherit from other classes. Except perhaps Monad, MonadIO, MonadPlus etc... Any thoughts? Thanks, Brian.

14 22