On Sun, 23 Feb 2003 18:12:30 -0500, Warp quoth:

> Christopher James Huff <cja### [at] earthlinknet> wrote:
>>>   There are no "object functions" in POV-Ray.
> 
>> trace(), min_extent(), max_extent(), inside()...I think that's it.
> 
>   Those are vector functions (because they can be used where a vector is
> expected). They are not object functions because they can't be used
> where an object is expected (there are no such functions in POV-Ray).
> 
>   You can call them "functions for getting information about an object",
> but don't mix up type terminology with this. That would only cause
> confusion.

The idea here is to make the manual easier to use.  If putting functions
into only one category causes problems like what Joseph Zeglinsky had,
they should be put in more than one place.  I repeat, is there any reason
why functions can't be placed in more than one category in the manual?

-- 
Mark

Post a reply to this message

I didn't follow this thread because I thought it was a simple answer when it
started out and then it seemed to go a few different directions. Seems a
shared sentiment after looking at some other messages.

Like was pointed out, the "manual" is of the electronic form. I don't
understand why the Index and Search was ever overlooked. If I type the word
strlen into either of those I find all I'd need to know. I'm an avid Index
user and it almost always shows me something I'm trying to find out about
(after double-clicking an item from the list).

However, I can't say that the documentation is perfect. Only that it changes
with time and usually for the better. I liked Joseph Zeglinski's idea of a
printable document which would have an index to page numbers. Something
which would be best done by some sort of document creation program. I
especially liked the Monty Python's Flying Circus remark.
:-)

Most important thing seems to be that all this stimulated a potentially
productive discussion about document layout and keyword types. I was hoping
someone would have carried this over into the appropriate group, namely
p.d.i.. Might be too late for that.

Bob

Post a reply to this message

"Joseph Zeglinski" <JAZ### [at] rogerscom> wrote in message
news:3e598261@news.povray.org...
>
>
> (1) I asked for HELP on the "Newusers" group, because I mistakenly thought it
> was meant for newbies on POVRAY, like myself. If that is the case, based on
> the replies, I am in the wrong group - is there a "tiny tots for POVRAY"
> group?
>

Look on the brightside - at least you didn't post to general. Hope we didn't
scare you off - hang around long enough and you will find the groups a valuable
source of help and information.

> (3) You have been wondering just what kind of a "dolt" ... you were being kind
> ... would dare ask such a stupid and simplistic answer from such an esteemed
> and areodite group of newbies(?), who would be so patient with a newcomer with
> his first post to the website, expecting someone equally new, to answer
> quickly, patiently, and simply - from what he had himself learned in his early
> days as a newbie.
>

Aw, you're being too hard on yourself (and us). You were just unlucky in that
you seemingly answered your own question - now if you'd posted "is there some
way of returning the number of letters in some text..."

>
> (4) Finally ... no one actually took the effort to simply copy the strlen()
> syntax statement into a reply.
> And I thought everybody was so expert in such a simple task.
>

Oops... ;)

> structure, and how poorly the documentation in POVRAY is considered, by some.
>

Poor, no, "intense", yes. Given the features of the Pov sdl, the documentation
is probably some of the best I've come across. It's us damn users who are the
problem.

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> If it doesn't fit in with the more specific categories. The "other" 
> category would be quite small, and easy to check.

  So instead of using a well-defined, unambiguous and logical classification
system, we should use some obscure classification method based on someone's
feelings of what a function does (and if he doesn't feel that a function
does anything concrete, it's given a very abstract "other" classification)?

  I'm still not very comfortable.

  I support the idea that in the sections related to a particular thing
(such as strings or floats) there would be a "see also" subsection with
links to functions used for same purposes, but I don't support the idea
of changing the current classification system.

-- 
#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

Christopher James Huff <cja### [at] earthlinknet> wrote:
> IMO, return type is a terrible way to organize things, with very limited 
> use.

  I have explained why it's a logical system and you have failed to show
where my argumentations went wrong.

-- 
#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

In article <pan### [at] gtenet>,
 Mark Wagner <mar### [at] gtenet> wrote:

> The idea here is to make the manual easier to use.  If putting functions
> into only one category causes problems like what Joseph Zeglinsky had,
> they should be put in more than one place.  I repeat, is there any reason
> why functions can't be placed in more than one category in the manual?

Length and redundancy. It would make the manual longer without adding 
any actual content, and it's harder to keep things up to date when you 
have the same thing documented in multiple places. Hyperlink cross 
references solve most of this problem, but make the documentation more 
complex and even less printable, and a reorganization would eliminate a 
lot of the need for them.

-- 
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