Mike Horvath <mik### [at] gmailcom> wrote:
> Should the POV-Ray links pages be moved to the wiki?
>...

Hi Mike

I'm not sure if that question was meant for me. But if it was - and if you if
you are referring about this page (which is probably very outdated by now):

    http://www.povray.org/resources/links/

- then my opinion is that we should try that.

I also think that we should add a date for when the link was last verified, so
that the link collection is easier to maintain.

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

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> I also think that we should add a date for when the link was last verified, so
> that the link collection is easier to maintain.

I know that there used to be a trivial way to have the webpage automatically
check all the links and grey-out any dead/invalid links.
I can't recall the exact format that I used to use, but I believe that it has
evolved into xml.

But yes, dates are nice, but I vote for the greying-out mechanism as well, if at
all possible.


(And if we're playing with hyperlink color schemes, I'd like a bit more
differentiation between the unvisited links and visited links, because they
appear far too similar in the message digest lists)

Post a reply to this message

On 5/16/21 12:10 PM, Tor Olav Kristensen wrote:
> 
> I have now created a new Github repository with POV-Ray macros that I think is
> useful.
> 
> https://github.com/t-o-k/Useful-POV-Ray-macros
> 
...

Cool! Very clean work as always. On my list to play with these macros 
along with your suggested stats updates.

---
A comment on local variables.

Where you have multiple references to a local variable, the symbol 
definition and look up is likely clearer and faster.

Where you have a local variable with only one reference, however, the 
symbol definition and look up is all overhead. There isn't any 
optimization which removes / streamlines the operations within macros.

There's a clarity vs performance trade-off in the single reference to 
local variable case.

Bill P.

--- Ref.

A millsion calls.

AngleBeteenVectors without Dot
-----------------------------

9.66user 5.30system 0:15.48elapsed
9.54user 5.44system 0:15.51elapsed
9.52user 5.49system 0:15.54elapsed
9.76user 5.14system 0:15.44elapsed
   "9.66 9.54 9.52"

AngleBeteenVectors with Dot local var
-------------------------------------

10.19user 5.58system 0:16.29elapsed
10.36user 5.39system 0:16.27elapsed
10.21user 5.48system 0:16.22elapsed
10.44user 5.48system 0:16.44elapsed
   "10.19 10.36 10.21"                 28.72 -> 30.76 ---> +7.10%

Post a reply to this message

> At the moment the macros are made for POV-Ray v3.7,
> but they should also work in v3.8.

If a macro is made for version 3.7, then, it will run in version 3.8.
To my knowledge, anything that works in version 3.3 to 3.7 will run in 3.8.

Post a reply to this message

On 5/17/2021 6:43 AM, Tor Olav Kristensen wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> Should the POV-Ray links pages be moved to the wiki?
>> ...
> 
> Hi Mike
> 
> I'm not sure if that question was meant for me. But if it was - and if you if
> you are referring about this page (which is probably very outdated by now):
> 
>      http://www.povray.org/resources/links/
> 
> - then my opinion is that we should try that.
> 
> I also think that we should add a date for when the link was last verified, so
> that the link collection is easier to maintain.
> 
> --
> Tor Olav
> http://subcube.com
> https://github.com/t-o-k
> 
> 


Yes, all this could be moved to the wiki.


Mike

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>
> > I also think that we should add a date for when the link was last verified, so
> > that the link collection is easier to maintain.
>
> I know that there used to be a trivial way to have the webpage automatically
> check all the links and grey-out any dead/invalid links.
> I can't recall the exact format that I used to use, but I believe that it has
> evolved into xml.
>
> But yes, dates are nice, but I vote for the greying-out mechanism as well, if at
> all possible.

An automatic check feature that can flag problematic links sounds good.

But I guess that it will not be able to detect all place-holding and parasitic
web pages that any new domain owners have placed there instead of old pages. So
manual checks will probably also be needed.


> (And if we're playing with hyperlink color schemes, I'd like a bit more
> differentiation between the unvisited links and visited links, because they
> appear far too similar in the message digest lists)

Yes, I agree.

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

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>...
> A comment on local variables.
>
> Where you have multiple references to a local variable, the symbol
> definition and look up is likely clearer and faster.
>
> Where you have a local variable with only one reference, however, the
> symbol definition and look up is all overhead. There isn't any
> optimization which removes / streamlines the operations within macros.
>
> There's a clarity vs performance trade-off in the single reference to
> local variable case.

Thank you for testing this Bill. - And for mentioning this performance issue.

As you say it's a clarity vs performance choice. Normally I prefer to go for
clarity and readability before performance. I also think that we should try to
make it easy for new users to learn from the code in the standard libraries. So
when I made those macros I tried to make it easy to recognize the parts that are
similar.

Further I think that descriptive, non cryptic variable names serve as part of
the documentation. (Some seem to think that programming in POV-Ray's SDL is a
continuous short code contest.)

But the macros in question are not so big and complicated, so I have followed
your advice and removed all but one of the local variables that are only
referenced once.

I have also rewritten a few of the macros slightly and added some new ones.

> A millsion calls.
>...

;)

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

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:
>
>
> > At the moment the macros are made for POV-Ray v3.7,
> > but they should also work in v3.8.
>
> If a macro is made for version 3.7, then, it will run in version 3.8.
> To my knowledge, anything that works in version 3.3 to 3.7 will run in 3.8.

Hi Alain

Yes, that is my understanding too. But I'm hesitating to claim that they work in
v3.8 before I or someone else have actually tested them there.

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

Post a reply to this message

On 5/19/21 3:55 PM, Tor Olav Kristensen wrote:
> I have also rewritten a few of the macros slightly and added some new ones.
> 

I like how macros using functions of transforms & inverse transforms 
ended up. :-) Those, I didn't expect you to change and yet what you did 
looks to me to be a clever approach to handling a macro's dynamically 
defined functions.

I'll have to spend more time thinking about it and the actual inner 
workings. I suspect you've gotten to something near like what happens 
with prod and sum internally with the vm.

>> A millsion calls.
>> ...
Yes, I'm forever inventing new words! :-) I've not a clue how I arrive 
at some of them.

---
I noticed in your vectors.inc the indenting occasionally varies. It 
looks like you mostly use increments of four - which is very common - 
but OrthogonalVector, for example, uses three. I'd guess because it was 
that in math.inc ?

---
I've been looking more at your Mean, Variance, Minimum, Maximum, 
PrintStatistics, and Histogram suggestions. First, issue I hit was 
testing your comments about vectors.

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

However, dimension_size() expects an array identifier. Is there some 
trick to getting vectors to work with dimension_size()?  As far as I 
know, the dimension* SDL keywords work only with array identifiers and 
'defined on call' arrays. The latter meaning:

    Mean(array {0.1,0.2,0.3,0.4,0.5})

is OK to do. Yes, this last bit is a little more than what our current 
documentation says you can do.

---
I've recently moved the vector analysis macros in math.inc to a 
vectoranalysis.inc include - which itself won't be a 'core' include. 
Thinking the array statistics a better fit in a similar 
arraystatistics.inc include - again now not a 'core' include.

With your vectors.inc, on the other hand, I'm starting to lean toward it 
being a 'core' include file. Need to resolve collisions with math.inc 
macros as a start.

---
Aside: Instead of moving some of the contents of arraycoupleddf3s.inc to 
arrays.inc, I went the other way! I moved the ARRAY_WriteDF3 macro into 
arraycoupleddf3s.inc alongside the ARRAY_ReadDF3 macro already therein 
along with some other DF3 related macros. I dropped too the ARRAY_ 
prefixes. I now plan to treat arraycoupleddf3s.inc as a core include 
file. I believe reading and writing DF3s should be doable from SDL as 
'POV-Ray' is shipped.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>...
> I noticed in your vectors.inc the indenting occasionally varies. It
> looks like you mostly use increments of four - which is very common -
> but OrthogonalVector, for example, uses three. I'd guess because it was
> that in math.inc ?

Yes, sorry about that. I hope I've fixed it now.

Years ago, when I had a tiny monitor, I used 2 spaces for indentation. Now I
prefer 4. 3 is very odd !  And I really hate indentation with TABs. (Because
stuff jumps around - and very seldom ends up where it looks consistent and
nice.) The Golang linter use TABs for indentation, so it's not very likely that
I will love to program in Go.


> I've been looking more at your Mean, Variance, Minimum, Maximum,
> PrintStatistics, and Histogram suggestions.

Good. I'm not sure if I like that the minimum and maximum values in the
Histogram macro always ends up at the "edges" of the outer bins. Perhaps someone
well-versed in statistics can give some advice here.


> First, issue I hit was
> testing your comments about vectors.
>
> // Does also work for vectors
> #macro Mean(Values)
> ...
>
> However, dimension_size() expects an array identifier. Is there some
> trick to getting vectors to work with dimension_size()?  As far as I
> know, the dimension* SDL keywords work only with array identifiers and
> 'defined on call' arrays. The latter meaning:
>
>     Mean(array {0.1,0.2,0.3,0.4,0.5})
>
> is OK to do. Yes, this last bit is a little more than what our current
> documentation says you can do.
>...

Try this:

#declare SomeVectors2D =
    array[5] {
        < 1,  5>,
        <-2, -2>,
        < 6,  3>,
        < 0,  2>,
        < 3, -1>
    }
;
#declare vMean2D = Mean(SomeVectors2D);
#declare vVariance2D = Variance(SomeVectors2D);
#debug "\n\n"
#debug concat("<", vstr(2, vMean2D, ", ", 0, -1), ">")
#debug "\n"
#debug concat("<", vstr(2, vVariance2D, ", ", 0, -1), ">")
#debug "\n\n"

#declare SomeVectors3D =
    array[5] {
        < 1,  5,  3>,
        <-2, -2,  0>,
        < 6,  3, -4>,
        < 0,  2,  2>,
        < 3, -1, -5>
    }
;
#declare vMean3D = Mean(SomeVectors3D);
#declare vVariance3D = Variance(SomeVectors3D);
#debug "\n\n"
#debug concat("<", vstr(3, vMean3D, ", ", 0, -1), ">")
#debug "\n"
#debug concat("<", vstr(3, vVariance3D, ", ", 0, -1), ">")
#debug "\n\n"

#error "Finished"

- and so on...

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

Post a reply to this message