POV-Ray : Newsgroups : povray.general : Why only a +1 clamp with VAngle, VAngleD macros in math.inc? Server Time
29 Mar 2024 02:06:55 EDT (-0400)
  Why only a +1 clamp with VAngle, VAngleD macros in math.inc? (Message 11 to 15 of 15)  
<<< Previous 10 Messages Goto Initial 10 Messages
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 10 Messages Goto Initial 10 Messages

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