On 10/13/19 5:14 PM, jr wrote:
> 
> in a way I'm surprised that POV-Ray does not contain its own low-level maths
> library, I'd have thought that an advantage.  

If I'm following your meaning. There is some. Some even in the shipped 
SDL includes.

> so, I wonder (not knowing the code
> base + off the top of my head) whether collecting various low-level routines
> into a "convenience" library included with POV-Ray would not help with platform
> independence/"implementation differences". 

Again improvement possible in this vein though I don't expect it to help 
much with platform issues - if we have many.

Truth is POV-Ray is really good at compiling and running the same way on 
any platform with a standards compliant C++ compiler. The core 
developers have worked hard at to make this so.

I was speaking of a few concerns - those mostly given recent past 
vector.h behavior in not getting the C++ standard include for abs. It 
just happened the code involved here touches on those 'concerns.' Had 
OSX and Windows users tested, it was as much to confirm no differences 
as anything. I think we 'might' have a soft spot - but maybe not, it's a 
worry.

> libraries like the GSL (see
> attached) are highly optimised and easily wrapped/"plundered".
> 

Yeah, such suggestions always sound good - to me too on first glance. 
The devils are in the details...

In looking at the solvers I've looked on and off at gsl, eigen, Intel's 
embree(sp?) package and others. I borrowed ideas for updates to our 
common quadratic solver from a CERN math package. The julia language 
itself is interesting in that it might eventually be a path to an llvm 
jit implementation POV-Ray could use - but I think it too unstable to 
consider seriously at this point. Julia is in the shiny, new, gazillion 
commits a day phase. Aside: I see julia as an implementation of try this 
math on the fly ideas CERN has been doing themselves for a long time by 
hacking C or C++. So many languages, packages, and papers out there... 
One just drowns in the noise.

I'm looking again at eigen's nD vector support of late as an alternative 
to vector.h which - it appears - is tangled in a negative performance 
impact 3.7 to 3.8. But more interested due my immediate solver work 
needs for flexibility with respect to the 'n' part of nD. I'd like our 
vector.h to be just what I need and it isn't. :-)

Anyway. What can I say somewhat quickly. With my solver work one aim has 
been moving my code in a direction which makes plugging in a common 
library more doable. Still, lots of details would hang us up. Just 
trying to plug in standard solvers where it could be done technically 
(you'd get roots) is iffy because ours are often ray tracer tweaked 
solvers. A lot of the code you find, in sage for example, has the 
solvers set up for more than direct on floating point hardware reals too 
- meaning the code is often built upon largish software packages 
themselves - which makes extracting just what we want harder.

Making parts and pieces of gsl et al available as functions in the 
POV-Ray VM could be interesting. There, not be being tangled in the 
larger POV-Ray code base might make it easier to do.

Bill P.

Post a reply to this message