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