[Octave-bug-tracker] [bug #60818] delaunayn - 2D code path vectorization doesn't match nD algorithm

[Nicholas Jankowski]

Follow-up Comment #37, bug #60818 (project octave):

ok. file attached makes a few changes. 

1: replaced both l and q with ~ is the lu output. just leaving q out issues a
warning and significantly alters the output, but leaving the placeholder in is
fine.  a bit less in memory now, but it's still big.

2: both code paths now start with the same dimension independent edg_vec as
currently set in the LU path, and end with the same dimension independent
volume/prod(edge_lengths) <tol check.  the edge_lengths reshapes/permutes for
that are pretty low impact. 

3: it would be a nice-to-have, but not necessary, if we could use the 
reshape/permuted edg_vec in the first place, and go from that to eqs. it would
remove two separate reshapes. but, compared to other things they are low
impact.

3: what is an oddly large impact is getting the vol back out of the R's.  the


prod(reshape(kron(R,ones(1,nt))(reordered_tri_idx.'==(1:nt)),dim,nt),1)

process is oddly time consuming.  splitting it apart, kron(R,ones(1,nt) for
the 1000pt 3D case takes a few seconds, and then the
(reordered_tri_idx.'==(1:nt)) take the same about of time, too.  

Was hoping to get that to work so we'd have a consistent <tol test between
codepaths (which kicked this off in the first place). if that's an issue maybe
could go back to the idea of just testing R/min(edg_vec) for each tri, but
that may have the same kron / reordered issue. will look more at that.

this version also still just uses the laplace expansion for 2 and 3d.   once
happy with the nD codepath it's trivial for me to move in higher order
dimensions for that if that turns out to be better. faster code vs
less/simpler code?


(file #51640)
    _______________________________________________________

Additional Item Attachment:

File name: delaunayn.m                    Size:6 KB
    <https://file.savannah.gnu.org/file/delaunayn.m?file_id=51640>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60818>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/