 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaap Frank <jjf### [at] xs4all nl> wrote:
> When using the functions mod(A,B) and div(A,B)
> you can't give values for A greater then int(float),
I suppose these use internally C's int() as well. Using fdiv() and floor()
instead should fix the problem.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3ec2a952@news.povray.org...
> In article <3ec25305@news.povray.org> , "Will W"
<wil### [at] NOSPAMwizzardsnet>
> wrote:
>
> > So, this demonstrates this implementation of POV represents integers
with a
> > 32 bit number wheel, that wraps from positive to negative values at 2
raised
> > to the 31st power (2^31, 2**31, or pow(2,31). This is of course because
the
> > high order bit is used as a sign bit.
>
> Nobody ever said POV-Ray offers infinite precision. To the contrary, it
has
> been said very often that very small or very big numbers when used will
not
> always produce the desired results.
>
> Thorsten
>
I feel like you've missed my main point and focused on a minor explanatory
detail.
I don't see where there is anything wrong with the POV implementation of
int( ). The limitations of integer arithmetic are well known; the SDL's
limitations in this regard are no different from most C and C++ compilers,
and derivative works.
With one exception.
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.
A broad statement that very "very big or very small numbers when used will
not always produce the desired results" implies, to me, that there are the
usual problems with very large or very small floats, like around pow(10,80)
and pow(10,-80). Two billion and change just isn't all that big-- and is an
entirely different kind of accuracy problem.
I'm not saying you've got an ugly baby or it needs corrective surgery. It's
a bright, happy baby, and a lot of fun. But there is a button undone on her
documentation.
--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3ec2ac3d@news.povray.org...
> (Or better "x<0 ? -floor(-x) : floor(x)" to maintain the same
behaviour.)
fwiw, I agree that this is the clause most people should be using instead of
int( ).
--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
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. 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.
2. The behavior is intended as is right now.
3. Values of this size will not be useful for anything in a scene.
4. It will not be changed in POV-Ray 3.x.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ec3b01a@news.povray.org>,
"Will W" <wil### [at] NOSPAMwizzardsnet> wrote:
> 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.
Of course there's a limit, and anyone coding these types of scenes
should already be aware of that. It's not anything special to POV-Ray.
> 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.
Right...the parser shouldn't say anything if you do something wrong, it
should just mysteriously fail. That's wonderful for user-friendliness.
(Yuck, Perl...)
> This conflicts with your statement that the boundaries are platform/compiler
> dependent, and not a part of POV itself.
No it doesn't. By looking at the source code, you can tell what
platform-dependant constants are being used.
> > 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.
It most likely will, as 4.0 will be a different program. Using the
documentation for previous versions often does not work very well.
--
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 <cja### [at] netplexaussieorg> ,
Christopher James Huff <cja### [at] earthlinknet> wrote:
>> 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.
>
> Right...the parser shouldn't say anything if you do something wrong, it
> should just mysteriously fail. That's wonderful for user-friendliness.
> (Yuck, Perl...)
>
>> This conflicts with your statement that the boundaries are platform/compiler
>> dependent, and not a part of POV itself.
>
> No it doesn't. By looking at the source code, you can tell what
> platform-dependant constants are being used.
Sorry, haven't had time to follow-up on this thread. Your answer is exactly
what I would have answered.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3ec2d0ad@news.povray.org...
> Jaap Frank <jjf### [at] xs4allnl> wrote:
> > When using the functions mod(A,B) and div(A,B)
> > you can't give values for A greater then int(float),
>
> I suppose these use internally C's int() as well. Using fdiv() and floor()
> instead should fix the problem.
>
> --
> #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{
The first three numbers below exceed the max-value 2 147 483 647 for div() and
mod().
> N(11 117 333 955)N(4 254 934 330)N(3 900 569 407)N(7 382 340)N(3358)N(970)}// -
Warp -
Haven't this give you troubles?
Jaap Frank
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaap Frank <jjf### [at] xs4allnl> wrote:
> The first three numbers below exceed the max-value 2 147 483 647 for div() and
> mod().
>> N(11 117 333 955)N(4 254 934 330)N(3 900 569 407)N(7 382 340)N(3358)N(970)}// -
> Warp -
> Haven't this give you troubles?
Nope. By chance, not because I knew how to avoid it.
mod() doesn't matter because it only takes the least-significant values
of the number. If the most-significant are lost in a double->int conversion,
that doesn't affect the value of mod.
As for div(), I suppose that what the POV-Ray source code is doing is
something like "int(a/b)" (instead of "floor(a/b)" as it really should).
That is, the division is done first, and the conversion to int only to the
result. Since for example 11117333955/13 = 855179535, which is well
inside the 31-bit range of int, the result is (luckily) not cut.
--
#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
|
|
| |
| |
|
|
|
|
| |
|
|
