[EMAIL PROTECTED] writes
>> Do you want to have a function
>> inverse :: (a -> b) -> (b -> a)
>> so that (inverse f) . f = id
>> ?
>> []
>> that is not possible in the general case.
>> Not to forget that even if it was, not all functions has inverses.
> Perhaps I should elaborate. The specific case I'm looking at is writing a
> simple ray-tracer in haskell.
> [..]
> The way I was looking at attacking this problem was by representing each
> primitive object as some easy to work with base object, followed by any
> necessary transformations. For example, suppose our base plane is y=0, we
> could represent all planes with something like:
>
> data Object = Plane [Transformation] where Transformation consists of the
> obvious rotate, translate, and scale functions.
>
> [..]
Representing planes as Haskell functions (for linear operators)
will cause difficulty in comparing planes for equality, inversing
operators, and such. For example, the inversion of a linear operator
is likely to require its *matrix*.
Sometimes a clever compiler (program transformer) may guess what
is the program f "inverse" to the program g. But generally, such
problematic questions cannot be solved by compilers.
For the ray tracer programming, i would rather suggest to represent
a surface as polyhedron, its sides - as bases of vectors, vectors -
as the number lists, transformations on rays - as matrices.
Then - apply standard techniques with linear algebra of matrices.
And polyhedron matters, convex bodies and such, it is still a mess.
The whole subject is hardly a matter of programming language.
This is mathematics, geometry. Any programming tool will be good -
if only it provides a good piece of library for such geometry.
I am not sure, but probably, Maple, Axiom, other computer algebra
systems have something for this.
One might also hope to develop such library for Haskell, as well.
Personally, i am doing CA in Haskell, but do not deal with convex
geometry.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
