[prev in list] [next in list] [prev in thread] [next in thread]
List: haskell-cafe
Subject: Re: [Haskell-cafe] Typing in haskell and mathematics
From: Henning Thielemann <lemming () henning-thielemann ! de>
Date: 2005-01-31 17:56:58
Message-ID: Pine.LNX.4.58.0501311836140.25001 () x13 ! informatik ! uni-bremen ! de
[Download RAW message or body]
On Mon, 31 Jan 2005 karczma@info.unicaen.fr wrote:
> Now:
>
> Please don't abuse the examples based on differentiation in order to point
> out the difference between 'expressions with variables' and 'functions'.
> This is simply NOT TRUE that only functions can be differentiated. The
> differentiation is an ALGEBRAIC procedure, people acquainted with the
> differential algebra know that.
Ok, then generalize 'function' to other mathematical objects you like.
E.g. polynomials are a good example. For a polynomial p (a tuple) I can
define D point-wise as
D p = (p_1, 2*p_2, 3*p_3, ..., n*p_n)
Then D fulfills the Leibnitz rule
D (p0*p1) = D p0 * p1 + p0 * D p1
this is probably what you mean.
But I still doubt that it is necessary to accept 'expressions' as
mathematical objects.
> The differentiation (derivation) operator is a linear operator which
> fulfils the Leibniz rule when acting on products.
Linearity of D means for me:
D (k*p) = k * D p
D (p0+p1) = D p0 + D p1
But what is the linearity of an operator acting on an _expression_?
For instance the Simplify function, which is rather an Identity function,
is not linear with respect to expression:
Simplify [3*4] = 12
but if it were linear with respect to expressions it had to be
Simplify [3*4] = 3 * Simplify[4]
Simplify [3*4] = 3 * 4
> Math is not a question of notation, but of structure.
Notation _is_ written structure. As my examples should show there is a
benefit if notation matches the structure of the considered problem.
> The double ordering: a < b < c
> is a very well known contraption in Icon. The operator "<" may confirm
> the inegality or FAIL. The failure is something which propagates across
> all embedded expressions until it is caught. If it succeeds, then it returns
> the SECOND argument. In such a way, going from left to right, "<" gives the
> correct result. This is not 'functional' but I like it.
I also use this short-cut, but I don't expect that to make it work in a
programming language, because you need a lot of explanation to make it
work, thus making the compiler and source code processors more
complicated. All that just for sticking to a habit!
By the way there is a nice functional implementation of a < b < c:
zapWith :: [a -> a -> b] -> [a] -> [b]
zapWith fs xs = zipWith3 id fs xs (tail xs)
usage:
and zapWith [ (<), (<) ]
[a, b, c]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic