Num instances for 2-dimensional types

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Num instances for 2-dimensional types

Soenke Hahn
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

Job Vranish
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!

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


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

MigMit
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

John A. De Goes

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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

Lennart Augustsson
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

jerzy.karczmarczuk
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

Job Vranish
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:


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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

MigMit
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

MigMit
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

Lennart Augustsson
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

Brad Larsen
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

MigMit
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

Lennart Augustsson
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

Daniel Fischer-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

jfredett
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

Jacques Carette
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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

Lennart Augustsson
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
Reply | Threaded
Open this post in threaded view
|

What is a number. (Was: Num instances for 2-dimensional types)

jerzy.karczmarczuk
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
Reply | Threaded
Open this post in threaded view
|

Re: What is a number. (Was: Num instances for 2-dimensional types)

Anton van Straaten
[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
Reply | Threaded
Open this post in threaded view
|

Re: Num instances for 2-dimensional types

MigMit
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
123