octave-maintainers
[Top][All Lists]
Advanced

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

Fwd: Considering adding a "dispatch" function for compile-time polymorph


From: David Spies
Subject: Fwd: Considering adding a "dispatch" function for compile-time polymorphism
Date: Thu, 31 Jul 2014 22:00:55 -0600



---------- Forwarded message ----------
From: David Spies <address@hidden>
Date: Thu, Jul 31, 2014 at 10:00 PM
Subject: Re: Considering adding a "dispatch" function for compile-time polymorphism
To: "John W. Eaton" <address@hidden>



In many Octave functions, we have code that does things like

  NDArray nda = ov.array_value ();

and this operation succeeds if it is possible for the octave_value object OV to be converted to an NDArray object.  Is it really better to have what is essentially a big switch statement that checks known types of octave_value objects?  Using the switch statement means that if a new type is added that can be converted to an NDArray object, you have to modify the switch statement to make this work.
Not necessarily.  The switch statement still does this with types it doesn't handle.  For instance, Range degenerates into an NDArray.

With conversions, you can make this work just by providing an array_value function in your new type.
This is not true.  You're assuming that the matrix you're trying to deal with "can" be efficiently represented as an NDArray.  If this were always true, there would be no need to have other matrix types.

NDArray is not a valid substitute for Sparse, DiagArray2, or PermMatrix (as all of these are "sparse" in the sense that they are mostly zeros and so it's necessary to use the proper nz-iterator types).  As soon as these matrices exceed the bounds of octave_idx_type, they can no longer be converted to an NDArray, but long before that point, converting can result in hideously inefficient behavior and can cause Octave to consume all of a machine's memory and crash.


Instead of an array_value function which only takes a permutation matrix
as an argument, wouldn't you prefer one which takes any matrix type as
an argument (including sparse or diagonal)?

I guess I don't understand this question because the octave_value::array_value function is implemented for more than just permutation matrices, isn't it?


Yes, but there's a separate implementation of array_value for every matrix type even though the logic is virtually identical in all of them (start with a matrix of all zeros.  Iterate over the nonzero values in the original matrix and set them to the same value in the result matrix).  With dispatch (together with nz-iterators), the same code can be reused for all implementations of array_value (No copy-pasting or macros required).


    If you are checking for each specific type and dispatching, then how
    is this approach better than providing a "find" method in the
    octave_value class and using a virtual function to perform the
    dispatching?


I'm not dispatching to different implementations, I'm dispatch to the
same implementation with different template types.  As far as I know,
that's impossible with virtual methods (because virtual methods can't be
templated)

Please point me to the code that does this.

The dispatch method in libinterp/corefcn/dispatch.h calls its template template functor argument "fun" with the deduced template type.
 

reply via email to

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