|
Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.
Mensajes - JuanK
Páginas: 1 ... 54 55 [56] 57 58 ... 231
1376
« en: Jueves 9 de Noviembre de 2006, 21:31 »
.net no
el punto no es .net el punto es el CLR.
código administrado se refiere a un conjunto de características entre ellas las mas destacadas:
1- memoria administrada: todo el manejo de memoria lo hace el framework directamente, es decir no te preocupes por liberar áreas de memoria ni por pensar en punteros ni por pensar en referencias de una manera excesiva, esa lógica ya esta resuelta.
2- Los tipos de dato son 'safe type' ( comprobación de tipos ) y no se pueden crear punteros ni asignar valores en tiempo de compilación o de ejecución que alteren la logica propia de un tipo de dato, por ejemplo asignarle de buenas a primeras un tipo int a un tipo byte o asignar a un tipo int el resultado de dividir un float en un double etc...
En CLR no es camiza de fuerza usar el 'administrador de memoria' o garbage colector pero si es la opción preferida y/o predeterminada así mismo como lo es el uso de punteros y el uso o no de safe type también es opcional si bien son la opción por defecto.
Los dos anteriores son la gran ventaja porque definitivamente ayudan a deshacerce de mucho trabajo engorroso y con fácil tendencia a la generación de errores como sucede en lenguajes como C++ por ejemplo. Asi que se acelera el tiempo de desarrollo y se disminuye el porcentaje de errores o flujos no controlados.
1377
« en: Jueves 9 de Noviembre de 2006, 19:51 »
aja.... y como de donde debemos adivinar cuales han sido tus problemas
1378
« en: Jueves 9 de Noviembre de 2006, 13:41 »
Pero sino anexas el fuente es poco lo que podemos llegar a hacer por ti no crees?
1379
« en: Jueves 9 de Noviembre de 2006, 13:39 »
mm complicado, habria que revisar... tal ves gdi no es la mejor opcion para lo que quieres hacer.
1380
« en: Jueves 9 de Noviembre de 2006, 13:37 »
Depende a lo que te refieras con leerlo al reves.
Como dice eternal idol inicialmente hay que irse al final del archivo pero de que manera vas a leer los datos? que esperas iniciar a leerlo desde el final o leer los bytes desde el final o leer de a enteros desde el final?...
1381
« en: Jueves 9 de Noviembre de 2006, 13:35 »
Disculpen la Ignorancia... Pero Hay alguna manera de Regresar los Valores de un Arreglo en una Funcion. Si existe me podrian decir como es Depende a lo que tu te refieras con regresar.
1382
« en: Jueves 9 de Noviembre de 2006, 13:35 »
Y como vas a modificar la funcion ima.Load(picDC,path);
tienes el fuente?
Estas seguro que no hay otro método de esa clase que hace lo que tu quieres?
1383
« en: Jueves 9 de Noviembre de 2006, 13:29 »
La verdad no has logrado hacerte entender con lo que quieres.
1384
« en: Jueves 9 de Noviembre de 2006, 13:28 »
Yo creo que tiene ganas de hacer malware pero es muy novato para eso.
1385
« en: Jueves 9 de Noviembre de 2006, 01:11 »
<!--sql--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>SQL </td></tr><tr><td id='CODE'><!--sql1-->[color=blue;font-weight]select[/color] p persona,count(1) from persona p,persona_mujeres pm,mujeres m where p.dni= pm.dni and pm.mujer = m.mujer GROUP BY m.mujer <!--sql2--></td></tr></table><div class='postcolor'><!--sql3-->
Usa 1 en vez de * para este caso.
1386
« en: Martes 7 de Noviembre de 2006, 16:04 »
Avance:
*Todo terminado... en lo relacionado con la codificación y decodificación de formato de Imagen JKI soportando 4 tipos de color:
8 bit 16 bit 24 bit 32 bit
*Soportado 4 tipos de compresión de datos, 3 de los cuales son propios y uno adicional que es una adaptación del algoritmo de Huffman para usar la con los tipos de color que he definido.
*Terminado soporte de conversión de archivos imagen JKI a BMPS generando un BMP por cada cuadro de animación, y soporte para crear un cuadro de animación importando bmps de 16,24,32 bit sin compresión.
*Todo lo demas que pide el reto en cuanto a especificación del formato esta terminado.
En desarrollo me encuentro haciendo un control de Windows Forms que permite reproducir el formato creado, por el momento soporta:
* Imagenes JKI de cualquier profundidad de color * Animaciones cíclicas o de un solo ciclo
Pendientes ** Animaciones con numero de repeticiones predeterminado ** Usar el color de enmascaramiento para no dibujar esos colores en cada cuadro ** Usar la bandera de overlapped implementando que un dibujo se dibuje sobre el otro menos en los píxeles de mascara, cuando esta desactivado un dibujo reemplaza totalmente el anterior cuadro animado ( eso ya funciona)
+ pendientes
editor del formato mejorar documentacion de codigo y entregable
1387
« en: Martes 7 de Noviembre de 2006, 14:36 »
mmmmmm vaya deberia sorprenderme, pero no, sera que estamos en un mundo muy egoista, asi como yo hay muchos... Estamos en un mundo injusto e injusto seguira siendo... Mas que eso pienso que estamos en un mundo capitalista... el sosialismo funciona , pero solo en teoria porque para que funcione tendria que funcionar todo el planeta = sino siempre alguien trataria de sacar ventaja...
1388
« en: Martes 7 de Noviembre de 2006, 14:32 »
27 , bueno los cumplo en unos dias...
1389
« en: Lunes 6 de Noviembre de 2006, 16:10 »
Bastante frecuente, en todo tipo de situaciones.
1390
« en: Domingo 5 de Noviembre de 2006, 19:01 »
JuanK trabaja con C# como si fuera MS-DOS No se puede del todo porque no existen en el momento implementaciones del CLR que generen código de 16 bit y que corran en modo real. reserva memoria estática, te lo recomiendo ya que yo me dedico a optimizar programas que no usa nadie jamas ni sirven para nada. Y sino sirven para nada... para que los haces?
1391
« en: Domingo 5 de Noviembre de 2006, 18:58 »
Quizas una de las formas mas comunes de perder el tiempo es alojando y desalojando memoria, muchas veces (por no decir todas) es posible estimar cuanto de memoria se va a usar y podes definir la memoria en forma estatica, esto es un horror para muchos puristas del lenguaje, pero generalmente estos puristas jamas en su vida tuvieron que optimizar un codigo.
Es notable como las practicas de "buena" programacion como no usar variables globales y definir clases para cualquier cosa se vuelven contraproducentes cuando tratas de optimizar el codigo.
Yo te recomendaria tratar de programarlo en C pelado (es un dialecto exclusivo , utilizar PROFUSAMENTE puntl detectar lo que realmente esta pasando peros y evitar todo movimiento de memoria, a veces puede ser dificior muchas caracteristicas del lenguaje (late binding, sobrecarga de operadores, garbage colector y esas cosas). OK, llegue a pensar en hacerlo en C++/C pero definitivamente no porque esto es para el reto y ya lo llevo casi en 80% y terminado en C#. En C# también puedo valerme de diabluras  para reservar algo de la memoria estáticamente pero no logre adecuar esas diabulras para hacer un uso mas optimo... si la mayoría de problemas los he tenido en la reserva de memoria y en este ultimo caso con lo de la sobrecarga de operadores que desde luego al codificar esta parte del codigo paso desapercibidamente y no fue sino hasta cuando hice un debug paso a paso al 100% de profundidad dentro del código que logre detectarlo y abolir su uso en este segmento. Como te daras cuanta me fui por la opción de comparación de punteros la cual es completamente mas rápida. Tengo un proyecto muy importante para iniciar... de hecho en eso ando también por estos días y el performance puede llegar a ser un asunto demasiado importante , de hecho demasiado delicado, por lo cual estoy pensando seriamente en hacerlo en C++ y si el asunto se me complica tanto como peude ser posible yo no descartaria tener que usar algunas técnicas extremas.
1392
« en: Domingo 5 de Noviembre de 2006, 17:13 »
Ok, ya lo solucione... La clase color tiene una sobrecarga en los operadores == y != porque en otras partes del código necesito comparar entre colores... Asi que cambie la pregunta que usaba para saber si estaba en una hoja y en vez de preguntar esto: pregunto esto: if (nodo.derecha == null && nodo.izquierda == null)
Hice algunos cambios relacionados con eso mismo y ahora el proceso tarda 3 segundos En todo caso sigo recibiendo sugerencias para hacerlo aun mas rápido.
1393
« en: Domingo 5 de Noviembre de 2006, 16:46 »
Saludos,
quisiera recibir opiniones y sugerencias para optimizar el rendimiento de esta funcion porque me esta costando mucho trabajo y no se que mas hacerle.
La funcion ObtenerTablaHuffman recibe como parámetro el primer nodo de un árbol binario donde los únicos nodos que me interesan son las hojas, esta función invoca a la función ProcesarNodo la cual se encarga de recorrer el árbol de manera recursiva e ir elaborando un mapa para llegar a cada una de las hojas, cuando tiene completo el mapa para llegar a una de las hojas guarda esa información en el objeto tablaHuffman.
El problema desde luego esta en la funcion recursiva, he hecho pruebas usando arrays en vez de listas pero los resultados, si bien han existido, son casi despreciables, y estoy necesitando optimizar esta rutina de alguna manera.
Recibo sugerencias y/o correcciones.
Gracias.
<!--xc1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>XCODE </td></tr><tr><td id='XCODE'><!--exc1--> /// <summary> /// Obtiene una tabla con el color y el mapa a seguir en el arbol binario /// para hallar dicho color /// </summary> /// <param name="nodoPadre">Nodo padre del arbol huffman</param> /// <returns>Un array que representa la tabla creada</returns> public NumeroColorHuff[] ObtenerTablaHuffman(NodoHuffman nodoPadre) { List<NumeroColorHuff> tablaHuffman = new List<NumeroColorHuff>(nodoPadre.frecuencia); NodoHuffman nodoAux = nodoPadre; CodificadorJKI<T>.CompNumColorHuff_NumColorHuff_Color comparador = new CodificadorJKI<T>.CompNumColorHuff_NumColorHuff_Color(); List<byte> listaBytes = new List<byte>(32);
ProcesarNodo(nodoAux, tablaHuffman, listaBytes);
NumeroColorHuff[] tabla = tablaHuffman.ToArray(); Array.Sort(tabla, comparador); return tabla; }
/// <summary> /// Procesa un nodo y sus hijos, determina si agrega u nuevo nodo a la tabla y lleva un registo de la /// ruta seguida hasta llegar a un nodo que debe ser ingresado en la tabla /// </summary> /// <param name="nodo">Nodo padre del arbol huffman</param> /// <param name="tablaHuffman">Tabla donde se dejaran los nodos validos hallados</param> /// <param name="listaBytes">Lista de bytes que sirve de mapa para determinar la ruta hasta llegar a los diferentes nodos hoja.</param> private void ProcesarNodo(NodoHuffman nodo, List<NumeroColorHuff> tablaHuffman, List<byte> listaBytes) { if (nodo.color != null) tablaHuffman.Add(new NumeroColorHuff( (T)nodo.color, listaBytes) ); else { if (nodo.derecha != null) { listaBytes.Add(1); ProcesarNodo(nodo.derecha, tablaHuffman, listaBytes); }
if (nodo.izquierda != null) { listaBytes.Add(0); ProcesarNodo(nodo.izquierda, tablaHuffman, listaBytes); } }
if (listaBytes.Count > 0) listaBytes.RemoveAt(listaBytes.Count - 1); } }<!--xc2--></td></tr></table><div class='postcolor'><!--exc2-->
Actualmente esta tardando mas 20 segundos en recorrer un árbol que tiene 22.196 hojas aunque el total de nodos es considerablemente mayor y no lo tengo estimado. b:(
1394
« en: Viernes 3 de Noviembre de 2006, 22:26 »
el moderador de la taberna deberia arreglar el thread para arreglar el chiste
1395
« en: Viernes 3 de Noviembre de 2006, 21:33 »
1396
« en: Viernes 3 de Noviembre de 2006, 16:48 »
Hay algo raro en el servidor.. los correos de notificación me astan llegando ahora con fechas muy raras...
1397
« en: Viernes 3 de Noviembre de 2006, 15:49 »
Según tengo entendido es un ejecutable normal hasta cierto punto y luego este lo que hace es enviar el codigo IL que posee al JIT.
En efecto el CLR de mono también los puede ejecutar pues me imagino que hay algún marcador o bandera que indica que el archivo contiene código intermedio y desde donde comienza ese código.
en todo caso , para poder ejecutar un programa creado con .net o con cualquier CLR se debe tener un runtime de alguno de los CLR disponibles ( mono, .net , boo o el que sea.)
1398
« en: Viernes 3 de Noviembre de 2006, 15:46 »
hay muchas formas.
unas es dibujar el bmp en un picturebox, luego en el evento on mouse move de la forma reposicionar el picturebox de acuerdo a las coordenadas del ratón.
Creo que esa seria la mas viable para ti, todo depende de lo que quieras hacer.
1399
« en: Viernes 3 de Noviembre de 2006, 15:40 »
tal ves se deba ala zona horaria de cada usuario.
1400
« en: Jueves 2 de Noviembre de 2006, 04:37 »
Si, = pero con el precedente que sera mucho mas fácil la integración con windows y si te genera un ejecutable.
Páginas: 1 ... 54 55 [56] 57 58 ... 231
|
|
|