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

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

[Octave-bug-tracker] [bug #61319] idivide fails to distinguish between c


From: Michael Leitner
Subject: [Octave-bug-tracker] [bug #61319] idivide fails to distinguish between ceil and floor for inputs close to perfect squares
Date: Tue, 22 Feb 2022 04:20:28 -0500 (EST)

Follow-up Comment #17, bug #61319 (project octave):

Yes, there is overhead, but what is shown in bug #62006 is not directly
applicable here: the comparison should not be between an empty loop and a loop
with an empty .oct file function, but between a loop with a trivial built-in
function and a loop with a trivial .oct file function. Because we would
replace the z = x ./ y; (which I think to be exactly the same as
z=rdivide(x,y), with the same overhead, without having tested), by this .oct
file function call. Thus, is there more overhead for.oct file functions than
for built-ins? 

And in my naive view (never been closer to the internals of octave than .oct
files) it would not mean diving into the interpreter: we would not need a new
operator (in the sense of a new symbol that the interpreter has to parse), but
just a new built-in function named somewhat like idivide_nat, that does native
(right) integer division, exactly the same as rdivide (specialized to integers
and to element-wise operation), but only without the post-processing. And (to
repeat, in my naive view) adding a new built-in function should not be so
hard, but definitely has also disadvantages (function look-up for any function
would become slower, as the list to be searched becomes longer). 

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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