"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3ec384dc$1@news.povray.org...
> In article <3ec2d53b@news.povray.org> , "Will W"
<wil### [at] NOSPAMwizzardsnet>
> wrote:
>
> > Generally in other packages the limitations of int( ) function are
> > documented. This is missing from POV's documentation. An additional
sentence
> > that stated the range of integers would bring POV's int( ) function into
> > alignment with similar packages, and help savvy SDL writers avoid
problems
> > in their code.
>
> But generally you get a ready made library and/or documentation specific
to
> one platform.  Adding such arbitrary detail to the POV-Ray documentation
> helps nobody but will confuse many.


Actually, the documentation of cross platform packages I've used generally
cover this by saying that there is a limit, which is dependent on the
platform or compiler settings, and advises that those who need to know where
to go to find that other documentation. In my opinion, including detail like
this is in the documentation of something like the int( ) function is not
arbitrary. It has a specific use in decreasing the time a reasonably astute
user with a bit of experience will spend in searching through documentation
or developing his own methods of assessing the limits of the software.

In the current discussion, if this detail had been included in the docs this
discussion would have much more quickly moved on to how to get around the
limitation. The idea of using "#declare x = (x<0 ? -floor(-x) : floor(x));"
would have been brought to the fore much sooner. A lot of verbiage would
have been avoided. Also, I would not now be wondering if I've stepped into
some kind of pissing contest with a youngsta programma who still has too
much ego involvement with his code. I'm not saying that is the case; I don't
know. The doubt does interfere with communications though-- I'm spending a
lot more time reviewing my words trying to make sure I don't step on a
tender ego than I would if we were in, say, a perl forum. I don't much like
having to go to that extra work.

> The real problem is that the parser currently does not prevent you from
> shooting yourself in the foot.  I agree that it should enforce bounds
> whenever possible.


Actually, I prefer parsers that do not enforce arbitrary bounds. I've become
pretty perlish in my coding practices in the last decade, and I now
recognize my responsibility as the programmer is to know what the limits are
and to break them only when necessary. The parser's responsibility goes no
further than accurately translating what I write into executable code. If I
want to do something "illegal", I don't want some stupid parser yapping that
I can't do that. So I'm not sure who you are agreeing with here, but it
isn't me. My position is not that the parser should enforce limits, but that
the documentation should clearly state those limits where it is reasonable
to expect to see them stated. It would also be helpful to point to an idiom
that can get around the limitation, when doing so would cost no more than a
handful of text characters.


> Nevertheless, finding by trial and error what works and
> what doesn't really does not help because:
> 1. It can be found in the source code more accurately.


This conflicts with your statement that the boundaries are platform/compiler
dependent, and not a part of POV itself.


> 2. The behavior is intended as is right now.


I have said nothing anywhere about changing the intended behavior. My
concern is about communicating what the intended behavior is, in a clear
fashion, in a place where it is intended that the user should go to find out
such things.


> 3. Values of this size will not be useful for anything in a scene.


I don't think you can count on that never happening. I'm amazed at the
rendering times some povers have the patience for, and the level of fine
detail that some strive for. Between fractals and meshes, and renderings at
7800x5200 pixels or more,  and faster CPUs, it won't be long before some
povers are attempting to iterate over such quantities-- 2 billion and change
isn't so very many snowflakes, grains of sand, leaves in a forest, etc. I
really wouldn't be surprised if some users aren't already deep in the "more
than 2 billion" territory. You have just given me cause to wonder how many
people have silently set aside projects that showed a lot of promise in the
early detail phases of development, but blew up when they attempted to scale
them to full size.


> 4. It will not be changed in POV-Ray 3.x.


But will the documentation be changed in POV-Ray 4.x?  After this
discussion, there is now the possibility. Before this discussion, there was
not.


>     Thorsten
>


Thorsten, thank you for your time.



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

Post a reply to this message