On 5/8/21 7:06 PM, Tor Olav Kristensen wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 5/6/21 10:58 AM, Tor Olav Kristensen wrote:
>>> ...
>>> My opinion is that several of the other math related macros in the include files
>>> need some rework.
>>>
>>
>> I'd consider alternatives for my branch if you want to offer details.
> 
> That sounds good.
> 
> Today I looked at the statistical macros in math.inc.
> 
> Here's how they could be rewritten:
> (Please note that have not tested these thoroughly yet.)
> 

Thank you. I'll have a look.

Aside: I've been working on adding self testing to all the includes 
(Ingo's suggestion and method) and in addition to macros I broke myself 
with povr branch changes, Histogram, was a macro long shipped which 
already wasn't working... ;-)

> 
> 
>> Suppose I could compare to forms in skvectors?
>> ...
> 
> I'm not sure what you mean here.

I was guessing what you have in your package would be what you consider 
solid/better implementations numerically. However, it helps me if you do 
the sorting of what might be better implementations of current code.

> 
> 

For reference I'm shipping only the following includes as 'core' ones in 
the povr branch.

arrays.inc
functions.inc
math.inc
rand.inc
shapes.inc
strings.inc
transforms.inc

Limit your look to these files for my participation. Further, I have on 
my list to move some of the macros in these to munctions.inc or other 
include files as 'not core' related / not commonly used.

arraycoupleddf3s.inc - This temporarily needed as it goes with some DF3 
related work I did years back which is in the povr branch. Some of it 
should end up in arrays.inc; some of it should go away. I've not sorted it.

Aside: My belief is future POV-Ray ray needs to move to a support 
structure which breaks things into core-code, scenes, includes, 
documentation, ini/configs, helper scripts / programs, (fonts?) and the 
web site (also the wiki?) as independent code control structures on 
github say ideally all with different primarys though perhaps still 
common POV-Ray owners like Chris. I think it would work better having 
multiple gate keepers to multiple POV-Ray domains. This model also 
matches to a degree what linux package developers are already going 
themselves breaking POV-Ray into multiple packages.

Bill P.

Post a reply to this message