octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #38628] bsxfun slow for complex


From: Arun Giridhar
Subject: [Octave-bug-tracker] [bug #38628] bsxfun slow for complex
Date: Sat, 17 Sep 2022 13:50:05 -0400 (EDT)

Follow-up Comment #13, bug #38628 (project octave):

Question. Why are we doing this pattern for each element?

if (! tmp(0).isfloat ())
  {
    have_FloatNDArray = false;
    C = result_FloatNDArray;
    C = cat_op (C, tmp(0), ra_idx);
  }
else if (tmp(0).isreal ())
  result_FloatNDArray.insert
    (tmp(0).float_array_value (), ra_idx);
else
  {
    result_FloatComplexNDArray
      = FloatComplexNDArray (result_FloatNDArray);
    result_FloatComplexNDArray.insert
      (tmp(0).float_complex_array_value (), ra_idx);
    have_FloatNDArray = false;
    have_FloatComplexNDArray = true;
  }

This is casting the partial result generated so far into a new type, then
appending the current element's result, and declaring that to be the new
augmented result.

>From what I've seen so far, some things like sparse/full or single/double or
float/integer can be decided up-front, so the above checks could be done once
before starting the loop. Does that extend to real/complex as well? If the
first few elements of a complex array have no imaginary part, are they being
treated as real, and is that why the above code pattern exists to allow the
whole result to become complex?


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]