> "Just pairs" have no natural arithmetic upon them.
Exactly my point. > BTW. the missing term of M.M. is DUAL NUMBERS. Remembered this already. Thanks anyway. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
OK, "just pairs" have no arithmetic, but one way of defining
arithmetic is to treat the pairs as complex numbers. Or as mantissa and exponent. Or as something else. So there's nothing wrong, IMO, to make pairs an instance of Num if you so desire. (Though I'd probably introduce a new type.) On Mon, Oct 5, 2009 at 6:46 PM, Miguel Mitrofanov <[hidden email]> wrote: >> "Just pairs" have no natural arithmetic upon them. > > Exactly my point. > >> BTW. the missing term of M.M. is DUAL NUMBERS. > > Remembered this already. Thanks anyway. > > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
And I agree that sometimes it can be suitable.
But simply "defining an instance of Num" without a single word on the problem one is trying to solve is not just pointless. It's something that should not be done. On 5 Oct 2009, at 21:06, Lennart Augustsson wrote: > OK, "just pairs" have no arithmetic, but one way of defining > arithmetic is to treat the pairs as complex numbers. Or as mantissa > and exponent. Or as something else. So there's nothing wrong, IMO, > to make pairs an instance of Num if you so desire. (Though I'd > probably introduce a new type.) > > On Mon, Oct 5, 2009 at 6:46 PM, Miguel Mitrofanov <[hidden email] > > wrote: >>> "Just pairs" have no natural arithmetic upon them. >> >> Exactly my point. >> >>> BTW. the missing term of M.M. is DUAL NUMBERS. >> >> Remembered this already. Thanks anyway. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> [hidden email] >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
>
> On 5 Oct 2009, at 21:06, Lennart Augustsson wrote: > > OK, "just pairs" have no arithmetic, but one way of defining > > arithmetic is to treat the pairs as complex numbers. Or as mantissa > > and exponent. Or as something else. So there's nothing wrong, IMO, > > to make pairs an instance of Num if you so desire. (Though I'd > > probably introduce a new type.) I was looking for one intuitive way of instantiating pairs of numbers as Num. One where i wouldn't have to look in the documentation to remember what (+) does. So considering all these examples of what pairs of numbers could be, i agree with Miguel Mitrofanov: "It's something that should not be done." Two questions remain, i think: 1. How can i have some notion of addition and subtraction for something that i don't want to put in the Num class? That's easy: I could just write a class that defines binary operators (like (+~) and (-~), for example). I don't get the fanciness of (+), but that's okay. 2. How can i use numeric literals to construct values, whose types are not in the Num class? Haskell could provide a class IsNumber (like IsString for string literals). Is that something we would want? BTW, interesting discussion, thanks! Sönke On Monday 05 October 2009 07:24:37 pm Miguel Mitrofanov wrote: > And I agree that sometimes it can be suitable. > > But simply "defining an instance of Num" without a single word on the > problem one > is trying to solve is not just pointless. It's something that should > not be done. > > > > On Mon, Oct 5, 2009 at 6:46 PM, Miguel Mitrofanov <[hidden email] > > > > > wrote: > > > > >>> "Just pairs" have no natural arithmetic upon them. > >> > >> Exactly my point. > >> > >>> BTW. the missing term of M.M. is DUAL NUMBERS. > >> > >> Remembered this already. Thanks anyway. > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> [hidden email] > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > > Haskell-Cafe mailing list > > [hidden email] > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Soenke Hahn
Sönke Hahn schrieb:
> Hi! > > I often stumble upon 2- (or 3-) dimensional numerical data types like > > (Double, Double) > > or similar self defined ones. I like the idea of creating instances for Num for > these types. The meaning of (+), (-) and negate is clear and very intuitive, i > think. I don't feel sure about (*), abs, signum and fromInteger. I used to > implement > > fromInteger n = (r, r) where r = fromInteger n > > , but thinking about it, > > fromInteger n = (fromInteger n, 0) > > seems very reasonable, too. > > Any thoughts on that? How would you do it? I use NumericPrelude that has more fine grained type classes. E.g. (+) is in Additive and (*) is in Ring. http://hackage.haskell.org/package/numeric-prelude _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Monday 05 October 2009 10:14:02 pm Henning Thielemann wrote:
> Sönke Hahn schrieb: > > Hi! > > > > I often stumble upon 2- (or 3-) dimensional numerical data types like > > > > (Double, Double) > > > > or similar self defined ones. I like the idea of creating instances for > > Num for these types. The meaning of (+), (-) and negate is clear and very > > intuitive, i think. I don't feel sure about (*), abs, signum and > > fromInteger. I used to implement > > > > fromInteger n = (r, r) where r = fromInteger n > > > > , but thinking about it, > > > > fromInteger n = (fromInteger n, 0) > > > > seems very reasonable, too. > > > > Any thoughts on that? How would you do it? > > I use NumericPrelude that has more fine grained type classes. E.g. (+) > is in Additive and (*) is in Ring. > > http://hackage.haskell.org/package/numeric-prelude > That is pretty cool, thanks. How do your import statements look like, when you use numeric-prelude? Mine look a bit ugly: import Prelude hiding ((+), (-), negate) import Algebra.Additive ((+), (-), negate) Sönke _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Mon, 5 Oct 2009, Soenke Hahn wrote: > On Monday 05 October 2009 10:14:02 pm Henning Thielemann wrote: >> >> I use NumericPrelude that has more fine grained type classes. E.g. (+) >> is in Additive and (*) is in Ring. >> >> http://hackage.haskell.org/package/numeric-prelude >> > > That is pretty cool, thanks. How do your import statements look like, when you > use numeric-prelude? Mine look a bit ugly: > > import Prelude hiding ((+), (-), negate) > import Algebra.Additive ((+), (-), negate) {-# LANGUAGE NoImplicitPrelude #-} or import Prelude () and import qualified Algebra.Additive as Additive (e.g. for Additive.C) import NumericPrelude import PreludeBase The first form is necessary if you use number literals, what is the case for you I think. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Monday 05 October 2009 11:58:28 pm Henning Thielemann wrote:
> On Mon, 5 Oct 2009, Soenke Hahn wrote: > > On Monday 05 October 2009 10:14:02 pm Henning Thielemann wrote: > >> I use NumericPrelude that has more fine grained type classes. E.g. (+) > >> is in Additive and (*) is in Ring. > >> > >> http://hackage.haskell.org/package/numeric-prelude > > > > That is pretty cool, thanks. How do your import statements look like, > > when you use numeric-prelude? Mine look a bit ugly: > > > > import Prelude hiding ((+), (-), negate) > > import Algebra.Additive ((+), (-), negate) > > {-# LANGUAGE NoImplicitPrelude #-} > > or > > import Prelude () > > and > > import qualified Algebra.Additive as Additive (e.g. for Additive.C) > import NumericPrelude > import PreludeBase > > The first form is necessary if you use number literals, what is the case > for you I think. > Thanks. If you want to use number literals, you have to implement an instance for Algebra.Ring.C, if i understand correctly. Is there any special reason, why fromInteger is a method of Algebra.Ring.C? Sönke _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Soenke Hahn
On Mon, Oct 5, 2009 at 11:02 AM, Sönke Hahn <[hidden email]> wrote:
I don't know how well it works in practice, but you could hide the prelude in your module and then import it qualified. This would allow your module to redefine the normal symbols as the operators you want them to be.
This I don't know how to do without a pre-processor or maybe Template Haskell would work.
Seems like IsBoolean would also be useful if you went this route. And perhaps, IsList :) I'm sure we could think of more. I can see how they would be handy for anyone making an eDSL, especially if combine with view patterns. Jason _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Mon, 5 Oct 2009, Jason Dagit wrote: >> 2. How can i use numeric literals to construct values, whose types are not >> in >> the Num class? Numeric literals are treated as Integer or Rational, and are then converted with the function fromInteger or fromRational, respectively, to the required type. Whatever fromInteger function is in scope, will be used. If fromInteger is in a class other than Num (in NumericPrelude it is Ring, but it can be also a function that is not a class method), then number literals have a type like: 2 :: MyNumClass a => a _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Hi,
On Tue, Oct 6, 2009 at 2:37 AM, Henning Thielemann <[hidden email]> wrote: > Numeric literals are treated as Integer or Rational, and are then converted > with the function fromInteger or fromRational, respectively, to the required > type. Whatever fromInteger function is in scope, will be used. If > fromInteger is in a class other than Num (in NumericPrelude it is Ring, but > it can be also a function that is not a class method), then number literals > have a type like: > 2 :: MyNumClass a => a This is only the case if you use GHC's NoImplicitPrelude extension, otherwise the "fromInteger" of the Prelude is used, even if it is not in scope. Here is an example: module A where boolLit :: Integer -> Bool boolLit 0 = False boolLit _ = True {-# LANGUAGE NoImplicitPrelude #-} module Main where import A(boolLit) import Prelude(Integer,Bool,print) fromInteger :: Integer -> Bool fromInteger = boolLit main = print 0 Note that 0 means different things in the different modules! -Iavor _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Lennart Augustsson
On Oct 6, 2009, at 3:49 AM, Lennart Augustsson wrote: > But complex numbers are just pairs of numbers. So pairs of numbers > can obviously be numbers then. The basic problem here is that pairs of numbers can be made to fit into the Haskell framework with more than one semantics. For example, historically one use for a pair of floating point numbers was to get twice the precision. You implement the operations for that use very differently from the use as complex numbers. If you *know* what you want each of the operations to mean, go ahead. If you don't know, if you have to define some operation just to satisfy the typeclass requirements, and aren't sure what to do in some case, you probably shouldn't use that typeclass. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Soenke Hahn
Soenke Hahn schrieb:
> If you want to use number literals, you have to implement an instance for > Algebra.Ring.C, if i understand correctly. Is there any special reason, why > fromInteger is a method of Algebra.Ring.C? Yes, Ring is the most basic class in the hierarchy that provides a zero, a one and addition, thus you could implement fromInteger by successively adding or subtracting one from zero, given some basic operations on Integer. 'fromInteger' just allows a more efficient implementation. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by MigMit
Why? real numbers, complex nuimbers, n-dimensional spaces have well defined + and * operations (vectorial product in the latter case). even algebraic expressions like:
data Expr = Var String | Number Integer | Sin Expr | Cos Expr can be instances of Num and express certain simplification rules in the definition. instance Num Expr where ... (Sin x) * (Cos x) = (Sin (2 * x))/2 ... I started to develop a extensible symbolic math manipulation around the idea of using symbolic expressions as instances of Num and other basic classes. But I leaved it out due to lack of time.
By the way I attach it just in case anyone want to get some idea from it: module DynAlgebra where data Dyn= forall a.(Num a, Eq a, Show a, Ord a, Read a, Simplify a)=> Dyn a
instance Show Dyn where show (Dyn a)= show a instance Eq Dyn where (Dyn a) == (Dyn b)= solve a== solve b class Simplify a where
simplify :: a -> a solve :: a -> Polonomial Expr1 data Polonomial e = e :/ e | e :+ e | e :* e deriving Show data Expr1= Var String | I Integer | Pi | E deriving Show
-- Integer :/ Integer for exact rational arithmetic data Expr= Polinomial Expr | Formula Dyn deriving (Show, Eq) instance Num (Polonomial Expr1) where
fromInteger = I (+) (I a) (I b)= I (a+b) (+) e1 e2 = e1 :+ e2 (*) (I a) (I b)= I (a*b) (*) e1 e2 = (:*) e1 e2 abs (I x) | x>=0 = I x
| otherwise = I (-x) signum (I x) | x >= 0 = 1 | otherwise= -1 instance Ord Polonomial where compare (I a) (I b)= compare a b
compare ( x :+ z) y | x < y && z >0 = LT | x > y && z >0 = GT compare y ( x :+ z) | y > x && z >0 = LT
| y > x && z >0 = GT instance Eq Polonomial where (I a) == (I b) = a == b (I a :+ I b)== ( I c :+ I d)= a + b== c + d
(I a :* I b)== ( I c :* I d)= a * b== c * d (a :+ b)== (c :+ d)= a==c && b == d (a :* b)== (c :* d)= a== c && b == d (a :/ b)== (c :/ d)= a * d == b * c
exp1 == exp2 = simplify exp1== simplify exp2 instance Simplify (Polonomial Expr1) where solve x = simplify x
simplify ( (I x) :/ (I y))= case quotRem x y of (q,0) -> I q (q,r) -> let m= mcd y r in (I(x `div` m)) :/ (I(y `div` m))
simplify ((I a) :+ (I b))= I (a + b) simplify ((I a) :* (I b))= I (a * b) simplify ((a :* b) :+ (c :* d)) | a == c = simplify $ a * (b :+d)
simplify (exp1 :+ exp2) = simplify exp1 :+ simplify exp2
simplify (exp1 :* exp2) = simplify exp1 :* simplify exp2 simplify expr= expr mcd x y= case mod x y of 0 -> y t -> mcd y t
subst:: Polonomial -> [(String, Polonomial )] -> Polonomial subst exp l= subs1 exp where subs1 (Var v)= case lookup v l of Nothing -> Var v
Just e -> e subs1 (e1 :+ e2) = ((subs1 e1) :+ (subs1 e2)) subs1 (e1 :* e2) = ((subs1 e1) :* (subs1 e2)) subs1 (e1 :/ e2) = ((subs1 e1) :/ (subs1 e2)) subst e= e f x= x :* x main= print $ solve $ 2 :+1 2009/10/5 Miguel Mitrofanov <[hidden email]>
_______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Daniel Fischer-4
Daniel Fischer wrote:
> Am Montag 05 Oktober 2009 16:29:02 schrieb Job Vranish: >> In what way is it not a number? > > If there's a natural[1] implementation of fromInteger, good. > If there isn't, *don't provide one*. > fromInteger _ = error "Not sensible" is better than doing something > strange. > > [1] In the case of residue class rings, you may choose between restricting > [the range of > legitimate arguments for fromInteger or doing a modulo operation on the > argument, both ways are natural and meet expectations sufficiently well. More generally, any ring with multiplicative unit (let's call it 'one') will do. If there were 'one' and 'zero' methods in class Num, we could even give a default implementation (however inefficient) as fromInteger n | n < 0 = negate (fromInteger n) fromInteger n | n > 0 = one + fromInteger (n-1) fromInteger _ = zero In fact, I'd argue that the existence of fromInteger in class Num "morally" implies a unit for multiplication (namely 'fromInteger 1'), otherwise fromInteger isn't even a ring morphism. Cheers Ben _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Wed, Oct 7, 2009 at 12:08 PM, Ben Franksen <[hidden email]> wrote:
> > More generally, any ring with multiplicative unit (let's call it 'one') will > do. Isn't that every ring? As I understand it, the multiplication in a ring is required to form a monoid. -- Dave Menendez <[hidden email]> <http://www.eyrie.org/~zednenem/> _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
A ring is an abelian group in addition, with the added operation (*)
being distributive over addition, and 0 annihilating under multiplication. (*) is also associative. Rings don't necessarily need _multiplicative_ id, only _additive_ id. Sometimes Rings w/o ID is called a Rng (a bit of a pun). /Joe On Oct 7, 2009, at 4:41 PM, David Menendez wrote: > On Wed, Oct 7, 2009 at 12:08 PM, Ben Franksen > <[hidden email]> wrote: >> >> More generally, any ring with multiplicative unit (let's call it >> 'one') will >> do. > > Isn't that every ring? As I understand it, the multiplication in a > ring is required to form a monoid. > > -- > Dave Menendez <[hidden email]> > <http://www.eyrie.org/~zednenem/> > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Am Mittwoch 07 Oktober 2009 22:44:19 schrieb Joe Fredette:
> A ring is an abelian group in addition, with the added operation (*) > being distributive over addition, and 0 annihilating under > multiplication. (*) is also associative. Rings don't necessarily need > _multiplicative_ id, only _additive_ id. Sometimes Rings w/o ID is > called a Rng (a bit of a pun). > > /Joe In my experience, the definition of a ring more commonly includes the multiplicative identity and abelian groups with an associative multiplication which distributes over addition are called semi-rings. There is no universally employed definition (like for natural numbers, is 0 included or not; fields, is the commutativity of multiplication part of the definition or not; compactness, does it include Hausdorff or not; ...). _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
I was just quoting from Hungerford's Undergraduate text, but yes, the
"default ring" is in {Rng, Ring}, I haven't heard semirings used in the sense of a Rng. I generally find semirings defined as a ring structure without additive inverse and with 0-annihilation (which one has to assume in the case of SRs, I included it in my previous definition because I wasn't sure if I could prove it via the axioms, I think it's possible, but I don't recall the proof). Wikipedia seems to agree with your definition, though it does have a note which says some authors use the definition of Abelian Group + Semigroup (my definition) as opposed to Abelian Group + Monoid (your defn). Relevant: http://en.wikipedia.org/wiki/Semiring http://en.wikipedia.org/wiki/Ring_(algebra) http://en.wikipedia.org/wiki/Ring_(algebra)#Notes_on_the_definition /Joe On Oct 7, 2009, at 5:41 PM, Daniel Fischer wrote: > Am Mittwoch 07 Oktober 2009 22:44:19 schrieb Joe Fredette: >> A ring is an abelian group in addition, with the added operation (*) >> being distributive over addition, and 0 annihilating under >> multiplication. (*) is also associative. Rings don't necessarily need >> _multiplicative_ id, only _additive_ id. Sometimes Rings w/o ID is >> called a Rng (a bit of a pun). >> >> /Joe > > In my experience, the definition of a ring more commonly includes > the multiplicative > identity and abelian groups with an associative multiplication which > distributes over > addition are called semi-rings. > > There is no universally employed definition (like for natural > numbers, is 0 included or > not; fields, is the commutativity of multiplication part of the > definition or not; > compactness, does it include Hausdorff or not; ...). > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Am Mittwoch 07 Oktober 2009 23:51:54 schrieb Joe Fredette:
> I was just quoting from Hungerford's Undergraduate text, but yes, the > "default ring" is in {Rng, Ring}, I haven't heard semirings used in > the sense of a Rng. It's been looong ago, I seem to have misremembered :? But there used to be a german term for Rngs, and it was neither Pseudoring nor quasiring, so I thought it was Halbring. > I generally find semirings defined as a ring > structure without additive inverse and with 0-annihilation (which one > has to assume in the case of SRs, I included it in my previous > definition because I wasn't sure if I could prove it via the axioms, I > think it's possible, but I don't recall the proof). 0*x = (0+0)*x = 0*x + 0*x ==> 0*x = 0 > > Wikipedia seems to agree with your definition, though it does have a > note which says some authors use the definition of Abelian Group + > Semigroup (my definition) as opposed to Abelian Group + Monoid (your > defn). > > Relevant: > > http://en.wikipedia.org/wiki/Semiring > http://en.wikipedia.org/wiki/Ring_(algebra) > http://en.wikipedia.org/wiki/Ring_(algebra)#Notes_on_the_definition > > /Joe > > On Oct 7, 2009, at 5:41 PM, Daniel Fischer wrote: > > Am Mittwoch 07 Oktober 2009 22:44:19 schrieb Joe Fredette: > >> A ring is an abelian group in addition, with the added operation (*) > >> being distributive over addition, and 0 annihilating under > >> multiplication. (*) is also associative. Rings don't necessarily need > >> _multiplicative_ id, only _additive_ id. Sometimes Rings w/o ID is > >> called a Rng (a bit of a pun). > >> > >> /Joe > > > > In my experience, the definition of a ring more commonly includes > > the multiplicative > > identity and abelian groups with an associative multiplication which > > distributes over > > addition are called semi-rings. > > > > There is no universally employed definition (like for natural > > numbers, is 0 included or > > not; fields, is the commutativity of multiplication part of the > > definition or not; > > compactness, does it include Hausdorff or not; ...). _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Free forum by Nabble | Edit this page |