In article <3e5601e0@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Functions are categorized based on what they return.

And I personally have never liked this method.


>   Functions can take any type of parameters (floats, vectors, strings,
> objects...) and it would be too hard and awkward to start categorizing
> them according to what they take as parameter. (For example, how would
> you categorize the trace() function?)

"Other"

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3e56003e.6747031@news.povray.org>,
 mca### [at] aolcom (S McAvoy) wrote:

> I think what George meant was, that to someone starting out using PovRay, the
> manual has too much to much information to take in all at once. Not all users
> are professional IT experts you know. PovRay attracts artists, as well as
> techies, whose search skills may not be the best. It can be daunting trying to
> find information you only have a hazy idea about using a manual you are not
> familiar with. 

The person knew the C strlen() function, which strongly implies he is 
not in that group. It would have been very simple to search the 
documentation for "strlen", or just try it in a simple scene. If he 
hadn't known about strlen(), a slightly more complex search would still 
quickly find it, but I would have reacted differently. (the probability 
of him being a newbie or non-coder type would have been much higher)

Anyway, this is getting out of hand. The question has been answered, 
lets drop it. I'm sorry if I appeared excessively rude, but the 
documentation is written to answer these kinds of questions before they 
are asked, it is annoying and frustrating to have that work ignored.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
>> (For example, how would you categorize the trace() function?)

> "Other"

  Very logical naming? When you want to consult the documentation to
see what was the syntax of that function, you immediately can deduce
by logic that this function is of type "other"? (How do you deduce
that? Perhaps "because it takes lots of mixed-type parameters"? Not
very logical.)

  And what about defined(), dimensions(), dimensions_size(), inside(),
val() and min_extent()? Are they of type "other" (because they use
several types as parameters/return values) or perhaps something else?

  When you know that functions are categorized by their return value,
it's easy to find the function in the documentation. (eg. "min_extent()
returns a vector, thus it's in 'vector functions'")

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3e563e0a@news.povray.org...
> Christopher James Huff <cja### [at] earthlinknet> wrote:
> >> (For example, how would you categorize the trace() function?)
>
> > "Other"
>
>   Very logical naming? When you want to consult the documentation to
> see what was the syntax of that function, you immediately can deduce
> by logic that this function is of type "other"? (How do you deduce

IMHO a less binary approach would be best - the general convention of
catagorising by return seems good, but in the case of, e.g., strlen, it should
appear in both catagories.

IMHO the manual would benefit from more redundancies based on workflow and
common-sense - though I hasten to add that this is largely a criticism of human
beings rather than the manual.

Post a reply to this message

On Fri, 21 Feb 2003 09:45:46 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:


>Anyway, this is getting out of hand. The question has been answered, 
>lets drop it. 
Yes a good idea.

>I'm sorry if I appeared excessively rude, 

No you didn't, nor do I mean to offend.


Regards
        Stephen

Post a reply to this message

In article <3e563e0a@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Very logical naming? When you want to consult the documentation to
> see what was the syntax of that function, you immediately can deduce
> by logic that this function is of type "other"? (How do you deduce
> that? Perhaps "because it takes lots of mixed-type parameters"? Not
> very logical.)

I see a bunch of categories that it doesn't fit in, and one that it 
does. strlen() isn't a float function, it is a string function. 
Categorizing by purpose makes much more sense.


>   And what about defined(), dimensions(), dimensions_size(), inside(),
> val() and min_extent()? Are they of type "other" (because they use
> several types as parameters/return values) or perhaps something else?

If there were more array manipulation functions it would make sense to 
put dimensions() and dimension_size() in an array category. inside(), 
min_extent(), max_extent(), and trace() could fit in an objects 
category. val() is a string function.


>   When you know that functions are categorized by their return value,
> it's easy to find the function in the documentation. (eg. "min_extent()
> returns a vector, thus it's in 'vector functions'")

min_extent() deals with objects, so it's in the category of functions 
that deal with objects.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

in news:3e55ee3f$1@news.povray.org Tom Melly wrote:

> Okay, it returns a float, but IMHO such functions could
> be listed in both sections.

I'll make a small change to the last paragraph of the 
stringfunctionsection so that it specifically mentions and links the 
"stringfunctions" that don't return a string.

Ingo

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> I see a bunch of categories that it doesn't fit in, and one that it 
> does. strlen() isn't a float function, it is a string function. 
> Categorizing by purpose makes much more sense.

  strlen() is a float function.

  There's a good and logical reason for calling it a float function (and
you should know it without me telling it).
  The reason for calling it a float function according to its return value
type is that it can be used anywhere a float is expected. In the same
way a vector function can be used anywhere a vector is expected.

  For example, in the definition of a sphere object the first parameter
is a vector. You can use a vector literal, a vector identifier or a
vector function there. The second parameter is a float. This means that
you can use a float literal, a float identifier or a float function there.
(Of course you can also use expressions which result in a float/vector or
can be promoted to it.)

  So naming and categorizing functions by their return value is not only
logical but it's actualy a categorization by purpose: Float functions are
those which can be used anywhere a float value is expected.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

ingo <ing### [at] tagpovrayorg> wrote:
> I'll make a small change to the last paragraph of the 
> stringfunctionsection so that it specifically mentions and links the 
> "stringfunctions" that don't return a string.

  Perhaps a "see also" section at the end of the function list?

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <3e576a0f@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   strlen() is a float function.

It's part of the string toolkit, meant specifically for working with 
strings. It's a string function. If POV were object oriented, it would 
be a method of string objects, not floats.


>   There's a good and logical reason for calling it a float function (and
> you should know it without me telling it).

Yes, but theres also a logical reason for calling it a string function, 
and a much more intuitive one.


>   So naming and categorizing functions by their return value is not only
> logical but it's actualy a categorization by purpose: Float functions are
> those which can be used anywhere a float value is expected.

But it isn't a categorization by purpose, which is the problem. It is a 
categorization by return type.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message