Preguntas de un "tonto" - página 127

[Vladimir Gomonov]

Renat:

Estimado señor, observe el contexto.

1) Cuando saltas de un entorno controlado y seguro a un búfer sin control alguno, tú eres el responsable de la compatibilidad con ese entorno binario.

2) Cuando escribes código, eres responsable de la arquitectura de ese código. Y no te quejes de que "es difícil meter a un caballo y a una cierva en el mismo carro" cuando utilizas estructuras diferentes.

3) Te recomiendo que leas la descripción de CLBufferRead y CLBufferWrite - gracias a la referencia universal void*, puedes pasar cualquier tipo de referencia a OpenCL. Y también hay compensaciones y tamaños.

1. Estoy preparado para esta responsabilidad. // ajustando una corbata imaginaria y luchando por contener la risa.

2. No estoy llorando. Es una tontería escribir tus propias matrices bidimensionales o tridimensionales que parece que ya existen en el lenguaje. Y tienes que hacerlo.

3. Lo comprobaré. En la versión antigua, el paso de un array bidimensional NO FUNCIONABA. No lo probé en el nuevo de la vieja memoria.

// ArrrayCopy() también parece tener su void, pero es de felpa y se aplica sólo al tipo de array, no a la dimensión.

Fui a comprobar el tercer punto.

[Renat Fatkhullin]

Precisamente estáis llorando y acusando a los demás de tener carencias en el proceso. Así que no hay necesidad de hacer payasadas.

Sobre las matrices multidimensionales:

• Las matrices multidimensionales funcionan.
• utilizar la POO, mantener/ocultar las matrices dentro de las clases
• menos desmedida de pasar matrices multidimensionales como parámetros.
  
• utilizar activamente las estructuras: facilitan mucho la vida y el control, reduciendo la complejidad.
  

Inmediatamente será más fácil y correcto.

[Vladimir Gomonov]

Renat:

Precisamente estáis llorando y acusando a los demás de tener carencias en el proceso. Así que no hay necesidad de hacer payasadas.

Sobre las matrices multidimensionales:

• Las matrices multidimensionales funcionan.
• utilizar la POO, mantener/ocultar las matrices dentro de las clases
• Pasar menos arrays multidimensionales como parámetros
  
• utilizar activamente las estructuras: facilitan mucho la vida y el control, reduciendo la complejidad.
  

Inmediatamente será más fácil y correcto.

Y mi descontento estaba bien fundamentado porque (por ejemplo) este código no funcionaba en la versión anterior:

void gpuCalculate()
  {
//   for(int i=0; i<CountPass; i++) {for(int j=0; j<CountInd; j++) {nets[i*CountInd+j]=NETs[i][j];}}
//   CLBufferWrite(cl_Mem_NET,nets);
   CLBufferWrite(cl_Mem_NET,NETs);
   CLExecute(cl_Krn,1,Offs,Works);
   CLBufferRead(cl_Mem_Result,Result);
//   CLBufferRead(cl_Mem_NET,nets);
   CLBufferRead(cl_Mem_NET,NETs);
//   for(int i=0; i<CountPass; i++) {for(int j=0; j<CountInd; j++) {NETs[i][j]=nets[i*CountInd+j];}}
  }

Y he tenido que reescribir el array redundantemente dos veces en cada bucle de procesamiento (ver el código comentado).

En otra versión hice una matriz de objetos propia virtual (como la de Nikolai), pero es torpe de usar (especialmente al escribir la genética) - la sintaxis funcional es agotadora en algunos lugares.

Ahora el código funciona, el array bidimensional se escribe realmente en el buffer. Esto es progreso. :)

OK, Paz, Amistad, Chicle... :) Si haces la sobrecarga de operadores, yo mismo arreglaré la sintaxis.

[Renat Fatkhullin]

La sobrecarga de operadores ya está hecha, estará disponible en la próxima versión.

[Vladimir Gomonov]

Renat:
La sobrecarga de operadores ya está hecha, estará disponible en la próxima versión.

¡Vaya! Es un bonito detalle.

Muchas gracias a todo el equipo de desarrollo por ello.

Ahora será posible escribir un código realmente bonito.

[Mykola Demko]

Renat:
La sobrecarga de operadores ya se ha realizado, estará disponible en la próxima compilación.

¿Por qué las letras tan pequeñas? Es una pregunta retórica.

Mejor así:

Перегрузку операторов уже сделали, будет доступно в следующем билде.

[Anatoli Kazharski]

La sobrecarga del operador es un concepto nuevo para mí. He encontrado una descripción detallada aquí: http://programmersclub.ru/24/

¿Esto es todo?

[Mykola Demko]

tol64:

La sobrecarga del operador es un concepto nuevo para mí. He encontrado una descripción detallada aquí: http://programmersclub.ru/24/

¿Esto es todo?

Sí, lo es.

[Vladimir Gomonov]

Urain:

¿Por qué las letras tan pequeñas? Es una pregunta retórica. Lo prefiero:

Перегрузку операторов уже сделали, будет доступно в следующем билде.

Sí, va a ser una construcción muy solemne.

:)

[Vladimir Gomonov]

Renat:

Me temo que no querías notar el solapamiento en la descripción:

typedef Int8 = int[8];
struct   Int8 { int arr[8]; };

La segunda opción es mucho más limpia, más potente y con más control. No hay ninguna resonancia en inventar otra entidad más débil en la forma existente.

La segunda versión de la descripción no es el problema. El problema es que cuando lo usas, la sintaxis no cambia para bien.

Le ofrezco un compromiso potente y absolutamente seguro: los campos "por defecto". La palabra clave "por defecto" resuelve completamente las diferencias de sintaxis. :)

En este caso.

struct   Int8 
  { 
    int arr[8]; default;
  };

(C++ lo hace, C# lo hace, Delphi lo hace, etc.)

Es decir, al acceder a un campo de este tipo, basta con escribir Int8Var[i] en lugar de Int8Var.arr[i] - el compilador lo entenderá correctamente.

// Y lo principal es no olvidar hacer esto no sólo para las clases, sino también para las estructuras. :)