POV-Ray : Newsgroups : povray.newusers : Ignorance rules! Server Time
29 Mar 2024 01:55:32 EDT (-0400)
  Ignorance rules! (Message 19 to 28 of 28)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: William F Pokorny
Subject: Re: Ignorance rules!
Date: 26 Jun 2020 08:47:54
Message: <5ef5ee7a$1@news.povray.org>
On 6/26/20 1:43 AM, Thorsten wrote:
> On 24.06.2020 19:53, William F Pokorny wrote:
>> (4) - And, yep. I don't like the DBL, SNGL in our source code since 
>> v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request 
>> years back which then never got adopted. PRECISE_FLOAT now needs to be 
>> yanked at some point from povr and I'd like to drop DBL and SNGL too. 
>> Today you can find the bare 'foat/double' declarations in the source 
>> code depending on who wrote what. This makes it unlikely we can really 
>> ever change DBL to be anything but double, for example. Certainly not 
>> without a lot of type conversions even if, by some chance, everything 
>> works correctly.
> 
> Except, that is not why they are there: DBL is in the source code 
> because there was a time when you could not depend on "double" actually 
> doing what you wanted it to do. A time when certain CPUs had 80 bit 
> floating point numbers, and other odd things with software emulated 
> floating-point. In this world it was essentially that the floating-point 
> representation could be changed. These days are long over, but the code 
> just happens to be so old that it still has these leftovers.
> 

Yes, thanks. A good point.

It's easy to forget while playing with code today that those who created 
POV-Ray were working in a much tougher, unstable environment. Plus we 
now have ready access to so much more information - Wikipedia, papers, 
on line code, etc.

Bill P.


Post a reply to this message

From: Thorsten
Subject: Re: Ignorance rules!
Date: 26 Jun 2020 13:05:16
Message: <5ef62acc$1@news.povray.org>
> Yes, thanks. A good point.
> 
> It's easy to forget while playing with code today that those who created 
> POV-Ray were working in a much tougher, unstable environment. Plus we 
> now have ready access to so much more information - Wikipedia, papers, 
> on line code, etc.

Ah, the same things existed back then. They were called books ;-)

Thorsten


Post a reply to this message

From: Bald Eagle
Subject: Re: Ignorance rules!
Date: 27 Jun 2020 11:10:01
Message: <web.5ef76041ea0d75eafb0b41570@news.povray.org>
Cousin Ricky <ric### [at] yahoocom> wrote:
> One just has to keep in mind POV-Ray's scope leakage

> [2] If you have formal computer science education, you are mortified by
> these restrictions, wondering how people smart enough to create POV-Ray
> could have allowed such boneheaded violations of modular practice.  I am
> assured that the current development team is aware of such problems.
> Yes, I will keep complaining about the scope leakage until it is fixed.

This is an area where I've harbored suspicions and trepidation, due to
subconscious knowledge gathered from reading the newsgroups and docs over the
past years.

Jr and I have recently been working on some code, and while implementing /
rewriting a macro, some recursion was introduced, and a variable identifier was
passed back into the macro as an argument.  Debugging hilarity ensued.

If I understand it all correctly:
When you #declare variable N to have some value, and then use N as the
"temporary" variable name of what gets passed into the macro, and then use
#local to declare N's new in-macro / in-loop value ....  the global / higher
level value of N gets redeclared.
So apparently "POV SDL apparently makes no distinction between passing-by-value
and passing-by-reference, as other languages do."

Or maybe I have that wrong somehow - because reading the docs seems to
contradict that assertion:
2.2.2.2.3 Identifier Name Collisions
http://www.povray.org/documentation/view/3.6.1/237/

Perhaps we can have some more educated and astute (than I am) commentary on
this?
This goes back to a point I've made many times.   Documentation is fine - but
code examples give you something that is undeniable and that you have far less
likelihood of misunderstanding.

THIS works (as expected intended):

THIS does not: (because...)

THESE are a few tricky examples....:


Now here's the interesting part - which I had NO IDEA was even a thing:
"turns out, there's a (documented *) way to force POV-Ray to always treat a
macro argument as pass-by-value.  Add a '+' in front of the identifier name and
voila, POV-Ray is not "not allowed" to pass-by-reference because we're not using
an identifier, but an expression.

so:
     A(+N)
will leave N alone."

http://www.povray.org/documentation/view/3.6.1/243/
* "Consider these examples.

  #declare Value=5.0;
  MyMacro(Value)     //MyMacro can change the value of Value but...
  MyMacro(+Value)    //This version and the rest are not lone
  MyMacro(Value+0.0) // identifiers. They are float expressions
  MyMacro(Value*1.0) // which cannot be changed.
Although all four invocations of MyMacro are passed the value 5.0, only the
first may modify the value of the identifier."


Post a reply to this message

From: Cousin Ricky
Subject: Re: Ignorance rules!
Date: 28 Jun 2020 20:46:10
Message: <5ef939d2$1@news.povray.org>
On 2020-06-27 11:05 AM (-4), Bald Eagle wrote:
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> One just has to keep in mind POV-Ray's scope leakage
> 
>> [2] If you have formal computer science education, you are mortified by
>> these restrictions, wondering how people smart enough to create POV-Ray
>> could have allowed such boneheaded violations of modular practice.  I am
>> assured that the current development team is aware of such problems.
>> Yes, I will keep complaining about the scope leakage until it is fixed.
> 
> This is an area where I've harbored suspicions and trepidation, due to
> subconscious knowledge gathered from reading the newsgroups and docs over the
> past years.
> 
> Jr and I have recently been working on some code, and while implementing /
> rewriting a macro, some recursion was introduced, and a variable identifier was
> passed back into the macro as an argument.  Debugging hilarity ensued.

Ah, yes, I've run across this before.  Take a look at macro CH2RGB() in 
colors.inc.  The parameter HH used to be H before I blundered into the 
pass-by-reference trap and my scene file fell into an infinite loop. 
Thanks to Jerome for figuring out the problem, and to whoever fixed it 
in time for the POV-Ray 3.7 release.

I ran across it again in Lightsys IV.  (That bug was also fixed in 2012.)

Which area are you concerned about, scope leakage, or accidental 
pass-by-reference?

> If I understand it all correctly:
> When you #declare variable N to have some value, and then use N as the
> "temporary" variable name of what gets passed into the macro, and then use
> #local to declare N's new in-macro / in-loop value ....  the global / higher
> level value of N gets redeclared.
> So apparently "POV SDL apparently makes no distinction between passing-by-value
> and passing-by-reference, as other languages do."

I would say that it does, but the distinction is not explicit; the 
distinction manifests in how you express the argument, as you have 
discovered below.

> [snip]
> 
> Now here's the interesting part - which I had NO IDEA was even a thing:
> "turns out, there's a (documented *) way to force POV-Ray to always treat a
> macro argument as pass-by-value.  Add a '+' in front of the identifier name and
> voila, POV-Ray is not "not allowed" to pass-by-reference because we're not using
> an identifier, but an expression.
> 
> so:
>       A(+N)
> will leave N alone."
> 
> http://www.povray.org/documentation/view/3.6.1/243/
> [snip]

I have no problem with this.  At the *very* worst, it's a "I don't like 
the way this works so it must be a bug," but I won't even go that far. 
While pass-by-reference is dangerous if misused, it is still an 
important tool, and making POV-Ray strictly pass-by-value would 
compromise its flexibility.  C can be strictly pass-by-value it because 
one can pass an address to effect pass-by-reference.

While I admit it would be nice for POV-Ray to have an explicit 
distinction between pass-by-value and pass-by-reference, I would give it 
a low priority.  POV-Ray's implicit distinction is clearly defined and, 
as you have noted, well documented, confusing though it may be.  As long 
as you are careful with your coding, it is not a problem.

Scope leakage is a different matter.


Post a reply to this message

From: Bald Eagle
Subject: Re: Ignorance rules!
Date: 28 Jun 2020 21:20:00
Message: <web.5ef940b4ea0d75eafb0b41570@news.povray.org>
Cousin Ricky <ric### [at] yahoocom> wrote:

> >> Yes, I will keep complaining about the scope leakage until it is fixed.
> >
> > This is an area where I've harbored suspicions and trepidation, due to
> > subconscious knowledge gathered from reading the newsgroups and docs over the
> > past years.
> >
> > Jr and I have recently been working on some code, and while implementing /
> > rewriting a macro, some recursion was introduced, and a variable identifier was
> > passed back into the macro as an argument.  Debugging hilarity ensued.

> Which area are you concerned about, scope leakage, or accidental
> pass-by-reference?

> Scope leakage is a different matter.

Scope leakage.
Pass-by method is fine so long as it's stable and reliable and constant.

Not knowing what scope I'm working in - that can be a real issue.
I'll have to think about the permutations and write a pov and inc file to see
how I can try to either break or retain the scope of a given variable between
the two files, and with loops and macros throw into each as well.


Post a reply to this message

From: tth
Subject: Re: Ignorance rules!
Date: 7 Feb 2021 17:25:05
Message: <602068c1@news.povray.org>
On 6/26/20 7:05 PM, Thorsten wrote:

>> It's easy to forget while playing with code today that those who 
>> created POV-Ray were working in a much tougher, unstable environment. 
>> Plus we now have ready access to so much more information - Wikipedia, 
>> papers, on line code, etc.
> 
> Ah, the same things existed back then. They were called books ;-)

    And we can call 911-COMPU$ERVE :)


-- 
+-------------------------------------------------------------------+
http://weblog.mixart-myrys.org/?post/2021/01/Laissez-nous-exister-%21
+-------------------------------------------------------------------+


Post a reply to this message

From: clipka
Subject: Re: Ignorance rules!
Date: 26 May 2021 21:23:06
Message: <60aef47a$1@news.povray.org>
Am 23.06.2020 um 19:25 schrieb Cousin Ricky:
> On 2020-06-23 7:28 AM (-4), William F Pokorny wrote:
...
>> We have the convention today users should not declare IDs with lower 
>> case characters because such things might become, or might already be, 
>> SDL keywords. What I'm thinking about for povr is adding checking such 
>> that users cannot declare/local a name with only (lower case ascii, _) 
>> characters. #declare _a =... would be a parsing error.
>>
>> With this in place, I think it would then be the case we could always 
>> use something like _<lowercase_parm> for all our parameters without 
>> worry of collisions. The _ leading character would never be part of a 
>> keyword.
>>
>> Am I missing something with this planned approach?

Been there. Done that.
Curesed a lot.

> I suppose it could work.  It could potentially break old scenes, but I 
> don't suppose many such scenes exist.  None of the stock include files 
> have any such names that I can find.

Look harder.
`functions.inc` is what made me put the idea on the back burner.


Post a reply to this message

From: clipka
Subject: Re: Ignorance rules!
Date: 26 May 2021 22:58:47
Message: <60af0ae7$1@news.povray.org>
Am 24.06.2020 um 19:53 schrieb William F Pokorny:

> (4) - And, yep. I don't like the DBL, SNGL in our source code since 
> v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request 
> years back which then never got adopted. PRECISE_FLOAT now needs to be 
> yanked at some point from povr and I'd like to drop DBL and SNGL too.

I'm trying to jog my memory here to recall what that PRECISE_FLOAT was 
all about, but for the love of it I can't find no reference to it, 
except mentions by you yourself: One in 2019-02-17 in povray.beta-test 
where you posted a snippet apparently from a custom 
`polynomialsolver.cpp` where it appears in a comment, and one in a pull 
request from LeForgeron, titled "fix for FS324, regression on triangle" 
(pull request #358), where you mentioned "the new PRECISE_FLOAT compile 
hook" on 2019-06-06.

Can you help me out which pull request of yours that would have been, 
for which I suggested the use of PRECISE_FLOAT?

The Interwebkraken knows nothing else about it, GitHub can't seem to dig 
it up, and even in all my dozen unpublished half-finished branches that 
spun off at different times in history and still reside on my computer, 
none of them seems to contain the character sequence "PRECISE_FLOAT".


Is there a publicly accessible repo for your povr branch? Seeing where 
you're using the thing might bring my memory back up to speed.


Post a reply to this message

From: William F Pokorny
Subject: Re: Ignorance rules!
Date: 27 May 2021 05:57:26
Message: <60af6d06$1@news.povray.org>
On 5/26/21 10:58 PM, clipka wrote:
> Can you help me out which pull request of yours that would have been, 
> for which I suggested the use of PRECISE_FLOAT?

Related to selective use of long doubles where the hardware supports 
80/96 bits or more.

There is today no value to you or the POV-Ray code mainstream to dig 
into this. It's my code base stuck with something once thought might be 
of value which - knowing what I know today - isn't. It doesn't hurt 
anything other than my code's esthetics to have it sitting in there. It 
just bugs me that it is there.

Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: Ignorance rules!
Date: 27 May 2021 06:04:42
Message: <60af6eba$1@news.povray.org>
On 5/26/21 9:23 PM, clipka wrote:
> Am 23.06.2020 um 19:25 schrieb Cousin Ricky:
>> On 2020-06-23 7:28 AM (-4), William F Pokorny wrote:
> ...
>>> We have the convention today users should not declare IDs with lower 
>>> case characters because such things might become, or might already 
>>> be, SDL keywords. What I'm thinking about for povr is adding checking 
>>> such that users cannot declare/local a name with only (lower case 
>>> ascii, _) characters. #declare _a =... would be a parsing error.
>>>
>>> With this in place, I think it would then be the case we could always 
>>> use something like _<lowercase_parm> for all our parameters without 
>>> worry of collisions. The _ leading character would never be part of a 
>>> keyword.
>>>
>>> Am I missing something with this planned approach?
> 
> Been there. Done that.
> Curesed a lot.
> 
>> I suppose it could work.  It could potentially break old scenes, but I 
>> don't suppose many such scenes exist.  None of the stock include files 
>> have any such names that I can find.
> 
> Look harder.
> `functions.inc` is what made me put the idea on the back burner.

Yes, there's that and more for complications. I've had some success with 
it and it's how I've been running day to day for near a year now(1). 
Twiddle with the hacked in code now and again as I pick up some detail - 
recently performance impacts doing millions of calls to macros. Made it 
better, but, thinking now even when compiled in there should perhaps be 
a run time switch - but given how our macros work even simple that would 
be seen performance wise in the worst cases.

Today, I'd say it'll stay in as a configure option for sure, but we'll see.

Bill P.

(1) - It lines up with my coding style/aim where it won't with all.


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.