Re: Revamping the numeric classes

2001-02-07 Thread Tom Pledger
Dylan Thurston writes: : | (A question in the above context is whether the literal '0' should | be interpreted as 'fromInteger (0::Integer)' or as 'zero'. | Opinions?) Opinions? Be careful what you wish for. ;-) In a similar discussion last year, I was making wistful noises about subtyping

Please help me

2001-02-07 Thread FAIZAN RAZA
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 cartesianPr

Re: Revamping the numeric classes

2001-02-07 Thread Ketil Malde
Dylan Thurston <[EMAIL PROTECTED]> writes: > On Wed, Feb 07, 2001 at 01:57:41PM -0500, Dylan Thurston wrote: > > ... One point that has not been made: given a class > > setup like > > > > then naive users can continue to use (Num a) in contexts, and the same > > programs will continue to work.

Re: Revamping the numeric classes

2001-02-07 Thread Marcin 'Qrczak' Kowalczyk
Wed, 7 Feb 2001 16:17:38 -0500, Peter Douglass <[EMAIL PROTECTED]> pisze: > 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 > f

Re: Revamping the numeric classes

2001-02-07 Thread Brian Boutel
Dylan Thurston wrote: > > > Why doesn't your argument show that all types should by instances of > Eq and Show? Why are numeric types special? > Why do you think it does? I certainly don't think so. The point about Eq was that a objection was raised to Num being a subclass of Eq because, for

Re: Revamping the numeric classes

2001-02-07 Thread Dylan Thurston
On Wed, Feb 07, 2001 at 01:57:41PM -0500, Dylan Thurston wrote: > ... One point that has not been made: given a class > setup like > > then naive users can continue to use (Num a) in contexts, and the same > programs will continue to work. I take that back. Instance declarations would change,

Re: Revamping the numeric classes

2001-02-07 Thread Dylan Thurston
On Wed, Feb 07, 2001 at 10:08:26PM +, [EMAIL PROTECTED] wrote: > - 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 to

RE: Revamping the numeric classes

2001-02-07 Thread Peter Douglass
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

Re: Revamping the numeric classes

2001-02-07 Thread andrew
On Wed, Feb 07, 2001 at 11:47:11AM +0100, Ketil Malde wrote: > "Ch. A. Herrmann" <[EMAIL PROTECTED]> 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 m

Re: Revamping the numeric classes

2001-02-07 Thread Dylan Thurston
Other people have been making great points for me. (I particularly liked the example of Dollars as a type with addition but not multiplication.) One point that has not been made: given a class setup like class Additive a where (+) :: a -> a -> a (-) :: a -> a -> a negate :: a -> a zero

Re: Revamping the numeric classes

2001-02-07 Thread Marcin 'Qrczak' Kowalczyk
07 Feb 2001 11:47:11 +0100, Ketil Malde <[EMAIL PROTECTED]> pisze: > If it is useful to have a fine granularity of classes, you can > imagine doing: > > class Multiplicative a b c where > (*) :: a -> b -> c Then a*b*c is ambiguous no matter what are types of a,b,c and th

(no subject)

2001-02-07 Thread Dylan Thurston
___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Show, Eq not necessary for Num [Was: Revamping the numeric classes]

2001-02-07 Thread Jerzy Karczmarczuk
"Ch. A. Herrmann" answers my questions: > Jerzy> What do you mean "predefined" operators? Predefined where? > > In hugs, ":t (*)" tells you: >(*) :: Num a => a -> a -> a > which is an intended property of Haskell, I suppose. Aha. But I would never call this a DEFINITION of this operator

Re: Show, Eq not necessary for Num [Was: Revamping the numeric classes]

2001-02-07 Thread Ch. A. Herrmann
Hi Haskellers, > "Jerzy" == Jerzy Karczmarczuk <[EMAIL PROTECTED]> writes: Jerzy> "Ch. A. Herrmann" wrote: >> the problem is that the --majority, I suppose?-- of >> mathematicians tend to overload operators. They use "*" for >> matrix-matrix multiplication as well as for matr

Re: Show, Eq not necessary for Num [Was: Revamping the numeric classes]

2001-02-07 Thread Jerzy Karczmarczuk
Patrik Jansson wrote: > [I am not sure a more mathematically correct numeric class system is > suitable for inclusion in the language specification of Haskell (a > library would certainly be useful though)] I think it should be done at the language level. Previously Brian Boutel wrote: ...

Re: Revamping the numeric classes

2001-02-07 Thread Ketil Malde
"Ch. A. Herrmann" <[EMAIL PROTECTED]> 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 a

Re: Revamping the numeric classes

2001-02-07 Thread Ch. A. Herrmann
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.