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

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

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

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