"jr" <cre### [at] gmailcom> wrote:

> had a quick look, the page appears to give you the lot.

Right, it looked solid enough to pursue, though it will require a lot of
fiddling to adapt to SDL.

> thinking you ought to have a look at the GSL (GNU Scientific Library); I just
> found an index entry for singular value decomp.

I got that set up, and now need to learn how to use such things.

It appears that I have to write a c++ program and compile it, and then run it.


Looks like this guy has a short program written, where we could just delete or
comment out the Eigen stuff:

https://stackoverflow.com/questions/36959506/eigen-library-svd-is-slow-compared-to-gsl

If you can work something out that runs - tell me what format we need for the
data input - CSV would be nice ;) and then we can see what this thing _does_.

Can we run POV-Ray to #write trace() results to disk, and then call the c++ to
write the SVD data to a file?  Can that c++ program then restart POV-Ray to use
the SVD data? (have an if file exists block to switch between write data and
read data)?

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ... I wrote a macro which "scans" an object's BB ...

find attached the second update of the 'Bounder'.

things have changed a little.  now, if the object's BB is found to be "(near)
optimal", the macro prints that and ends, otherwise, ie having some "slack", the
macro prints the difference lines as before, plus the optimised extents and
dimensions, as per Thomas's feedback.

also new, if "slack" is reported, two variables with the differences from the
BB's min/max extents are declared, to allow use of the info from in-scene.
after 'Bounder' has run, one can for instance:

#ifdef(Bounder_min_diff)
  // do something
#end

so.  version 3.  fingers crossed.


enjoy, jr.

Post a reply to this message

Attachments:
Download 'bounder.inc.txt' (9 KB)

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > had a quick look, the page appears to give you the lot.
> Right, it looked solid enough to pursue, though it will require a lot of
> fiddling to adapt to SDL.
>
> > thinking you ought to have a look at the GSL (GNU Scientific Library); I just
> > found an index entry for singular value decomp.
>
> I got that set up, and now need to learn how to use such things.
> It appears that I have to write a c++ program and compile it, and then run it.

'C', not 'C++'.  ;-)  (in an ideal world, anyway)

I think cutting and pasting that c++ code into a single source and getting that
to compile, or at least spit out errors, would be a good exercise, then.

> Looks like this guy has a short program written, where we could just delete or
> comment out the Eigen stuff:
>
>
https://stackoverflow.com/questions/36959506/eigen-library-svd-is-slow-compared-to-gsl

I'll look at that later.  one thing at a time.

> If you can work something out that runs - tell me what format we need for the
> data input - CSV would be nice ;) and then we can see what this thing _does_.

first I suggest get that c++ to build, as exercise.

I did not read the article too closely but am under the impression that if one
re-assembles the functions in one source file, it'll build.  do you want to use
this code as a starting point?  if yes, then that will determine/influence the
data format.

> Can we run POV-Ray to #write trace() results to disk, and then call the c++ to
> write the SVD data to a file?  Can that c++ program then restart POV-Ray to use
> the SVD data? (have an if file exists block to switch between write data and
> read data)?

yes, in all likelihood _but_ how's your 'C', Bill?  or are you .. wedded to
'C++'?


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> 'C', not 'C++'.  ;-)  (in an ideal world, anyway)

I can't really ever tell the difference just by looking   :P

> I think cutting and pasting that c++ code into a single source and getting that
> to compile, or at least spit out errors, would be a good exercise, then.

.... a single source.  a .c file and then do a gcc compile to make a ... .bin?
..exe?


> first I suggest get that c++ to build, as exercise.

this one:
https://www.codeproject.com/Articles/1268576/Singular-Values-Decomposition-SVD-In-Cplusplus11-B

I have never "built" anything from scratch, so I really have no idea what I'm
doing or why.

> I did not read the article too closely but am under the impression that if one
> re-assembles the functions in one source file, it'll build.  do you want to use
> this code as a starting point?  if yes, then that will determine/influence the
> data format.

Sure, whatever.   but that guy's code is redundant to the gsl library.  If I've
already installed that - isn't that ... built? (*)



> yes, in all likelihood _but_ how's your 'C', Bill?  or are you .. wedded to
> 'C++'?

I used to write a bunch of stuff for different Arduinos - ATMega and Leonardo...
 still some confusion as to whether that's C or c++


But I'm sure I could learn.  I _would_ rather stick with one language, to
minimize confusion, and if POV-Ray source is in c++, then I'd prefer that, but
I'm sure one translates over to the other to some extent.

(*)

oem@oem-Inspiron-N5110 ~/Desktop $ apt-cache show gsl-bin
Package: gsl-bin
Source: gsl
Priority: optional
Section: math
Installed-Size: 63
Maintainer: Dirk Eddelbuettel <edd### [at] debianorg>
Architecture: amd64
Version: 2.5+dfsg-6~16.04
Replaces: gsl
Depends: libc6 (>= 2.7), libgsl23 (>= 2.5)
Conflicts: gsl
Filename: pool/main/g/gsl/gsl-bin_2.5+dfsg-6~16.04_amd64.deb
Size: 29470
MD5sum: d91cad88f7767c41d41d9194e79c5b51
SHA1: 722962da0169254fee7bc14b48b1ba948514df7f
SHA256: d2e80f2cabcdec706397145d324ea57c425b9184b1fb1afe8d80de711438468e
Description-en: GNU Scientific Library (GSL) -- binary package
 The GNU Scientific Library (GSL) is a collection of routines for
 numerical analysis.  The routines are written from scratch by the GSL
 team in C, and present a modern API for C programmers, while allowing
 wrappers to be written for very high level languages.
 .
 This package provides several example binaries.
 .
 URL: http://www.gnu.org/software/gsl/
Description-md5: 7553709bb194c39b6d774e61c06ec157
Multi-Arch: foreign

Package: gsl-bin
Priority: optional
Section: universe/math
Installed-Size: 62
Maintainer: Ubuntu Developers <ubu### [at] listsubuntucom>
Original-Maintainer: Dirk Eddelbuettel <edd### [at] debianorg>
Architecture: amd64
Source: gsl
Version: 2.1+dfsg-2
Replaces: gsl
Depends: libc6 (>= 2.7), libgsl2
Conflicts: gsl
Filename: pool/universe/g/gsl/gsl-bin_2.1+dfsg-2_amd64.deb
Size: 11250
MD5sum: d182e4dfa1ce45358d88dbf728871e3d
SHA1: b23fab8ea5f411ebfb6be076c0f43fd1271b613d
SHA256: 826ee499196a9fa12aabcd4ca66616334ae9abf8f11467c7b007f63666f56732
Description-en: GNU Scientific Library (GSL) -- binary package
 The GNU Scientific Library (GSL) is a collection of routines for
 numerical analysis.  The routines are written from scratch by the GSL
 team in C, and present a modern API for C programmers, while allowing
 wrappers to be written for very high level languages.
 .
 This package provides several example binaries.
 .
 URL: http://www.gnu.org/software/gsl/
Description-md5: 7553709bb194c39b6d774e61c06ec157
Multi-Arch: foreign
Homepage: http://www.gnu.org/software/gsl
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > 'C', not 'C++'.  ;-)  (in an ideal world, anyway)
>
> I can't really ever tell the difference just by looking   :P
>
> > I think cutting and pasting that c++ code into a single source and getting that
> > to compile, or at least spit out errors, would be a good exercise, then.
>
> .... a single source.  a .c file and then do a gcc compile to make a ... .bin?
> ..exe?

one file, yes.  the usual extension is '.cpp'.  then compiling with:
  $ c++ myfile.cpp
should create an 'a.out' executable.

> > first I suggest get that c++ to build, as exercise.
>
> this one:
>
https://www.codeproject.com/Articles/1268576/Singular-Values-Decomposition-SVD-In-Cplusplus11-B
>
> I have never "built" anything from scratch, so I really have no idea what I'm
> doing or why.

now's the time.

> > I did not read the article too closely but am under the impression that if one
> > re-assembles the functions in one source file, it'll build.  do you want to use
> > this code as a starting point?  if yes, then that will determine/influence the
> > data format.
>
> Sure, whatever.   but that guy's code is redundant to the gsl library.  If I've
> already installed that - isn't that ... built? (*)

sure, but a library is just (a bag of) components.


> > yes, in all likelihood _but_ how's your 'C', Bill?  or are you .. wedded to
> > 'C++'?
>
> I used to write a bunch of stuff for different Arduinos - ATMega and Leonardo...
>  still some confusion as to whether that's C or c++

Arduino has a 'C' SDK afaik.

> But I'm sure I could learn.  I _would_ rather stick with one language, to
> minimize confusion, and if POV-Ray source is in c++, then I'd prefer that, but
> I'm sure one translates over to the other to some extent.

it does, and it doesn't.  while c++ was developed from c, and so has some vague
visual semblance, that exactly is a big problem -- people tend to overestimate
the "some extent".

from a practical point of view, forget the POV-Ray source for now, other than
for reading.  get working experience of the tool chain.

since I do not speak c++, I won't be too much help when, as we all do, you find
yourself in a battle with the finer points of the language, however, maybe Dick
Balaska will chip in.

> (*)
> oem@oem-Inspiron-N5110 ~/Desktop $ apt-cache show gsl-bin
> Package: gsl-bin

looks like you're good to go.  (effing weird this gratuitous splitting of
packages in to 'bin' and 'dev'.  but hey, "you pays your money and takes your
choice")


regards, jr.

Post a reply to this message

Op 04/11/2019 om 15:07 schreef jr:
> "jr" <cre### [at] gmailcom> wrote:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>> ...
>>> - I include the test scene file for you to play with.
>>
>> thank you v much for this.  not only do I get those natty presentation settings
>> :-), but looking at the code I surmise you replaced the 'local's of the
>> difference vectors with 'declare's?  that's given me another idea for an
>> improvement: create two variables, 'Bounder_{min,max}_diff' and export
>> ('declare') them for in-scene use.  thoughts?
>

I did. Just changed #local to #declare.  ;-)
I suppose that using #local inside the macros is ok; #declare in the 
resuming section could be more useful for subsequent use.

> d'oh!  finally got the "why".  :-)  with yr permission will add the calculator,
> also will adopt the "proper" labelling in existing output.  thanks.
> 

Be my guest :-)

-- 
Thomas

Post a reply to this message

Op 04/11/2019 om 20:01 schreef Bald Eagle:
> Great job Thomas - those results are surprising, given the absolute mathematical
> nature of those shapes.
>

Thank you indeed, sir. I was curious to see if bounder.inc was universal 
or not. I assumed it was given the nature of the tests, and like you, I 
was surprised.

> I would have imagined that with something like a parametric, you'd be able to
> cycle through u and v real quick, and get a min and max value for each axis to
> use for the AABB dimensions.   I'm also still completely mystified as to why the
> parametric is such a slow-to-render object, and why the triangle approximation
> isn't a source-coded native primitive.
> 

These are mysteries on Earth and below the heavens which we may not be 
permitted to fathom...

-- 
Thomas

Post a reply to this message

Op 04/11/2019 om 09:09 schreef Thomas de Groot:
> - rotating the object changes the 'tightness' of the standard BB. I did 
> that with a simple cylinder: when properly aligned along one of the 
> axis, the BB test is always optimal; rotate the cylinder (e.g. 
> <45,45,45>) and do the test, and the standard BB becomes too wide.
> 

I have to correct this: The BB only becomes slightly less optimal in the 
example cited. With increasing complexity of the object however, 
optimisation kicks in.

-- 
Thomas

Post a reply to this message

Op 04/11/2019 om 09:09 schreef Thomas de Groot:
> - the test is also useful with hyperboloid, superellipsoid, and 
> isosurface objects. Quartic and parametric objects do no comply, 
> probably they are not 'solid'? I did not test this thoroughly.
> 

The test (using version 2 of bounder.inc) for quartic objects is 
interesting. Using the Lemniscate object the BB seems to be infinite and 
the test is considered optimal. See image attached.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'quarticbound.jpg' (174 KB)

Preview of image 'quarticbound.jpg'

Op 05/11/2019 om 01:19 schreef jr:
> "jr" <cre### [at] gmailcom> wrote:
>> ... I wrote a macro which "scans" an object's BB ...
> 
> find attached the second update of the 'Bounder'.
> 
> things have changed a little.  now, if the object's BB is found to be "(near)
> optimal", the macro prints that and ends, otherwise, ie having some "slack", the
> macro prints the difference lines as before, plus the optimised extents and
> dimensions, as per Thomas's feedback.
> 
> also new, if "slack" is reported, two variables with the differences from the
> BB's min/max extents are declared, to allow use of the info from in-scene.
> after 'Bounder' has run, one can for instance:
> 
> #ifdef(Bounder_min_diff)
>    // do something
> #end
> 
> so.  version 3.  fingers crossed.
> 
> 
> enjoy, jr.
> 

With version 3, I get a parser error in the scene file when the object 
is considered as near optimal: "Expected 'numeric expression', 
undeclared 'Bounder_min_diff' found instead"

-- 
Thomas

Post a reply to this message