>> I understood (apparently correctly) that Brett *knows* the inverse of
>> functions he is interested in.
Exactly.
>> The problem is that in Haskell it is not possible to distinguish
>> between functions, they do not belong to the Eq class
Yes, I believe this is the heart of the problem. A newbie error on my
part. A language like C would allow you to do something silly like
comparing the addresses of the functions to test for equality.
Which is really just a (bad) way to do this...
>> ... you can always envelop a function in a record and add a *constant*
>> label, say (Inv "sin" arcsin), and use such a structure instead of your
>> function.
Which is what I ultimately did with something like...
data Transform = Translate Vector | Rotate Vector | Scale Vector
data Object = Plane [Transform] | Sphere [Transform]
> Hmmm. The IO is not so limited in a *real* case. Concretely, you
> generate pixel by pixel, and you have to operate upon an *updateable*
> frame buffer.
I was planning on just writing the resultant image to a file. I'm not sure
what I would gain by accessing an updateable frame buffer, as displaying
the resultant image would be accomplished by some other program.
>> the bulk of the complexity is
>> elsewhere. It is the calculus of intersections with *all* the objects
>> of the scene
I agree. That is why I tried to make the intersection functions as simple
as possible and what led me to the previously mentioned (bad?) design,
which, if nothing else, is simple.
>> and the Renderman-compatible ones (BMRT, etc.) use
>> a specific "shader language" which is worse than C!
The RT I am familiar with (Pov-Ray) also has its own specific language.
This was also part of my motivation, as haskell seems like a very good
replacement for it.
>> For the moment I plan (?) to do something of that kind in Clean.
I am unfamiliar with Clean. Is this a speed issue?
Thanks-
Brett Letner
