Hi,
    I have a string Value I need to "print". However, in order to scale the
space for the word to fit on the object, I need to know how many charcaters
are in the variable. Is there a strlen() function in POVRAY ?

Thanks.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/01/2003

Post a reply to this message

In article <3e5419b4@news.povray.org>,
 "Joseph Zeglinski" <JAZ### [at] rogerscom> wrote:

>     I have a string Value I need to "print". However, in order to scale the
> space for the word to fit on the object, I need to know how many charcaters
> are in the variable. Is there a strlen() function in POVRAY ?

Er, yes...it's called "strlen()". Did you even bother to check the 
manual or try it?

-- 
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 defense of the newbs, that manual is pretty intimidating and hard to use
for someone new to the program. I know my brain used to turn to jello just
looking at it.. even if it seems thorough and straightforward now :)

George


"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cja### [at] netplexaussieorg...
> In article <3e5419b4@news.povray.org>,
>  "Joseph Zeglinski" <JAZ### [at] rogerscom> wrote:
>
> >     I have a string Value I need to "print". However, in order to scale
the
> > space for the word to fit on the object, I need to know how many
charcaters
> > are in the variable. Is there a strlen() function in POVRAY ?
>
> Er, yes...it's called "strlen()". Did you even bother to check the
> manual or try it?
>
> --
> 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

On Thu, 20 Feb 2003 20:10:55 -0500, "George Pantazopoulos"
<the### [at] attbicom*KILLSPAM*> wrote:
> In defense of the newbs, that manual is pretty intimidating and hard to use
> for someone new to the program.

If you are looking for function to operate on strings what will be the name you
will be looking for ? Isn't chapter "String Functions" well named ? The last but
one sentence there says: 'See section "Float Functions" for other functions
which are somewhat string-related but which return floats.' So switching to
"Float Functions" gives an answer. What hard in use was there exactly ?

ABX

Post a reply to this message

"George Pantazopoulos" <the### [at] attbicom*KILLSPAM*> wrote in message
news:3e5579ee$1@news.povray.org...
>
> In defense of the newbs, that manual is pretty intimidating and hard to use
> for someone new to the program. I know my brain used to turn to jello just
> looking at it.. even if it seems thorough and straightforward now :)
>

One oddity in this case is that strlen (and some other string-related functions)
do not appear under the string function section, but instead are under the
float-function section. Okay, it returns a float, but IMHO such functions could
be listed in both sections.

Post a reply to this message

On Fri, 21 Feb 2003 10:13:45 +0100, ABX <abx### [at] abxartpl> wrote:

 What hard in use was there exactly ?
>
>ABX

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. 
Knowing how helpful you are I assume that you meant "how can the documentation
be improved to help you find what you want to know". 

Regards
        Stephen

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
> One oddity in this case is that strlen (and some other string-related functions)
> do not appear under the string function section, but instead are under the
> float-function section. Okay, it returns a float, but IMHO such functions could
> be listed in both sections.

  Functions are categorized based on what they return.
  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?)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

On Fri, 21 Feb 2003 10:33:12 GMT, mca### [at] aolcom (S McAvoy) wrote:
> Knowing how helpful you are I assume that you meant "how can the documentation
> be improved to help you find what you want to know". 

Yes and no. While working on softwear professionally I'm interested in making
apps as much user-friendly as possible because it makes my profits. In various
projects I'm also responsible for making/updating documentation and I have
direct access to users so I always listen all notes. Relating to POV-World I'm
working on MegaPOV and I know how much there is to improve - for example next
MegaPOV will probably have context help for MegaPOV related keywords (have to
solve some problem there).

In general working with computers requires some assumptions about user. If he is
looking for string related function I expect he will read "String functions"
chapter because logical connection between searched keyword and name of chapter
is obvious. Please note either "function" and "string" keywords appear in
subject of original post so you can't say he has language problems in that area.

I understand user can not know all names of chapters. But then simple search any
combination of "string", "function", "functions", "length" should lead to
something like: http://www.povray.org/search/?s=string+length+function where
either "String functions" and "Float functions" are at top. If he do not tried
search nor read table of content then whatever will be written in documentation
he will never find it. Moreover he used "strlen" keyword which appear in index
of documentation.

My elaborated answer is not offence against original poster because I understand
that's what new users usually do - never start from manual. My answer is against
wrong conclusions mentioned later. Documentation has probably holes but none
documentation hole caused that user to be asking for string length function.

ABX

Post a reply to this message

On Fri, 21 Feb 2003 12:17:09 +0100, ABX <abx### [at] abxartpl> wrote:
> for example next
> MegaPOV will probably have context help for MegaPOV related keywords

Of course I mean Windows port of MegaPOV.

ABX

Post a reply to this message

I'm pleased to hear that MegaPOV will probably have context sensitive help
although I've not used it since POV Ver 3.5 was released, too many other things
to do. Keep up the very good work.
It's true what you say about users, and when your getting paid for supporting
them you just have to "grin and bare it" but when your support is free and done
out of love it can be frustrating to know that if they had read the manual they
would not need to ask.
BTW I read this Q & A a few weeks ago : . Q - What do you call a person who asks
for easily obtainable information. A - A boss."
I understood the response to 'Christopher James Huff' as an attempt to soften
this reply. Writing to news groups can be a means of joining a community and
should be encouraged IMHO. Personally no one I know is the slightest bit
interested in computer graphics and it can get lonely. Maybe that is why I like
to encourage others.

Regards
        Stephen

Post a reply to this message

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

Christopher James Huff <cja### [at] earthlinknet> wrote:
> It's a string function.

  If it was, then it could be used anywhere where a string is expected.
It can't.
  For example the #debug command takes as parameter a string. A string
can be a string literal, a string identifier or a string function. Since
strlen() is not a string function (but a float function) it can't be given
to #debug.

> If POV were object oriented, it would 
> be a method of string objects, not floats.

  Its location would not change the fact that it's a float function
(there's no reason why there could not be float functions in a string
class).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

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

>   For example the #debug command takes as parameter a string. A string
> can be a string literal, a string identifier or a string function. Since
> strlen() is not a string function (but a float function) it can't be given
> to #debug.

That's got nothing to do with it. Return type is only loosely related to 
the purpose of a function. strlen() deals with strings, feed it a float 
and see what it does.


> > If POV were object oriented, it would 
> > be a method of string objects, not floats.
> 
>   Its location would not change the fact that it's a float function
> (there's no reason why there could not be float functions in a string
> class).

All methods of a string class are string methods. Return type is 
irrelevant.

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

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3e55ee3f$1@news.povray.org...
>
> One oddity in this case is that strlen (and some other string-related
functions)
> do not appear under the string function section, but instead are under the
> float-function section. Okay, it returns a float, but IMHO such functions
could
> be listed in both sections.
>

When I first read the post, and the subsequent response, I initally had
quite a chuckle and thought to myself, "Ha! What a dolt!"  But now, I agree,
and I have to admit that it would have been hard to spot.

I've been programming professionally (not in POV-Ray) for about 15 years.
Not that it makes me a great person, but just to establish some credibility.
If I wanted to find out if there was a string length function, I would have
typed "string" into the help.  I would have then scanned the page of all of
the string functions, which appear in blue on the left.  At that point, I
wouldn't have noticed anything about strlen.  I would have then scanned thru
strings.inc (in the help) and noticed that it didn't say anything either.
At that point, I could have taken my best guess and typed in "strlen", in
which case I would have found it, but I may just as easily have concluded
that it doesn't exist.

So...  Looking in Borland Delphi, I searched help, and found "string
handling routines", which then quickly took me to the Length function (which
is what it is called in Delphi).  The last place in POV-Ray that I would
have thought to look is in "Float Functions".  I understand how that can
make sense in terms of the design of the SDL and organization of the manual,
but without entirely understanding the SDL, I never would have thought to
look there.  If I see "float functions", I think about things that operate
on floating points values.  Does a string ever have a length of 7.12389
e-26?

I'm not saying the manual sucks or anything.  In fact, I've found it to be
incredibly useful and generally easy to follow.  If I had a dollar for every
time I thought a user was out of his @*&*(#$ mind, only to realize later
that perhaps he had a point, I'd be a rich man.

Just my $0.02

--
Slash

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3e56432a$1@news.povray.org...
<snip>
> 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.


I agree with this, Tom.

The manual has to serve several different audiences. I think what has been
written meets the needs of most newbies very well; certainly I've found it
was easy to use the SDL before I was really fluent with it. But my
background in Perl and other languages does get in the way a little, in that
sometimes my assumptions about how the SDL works and the philosophy that
organizes POV gets in my way.

An added section of cross references for those who come to POV from a
programming background could be very helpful. If there was a section
entitled "Especially for Programmers New To POV" I would have read that
before any other part of the manual, and I think that would be true for any
other programmer, too. That would be a good place to say that in the SDL
philosophy functions are organized by their return type, describe how POV
macros differ from keyboard macros and subroutine calls, and so on. Such
material should not replace what has been written, but should be added as an
appendix.

In the meantime, like the guy who couldn't find "strlen" even though he had
correctly guessed its name, I anticipate asking the occasionally stupid
question... because sometimes I'm jumping around in the manual to figure out
how to do one particular thing in an area I don't plan to study until later,
so I miss some cues that I would have otherwise seen.


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cja### [at] netplexaussieorg...
> All methods of a string class are string methods. Return type is
> irrelevant.

I'm reasonably familiar with the POV documentation at this point, and I
don't recall ever seeing "method" or any of the other words of the OOP
lexicon used in the SDL.  Well, "object" is used of course-- but that's a
homonyn thing. POV objects and OOP objects are completely different. There
are no "methods", there is no "inheritance", talking about "classes" or
"instantiations" doesn't make any sense since these are not part of POV's
world.

The POV SDL is not an object oriented language. The rules and organizing
philosophies of object oriented languages don't apply. There is nothing
broken here that needs to be fixed. There is instead an opportunity to learn
a different way of looking at things, and maybe even gain some new insights
from the different perspective.

Organizing functions by return type is, for me, an intriguing idea. It
suggests that when I'm working on a texture or a transformation, I should
take a gander at the various functions that I could plug into the thing at
that point. That's very different from the way I think in a procedural
language or an OOP. It's more like looking over my tubes of watercolors to
get an idea of what to do next.

Would POV be better if the SDL was rewritten as an OOP?  Idunno, that could
be an interesting discussion. But I don't think this is the place for that
discussion.



--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

in news:3e576a7a@news.povray.org Warp wrote:

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

I've been thinking about moving the "see also" section from the end of 
each "nnn functions" chapter to close to the top of the chapter and put it 
in a "Note" block to make it stand out a bit more.
I'll play with it a bit to see what works best.

Ingo

Post a reply to this message

On Sat, 22 Feb 2003 07:16:15 -0500, Warp quoth:

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

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

Is there any reason why it can't go in both places?  It's a float
function because it returns a float, and a string function because it
operates on strings.

And before you object, "trace" would be a vector function because it
returns a vector, and an object function because it operates on objects.

-- 
Mark

Post a reply to this message

Will W <wil### [at] nospamwizzardsnet> wrote:
> Organizing functions by return type is, for me, an intriguing idea.

  There's a very good reason for this in programming, as I explained
previously.
  In the same way as a variable has a type (eg. a variable of integer type),
a function has a type as well. The type of the function is determined by
its return value. Also constant literals have a type as well.
  The type of something determines where it can be used. For example, if
an integer is expected in a particular place, then any item of integer
type can be used there (ie. an integer literal, an integer variable, an
integer function or an expression which result is an integer).

  The purpose of a function (eg. to manipulate strings or whatever) is
a higher-level concept which has nothing to do with its type. The parameters
the function takes have nothing to do with its type (they don't affect in
any way *where* you can use the function).

  Organizing functions by their type is the easiest and most unambiguous
way of doing it. There are some functions which are very hard to classify
by their higher-level concept (because it's not unambiguous or it's a very
unique function).

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

Mark Wagner <mar### [at] gtenet> wrote:
> Is there any reason why it can't go in both places?

  There could be a "see also" subsection in the string functions section
where it's mentioned.

> And before you object, "trace" would be a vector function because it
> returns a vector, and an object function because it operates on objects.

  There are no "object functions" in POV-Ray.

-- 
#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 <3e58e486@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> > And before you object, "trace" would be a vector function because it
> > returns a vector, and an object function because it operates on objects.
> 
>   There are no "object functions" in POV-Ray.

trace(), min_extent(), max_extent(), inside()...I think that's it.

-- 
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 <3e58e425@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> Will W <wil### [at] nospamwizzardsnet> wrote:
> > Organizing functions by return type is, for me, an intriguing idea.
> 
>   There's a very good reason for this in programming, as I explained
> previously.

This isn't programming, it's documentation. The first thing most people 
will look for when looking for a string length function is a group of 
functions for manipulating strings.


>   The type of something determines where it can be used. For example, if
> an integer is expected in a particular place, then any item of integer
> type can be used there (ie. an integer literal, an integer variable, an
> integer function or an expression which result is an integer).

The purpose determines where it is useful. strlen() is only useful when 
handling strings, it is useless for math stuff.


>   The purpose of a function (eg. to manipulate strings or whatever) is
> a higher-level concept which has nothing to do with its type. The parameters
> the function takes have nothing to do with its type (they don't affect in
> any way *where* you can use the function).

Higher-level means closer to human thinking. The documentation is meant 
to teach humans.

-- 
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 <3e58628d@news.povray.org>,
 "Will W" <wil### [at] NOSPAMwizzardsnet> wrote:

> An added section of cross references for those who come to POV from a
> programming background could be very helpful. If there was a section
> entitled "Especially for Programmers New To POV" I would have read that
> before any other part of the manual, and I think that would be true for any
> other programmer, too. That would be a good place to say that in the SDL
> philosophy functions are organized by their return type, describe how POV
> macros differ from keyboard macros and subroutine calls, and so on. Such
> material should not replace what has been written, but should be added as an
> appendix.

It would be nice if it could be done without making the reader jump all 
over the documentation, but without much duplication. Here's one 
possible layout:

numeric functions
    scalar functions (float and integer)
        trig sub group...trig functions should be together, not mixed 
with functions like pow() and int().
    vector functions
string functions
object functions
array functions
other functions

And a separate section listing them by return type, with links to the 
main documentation.

-- 
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 wrote:
> 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.
> 
Now I agree!
Some time ago I was searching for the dot_product(..) syntax
but wasn't able to find it in the "vector functions" category... ;-)

Sebastian H.

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e58e425@news.povray.org...
> Will W <wil### [at] nospamwizzardsnet> wrote:
> > Organizing functions by return type is, for me, an intriguing idea.
>
>   There's a very good reason for this in programming, as I explained
> previously.

Yes, I see that. You are preaching to the choir.

I do not see any compelling reason for changing the way the POV and its
documentation are organized. As I have said elsewhere, I do think a brief
appendix for experienced programmers who are new to POV could be very useful
in cutting down aggravation and stupid sounding questions. But that would be
an added feature, not a change in what has already been done. It would be
something nice to have, but not strictly necessary.


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> other functions

  I'm still not comfortable with that.
  How do you classify a function as "other"? How do I know from a given
function if it's an "other" function?

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

-- 
#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 <3e595477@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   I'm still not comfortable with that.
>   How do you classify a function as "other"? How do I know from a given
> function if it's an "other" function?

If it doesn't fit in with the more specific categories. The "other" 
category would be quite small, and easy to check.

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

"Joseph Zeglinski" <JAZ### [at] rogerscom> wrote in message
news:3e5419b4@news.povray.org...
> Hi,
>     I have a string Value I need to "print". However, in order to scale the
> space for the word to fit on the object, I need to know how many charcaters
> are in the variable. Is there a strlen() function in POVRAY ?
>
> Thanks.
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.449 / Virus Database: 251 - Release Date: 27/01/2003
>
>

Gentlemen,
    Pray, thank you one and all ...some 35...so far. It was a simple question,
and wasn't meant to get off topic in some cases, with snide remarks by some.
As I scanned through the barrage of idle conversation, I wasn't sure if I had
inadvertantly logged into Monty Python's flying circus in rehearsal.

    To answer some of your questions about just WHO would be so very lazy
enough to ask such a totally stupid question about a "strlen()) function...I
see why you are dying to learn this answer.

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

(2) I was just entering my initial trials with this product, and needed a
quick answer.  But, did I do "any work" to find the answer for myself?

    Well...yes... I downloaded the POVRAY Tutorial (because after a half day's
search on the internet and local bookstores, I couldn't find a POVRAY book,
still in print, even a used one,  to buy. Then I read through all of the
discussions on the POVRAY documentation group, etc. trying to find out if a
book was in the works. Discovered they aren't organized enough to answer at
this time, perhaps ever. Still no strlen() answer... so I looked through the
help file ... without much luck ( I must have missed it, I guess? damned
bi-focals).
    O.K. Needed to get out the heavy artillary - needed to print out (computer
screens are for propeller heads)  the TUTORIAL for POVRAY 3.5 - strange name
for a tombe of 782 pages - needs to be renamed  THE MANUAL or the BIBLE.
Inkjet....forget it. My old Laserjet-2 ... life is too short.
I needed to upgrade my 15 year old, and working great, LJ-2, to something
better.... yes... a Colour HP Laserjet 4600DN ...double sided duplexed colour
printing at an actual 8 seconds a colour page for a mere $4,500 Canadian
pesos.
    Finally, 1 hour 20 minutes, and 782 double sided pages, later I had a
beautiful copy of the colour  POVRAY Tutorial.
    However, as lovely as it is, and as well written as it was, and extremely
well organized, in all of it's Bachus-Naur illustrated explanations, along
with a detailed list of subject matter at the front  - though this entire
section was badly screwed up in PDF - the rest was indeed exquisite.
To my dismay, this turkey ... has no INDEX to scan for a topic quickly. Did
you guys forget something after putting the tombe to bed?
So, I flipped through the pages hunting for anything that talked about
"strings... functions... the meaning of life"  ... (should have read the
responses for that).

    So, after considerable hunting, expenditure of a fair amount of time and
energy, and a premature purchase of a printer for $4,500 ... I was no closer
to the holy grail of a strlen() answer.
Although ...I was beginning to think somebody was stringing me along.

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

The ANSWER....
    Well, I started out in "Machine Language Programming" (that's OP-CODES
entered using mechanical toggle switches, on a front panel with neon bulbs -
later advanced to typing them into a Selectric typewriter console on the old
IBM-1620 console - loved that machine, wish I had one today. That was using
binary one's and zero's, for most who are too young to know about such things,
back in the early 60's (... that's in the 1900's), and soon graduated to using
an ASSEMBLER. Finally, worked my way up through Fortran, Snowball, and several
others I don't recall, upto "The Great C+".

    So to your question "How does he know about something called strlen()"
enough to spell it correctly in a question  - ... I tripped over it while
reading my C-Manual.

Oh yes - is he an artiste? No, just a profesional engineer, with years of
dabbling in computer graphics as an interest. I would never have tried POVRAY
if I didn't find a sudden need to use it with EagleCAD 3D circuit board
eye-candy creations. Then, like most, got addicted... but I'm working on that
problem.

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

    I really enjoyed the serious sessions of navel gazing ...or is it navel
grazing...that this question provoked. It might end up improving the
documentation ... perhaps by adding something like an INDEX section? Reading
the replies, I certainly learned a lot about the intricacies of language
structure, and how poorly the documentation in POVRAY is considered, by some.

    Then again... maybe I should have hunted for THE MANUAL instead of the
TUTORIAL at the POVRAY website. Or perhaps, have downloaded the POVRAY source
code, and skimmed through it - surely would have found a strlen() something.
My mistake, I just took the "obviously" easy way out.

I now have my answer ... but did anybody spot the answer to my question in all
of the 35 or so replies thus far?


...This has been niether a rant nor a flame...
but perhaps a tale told by a Dolt
full of sound and fury...
signifying nothing...

Cheers,
the DOLT !



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 18/02/2003

Post a reply to this message

In article <3e598261@news.povray.org>,
 "Joseph Zeglinski" <JAZ### [at] rogerscom> wrote:

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

It's just generally assumed that the manual is the first place people 
will look. That's why it exists, and is included with every distribution 
of POV-Ray.


>     Well...yes... I downloaded the POVRAY Tutorial (because after a half day's
> search on the internet and local bookstores, I couldn't find a POVRAY book,
> still in print, even a used one,  to buy. Then I read through all of the
> discussions on the POVRAY documentation group, etc. trying to find out if a
> book was in the works. Discovered they aren't organized enough to answer at
> this time, perhaps ever. Still no strlen() answer... so I looked through the
> help file ... without much luck ( I must have missed it, I guess? damned
> bi-focals).

I don't know what you downloaded. The manual is not separately available 
in an easily downloadable form, and there is no document called anything 
like "The POV-Ray Tutorial".
As for books...there are none that deal with a recent version of 
POV-Ray, and they would be unlikely to cover the strlen() function 
anyway...it's already documented in the manual.


>     O.K. Needed to get out the heavy artillary - needed to print out (computer
> screens are for propeller heads)  the TUTORIAL for POVRAY 3.5 - strange name
> for a tombe of 782 pages - needs to be renamed  THE MANUAL or the BIBLE.
> Inkjet....forget it. My old Laserjet-2 ... life is too short.

If you are talking about the document that came with POV-Ray, that *is* 
the manual, it just contains 2 tutorials. And it would be easier to 
search the electronic version than hunt through a hard copy.
Printing the manual takes a lot of paper, ink, and time, you miss out on 
any corrections, plus you would need to re-print it for POV updates. I 
initially printed large chunks of the manual twice, found I never used 
the hard copies, and gave up on it.


> To my dismay, this turkey ... has no INDEX to scan for a topic quickly. Did
> you guys forget something after putting the tombe to bed?

It's designed as an electronic document. Page numbers are pretty 
useless, it uses hyperlinks.


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

Well, you pretty much used it in your original message. strlen(STRING)


>     I really enjoyed the serious sessions of navel gazing ...or is it navel
> grazing...that this question provoked. It might end up improving the
> documentation ... perhaps by adding something like an INDEX section? Reading
> the replies, I certainly learned a lot about the intricacies of language
> structure, and how poorly the documentation in POVRAY is considered, by some.

An index of the type you are looking for wouldn't really be very useful. 
The manual *does* have an index (surprisingly enough, with the title of 
"Index"), but it does not use page numbers, it uses section numbers and 
hyperlinks, as is appropriate for a document intended to be read 
electronically.


>     Then again... maybe I should have hunted for THE MANUAL instead of the
> TUTORIAL at the POVRAY website. Or perhaps, have downloaded the POVRAY source
> code, and skimmed through it - surely would have found a strlen() something.
> My mistake, I just took the "obviously" easy way out.

I don't know where you got "THE TUTORIAL". There is no tutorial document 
remotely like what you describe, so you must be speaking of some version 
of the manual, and probably an old version because the new one isn't 
downloadable separately. Finding the current manual is quite easy: go to 
povray.org, click Documentation, or just find it in your POV-Ray 
installation.

-- 
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 <3e59555e@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

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

I'm not using type terminology. I'm categorizing them by use. When I 
look for documentation on a function, I look for it by use, not by 
return type. I don't care what I'm going to use the return for, I care 
what I'm going to use the function with.
IMO, return type is a terrible way to organize things, with very limited 
use.

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

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