 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <nat### [at] kopp com> wrote:
> There's a fundamental difference between vnormalize(<0,0,0>) and 1/0:
> backwards compatibility. :-)
I don't think vnormalize has ever been defined as returning <0,0,0> if
a zero-vector is given to it. What has not been defined can change in the
future without breaking backwards compatibility.
Besides, backwards compatibility has never been such a strong issue in
POV-Ray to maintain bad behaviour or bad features. For example, filter
working as transmit in layered textures was a bad behaviour and it was
fixed regardless of breaking backwards compatibility.
IMO trying to perform vnormalize(<0,0,0>) is a sign of a programming
mistake (ie. bug) and thus the error is only helpful. If the algorithm
is properly made, such case should never happen (in the exact same way as
dividing by 0 should never happen).
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jonathan Wooldridge wrote in message <3d0bb13f$1@news.povray.org>...
>Why would a feature be "de-implemented"? What advantage is it to the coding
>team to eliminate the feature?
Reducing tech-support headaches. By eliminating the ^ operator, the
POV-Team will get far fewer e-mails complaining about operator precedence
being broken with respect to the ^ operator.
--
Mark
The Universe is expanding.
The budget for its exploration is shrinking.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Im Beitrag <3d0b6c80@news.povray.org>, Warp <war### [at] tagpovrayorg> schrieb:
> You complain that vnormalize(<0,0,0>) returns an error, yet you don't
> complain that 1/0 returns an error.
> However, they are practically the same thing (the vnormalize also performs
> a division by 0, as it divides each component with the length of the vector,
> which is 0).
>
Sorry, but that is not absolutely true, because that is NOT taking 1/0, but
0/0, and that can, depending on the circumstances, be almost anything.
And I KNOW (!) that it is rightfully undefined.
As I pointed out earlier in this thread, a function that returns the
normalized vector IF POSSIBLE and <0,0,0> else is USEFUL - and at least on
my system, POV3.1g and MacMegaPOV0.7 DID behave like that - and since it is
USEFUL, there were already people writing macros "Vnormalize" (or
"VNormalize") that work like that (sorry, I can't find the threads in a
hurry, but they WERE here !).
The serious (i.e. not bracketed and smiley-free) part of my proposal was to
add such a macro to an appropriate include file, so that this functionality
can used by all with the same macro name, if they wish to.
Again: I KNOW that the "new" - or not so new - behaviour is mathematically
correct, that is NOT my point !
Karl
--
The two most common things in the universe are hydrogen and stupidity.
(H.Ellison)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Karl J. Anders <kar### [at] webde> wrote:
> Sorry, but that is not absolutely true, because that is NOT taking 1/0, but
> 0/0, and that can, depending on the circumstances, be almost anything.
Actually it's nothing. It's not defined in any system.
Even FPU's, when you actually perform 0/0 (and they are set up so that
they will not execute an interrupt if such thing happens) will return NaN
(Not a Number), which is a special value which is not usable anywhere.
> The serious (i.e. not bracketed and smiley-free) part of my proposal was to
> add such a macro to an appropriate include file, so that this functionality
> can used by all with the same macro name, if they wish to.
Such macro is so extremely simple that I don't see any good reason for
including it in the standard include files.
In the same way we should also include a macro which returns 0 if something
is divided by 0. It just doesn't make sense.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Such macro is so extremely simple that I don't see
> any good reason for including it in the standard
> include files.
I'm not for or against such a macro, but I do know that there are some
of the macros in the standard include files that are way simpler and IMO
ridiculous than this proposed one.
Two examples from math.inc:
// Squares the components of a vector
#macro VSqr(V) (V*V) #end
// Distance between V1 and V2
#macro VDist(V1, V2) vlength(V1 - V2) #end
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated May 20)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
> I'm not for or against such a macro, but I do know that there are some
> of the macros in the standard include files that are way simpler and IMO
> ridiculous than this proposed one.
But at least they are consistent, logical and mathematically correct.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> But at least they are consistent, logical
> and mathematically correct.
This was not the issue in question. You was talking about the simplicity
of the macro. The issue of the mathematical correctness has already been
discussed, where Karl pointed out that it would be useful nonetheless.
That was the point where you swithed the subject to the issue of the
simplicity, which I responded to in my last post. Now you switched the
subject back again, and we could go on like this forever.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated May 20)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
> This was not the issue in question. You was talking about the simplicity
> of the macro. The issue of the mathematical correctness has already been
> discussed, where Karl pointed out that it would be useful nonetheless.
> That was the point where you swithed the subject to the issue of the
> simplicity, which I responded to in my last post. Now you switched the
> subject back again, and we could go on like this forever.
I didn't change the subject (isn't "you switched the subject" a rather
cheap attack?).
My point was that if he wants a function which does not work as its
mathematical specification says, he can easily do a macro implementing
such function himself. It makes no sense to include such macro in the
official distribution (in the exact same way as it makes no sense including
a macro which performs a division so that if something is divided by 0 it
will return 0, which is almost an identical case).
A macro which squares a number might not be too useful, but at least it's
mathematically correct, which justifies better its inclusion. It doesn't
have any "if you give illegal parameters it will return a mathematically
incorrect result" exception.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I didn't change the subject (isn't "you switched
> the subject" a rather cheap attack?).
Yes, perhaps... :/
> My point was that if he wants a function which
> does not work as its mathematical specification
> says, he can easily do a macro implementing
> such function himself.
Many macros in the include files have no mathematical specifications at
all, they're just included because they're useful. Since we know that
there are many people who would also find the macro in question useful,
I don't see how it's any different from the others. There can be more
than one reason to include a macro, mathematical correctness being one,
and usefulness being another. The include files have 'em both.
Now, the macro in question is rather short and would be easy to make for
the user himself, but that also applies to macros that are already in
the include files. When deciding whether or not a short macro should be
included, I don't see why it makes any difference if the criteria for
inclusion is mathematical correctness or if it is usefulness. In both
cases the macro is valuable (an argument for inclusion), but also very
easy to create (an argument against inclusion).
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated May 20)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> Many macros in the include files have no mathematical specifications at
> all, they're just included because they're useful. Since we know that
> there are many people who would also find the macro in question useful,
> I don't see how it's any different from the others. There can be more
> than one reason to include a macro, mathematical correctness being one,
> and usefulness being another. The include files have 'em both.
>
> Now, the macro in question is rather short and would be easy to make for
> the user himself, but that also applies to macros that are already in
> the include files. When deciding whether or not a short macro should be
> included, I don't see why it makes any difference if the criteria for
> inclusion is mathematical correctness or if it is usefulness. In both
> cases the macro is valuable (an argument for inclusion), but also very
> easy to create (an argument against inclusion).
>
> Rune
> --
Thank you for precise expression of my thoughts - with one additional
sidestep ;) : since simpleness obviously is NOT a valid criterion for
exclusion ( didn't you mention VDist before ?), the reason for INclusion
probably is, that since many people can (and WILL) write such a macro, it's
helpful to provide it, so that there's just one name for that functionality
floating around, which simplifies exchange of scene files - and that's all I
wanted to express.
I REALLY whished some people would READ the posts they are answering ( now,
this one is NOT for you, Rune ), cause I already stated that I have already
written such a macro for myself, and yes, it is short, and yes, it is
simple, really don't need help with that :)
All in all, vnormalize is as redundant as the "^"-operator, because even the
docs describe its definition in terms of other POV-functions, so for
consistency it should be removed too ... ;)
( now, DID you all see that smiley ???!!!^)
Karl
--
The two most common things in the universe are hydrogen and stupidity.
(H.Ellison)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
