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

[Markus Mützel]

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

Could you please attach a patch for the latest version? I find it easier to
see what has changed with patches.

If we would like to implement that, we should probably not simply
half/quarter/... the input size of `lu`. Instead, we should probably partition
such that the size of `eqs` doesn't exceed a limit we'd still need to
determine.
E.g. if we should decide that the "payload" of `eqs` shouldn't exceed 256 MiB
with double precision floating point numbers:

max_num_simplices_per_loop = max (1, floor (2^28/8/nd^2));

Or whatever we deem reasonable.
I'm not sure how much memory `lu` needs for a given input size. So that
estimate could be quite off from a reasonable value.

Looking at the last patch, the limit that we use for deciding which simplices
to eliminate is: 

R < 100 * (nd - 1) * nt * eps (max (R))

The vector `R` should be small compared to the matrix `eqs`. Would it be
possible to collect the elements of `R` in that loop?

Since it looks like we are never using `q` (is that still true in the latest
version?), you could probably write:

[~, u, p, ~] = lu (eqs, "vector");

That might also save some memory.

    _______________________________________________________

Reply to this item at:

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

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