grt-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [grt-talk] Picking targets. Was: Some suggestions.


From: Anton N. Mescheryakov
Subject: Re: [grt-talk] Picking targets. Was: Some suggestions.
Date: Wed, 14 May 2003 10:53:01 +0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401

Nikodemus Siivola wrote:

On Tue, 13 May 2003, Anton N. Mescheryakov wrote:

you provided seem to favor terseness instead of clarity: it's by no means
obious to me what OP3* does and how it's supposed to be used. But it's

The problem above remains. Vector code is something so basic,
that *anyone* should be able to check that it's correct without having to
wrap their minds around op & company.
There are of problems here:
1) Repetative code patterns are *the* source of errors, especialy typos. With centralized facility like the infamous op* macro, you have just one place to check out and fix. 2) Future development. For example, let's imagine we'll be smart enough (?) to add 3DNow!/SSE2 code to speed up vector math. This stuff seems to be scheduled for SBCL at least, BTW. Does the habit of writing vector math "by hand" simplify its integration (*conditional* integration)? I think, it doesn't. The same thing applies to possible loop unrolls, cache optimization, threading and so on. Good degree of abstraction makes things simplier. I think that op* macro is quite dumb and easy to understand while it does good job with vector math.

I think a good test of an operators maintainability is how namable it is?
If you can both give it a short memonic name and and a long descriptive
name it's probably ok.
As you probably could suggest, this code is EXPERIMENTAL. I thought I'd denoted it somehow. While writing Lisp programs, I routinaly add and remove macros, functions and so on. Hence, the code seems to have a lot of non-descriptive features that will be renamed in light of their glory - or suffer M-C-k right in place. So op* and freinds aren't expected to be named "as is". Moreover, they may even don't *survive*. I think they won't survive as you're so strictly against them.

a) Usage of structures instead of vectors is evil;

We'll just have to disagree on this one. Lisps in general are much better
unboxing things inside structs that vectors, and vector match with float
boxing is just unacceptable.
Why???

b) Writing a lot of similar things is COBOL feature, not LISP.

Yeah. But indecipherable operators are never a feature, and don't generally
make maintenance any easier.
That puny op* is just *indecipherable*?
For usage of specialized utilites, read in "On lisp", there is a good point.

OK, I'll try to do something with pattern projection (_mapping_ or
whatever you call it) and probably bounding volumes, if nobody is
already in it.

Bounding is progressing as part of octrees, so you are likely to duplicate
a lot of effort.

Unscheduled.

Do I understand you correctly if you refer by pattern
projection to image maps and uv-mapping? Cool.
Pattern projection, along with texture matrix is obviously nescessary feature for any non-trivial scene. I use a lot of 3D stuff at work and as hobby and I know I'm speaking. Pattern projection (yes, *pattern*, without much of "special" things about image patterns) is "must be" for any rendering engine intended to do something useful, along with bump mapping and possible even shader language.

type. Of course, I can live with it, but it will be better if you
somewhat advocate employment of structures for things like 3D vectors or
RGB colors.

Show me a benchmark that I can believe. Or use use alternative
implementation and compare it side by side with the current one.
Coming soon.

By the way, patches are best sent as context diffs. That way they can
(hopefully) be applied against modified source trees. I'll check yours out
when I have the time, but I'm not really too wild about op3. Maybe I'm just
being boneheaded, so I'll give it a little time to sink in.
The attachments you've seen weren't a patch anyway: they were just an example of that I suggest as a bit better and lispish variant of math.lisp. Of course, I may be wrong here. I don't insist on it, but repetative code, "design patterns" and low level of algorythm abstraction were reasons for me to move to Lisp from mundane languages like Jawa (sic) or C++.

Best regards,
   Anton.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]