ABX wrote:

> On Wed, 11 Sep 2002 12:13:45 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> 
>>My vote, if you care
>>
> 
> I care, just don't be angry if I choose otherwise :-)
> 


No problem, it's your patch...


> 
>>would go for 'path' but no float, a keyword for 
>>each type/kind. (do you really remember by looking at the SDL that there
>>is various projection for image (using map_type) and which number
>>correspond to what kind ?
>>I do not.
>>
> 
> I do not either but I don't like so many keywords used so rarely. Apropriate
> include file with identifiers assigned to floats could be enough. There are
> two include files with identifiers assigned this way: "functions.inc" and
> "const.inc" ?
> 
> One of my teachers at technical university learned me that I shoudn't remember
> every equation, piece of kowledge, keyword. I should know how to find it if I
> need it.
> 


That's ok for technical inclined people, not for user-friendliness.
Let's me have a last 'extrem' example with POV.

You know there is a poly object... From your teacher point of view, it 
is fine as it is. The order of the poly comes first, then the user must 
provide the right number of float value. It's all in the doc, so no 
problem (even if since the extension, the doc does not give the order 
for more than 7th order while the root solver can handle up to 15th!).

But from a user-friendliness aspect, when Joe user (with a degree in 
math, a.k.a not a mathemacaly ignorant) wants to have a poly equation to 
be rendered, he has to carrefully spot the place for all values, and 
simple things like x^6+y^5+z^4-10=0 turn into a nightmare of values.

If keyword, instead of positional syntax, had been used, it would be
far more easier to use the poly object, and p.b.i might be full of them.
Instead of a long collection of values (with a lot of zero), using 
keyword would have make it easier (*):

   poly { x6 1 y5 1 z4 1 const -10 }

If later the user wants to add a x^2yz^3 term, it's also far easier than
retrieving the correct position in the list:

   poly { x6 1 y5 1 z4 1 const -10 x2yz3 -3 }

As a bad thing is always worth something, I believe iso-surface wouldn't 
have been there so early if poly would have been easier in syntax, and 
their success might have been reduced...



*: Using the classical 'keyword value' paradigm, instead of the 
expectable (but more programmer-hostile) 'value [keyword]' which would
allow "poly { 1 x6 +1 y5 +1 z4 -10 }" (using the unary + for once !!!)

P.S: I removed the order of the poly in the example, but I'm not sure 
that's a good idea, even if the order could be computed at the end of 
the parsing of the poly. Anyway, It's only for the illustration, there 
is no real patch here.

P.S.2: the number of keywords needed for the 15th order poly is between 
800 and 900...(exact number is in the source code formulae) which also 
means good luck to try a 15 th order poly in pov now (that's only about 
800 zero to type and some rigthly placed other values!!!) [I do not want 
to debug your formulae!]

P.S.3: You might ask what the relation with your question... my answer 
is 'Think about user-friendliness, dismiss if you want, but think about it'.

Post a reply to this message