POV-Ray : Newsgroups : povray.general : Why only a +1 clamp with VAngle, VAngleD macros in math.inc? Server Time
27 Jul 2021 00:55:58 EDT (-0400)
  Why only a +1 clamp with VAngle, VAngleD macros in math.inc? (Message 6 to 15 of 15)  
<<< Previous 5 Messages Goto Initial 10 Messages
From: Tor Olav Kristensen
Subject: Re: Why only a +1 clamp with VAngle, VAngleD macros in math.inc?
Date: 8 May 2021 19:10:00
Message: <web.609719613160e21be719296489db30a9@news.povray.org>
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.)


// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.8;


// Does also work for vectors
#macro Mean(Values)

   #local N = dimension_size(Values, 1);
   #local Sum = Values[0];
   #for (I, 1, N - 1)
      #local Sum = Sum + Values[I];
   #end // for

   (Sum/N)

#end // macro Mean


// Does also work for vectors
#macro Variance(Values)

    #local N = dimension_size(Values, 1);
    #local M = Mean(Values);
    #local D = Values[0] - M;
    #local SquareSum = D*D;
    #for (I, 1, N - 1)
        #local D = Values[I] - M;
        #local SquareSum = SquareSum + D*D;
    #end

    (SquareSum/N)

#end // macro Variance


#macro Minimum(Values)

   #local N = dimension_size(Values, 1);
   #local Min = Values[0];
   #for (I, 1, N - 1)
      #local Min = min(Min, Values[I]);
   #end // for

   Min

#end // macro Minimum


#macro Maximum(Values)

   #local N = dimension_size(Values, 1);
   #local Max = Values[0];
   #for (I, 1, N - 1)
      #local Max = max(Max, Values[I]);
   #end // for

   Max

#end // macro Maximum


// For population
#macro StandardDeviation(Values)

   sqrt(Variance(Values))

#end // macro StandardDeviation


#macro Statistics(Values)

    #local N = dimension_size(Values, 1);
    #local Value = Values[0];
    #local Min = Value;
    #local Max = Value;
    #local Sum = Value;
    #local SquareSum = pow(Value, 2);
    #for (I, 1,  N - 1)
        #local Value = Values[I];
        #local Min = min(Min, Value);
        #local Max = max(Max, Value);
        #local Sum = Sum + Value;
        #local SquareSum = SquareSum + pow(Value, 2);
    #end // for
    #local M = Sum/N;
    #local Var = SquareSum/N - pow(M, 2);

    dictionary {
        .Count: N,
        .Min: Min,
        .Max: Max,
        .Mean: M,
        .Var: Var,
        .StdDev: sqrt(Var)
    }

#end // macro Statistics


#macro PrintStatistics(Stats)

    #local S = array[6] { "Count", "Min", "Max", "Mean", "Var", "StdDev" };
    #debug "\n"
    #for (I, 0, 5)
        #debug concat(S[I], " = ", str(Stats[S[I]], 0, -1), "\n")
    #end // for
    #debug "\n"

#end // macro PrintStatistics


#macro Histogram(Values, NoOfBins)

   #local Stats = Statistics(Values);
   #local N = Stats.Count;
   #local Min = Stats.Min;
   #local Max = Stats.Max;
   #local BinWidth = (Max - Min)/NoOfBins;
   #local Bins = array[NoOfBins][3];
   #local BinLimitLow = Min;
   #for (I, 0, NoOfBins - 1)
      #local BinLimitHigh = BinLimitLow + BinWidth;
      #local Bins[I][0] = BinLimitLow;
      #local Bins[I][1] = BinLimitHigh;
      #local Bins[I][2] = 0; // Set count for bin to zero
      #local BinLimitLow = BinLimitHigh;
   #end // for
   #for (I, 0, N - 1)
      // Find the right bin for the value
      #local BinNo = int((Values[I] - Min)/BinWidth);
      // Make sure rounding errors do not lead to a non existent bin
      #local BinNo = min(max(0, BinNo), NoOfBins - 1);
      // Increase the count for the bin
      #local Bins[BinNo][2] = Bins[BinNo][2] + 1;
   #end // for

   Bins

#end // macro Histogram

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7


> Suppose I could compare to forms in skvectors?
>...

I'm not sure what you mean here.


I'll comment further on the math related macros in the include files later.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k


Post a reply to this message

From: Tor Olav Kristensen
Subject: Re: Why only a +1 clamp with VAngle, VAngleD macros in math.inc?
Date: 9 May 2021 02:25:00
Message: <web.60977f983160e21b8e52cc8789db30a9@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/6/21 10:58 AM, Tor Olav Kristensen wrote:
> >...
>...
> > Anyway the way that macro calculates the angle is not the best numerically.
> > I would rather suggest something like this:
> >
> >
> > #macro AngleBetweenVectors(v1, v2)
> >
> >      #local v1n = vnormalize(v1);
> >      #local v2n = vnormalize(v2);
> >
> >      (2*atan2(vlength(v1n - v2n), vlength(v1n + v2n)))
> >
> > #end // macro AngleBetweenVectors
> >
>
> Interesting, thanks. I'll play with it. There will be four sqrt calls
> with this vs two so I expect it's a slower approach.

I prefer better accuracy before speed. If we need this to go faster we could
compile it into POV-Ray and make it a new command; e.g. vangle().


> Reminds me I captured fast approximation atan2 code I was thinking of
> making an inbuilt function, but I've not gotten to it...
>
> And that thought reminds me of my plans to turn many macros into
> "munctions"(1) calling new faster, inbuilt functions. Done only a tiny
> bit of that so far.
>
> (1) - Yes, thinking about creating a munctions.inc file breaking out
> what are really macro wrappers to functions into that file to make clear
> what they are. Maybe all as M_ prefixed so my current F_dents() would
> become M_dents(). Angle perhaps then M_Angle.

This sounds interesting. Can you please explain more ?
Are there any benefits from using these instead of new built in commands ?


> Something I've done too with the inbuilt function changes is allow
> alternative calculations for the same thing. Compiled such conditionals
> not that expensive. Most frequently single float options where those are
> much faster, but different methods too. For one thing, the alternatives
> I can bang against each other as a way to test!

Are you using this functionality to perform speed tests ?


--
Tor Olav
http://subcube.com
https://github.com/t-o-k


Post a reply to this message

From: William F Pokorny
Subject: Re: Why only a +1 clamp with VAngle, VAngleD macros in math.inc?
Date: 9 May 2021 09:22:16
Message: <6097e208@news.povray.org>
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

From: William F Pokorny
Subject: Re: Why only a +1 clamp with VAngle, VAngleD macros in math.inc?
Date: 9 May 2021 09:31:42
Message: <6097e43e$1@news.povray.org>
On 5/9/21 2:22 AM, Tor Olav Kristensen wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 5/6/21 10:58 AM, Tor Olav Kristensen wrote:
>>> ...
>> ...
>>> Anyway the way that macro calculates the angle is not the best numerically.
>>> I would rather suggest something like this:
>>>
>>>
>>> #macro AngleBetweenVectors(v1, v2)
>>>
>>>       #local v1n = vnormalize(v1);
>>>       #local v2n = vnormalize(v2);
>>>
>>>       (2*atan2(vlength(v1n - v2n), vlength(v1n + v2n)))
>>>
>>> #end // macro AngleBetweenVectors
>>>
>>
>> Interesting, thanks. I'll play with it. There will be four sqrt calls
>> with this vs two so I expect it's a slower approach.
> 
> I prefer better accuracy before speed. If we need this to go faster we could
> compile it into POV-Ray and make it a new command; e.g. vangle().
> 
> 
>> Reminds me I captured fast approximation atan2 code I was thinking of
>> making an inbuilt function, but I've not gotten to it...
>>
>> And that thought reminds me of my plans to turn many macros into
>> "munctions"(1) calling new faster, inbuilt functions. Done only a tiny
>> bit of that so far.
>>
>> (1) - Yes, thinking about creating a munctions.inc file breaking out
>> what are really macro wrappers to functions into that file to make clear
>> what they are. Maybe all as M_ prefixed so my current F_dents() would
>> become M_dents(). Angle perhaps then M_Angle.
> 
> This sounds interesting. Can you please explain more ?

Unsure how much you've been following my povr branch posts...

For starters, over the last year or two I've replaced most of the 
existing 'odd shape' inbuilt functions for which functions.inc defines 
the interface and documents the usage with more generic ones. I've also 
extended and cleaned up the function<->pattern interface as related 
work. New function related wave modifiers for example.

On the idea on munctions.
-------------------------
One old macro always a "munction" is the Supertorus in shapes.inc but in 
the povr branch it now calls a new inbuilt function f_supertorus() for 
backward compatibility. New users should call f_supertorus() directly.

---
We've long had simple "munctions" that look like inbuilt capability such as:

#declare clip = function (x,y,z) {min(z,max(x,y))}

which in povr I changed to

#declare F_clip = function (x,y,z) {min(z,max(x,y))}

and I'm leaning now toward calling it M_clip because I want to make 
clear it is today a munction and not an inbuilt 'clip' keyword.

Longer term F_clip/M_Clip is educational in being simple, and it will be 
left as is on the creation of a proper 'clip' implementation to create 
inbuilt include test cases comparing M_clip results to 'clip' ones.

> Are there any benefits from using these instead of new built in commands ?

Sometimes. What munctions can today do not at all doable with inbuilts 
of the straight keyword kind, or the inbuilt functions, is pre-condition 
a larger set of stuff. Stuff being data / partial solutions - or the 
particular configuration and inter operation of a collection of 
functions(1).

When you say inbuilt command, there are flavors. For performance inbuilt 
is 'almost' - but not always better.

I've gotten somewhat comfortable adding inbuilt functions, patterns and 
shapes and the associated keywords.

When you talk a something like 'acos' there is an implementation in the 
parser and there is a parallel implementation in the vm to create/run 
the acos compiled code. Not all things in the parser are in the vm and 
visa versa. Things only in the parser cannot as a rule be used with the 
vm. Where the vm things mostly (all?) work during parsing.

Though 'acos' like implementations might often be best, I don't 
understand the code well enough to pull these sorts of dual keywords at 
the moment. In any case, I'd probably go after only a few things in this 
way such as: the 'munctions' even, odd, max3, min3, sind,... (Adding the 
constant 'e' is another though that I think I can work through today - 
just not done).

I can implement inbuilt functions helping simplify/speed or replace many 
effective 'munctions.' I've been working largely in this direction of late.

---
(1) Aside: I want to get to the point where we can tell whether a 
function is being run from the parser (single thread) or during 
rendering so we can precondition functions too. I have some ideas/notes 
around thread ids and such, but I've not worked out how to really do it.

Even today in f_ridged_mf() there is an allocation of memory which I 
believe should be done only by pre-conditioning during parsing(1a). 
Function equivalents of ripples, waves, wood, etc need a parse time 
preconditioning / set up capability too, to best work.

(1a) Depending on how threaded rendering work hits f_ridged_mf() today, 
I suspect we are sometimes getting minor memory leaks. In this case to 
with respect to functionality / result I think it harmless.

> 
> 
>> Something I've done too with the inbuilt function changes is allow
>> alternative calculations for the same thing. Compiled such conditionals
>> not that expensive. Most frequently single float options where those are
>> much faster, but different methods too. For one thing, the alternatives
>> I can bang against each other as a way to test!
> 
> Are you using this functionality to perform speed tests ?
> 

Sometimes, yes.

Aside: I've had several false starts looking at integrating the work you 
and I beleive more Alain Ducharme did years ago with quaternions.inc - 
as inbuilt capability of some kind, but never gotten very far with the 
effort. Always so much on that todo list - and I'm not that smart, so it 
goes slowly. :-)

Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: Why only a +1 clamp with VAngle, VAngleD macros in math.inc?
Date: 9 May 2021 10:04:28
Message: <6097ebec$1@news.povray.org>
On 5/9/21 9:31 AM, William F Pokorny wrote:
> Are there any benefits from using these instead of new built in commands ?

Dang..., one thing I was going to mention related to the 'munctions' 
concept and forgot.

I'm about 95% sure truly macro wrapped functions don't get 'compiled' by 
the vm until the macro is called. So, my thinking is there is a parse 
time reason to create 'macro wrapped' functions over pure function 
definitions of more complex math in our includes...

Not proven as in I haven't yet added throws to the vm code and tried 
functions defined both ways.

Bill P.


Post a reply to this message

From: Tor Olav Kristensen
Subject: Re: Why only a +1 clamp with VAngle, VAngleD macros in math.inc?
Date: 10 May 2021 22:55:00
Message: <web.6099f0f03160e21b6d7cc5a589db30a9@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/8/21 7:06 PM, Tor Olav Kristensen wrote:
>...
> 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... ;-)

That's good.

I'm not sure if I have seen Ingo's suggestion for how to test the include files.
Do you have any links to relevant threads ?

I hope that my rewrite of the Histrogram macro works ok in your branch then. I
tried to search for demo scenes that use this macro, but I couldn't find any.


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

Ok. I may be able to help with that, but it will probably take weeks or months
to go through all the macros and rewrite those that need to be improved.

If am going to spend much time rewriting a lot of macros, then I wish to dictate
the formatting style and the naming of variables in the macros.


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

Ok.

I have noticed at least one macro that duplicates the functionality of another
macro (I suspect that the author was not aware of that) - and there might be
more such macros.

Other macros demonstrate bad programming practice and/or are made in an
intricate way so that they require a lot of effort to redo in a proper way. I'm
reluctant to spend much time on those in the beginning.

Further, there are some macros that there should be no need for (because there
are better ways to do things), and others that there will very seldom be a use
for (or as you say: they are not commonly used).

Then there are macros that could be made simpler and/or more mathematical
efficient/robust/accurate.

New features in v3.8 will make it possible to rewrite macros that do things in a
"clumsy" way (because of earlier limitations in the language) to versions that
work in a more "elegant" and educational way.

The documentation inside the files for some macros are quite imprecise and
therefore need rewriting. Perhaps most of the documentation in the include files
should be moved into a document or to a web page that we refer to inside the
include files.

Some macros are so intricate and so influenced by its creator intricate way of
thinking that I'm having problems understanding what these macros are good for.
And they may be tightly coupled to other macros that do things in non-optimal
ways. I would suggest that the rewrite and inclusion of those is postponed until
we have decided if they really are useful or need.

Some macros use dubious (or obfuscated) "tricks", that are possible in the SDL,
just to save some characters or lines of code. Those can be quite difficult for
new users to understand. I suggest that those "tricks" should be saved for
problems where there are no other good ways to solve the problem.

Then there are macros that use syntax that are legal - and useful for those that
are a bit lazy or sloppy. But often they are not very educational. E.g. "scale
2", "#if (1)" or "ambient 0.2". These should be fixed so that it is easy for new
users to understand what is really going on.

There may be so many changes to the macros in the include files that I suggest
that we make new include files with new names which we move the good and fixed
macros into. The old files can then be left as legacy include files with their
old file names. We could then write that these include files are not recommended
for new scenes made with POV-Ray versions after v3.8.

I see now that I have been a bit brutal in my description of the current state.
Sorry about that.


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

Ok. I can't remember if I have seen that file.


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

I think that I agree with you on this. (I'll have to read it again later when
I'm not tired.)

If some include files are deemed to not be 'core', they could be moved into
another git repository that are maintained "on the side". (Perhaps you just
wrote that in the section above.)

--
Tor Olav
http://subcube.com
https://github.com/t-o-k


Post a reply to this message

From: ingo
Subject: Re: Why only a +1 clamp with VAngle, VAngleD macros in math.inc?
Date: 11 May 2021 04:11:47
Message: <XnsAD2767B86AC7Dseed7@news.povray.org>
in news:web.6099f0f03160e21b6d7cc5a589db30a9@news.povray.org Tor Olav
Kristensen wrote: 

> I hope that my rewrite of the Histrogram macro works ok in your
> branch then. I tried to search for demo scenes that use this macro,
> but I couldn't find any. 
> 

This is old stuff, it came from my "variate.inc" file that I can not find 
anymore. Iirc there was a test scene for it in there using histogram with 
the various distributions.

For testing includes, my like I did in "gradients.inc" 

#if(input_file_name="your_include_file.inc")

small test scenes or cases for each inc-item, maybe even render them as an 
animation

#end

http://news.povray.org/povray.tools.general/thread/%
3CXnsA9D2EF41831AEseed7%40news.povray.org%3E/

Ingo


Post a reply to this message

From: William F Pokorny
Subject: Re: Why only a +1 clamp with VAngle, VAngleD macros in math.inc?
Date: 11 May 2021 04:23:03
Message: <609a3ee7$1@news.povray.org>
On 5/10/21 10:50 PM, Tor Olav Kristensen wrote:

Up front, I want to state clearly I don't speak for POV-Ray.

My povr branch is a personal one. Anyone can use any work from it under 
the POV-Ray license terms. I consider it work donated to the POV-Ray 
team and community should they have use for any part of it.

It's linux/unix only for starters, simply because I'm not a real 
programmer and I don't know windows and long not used it day to day.


>> 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... ;-)
...
> I'm not sure if I have seen Ingo's suggestion for how to test the include files.
> Do you have any links to relevant threads ?
> 

None handy, but it basically adds a conditional at the very bottom of 
each include. There are variations but here is some stuff cut from my 
current functions.inc (less the line wrapping...):

//--- Self testing:  povr +mv3.8 +i<this_file>
#if(input_file_name="functions.inc")

     #fopen FID "SelfTestFunctionsInc.txt" write
     #write (FID,"\nExpect value followed by value generated.\nF_ 
prefixed are pattern/math wrapped equivalents.\n")

...
     // f_radial
     #write (FID,"\n---\n")
     #write (FID,concat("f_radial  0.000000 
",str(f_radial(+1,+0,+0),9,-1),"\n"))
     #write (FID,concat("f_radial  0.000000 
",str(f_radial(+0,+1,+0),9,-1),"\n"))
     #write (FID,concat("f_radial  0.875000 
",str(f_radial(+1,+0,+1),9,-1),"\n"))
...
     #ifdef (F_radial) #undef F_radial #end
     #declare F_radial = function { pattern { radial raw_wave } }
     #write (FID,concat("F_radial  0.000000 
",str(F_radial(+1,+0,+0),9,-1)," (raw_wave)\n"))
     #write (FID,concat("F_radial  0.000000 
",str(F_radial(+0,+1,+0),9,-1)," (raw_wave)\n"))
     #write (FID,concat("F_radial  0.875000 
",str(F_radial(+1,+0,+1),9,-1)," (raw_wave)\n"))
...
     #write (FID,"\n")
...

     #write (FID,"\n")

     #fclose FID

     #error "\n\n===Self testing. Stop before render.===\n"

#end // End self testing

#version Functions_Inc_Temp;
#end//functions.inc

Not set in stone but, the output is in the form:

   name expect_val SDL_created_val comment

for which I created a quick and dirty scanning and report script.


> I hope that my rewrite of the Histrogram macro works ok in your branch then. I
> tried to search for demo scenes that use this macro, but I couldn't find any.
> 

I also found nothing. Not tried yours as yet.

...
>>
>> 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.
> 
> Ok. I may be able to help with that, but it will probably take weeks or months
> to go through all the macros and rewrite those that need to be improved.
> 
> If am going to spend much time rewriting a lot of macros, then I wish to dictate
> the formatting style and the naming of variables in the macros.
> 

I'm mostly OK with that, but... :-)

Again, I'm not 'POV-Ray' - so measure your efforts here knowing it's not 
me that will decide whether any of your include changes become official 
ones.

povr specific
-------------
The pink elephant in room is that, though configurable, by default povr 
limits identifiers to a-z,0-9 and _ characters. I'm trying to make 
better the argument name collision exposure of traditional SDL by making 
the long recommended rules for identifiers hard parser checks.

Not 100% sure the hard identifier checking will stick, but... When 
there, you can use _abc like arguments and not worry about accidental 
collisions. And I'm hoping we can get away from macros such as the
Vector analysis macros with all the really long identifier names.

---
The blue elephant in the room is I want to make use of inbuilt code 
where I have it available. I want to make more pure macros, "munctions", 
and this can happen only in the povr branch around inbuilt functions 
which are not completely settled.

---
The green elephant in the room with the distributions in rand.inc. I'd 
like to move to something using the distributions shipped with c++ since 
c++11, but I've not worked out how to best do it.

---
Many elephants. :-) I can work off anything you publish aimed at a more 
generic, eventual v3.8. Perhaps that's a better direction for your work?

> 
>> For reference I'm shipping only the following includes as 'core' ones in
>> the povr branch.
...
>> Limit your look to these files for my participation. 
...
> 
> Ok.
> 
> I have noticed at least one macro that duplicates the functionality of another
> macro (I suspect that the author was not aware of that) - and there might be
> more such macros.

I know there are multiple interpolation macros(1) - and probably others.

(1) - One is outside the core set I think.

> 
...
> 
> New features in v3.8 will make it possible to rewrite macros that do things in a
> "clumsy" way (because of earlier limitations in the language) to versions that
> work in a more "elegant" and educational way.

Agree.

> 
> The documentation inside the files for some macros are quite imprecise and
> therefore need rewriting. Perhaps most of the documentation in the include files
> should be moved into a document or to a web page that we refer to inside the
> include files.
> 
...
> 
> There may be so many changes to the macros in the include files that I suggest
> that we make new include files with new names which we move the good and fixed
> macros into. The old files can then be left as legacy include files with their
> old file names. We could then write that these include files are not recommended
> for new scenes made with POV-Ray versions after v3.8.
> 
...

> I see now that I have been a bit brutal in my description of the current state.
> Sorry about that.

No issues here. I agree with everything you've said - and might even say 
more. :-) But, here too I need to make clear my povr branch breaks 
compatibility with many old scenes. Not so much in the parser where I'm 
trying to stick with v3.8's aim - except for the lower case identifiers 
but with other features / inner workings.

> 
>> arraycoupleddf3s.inc 

It's an include published along with DF3 documentation on put up on the 
wiki now quite a few years ago. Consider it povr specific though it was 
originally written to work with v3.7 or v3.8.

> 
> If some include files are deemed to not be 'core', they could be moved into
> another git repository that are maintained "on the side". (Perhaps you just
> wrote that in the section above.)
> 

Yes, that's exactly the idea. :-)

Bill P.


Post a reply to this message

From: ingo
Subject: Re: Why only a +1 clamp with VAngle, VAngleD macros in math.inc?
Date: 11 May 2021 04:35:30
Message: <XnsAD276BBE9FC07seed7@news.povray.org>
in news:6097e208@news.povray.org William F Pokorny wrote:

> For reference I'm shipping only the following includes as 'core' ones
> in the povr branch.
> 
> arrays.inc
> [...]
> 

If you see "core" as being "SDL extensions", to be maintained alongside 
POV-Ray itself, yes.

The texture and object creation includes are a just as vital part of a 
distribution imo. They could indeed be maintained in a different than the 
main repository. The same for the insert menu (win only?) and demo scene 
files.

Ingo


Post a reply to this message

From: Bald Eagle
Subject: Re: Why only a +1 clamp with VAngle, VAngleD macros in math.inc?
Date: 11 May 2021 06:05:00
Message: <web.609a569a3160e21b1f9dae3025979125@news.povray.org>
ingo <ing### [at] tagpovrayorg> wrote:

> The texture and object creation includes are a just as vital part of a
> distribution imo. They could indeed be maintained in a different than the
> main repository.

Yes - these are really important for new users as well as acting as a sort of
inbuilt idea-pad and historical record.

> The same for the insert menu (win only?)

qtpovray38 has the insert menu, and since it just uses the GUI to plop the
entire contents of a small file into a scene, those files could in theory be
used as includes, were they written to work that way.

> and demo scene files.

Yes, this is a sort of alternate documentation that is extremely important in
understanding the actual syntax and real-world implementation of various
features.


Post a reply to this message

<<< Previous 5 Messages Goto Initial 10 Messages

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