|
|
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
|
|