Metodologia de experimentación
Jérémy Barbay 19 Ago 201019/08/10 a las 11:43 hrs.2010-08-19 11:43:19
1.1b Metodologia de experimentación
===================================
Author: Jérémy Barbay
Date: 2010-08-19 15:42:11 XXX
1. Al inicio, Ciencias de la computacion fue solamente experimentacion.
* Turing y el codigo Enigma
- el importante estaba de solucionar la instancia del dia
(romper la llave del dia, basado en los messages de
meteo, para decryptar los messages mas importantes)
- no mucho focus en el problema, aunque Turing si escribio
la definicion de la Maquina universal.
* Experimentacion basica
- correga hasta que fonciona (o parece foncionar)
- correga hasta que entrega resultados correctos (o que parecen correctos)
- mejora hasta que fonciona en tiempo razonable (en las instancias que tenemos)
* Problemas:
- Demasiado "Ah Hoc"
- falta de rigor, de reproducibilidad
- desde el inicio, no "test bed" estandard, cada uno tiene sus tests.
- mas tarde, no estandard de maquinas
* Respuestas: Knuth et al.
- complejidad asymptotica: independancia de la maquina
- complejidad en el peor caso y promedio: independancia del "test bed"
- todavia es necesario de completar las estudias teoricas
con programacion y experimentacion: el modelo teorico es
solamente una simplificacion.
* Theoreticos desarollaron un lado "mathematico" de ciencias
de la computacion, con resultados importantes tal que
- NP-hardness
- "Polynomial Hierarchy" ([en.wikipedia.org/wiki/Polynomial_hierarchy])
* Theoria y Practica se completen, pero hay conflictos en ambos lados:
- demasiado theorias sin implementaciones (resultado del
ambiante social tambien).
- todavia hay estudios experimentales "no reproducibles"
2. Sobre la "buena" manera de experimentar
("A Theoretician's Guide to the Experimental Analysis of Algorithms", David S. Johnson, 2001)
1) Fija una hipothesis *antes* de programar.
- aunque el objetivo sea de programar un software
completo, solamente es necesario de implementar de
manera eficiente la partes relevantes. El resto se puede
implementar de manera "brutal". (E.g. "Intersection Problem")
2) "Incremental Programming"
- busca en la red "Agile Programming", "Software Engineering".
- una experimentacion es tambien un proyecto de software, y
las tecnicas de ingeniera de software se aplican tambien.
- Construe un simulador en etapas, donde a cada etapa
fonctiona el simulador entero.
3) "Modular Programming"
- Experimentacion es Investigacion, nunca se sabe por
seguro que se va a medir despues.
- Hay que programar de manera modular por salgar tiempo en
el futuro.
3. Sobre la "buena" manera de presentar sus resultados experimentales.
("Presenting Data from Experiments in Algorithmics", Peter Sanders, 2002)
1) El proceso:
* Experimentacion tiene un ciclo:
1. "Experimental Design" (inclue la eleccion de la hypothesis)
2. "Description of Measurement"
3. "Interpretation"
4. vuelve al paso 1.
* La presentacion sigue la misma estructura, pero solamente
exceptionalemente describe mas que una iteracion (la
mejor, no necesaramiente la ultima) del ciclo.
2) Eliges que quieres comunicar.
- el mismo dato se presenta diferamente en funcion de la
emfasis del reporte.
- pero, siempre la descripcion debe permitir la
*reproducibilidad* de la experimentacion.
3) Tables vs 2d vs 3d plot
* tables
- son faciles, y buenas para menos de 20 valores
- son sobre-usadas
* Grafes 3d
- mas modernos, impresionantes, pero
- en impresion no son tan informativos
- tiene un futuro con interactive media donde el usuario
puede cambiar el punto de vista, leer las valores
precisas, activar o no las surfacas.
* Grafes 2d
- en general preferables, pero de manera inteligente!
- cosas a considerar:
- log scale en x y/o y
- rango de valores en x y/o y.
- regla de "banking to 45 deg":
- "The weighted average of the slants of the line
segments in the figure should be about 45"
- se puede aproximar on un grafo en "paysage"
siguiendo el ratio de oro.
- factor out la informacion ya conocida
* Maximiza el Data-Ink ratio.
===================================
Author: Jérémy Barbay
Date: 2010-08-19 15:42:11 XXX
1. Al inicio, Ciencias de la computacion fue solamente experimentacion.
* Turing y el codigo Enigma
- el importante estaba de solucionar la instancia del dia
(romper la llave del dia, basado en los messages de
meteo, para decryptar los messages mas importantes)
- no mucho focus en el problema, aunque Turing si escribio
la definicion de la Maquina universal.
* Experimentacion basica
- correga hasta que fonciona (o parece foncionar)
- correga hasta que entrega resultados correctos (o que parecen correctos)
- mejora hasta que fonciona en tiempo razonable (en las instancias que tenemos)
* Problemas:
- Demasiado "Ah Hoc"
- falta de rigor, de reproducibilidad
- desde el inicio, no "test bed" estandard, cada uno tiene sus tests.
- mas tarde, no estandard de maquinas
* Respuestas: Knuth et al.
- complejidad asymptotica: independancia de la maquina
- complejidad en el peor caso y promedio: independancia del "test bed"
- todavia es necesario de completar las estudias teoricas
con programacion y experimentacion: el modelo teorico es
solamente una simplificacion.
* Theoreticos desarollaron un lado "mathematico" de ciencias
de la computacion, con resultados importantes tal que
- NP-hardness
- "Polynomial Hierarchy" ([en.wikipedia.org/wiki/Polynomial_hierarchy])
* Theoria y Practica se completen, pero hay conflictos en ambos lados:
- demasiado theorias sin implementaciones (resultado del
ambiante social tambien).
- todavia hay estudios experimentales "no reproducibles"
2. Sobre la "buena" manera de experimentar
("A Theoretician's Guide to the Experimental Analysis of Algorithms", David S. Johnson, 2001)
1) Fija una hipothesis *antes* de programar.
- aunque el objetivo sea de programar un software
completo, solamente es necesario de implementar de
manera eficiente la partes relevantes. El resto se puede
implementar de manera "brutal". (E.g. "Intersection Problem")
2) "Incremental Programming"
- busca en la red "Agile Programming", "Software Engineering".
- una experimentacion es tambien un proyecto de software, y
las tecnicas de ingeniera de software se aplican tambien.
- Construe un simulador en etapas, donde a cada etapa
fonctiona el simulador entero.
3) "Modular Programming"
- Experimentacion es Investigacion, nunca se sabe por
seguro que se va a medir despues.
- Hay que programar de manera modular por salgar tiempo en
el futuro.
3. Sobre la "buena" manera de presentar sus resultados experimentales.
("Presenting Data from Experiments in Algorithmics", Peter Sanders, 2002)
1) El proceso:
* Experimentacion tiene un ciclo:
1. "Experimental Design" (inclue la eleccion de la hypothesis)
2. "Description of Measurement"
3. "Interpretation"
4. vuelve al paso 1.
* La presentacion sigue la misma estructura, pero solamente
exceptionalemente describe mas que una iteracion (la
mejor, no necesaramiente la ultima) del ciclo.
2) Eliges que quieres comunicar.
- el mismo dato se presenta diferamente en funcion de la
emfasis del reporte.
- pero, siempre la descripcion debe permitir la
*reproducibilidad* de la experimentacion.
3) Tables vs 2d vs 3d plot
* tables
- son faciles, y buenas para menos de 20 valores
- son sobre-usadas
* Grafes 3d
- mas modernos, impresionantes, pero
- en impresion no son tan informativos
- tiene un futuro con interactive media donde el usuario
puede cambiar el punto de vista, leer las valores
precisas, activar o no las surfacas.
* Grafes 2d
- en general preferables, pero de manera inteligente!
- cosas a considerar:
- log scale en x y/o y
- rango de valores en x y/o y.
- regla de "banking to 45 deg":
- "The weighted average of the slants of the line
segments in the figure should be about 45"
- se puede aproximar on un grafo en "paysage"
siguiendo el ratio de oro.
- factor out la informacion ya conocida
* Maximiza el Data-Ink ratio.
| Última Modificación | 19 Ago 201019/08/10 a las 11:43 hrs.2010-08-19 11:43:19 |
|---|---|
| Vistas Únicas | 0 |
| Compartir |
