- Haskell - Haskell.org

Anyone calculating Nash or Wardrop equilibria in Haskell?
by Steffen Mazanek 28 Feb '03

28 Feb '03

Hello. Haskells declarativity is really useful to transform mathematical models into data types and algorithms. In the context of a seminary I have dealt with equilibria concepts (especially Nash and Wardrop equilibrium) in loss networks. (based on "Non-cooperative routing in loss networks" by Altman et al.) Thereby I have noticed that some algorithms are very easy to implement in Haskell, e.g. the state space or the blocking probability. Surely these algorithms are not efficient, they should just do their jobs. On the other hand there are algorithms, too, which appear to be really hard and long winded to implement, e.g. the equilibria by itself. My question: Is there an elegant way of programming a numerical solver of problems like "given the conditions ... find a solution which minimizes/maximizes the following function ...". Presumably there is no such "way" in general, but maybe someone can give a hint, how to tackle these kinds of problems. Or maybe there are some libraries doing this job. Thanks in advance and best greetings. Steffen Mazanek

1 0

RE: Happy Alex
by Simon Marlow 28 Feb '03

28 Feb '03

> I have successfully used the the excellent haskell tools > Happy and Alex in a > couple of parsing projects, but I have failed when trying to > combine a > monadic Happy grammar (using the %monad and %lexer > directives) together with > an Alex generated okenizer, nor are there any such examples > in the Happy and > Alex distributions. Have anyone tried this combination and > can give me some > advice or a simple example? I've been doing some work on Alex recently, and getting it to work smoothly with Happy's monadic scheme is one of the goals. I'll post something when it's done, but if you want to have a look at the work-in-progress look in the CVS tree, under fptools/happy/alex on the branch simonm-hackery-branch. The other things I'm doing include making Alex's syntax more lex-like and Happy-like (mostly done), making the generated code more efficient in terms of both space and time (mostly done), and adding support for Unicode (not done, I'm still thinking about how best to do this - I have some ideas but suggestions are welcome). Cheers, Simon

1 0

Happy Alex
by Per Larsson 28 Feb '03

28 Feb '03

I have successfully used the the excellent haskell tools Happy and Alex in a couple of parsing projects, but I have failed when trying to combine a monadic Happy grammar (using the %monad and %lexer directives) together with an Alex generated okenizer, nor are there any such examples in the Happy and Alex distributions. Have anyone tried this combination and can give me some advice or a simple example? -- Per

1 0

RE: fundeps known beforehand (was RE: fundeps for extended Monad definition)
by Simon Peyton-Jones 28 Feb '03

28 Feb '03

| since this claims that it will take a Bool and produce a value of type b | for all types b. However, would it be all right to say (in | pseudo-Haskell): | | > f :: exists b . Bool -> b | > f x = x But this is a singularly useless function, because it produces a result of utterly unknown type, so you can't actually use it. For example you could not say f x + 4 Simon

1 0

Announce: Haskell Data Clustering
by Hal Daume III 27 Feb '03

27 Feb '03

Hi all, I've had some software which implements a variety of unsupervised learning (aka clustering) algorithms around for some time, but finally got around to making the source code available. I thought some people on this list might find it of interest, so I include a pointer which explains how it is used: http://www.isi.edu/~hdaume/GDC/ Happy clustering! - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

1 0

Re : escape from existential quantification
by George Russell 27 Feb '03

27 Feb '03

Wang Meng wrote > I understand that existentially bound types cannot escape. > > For example, say we have > data Foo = forall a. Foo Int a > > Then we cannot define a function > extract (Foo i a) = a > > However,this limitation makes it extremly difficult to program with local > quantifications.Is there any way to by pass this? It occasionally happens that I *know* what type is (or at least ought to be) inside an existential type, but unfortunately GHC doesn't, and I need to get the value out. This can be solved using dynamic types, for example you declare the datatype as > data Foo = forall a. Typeable a => Foo Int a (or something like that), then you can extract the a value by going to Dynamic and back.

2 1

escape from existential quantification
by Wang Meng 27 Feb '03

27 Feb '03

I understand that existentially bound types cannot escape. For example, say we have data Foo = forall a. Foo Int a Then we cannot define a function extract (Foo i a) = a However,this limitation makes it extremly difficult to program with local quantifications.Is there any way to by pass this? -W-M- @ @ | \_/

3 2

does this irritate anyone else?
by Mike T. Machenry 26 Feb '03

26 Feb '03

I am trying to use type classes to get some percollate actions through a nested data structure. The problem is I can't make an instance of a class unless the type is defined with newtype or data. This means all of my functions look something like this: findFugitive :: DetectiveLocations -> FugitiveLocations -> Move -> FugitiveLocat findFugitive (DetectiveLocations dL) (FugitiveLocations fL) StartGame = (FugitiveLocations minusSet fL (occupiedStops dL)) instead of this: findFugitive :: DetectiveLocations -> FugitiveLocations -> Move -> FugitiveLocat findFugitive dL fL StartGame = minusSet fL (occupiedStops dL) which is much simpler to read. Why can't I make a normal type an instance of a type class? I get errors that it's an ambiguous type. thanks, -mike

2 3

fundeps for extended Monad definition
by Hal Daume III 26 Feb '03

26 Feb '03

Hi all, I'm hoping someone can explain some weirdnesses to me. I want to have a class that's like the standard Monad class, but is a bit more general. That is, I want: class Monad2 m a ma | m a -> ma, ma -> m a where return2 :: a -> ma bind2 :: Monad2 m b mb => ma -> (a -> mb) -> mb _unused :: m a -> () _unused = \_ -> () Here, all the real work happens in the combined "mb" parameter. The _unused definition is just to get Hugs to realize that 'm' should be of kind * -> * (for GHC, a kind definition does the same thing). I want to be able to define instances like: instance Monad2 [] a [a] where return2 x = [x] bind2 l f = concatMap f l However, in GHC, if I just give the instance declaration (without the function definitions), we get: Cannot unify the type-signature variable `mb' with the type `[b]' Expected type: [b] Inferred type: mb When using functional dependencies to combine Monad2 [] a [a], arising from the instance declaration at /nfs/isd/hdaume/projects/Trials/UsefulDTs/UsefulDTs.hs:114 Monad2 [] b mb, arising from a type signature at /nfs/isd/hdaume/projects/Trials/UsefulDTs/UsefulDTs.hs:114 When trying to generalise the type inferred for `bind2' Signature type: forall a mb1 b1. (Monad2 [] b1 mb1) => [a] -> (a -> mb1) -> mb1 Type to generalise: forall mb1 b1. (Monad2 [] b1 mb1) => [a] -> (a -> mb1) -> mb1 This doesn't make sense to me. Hugs accepts this without complaint. Here's why I don't understand it: We know that m is []. We have an instance definition (the one we're defining) that says that for any type x, we have 'Monad2 [] x [x]' where [] and x determine [x]. This should tell us that mb=[b], but somehow GHC doesn't get that (or there's something wrong with my reasoning). When the funciton definitions are provided for the instance, GHC complains: /nfs/isd/hdaume/projects/Trials/UsefulDTs/UsefulDTs.hs:119: Cannot unify the type-signature variable `mb' with the type `[b]' Expected type: a -> [b] Inferred type: a -> mb In the first argument of `concatMap', namely `f' In the definition of `bind2': concatMap f l and Hugs complains similarly: *** Expected type : (Monad2 [] a [a], Monad2 [] b c) => [a] -> (a -> c) -> c *** Inferred type : (Monad2 [] a [a], Monad2 [] b [c]) => [a] -> (a -> [c]) -> [c] Both are saying that they don't know that mb=[b], but I think the fundeps guarentee this. Note that if we change the type definition of bind2 to: bind2 :: Monad2 m b mb => ma -> (a -> m b) -> m b then Hugs accepts the instance declaration but GHC complains as it did the first time. Can someone explain which is right and why? Thanks! - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

Question about How use the ports in haskell
by Cesar Augusto Acosta Minoli 26 Feb '03

26 Feb '03

2 1