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? btw: These are two examples i looked at in hackage: Data.Complex.Complex (which is special, cause it is mathematically defined, what (*), abs, signum and fromInteger should do (i think)) and Physics.Hipmunk.Common.Vector (http://hackage.haskell.org/packages/archive/Hipmunk/5.0.0/doc/html/Physics- Hipmunk-Common.html#9) Sönke _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
You are in luck!
Such an instance is very simple with Applicative. If the type you want a Num instance for is a member of the Applicative type class you can define it like this: instance (Num a) => Num (Vector2 a) where a + b = pure (+) <*> a <*> b a - b = pure (-) <*> a <*> b a * b = pure (*) <*> a <*> b negate a = pure negate <*> a abs a = pure abs <*> a signum = fmap signum fromInteger = pure . fromInteger If you want to define a Num instance for _all_ applicatives, you can do this (you'll need a couple extensions): instance (Num a, Applicative f, Eq (f a), Show (f a)) => Num (f a) where a + b = pure (+) <*> a <*> b a - b = pure (-) <*> a <*> b a * b = pure (*) <*> a <*> b negate a = pure negate <*> a abs a = pure abs <*> a signum = fmap signum fromInteger = pure . fromInteger I am currently working on a vector and matrix library for haskell that uses instances of this form, which you can find here: http://github.com/jvranish/VectorMatix. The matrix half is very unfinished, but the vector half is pretty much done. Applicative is a pretty fantastic typeclass, it's definitly worth the time to figure out how it works. However, this technique won't work with tuples as they don't behave as Functors in the way you would like. (too many type parameters, tuples don't force all elements to be the same type so maps don't work, etc...) Hope that helps :) - Job On Mon, Oct 5, 2009 at 8:40 AM, Sönke Hahn <[hidden email]> wrote: Hi! _______________________________________________ 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 wrote: > 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. Stop pretending something is a number when it's not. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
That's not gonna happen until when/if Haskell supports name/operator overloading. There's a scarcity of good symbols/function names and everyone wants to use them. So naturally, type class abuse follows. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Oct 5, 2009, at 7:12 AM, Miguel Mitrofanov wrote: > > > Sönke Hahn wrote: > >> 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. > > Stop pretending something is a number when it's 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 |
In reply to this post by MigMit
And what is a number? Are complex numbers numbers?
On Mon, Oct 5, 2009 at 3:12 PM, Miguel Mitrofanov <[hidden email]> wrote: > > > Sönke Hahn wrote: > >> 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. > > Stop pretending something is a number when it's 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 |
In reply to this post by MigMit
Miguel Mitrofanov rebukes Sönke Hahn, who -:
> wrote: >> 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. > Stop pretending something is a number when it's not. Miguel Mitrofanov, please kindly stop pretending that you KNOW what is a number, and what is not. The numeric classes in standard Haskell are disgraceful, and the idea that if something can be added, it is a number is bad. Vectors are not numbers, but inventing "special" (+) for all kinds of Abelian additions is awkward. So, people call "numbers" what they wish, and it is *their* business. I needed to add functions (of course, without Eq nor Show membership), I had to fake... Pairs (a,b) may be "numbers" in various contexts, for example (value,derivative) in automatic differentiation. Or (mainTerm,otherOrders) in some infinitesimal calculus. Or pairs (scalar, 3vector) for quaternions. The idea of putting fromInteger in the same class, is a design bug (my personal opinion, of course). There are plenty of examples where conversions from integers are legitimate, but no addition or (*)seem natural. Or the other way round ; apparently Sönke Hahn is in that situation, so he fakes... Jerzy Karczmarczuk _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by MigMit
In what way is it not a number?
data MyNumber a = MyNum a a deriving (Show, Eq) instance Functor MyNum where fmap f (MyNum a b) = MyNum (f a) (f b) instance Applicative MyNum where pure a = MyNum a a MyNum f g <*> MyNum a b = MyNum (f a) (g b) instance (Num a) => Num (MyNum a) where a + b = pure (+) <*> a <*> b a - b = pure (-) <*> a <*> b a * b = pure (*) <*> a <*> b negate a = pure negate <*> a abs a = pure abs <*> a signum = fmap signum fromInteger = pure . fromInteger This instance obeys the commutative, distributive, and associative laws, and the multiplicative, and additive identities. (at least, if the numbers it contains satisfy those laws) How is MyNum not a number? Sönke Hahn: btw, I forgot to mention in my first email, but fromInteger n = (r, r) where r = fromInteger n is better than: fromInteger n = (fromInteger n, 0) as you get a lot of corner cases otherwise. I use fromInteger = pure . fromInteger, which when combined with my Applicative instance, is effectively the same as your: fromInteger n = (r, r) where r = fromInteger n - Job On Mon, Oct 5, 2009 at 9:12 AM, Miguel Mitrofanov <[hidden email]> wrote:
_______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by jerzy.karczmarczuk
> Miguel Mitrofanov, please kindly stop pretending that you KNOW
> what is a number, and what is not. Never said that. Sometimes it's debatable. But if you can't figure out a way to multiply things so that it would make some kind of sense - you haven't made them numbers (yet). > The numeric classes in standard Haskell are disgraceful, and the idea > that if something can be added, it is a number is bad. Which is kinda my point. > So, people call "numbers" what they wish, and it is *their* business. I'm not sure what do you mean here. Of course, it's OK to call anything "numbers" provided that you stated explicitly what exactly you would mean by that. But then you have to drop all kind of stuff mathematicians developed for the usual notion of numbers. In the same way, you shouldn't use the "Num" class for your "numbers". On the other hand, people can (ab)use the "Num" class as they wish, and it's their business until they ask a question about it somewhere outside - which makes the business not only theirs. > Pairs (a,b) may be "numbers" in various contexts, for example > (value,derivative) in automatic differentiation. Or (mainTerm,otherOrders) > in some infinitesimal calculus. Or pairs (scalar, 3vector) for quaternions. Or (real, imaginary) for complex numbers. That's right. All these notions are very different - which is why "pairs of numbers" are NOT numbers - but "complex numbers" are, as well as "value-derivative pairs". Isn't that what we have newtypes for? > There are plenty of examples where conversions from integers are legitimate, > but no addition or (*)seem natural. Certainly. I think it's commonplace that numerical classes in Haskell Prelude are not exactly an example of perfect design. Still, it doesn't make it good to abuse classes like "Num" just because we want a fancy plus sign. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Lennart Augustsson
Lennart Augustsson wrote:
> And what is a number? Can't say. You know, it's kinda funny to ask a biologist what it means to be alive. > Are complex numbers numbers? Beyond any reasonable doubt. Just like you and me are most certainly alive. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
But complex numbers are just pairs of numbers. So pairs of numbers
can obviously be numbers then. On Mon, Oct 5, 2009 at 4:40 PM, Miguel Mitrofanov <[hidden email]> wrote: > Lennart Augustsson wrote: >> >> And what is a number? > > Can't say. You know, it's kinda funny to ask a biologist what it means to be > alive. > >> Are complex numbers numbers? > > Beyond any reasonable doubt. Just like you and me are most certainly alive. > Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by MigMit
On Mon, Oct 5, 2009 at 10:36 AM, Miguel Mitrofanov
<[hidden email]> wrote: [...] > Of course, it's OK to call anything "numbers" provided that you stated > explicitly what exactly you would mean by that. But then you have to drop > all kind of stuff mathematicians developed for the usual notion of numbers. > In the same way, you shouldn't use the "Num" class for your "numbers". > > On the other hand, people can (ab)use the "Num" class as they wish, and it's > their business until they ask a question about it somewhere outside - which > makes the business not only theirs. [...] The Num class has `negate' as part of its definition. Natural numbers are numbers, but I don't believe there is any sensible definition of `negate' for them. Haskell 98's numeric hierarchy combines many operations which should be separate. As further evidence, every bit of Haskell I have seen that does symbolic manipulation of numeric expressions either leaves out instances that would make the syntax more convenient, or else defines partial instances because certain class functions have no sensible definition for symbolic expressions. Sincerely, Brad _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Lennart Augustsson
No, they aren't. They are polynomials in one variable "i" modulo i^2+1.
Seriously, if you say complex numbers are just pairs of real numbers - you have to agree that double numbers (sorry, don't know the exact English term), defined by (a,b)+(c,d) = (a+c,b+d) (a,b)(c,d) = (ac, ad+bc) are just pairs of real numbers too. After that, you have two choices: a) admit that complex numbers and double numbers are the same - and most mathematicians would agree they aren't - or b) admit that the relation "be the same" is not transitive - which is simply bizarre. Lennart Augustsson wrote: > But complex numbers are just pairs of numbers. So pairs of numbers > can obviously be numbers then. > > On Mon, Oct 5, 2009 at 4:40 PM, Miguel Mitrofanov <[hidden email]> wrote: >> Lennart Augustsson wrote: >>> And what is a number? >> Can't say. You know, it's kinda funny to ask a biologist what it means to be >> alive. >> >>> Are complex numbers numbers? >> Beyond any reasonable doubt. Just like you and me are most certainly alive. >> > _______________________________________________ > 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 Brad Larsen
Everyone agrees that the Haskell numeric hierarchy is flawed, but I've
yet to see a good replacement. On Mon, Oct 5, 2009 at 4:51 PM, Brad Larsen <[hidden email]> wrote: > On Mon, Oct 5, 2009 at 10:36 AM, Miguel Mitrofanov > <[hidden email]> wrote: > [...] >> Of course, it's OK to call anything "numbers" provided that you stated >> explicitly what exactly you would mean by that. But then you have to drop >> all kind of stuff mathematicians developed for the usual notion of numbers. >> In the same way, you shouldn't use the "Num" class for your "numbers". >> >> On the other hand, people can (ab)use the "Num" class as they wish, and it's >> their business until they ask a question about it somewhere outside - which >> makes the business not only theirs. > [...] > > The Num class has `negate' as part of its definition. Natural numbers > are numbers, but I don't believe there is any sensible definition of > `negate' for them. > > Haskell 98's numeric hierarchy combines many operations which should > be separate. As further evidence, every bit of Haskell I have seen > that does symbolic manipulation of numeric expressions either leaves > out instances that would make the syntax more convenient, or else > defines partial instances because certain class functions have no > sensible definition for symbolic expressions. > > Sincerely, > Brad > _______________________________________________ > 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 Job Vranish
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. > > Sönke Hahn: > btw, I forgot to mention in my first email, but > fromInteger n = (r, r) where r = fromInteger n > is better than: > fromInteger n = (fromInteger n, 0) > as you get a lot of corner cases otherwise. > > I use fromInteger = pure . fromInteger, which when combined with my > Applicative instance, is effectively the same as your: fromInteger n = (r, > r) where r = fromInteger n > > > - Job > > On Mon, Oct 5, 2009 at 9:12 AM, Miguel Mitrofanov <[hidden email]>wrote: > > Sönke Hahn wrote: > > > > 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. > > > > Stop pretending something is a number when it's not. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by MigMit
Shouldn't the question not be "Is this a number?" but rather "What is
a number?" -- I mean, from an abstract point of view, there's really no such thing, right? We have sets of things which we define an operation that has certain properties, and suddenly we start calling them numbers. Are the Symmetric groups -- which you can multiply and divide, but not add -- numbers? If they aren't, why should Z_n be numbers? What _is_ true, is that you can define a notion of addition and multiplication for both complexes and 'double' "numbers", that doesn't mean they are "numbers", rather, it means they are both Rings. Nor does it imply that they must be "the same" They are both rings over the same set of elements (Lets say, RxR), but with different operations. Furthermore, can't you construct the Rational's from the Integers in a similar way as you construct the complexes from the reals (by modding out an ideal/polynomial (resp)) -- I actually don't know for certain, we haven't gotten that far in my Alg. Class yet. :), but my intuition says that it's likely possible. Point is -- there are lots of classes for which you can implement a useful notion of addition in more than one way -- or a useful notion of some other class function (monad stuff for Lists and Ziplists, for example), but that doesn't necessarily mean that the two things are the same structure, right? /Joe On Oct 5, 2009, at 10:55 AM, Miguel Mitrofanov wrote: > No, they aren't. They are polynomials in one variable "i" modulo > i^2+1. > > Seriously, if you say complex numbers are just pairs of real numbers > - you have to agree that double numbers (sorry, don't know the exact > English term), defined by > > (a,b)+(c,d) = (a+c,b+d) > (a,b)(c,d) = (ac, ad+bc) > > are just pairs of real numbers too. After that, you have two > choices: a) admit that complex numbers and double numbers are the > same - and most mathematicians would agree they aren't - or b) admit > that the relation "be the same" is not transitive - which is simply > bizarre. > > > Lennart Augustsson wrote: >> But complex numbers are just pairs of numbers. So pairs of numbers >> can obviously be numbers then. >> On Mon, Oct 5, 2009 at 4:40 PM, Miguel Mitrofanov <[hidden email] >> > wrote: >>> Lennart Augustsson wrote: >>>> And what is a number? >>> Can't say. You know, it's kinda funny to ask a biologist what it >>> means to be >>> alive. >>> >>>> Are complex numbers numbers? >>> Beyond any reasonable doubt. Just like you and me are most >>> certainly alive. >>> >> _______________________________________________ >> 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 Lennart Augustsson
Lennart Augustsson wrote:
> Everyone agrees that the Haskell numeric hierarchy is flawed, but I've > yet to see a good replacement. > That's because the "good replacement" which is mathematically sound would be a real mess to work with -- for exactly the same reason that Functor , Applicative and Monad are unrelated classes. See [1]. In a prototype language I am playing with, my version of Num depends on 15 'previous' classes, and that's likely to increase, not decrease. Jacques [1] http://repetae.net/recent/out/classalias.html _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by MigMit
Complex numbers are just pairs of numbers, and then the various
operations on them are defined in a specific way. There may be other ways to define the operations on pairs of numbers that makes sense too. You can also view complex numbers as polynomials if you wish. Or two element lists of numbers. My real point is that you shouldn't tell others what they should regard as numbers and what not. Being a number is in the eye of the beholder. :) On Mon, Oct 5, 2009 at 4:55 PM, Miguel Mitrofanov <[hidden email]> wrote: > No, they aren't. They are polynomials in one variable "i" modulo i^2+1. > > Seriously, if you say complex numbers are just pairs of real numbers - you > have to agree that double numbers (sorry, don't know the exact English > term), defined by > > (a,b)+(c,d) = (a+c,b+d) > (a,b)(c,d) = (ac, ad+bc) > > are just pairs of real numbers too. After that, you have two choices: a) > admit that complex numbers and double numbers are the same - and most > mathematicians would agree they aren't - or b) admit that the relation "be > the same" is not transitive - which is simply bizarre. > > > Lennart Augustsson wrote: >> >> But complex numbers are just pairs of numbers. So pairs of numbers >> can obviously be numbers then. >> >> On Mon, Oct 5, 2009 at 4:40 PM, Miguel Mitrofanov <[hidden email]> >> wrote: >>> >>> Lennart Augustsson wrote: >>>> >>>> And what is a number? >>> >>> Can't say. You know, it's kinda funny to ask a biologist what it means to >>> be >>> alive. >>> >>>> Are complex numbers numbers? >>> >>> Beyond any reasonable doubt. Just like you and me are most certainly >>> alive. >>> >> _______________________________________________ >> 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 Lennart Augustsson
L.A. says:
> complex numbers are just pairs of numbers. Later : > Being a number is in the eye of the beholder. :) Now, the readers of this forum will with horror witness a discussion about the meaning of the word "just"... American people will call it a discussion about "semantics", and we, European will not understand why this word is used in a pejorative context... "Just pairs" have no natural arithmetic upon them. All the standard set theory will not help in "making numbers", unless we inject the notion of equivalence à la Gottlob Frege. And this is surely contextual, but perhaps "the eye of the beholder" should be somehow objectivized... BTW. the missing term of M.M. is DUAL NUMBERS. Lennart continues : > Everyone agrees that the Haskell numeric hierarchy is flawed, > but I've yet to see a good replacement. There *are* some "mathematical preludes" for Haskell. There were attempts to emulate the structures of, say, the C.A.S. Magma in FP (I lost the references...) http://www.haskell.org/haskellwiki/Mathematical_prelude_discussion The problem is, that Haskell is a huge factory, people responsible NOW for its evolution have other priorities. But the story has at least 15 years. Jeroen Fokker did something then, I worked on it at the same period. Now Jacques Carette has his own system, and Sergey Mechveliani another one... But other people don't care, so the efforts are atomized. Please, keep cool. Jerzy Karczmarczuk _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
[hidden email] wrote:
> American people will call it a discussion about "semantics", and > we, European will not understand why this word is used in a pejorative > context... "Semantics" *should* be a pejorative word unless it refers to something formally specified, and preferably executable or machine-checkable. Those subtle Contintental critics of informal semantics, namely Derrida, Irigaray, et al, showed us why. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Lennart Augustsson
On 5 Oct 2009, at 19:17, Lennart Augustsson wrote: > Complex numbers are just pairs of numbers, What about dual numbers? (Yes, I've remembered the term) Aren't they also just pairs of numbers? > There may be other ways to define the operations on pairs of numbers > that makes sense too. But these aren't the ways to define pairs of numbers, right? > My real point is that you shouldn't tell others what they should > regard as numbers and what not. Suppose somebody asks why his Haskell program doesn't work, and after some interrogation he reveals that he just renamed Program.hs to Program.exe. Shouldn't we tell him NOT to do this? > Being a number is in the eye of the beholder. :) Yes, and some points of view aren't as good as other. That's why we have psychiatric hospitals. > > On Mon, Oct 5, 2009 at 4:55 PM, Miguel Mitrofanov <[hidden email] > > wrote: >> No, they aren't. They are polynomials in one variable "i" modulo >> i^2+1. >> >> Seriously, if you say complex numbers are just pairs of real >> numbers - you >> have to agree that double numbers (sorry, don't know the exact >> English >> term), defined by >> >> (a,b)+(c,d) = (a+c,b+d) >> (a,b)(c,d) = (ac, ad+bc) >> >> are just pairs of real numbers too. After that, you have two >> choices: a) >> admit that complex numbers and double numbers are the same - and most >> mathematicians would agree they aren't - or b) admit that the >> relation "be >> the same" is not transitive - which is simply bizarre. >> >> >> Lennart Augustsson wrote: >>> >>> But complex numbers are just pairs of numbers. So pairs of numbers >>> can obviously be numbers then. >>> >>> On Mon, Oct 5, 2009 at 4:40 PM, Miguel Mitrofanov <[hidden email] >>> > >>> wrote: >>>> >>>> Lennart Augustsson wrote: >>>>> >>>>> And what is a number? >>>> >>>> Can't say. You know, it's kinda funny to ask a biologist what it >>>> means to >>>> be >>>> alive. >>>> >>>>> Are complex numbers numbers? >>>> >>>> Beyond any reasonable doubt. Just like you and me are most >>>> certainly >>>> alive. >>>> >>> _______________________________________________ >>> 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 |
Free forum by Nabble | Edit this page |