Semantics of signum

[Dylan Thurston]

On Sat, Feb 10, 2001 at 07:17:57AM +, Marcin 'Qrczak' Kowalczyk wrote:
 Sat, 10 Feb 2001 14:09:59 +1300, Brian Boutel [EMAIL PROTECTED] pisze:
 
  Can you demonstrate a revised hierarchy without Eq? What would happen to
  Ord, and the numeric classes that require Eq because they need signum? 
 
 signum doesn't require Eq. You can use signum without having Eq, and
 you can sometimes define signum without having Eq (e.g. on functions).
 Sometimes you do require (==) to define signum, but it has nothing to
 do with superclasses.

Can you elaborate?  What do you mean by signum for functions?  The 
pointwise signum?  Then abs would be the pointwise abs as well, right?
That might work, but I'm nervous because I don't know the semantics
for signum/abs in such generality.  What identities should they
satisfy?  (The current Haskell report says nothing about the meaning
of these operations, in the same way it says nothing about the meaning
of (+), (-), and (*).  Compare this to the situation for the Monad class,
where the fundamental identities are given.  Oddly, there are identities
listed for 'quot', 'rem', 'div', and 'mod'.  For +, -, and * I can guess
what identities they should satisfy, but not for signum and abs.)

(Note that pointwise abs of functions yields a positive function, which
are not ordered but do have a sensible notion of max and min.)

Best,
Dylan Thurston

___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Semantics of signum

[Marcin 'Qrczak' Kowalczyk]

Sat, 10 Feb 2001 11:25:46 -0500, Dylan Thurston [EMAIL PROTECTED] pisze:

 Can you elaborate?  What do you mean by signum for functions?
 The pointwise signum?

Yes.

 Then abs would be the pointwise abs as well, right?

Yes.

 That might work, but I'm nervous because I don't know the semantics
 for signum/abs in such generality.

For example signum x * abs x == x, where (==) is not Haskell's
equality but equivalence. Similarly to (x + y) + z == x + (y + z).

If (+) can be implicitly lifted to functions, then why not signum?

Note that I would lift neither signum nor (+). I don't feel the need.
It can't be uniformly applied to e.g. () whose result is Bool and
not some lifted Bool, so better be consistent and lift explicitly.

-- 
 __("  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTPCZA
QRCZAK


___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Semantics of signum

[William Lee Irwin III]

On Sat, Feb 10, 2001 at 11:25:46AM -0500, Dylan Thurston wrote:
 Can you elaborate?  What do you mean by signum for functions?  The 
 pointwise signum?  Then abs would be the pointwise abs as well, right?
 That might work, but I'm nervous because I don't know the semantics
 for signum/abs in such generality.  What identities should they
 satisfy?  (The current Haskell report says nothing about the meaning
 of these operations, in the same way it says nothing about the meaning
 of (+), (-), and (*).  Compare this to the situation for the Monad class,
 where the fundamental identities are given.  Oddly, there are identities
 listed for 'quot', 'rem', 'div', and 'mod'.  For +, -, and * I can guess
 what identities they should satisfy, but not for signum and abs.)

Pointwise signum and abs are common in analysis. The identity is:

signum f * abs f = f

I've already done the pointwise case. As I've pointed out before,
abs has the wrong type for doing anything with vector spaces, though,
perhaps, abs is a distinct notion from norm.

On Sat, Feb 10, 2001 at 11:25:46AM -0500, Dylan Thurston wrote:
 (Note that pointwise abs of functions yields a positive function, which
 are not ordered but do have a sensible notion of max and min.)

The ordering you're looking for needs a norm. If you really want a
notion of size on functions, you'll have to do it with something like
one of the L^p norms for continua and the \ell^p norms for discrete
spaces which are instances of Enum. There is a slightly problematic
aspect with this in that the domain of the function does not entirely
determine the norm, and furthermore adequately dealing with the
different notions of measure on these spaces with the type system is
probably also intractable. The sorts of issues raised by trying to
define norms on functions probably rather quickly relegate it to
something the user should explicitly define, as opposed to something
that should appear in a Prelude standard or otherwise. That said,
one could do something like

instance Enum a = Enum (MyTree a) where
... -- it's tricky, but possible, you figure it out

instance (Enum a, RealFloat b) = NormedSpace (MyTree a - b) where
norm f = approxsum $ zipWith (*) (map f . enumFrom $ toEnum 0) weights
where
weights = map (\x - 1/factorial x) [0..]
approxsum [] = 0
approxsum (x:xs)| x  1.0e-6 = 0
| otherwise = x + approxsum xs

and then do the usual junk where

instance NormedSpace a = Ord a where
f  g = norm f  norm g
...


Cheers,
Bill

___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe