- Haskell-Cafe - Haskell.org

Please help me
by FAIZAN RAZA 08 Feb '01

08 Feb '01

Hello Please help me to solve this questions Question Cartesian Product of three sets, written as X x Y x Z is defined as the set of all ordered triples such that the first element is a member of X, the second is member of Y, and the thrid member of set Z. write a Haskell function cartesianProduct which when given three lists (to represent three sets) of integers returns a list of lists of ordered triples. For examples, cartesianProduct [1,3][2,4][5,6] returns [[1,2,5],[1,2,6],[1,4,5],[1,4,6],[3,2,5],[3,2,6],[3,4,5],[3,4,6]] Please send me reply as soon as possible Ok I wish you all the best of luck

1 0

RE: Please help me
by Chris Angus 08 Feb '01

08 Feb '01

Faizan, A clue is to use list comprehensions (which are very like ZF set notation) First think how you would define a cartesian product in set notation X x Y x Z = {(x,y,z) | ...} and then think how this is written in list comprehension notation Chris > -----Original Message----- > From: FAIZAN RAZA [mailto:k19990158@192.168.1.4] > Sent: 08 February 2001 13:49 > To: haskell-cafe(a)haskell.org > Subject: Please help me > > > Hello > > > Please help me to solve this questions > > > Question > > Cartesian Product of three sets, written as X x Y x Z is > defined as the set > of all ordered triples such that the first element is a > member of X, the > second is member of Y, and the thrid member of set Z. write a Haskell > function cartesianProduct which when given three lists (to > represent three > sets) of integers returns a list of lists of ordered triples. > > For examples, cartesianProduct [1,3][2,4][5,6] returns > [[1,2,5],[1,2,6],[1,4,5],[1,4,6],[3,2,5],[3,2,6],[3,4,5],[3,4,6]] > > > > Please send me reply as soon as possible > > Ok > > I wish you all the best of luck > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Re: Please help me
by Ashley Yakeley 08 Feb '01

08 Feb '01

At 2001-02-08 02:04, Ashley Yakeley wrote: >That's easy. Just define 'product' as a function that finds the cartesian >product of any number of lists, and then once you've done that you can >apply it to make the special case of three items like this: > >cartesianProduct a b c = product [a,b,c] > >At least, that's how I would do it. eesh, 'product' is something else in the Prelude. Better call it 'cartprod' or something. -- Ashley Yakeley, Seattle WA

1 0

Re: Please help me
by Ashley Yakeley 08 Feb '01

08 Feb '01

At 2001-02-08 13:49, FAIZAN RAZA wrote: >write a Haskell >function cartesianProduct which when given three lists (to represent three >sets) of integers returns a list of lists of ordered triples. That's easy. Just define 'product' as a function that finds the cartesian product of any number of lists, and then once you've done that you can apply it to make the special case of three items like this: cartesianProduct a b c = product [a,b,c] At least, that's how I would do it. -- Ashley Yakeley, Seattle WA

1 0

RE: Revamping the numeric classes
by Peter Douglass 08 Feb '01

08 Feb '01

I have some questions about how Haskell's numeric classes might be revamped. Is it possible in Haskell to circumscribe the availability of certain "unsafe" numeric operations such as div, /, mod? If this is not possible already, could perhaps a compiler flag "-noUnsafeDivide" could be added to make such a restriction? What I have in mind is to remove division by zero as an untypable expression. The idea is to require div, /, mod to take NonZeroNumeric values in their second argument. NonZeroNumeric values could be created by functions of type: Number a => a -> Maybe NonZeroNumeric or something similar. Has this been tried and failed? I'm curious as to what problems there might be with such an approach. --PeterD

2 1

Re: Revamping the numeric classes
by andrew＠andrewcooke.free-online.co.uk 08 Feb '01

08 Feb '01

On Wed, Feb 07, 2001 at 11:47:11AM +0100, Ketil Malde wrote: > "Ch. A. Herrmann" <herrmann(a)infosun.fmi.uni-passau.de> writes: [...] > > the problem is that the --majority, I suppose?-- of mathematicians > > tend to overload operators. They use "*" for matrix-matrix > > multiplication as well as for matrix-vector multiplication etc. > Yes, obviously. On the other hand, I think you could get far by > defining (+) as an operator in a Group, (*) in a Ring, and so forth. As a complete newbie can I add a few points? They may be misguided, but they may also help identify what appears obvious only through use... - understanding the hierarchy of classes (ie constanly referring to Fig 5 in the report) takes a fair amount of effort. It would have been much clearer for me to have classes that simply listed the required super classes (as suggested in an earlier post). - even for me, no great mathematician, I found the forced inclusion of certain classes irritating (in my case - effectively implementing arithmetic on tuples - Enum made little sense and ordering is hacked in order to be total; why do I need to define either to overload "+"?) - what's the deal with fmap and map? > Another problem is that the mathematical constructs include properties > not easily encoded in Haskell, like commutativity, associativity, etc. > > > I don't think that it is acceptable for a language like Haskell > > to permit the user to overload predefined operators, like "*". Do you mean that the numeric classes should be dropped or are you talking about some other overloading procedure? Isn't one popular use of Haskell to define/extend it to support small domain-specific languages? In those cases, overloading operatores via the class mechanism is very useful - you can give the user concise, but stll understandable, syntax for the problem domain. I can see that overloading operators is not good in general purpose libraries, unless carefully controlled, but that doesn't mean it is always bad, or should always be strictly controlled. Maybe the programmer could decide what is appropriate, faced with a particular problem, rather than a language designer, from more general considerations? Balance, as ever, is the key :-) [...] > >From experience, I guess there are probably issues that haven't > crossed my mind. :-) This is certainly true in my case - I presumed there was some deep reason for the complex hierarchy that exists at the moment. It was a surprise to see it questioned here. Sorry if I've used the wrong terminology anywhere. Hope the above makes some sense. Andrew -- http://www.andrewcooke.free-online.co.uk/index.html ----- End forwarded message ----- -- http://www.andrewcooke.free-online.co.uk/index.html

2 1

Re: Revamping the numeric classes
by Ketil Malde 08 Feb '01

08 Feb '01

"Ch. A. Herrmann" <herrmann(a)infosun.fmi.uni-passau.de> writes: > moved to haskell-cafe No, but *now* it is. (Does haskell@ strip Reply-To? Bad list! Bad!) > the problem is that the --majority, I suppose?-- of mathematicians > tend to overload operators. They use "*" for matrix-matrix > multiplication as well as for matrix-vector multiplication etc. Yes, obviously. On the other hand, I think you could get far by defining (+) as an operator in a Group, (*) in a Ring, and so forth. Another problem is that the mathematical constructs include properties not easily encoded in Haskell, like commutativity, associativity, etc. > I don't think that it is acceptable for a language like Haskell > to permit the user to overload predefined operators, like "*". Depends on your definition of overloading. Is there a difference between overloading and instantiating a class? :-) > A cheap solution could be to define a type MathObject and operators like > :*: MathObject -> MathObject -> MathObject > Then, the user can implement: > a :*: b = case (a,b) of > (Matrix x, Matrix y) -> foo > (Matrix x, Vector y) -> bar Yes. If it is useful to have a fine granularity of classes, you can imagine doing: class Multiplicative a b c where (*) :: a -> b -> c now I can do instance Multiplicative (Vector a) (Vector a) (Vector a) where x * y = ... but also scalar multiplication instance Multiplicative a (Vector a) (Vector a) where a * x = .... Also, I think I can define Group a to be Additive a a a => class Group a where -- inherits plus from "Additive" zero :: a instance Group Int where (+) = built_in_int_addition zero = 0::Int Long qualifier lists might be countered by having Classes -- Num, say -- that just serve to include other classes in reasonable collections. Funny mathematical names would - at least to some extent - be avoided by having simple names for the classes actually defining the operators, so that errors will warn you about missing "Multiplicative" rather than Field or Ring or what have you. >From experience, I guess there are probably issues that haven't crossed my mind. :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

(no subject)
by Dylan Thurston 08 Feb '01

08 Feb '01

1 0

RE: GHC Core Language
by Andrew Tolmach 07 Feb '01

07 Feb '01

[moving to haskell-cafe] > From: matt hellige [mailto:matt@immute.net] > a quick question re: ghc's Core language... is it still very similar > to the abstract syntax given in, for example, santos' "compilation by > transformation..." (i think it was his dissertation?) and > elsewhere, or > has it changed significantly in the last couple of years? i only ask > because i know the language used in that paper is somewhat > different from > the Core language given in peyton jones and lester's > "implementing functional > languages" from 92, and includes type annotations and so on. > > m > The current Core language is still quite similar to what is described in Santos' work; see SL Peyton Jones and A Santos, "A transformation-based optimiser for Haskell," Science of Computer Programming 32(1-3), pp3-47, September 1998. http://research.microsoft.com/Users/simonpj/papers/comp-by-trans-scp.ps.gz But there have been some noticeable changes; for example, function arguments are no longer required to be atomic. A more recent version of Core is partially described (omitting types) in SL Peyton Jones & S Marlowe, "Secrets of the Glasgow Haskell Compiler Inliner," IDL'99. http://research.microsoft.com/Users/simonpj/papers/inline.ps.gz

1 0

Re: Revamping the numeric classes
by Ch. A. Herrmann 07 Feb '01

07 Feb '01

moved to haskell-cafe Ketil> E.g. way back, I wrote a simple differential equation solver. Ketil> Now, the same function *could* have been applied to vector Ketil> functions, except that I'd have to decide on how to implement Ketil> all the "Num" stuff that really didn't fit well. Ideally, a Ketil> nice class design would infer, or at least allow me to Ketil> specify, the mathematical constraints inherent in an Ketil> algorithm, and let my implementation work with any data Ketil> satisfying those constraints. the problem is that the --majority, I suppose?-- of mathematicians tend to overload operators. They use "*" for matrix-matrix multiplication as well as for matrix-vector multiplication etc. Therefore, a quick solution that implements groups, monoids, Abelian groups, rings, Euclidean rings, fields, etc. will not be sufficient. I don't think that it is acceptable for a language like Haskell to permit the user to overload predefined operators, like "*". A cheap solution could be to define a type MathObject and operators like :*: MathObject -> MathObject -> MathObject Then, the user can implement: a :*: b = case (a,b) of (Matrix x, Matrix y) -> foo (Matrix x, Vector y) -> bar -- Christoph Herrmann E-mail: herrmann(a)fmi.uni-passau.de WWW: http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html

1 0