matlab oop methods override

MATLAB: anulando métodos table()



oop methods (3)

Dependiendo del uso de la nueva clase, quizás pueda seguir un enfoque más limpio. El enfoque propuesto descrito en su publicación tiene el inconveniente de que tal vez el código utilizado en su entorno actualizado no sea fácilmente transportable a un nuevo entorno, o un programa ejecutado en su entorno puede mostrar un comportamiento diferente en un entorno diferente.

Algunas preguntas que podría considerar (y quizás aclarar) serían: ¿Cómo piensa utilizar la nueva clase? ¿Desea reemplazar todos los usos de tabla existentes? ¿Desea poder usarlo en lugar de un argumento de clase de tabla? O desea alterar la tabla para que cada uso de la clase de tabla original en su entorno use la nueva clase.

Si solo necesita una nueva tabla mejorada para su uso, podría considerar encapsular la clase de tabla original en una nueva clase. Por ejemplo, MyTable, delegue todos los métodos que no necesite a los métodos de la tabla original, reemplace los métodos que le gustaría mejorar o agregue otros nuevos.

Actualización: Acabo de ver la solución completa en Github y comprendí lo que pretendía hacer. Buen trabajo. Dejaré el post en caso de que alguien lo encuentre útil.

CONFIGURACIÓN Win7 64b, R2015b, 16 GB de RAM, CPU i7-2700

La table() es una clase de Matlab fundamental que también está sellada , por lo tanto no puedo subclasificarla.

Quiero arreglar algunos métodos de esta clase y agregar otros nuevos . Por ejemplo, table.disp() está básicamente dañado, por ejemplo, intente NOT disp(table(rand(1e7,1))) , u olvide el ; en la ventana de comandos. La variable solo requiere 76 MB en RAM, pero la pantalla no tiene buffer y se detendrá su sistema!

  1. ¿Puedo anular métodos como table.disp() sin escribir en matlabroot/toolbox/matlab/datatypes/@table ?

  2. ¿Puedo extender la clase de la tabla con un nuevo método en C:/MATLAB/@table/ismatrixlike.m ? Porque consigo

    ismatrixlike(table) Undefined function ''ismatrixlike'' for input arguments of type ''table''.

    Obviamente lo hice

    addpath C:/MATLAB/ rehash toolboxcache

    También intenté clear all .

    La ruta tiene prioridad (alfabética) sobre matlabroot , pero falta una definición de clase table.m . Si agrego la definición de clase nativa a C:/MATLAB/@table , entonces puedo ejecutar mi nuevo método (después de clear all ). Sin embargo:

    >> methods(table) Methods for class table: classVarNames ismatrixlike table varfun convertColumn renameVarNames unstack

    solo enumera los métodos en la nueva carpeta /@table , aunque (algunos de) los métodos antiguos todavía funcionan, por ejemplo

    size(table)

    Esto resuelve en parte el problema, ya que ahora, la carpeta /@table/private nativa ya no es accesible y, por lo tanto, muchos métodos nativos están rotos.

¿Por qué estoy haciendo esto? Porque no quiero esperar otros 2 años antes de que se arregle la table() . Ya perdí días enteros porque simplemente olvidé un ; en la ventana de comandos y no puedo forzar un reinicio en mi PC si está ejecutando simulaciones de varios días, pero tengo que esperar a que finalice el intercambio de discos :(.

APÉNDICE Más contexto sobre disp(table(rand(1e7,1))) . Esto es lo que sucede cuando lo golpeo (y afortunadamente soy lo suficientemente rápido para sacar CTRL-C):

El culpable es la línea 172 de table.disp() que convierte la matriz numérica en una cadena de celdas (¡con el relleno también!):

[cells, err, isLeft] = sprintfc(f, x, b);

Después de experimentar con varias alternativas, adopté la solución que menos se @table implementación nativa de la @table Matlab y se elimina fácilmente si las cosas salen mal.

La solución:

  • copie toda la carpeta @table , es decir, el fullfile(matlabroot,''toolbox'',''matlab'',''datatypes'',''@table'') , en un destino donde tenga permisos de escritura .

    fullfile(matlabroot,''toolbox'',''local'',''myfiles'') el destino para ser fullfile(matlabroot,''toolbox'',''local'',''myfiles'') ya que no tengo que preocuparme por la compatibilidad cruzada del sistema operativo, es decir, matlabroot se encarga de eso por mí.

  • pegue en el destino su carpeta @table con los métodos nuevos, sobrecargados y que sobrescriben (sobrescribiendo parcialmente los archivos originales copiados)

  • agregue el destino a la ruta matlab, antes de la @table original, por ejemplo, addpath your_destination -begin

Efectos, pros y contras:

  • La clase / métodos nativos de @table ahora están sombreados, intente, por ejemplo, which table -all . Sin embargo, este efecto es bastante claro, fácilmente detectable y fácil de eliminar (eliminar destino y eliminar ruta);
  • No hay conflictos extraños entre @table nativo (ahora sombreado) y nuevo @table ;
  • Todos los métodos, nuevos y antiguos, son visibles, pruebe los methods(table) ;
  • Métodos de mesa privada son accesibles ...
  • ... pero estás obligado a usarlos.
  • Exponer los nuevos métodos (implementados por el usuario) a los privados requiere más mantenimiento y manejo directo de los conflictos de versión en las implementaciones de tablas.
  • Necesita permisos de escritura en algún destino elegible.

Para aquellos interesados ​​en los detalles, puede consultar https://github.com/okomarov/tableutils . Específicamente el install_tableutils (el readme puede no estar actualizado).

Los siguientes trabajos para mí:

  1. Defina una función disp modificada, digamos disp_modified.m , como sigue, y póngala en su ruta:

    function disp_modified(t) if istable(t) %// Do whatever you want to display tables builtin(''disp'', ''''''disp'''' function intercepted!'') else %// For non-tables, call `disp` normally builtin(''disp'', t) end

  2. Defina disp como un controlador de función para la función modificada (puede hacerlo en startup.m para tenerlo siempre por defecto):

    disp = @disp_modified;

Después de esto, en la ventana de comando me sale

>> disp(1:5) 1 2 3 4 5 >> disp({1 2 3 ''bb''}) [1] [2] [3] ''bb'' >> disp(table(rand(1e3,1))) ''disp'' function intercepted!