• Llegar a las manos: Darse leches está mal visto. Meterse mano también.
• Jugárselo a piedra, papel o tijera: si es el otro es japonés estás perdido, vas a perder sí o sí, ellos nacieron con un don para ello. Si no es japonés nada te asegura que vayas a ganar, así que nada, mala opción.
• Jugárselo al tres-en-raya. Esta es la buena.

El tres en raya es un juego sencillo, cuando la gente se pone a jugar se cree que es un juego tonto (que lo es!) y que más o menos, sin considerar empates, el 50% de las partidas las ganarán y el resto las perderán pero no es tan tan sencillo. Así que le sueltas: “Pues ya está! Nos lo jugamos al tres en raya. El primero en ganar será el que tenga la razón, ¿es justo no?” Suelen aceptar.

Vamos a asumir que el juego es empezando con un tablero vacío, que empiezas donde quieras y que cuando ya has puesto las piezas posibles y no ha ganado nadie comienza una partida nueva desde cero.

También vamos a asumir que tú no estás en la parra y que sólo vas a perder si te provocan una situación en la que el contrincante te puede hacer tres en raya de dos maneras simultáneas y no es que se te ha escapado la línea ¬¬. Tú eres cruz, tu víctima será cara.

Cómo no perder

Se supone que el que empieza lleva la voz cantante. Tu contrincante puede empezar en el centro, en una esquina o en un lado. Lo decisivo son las 2 primeras posiciones.

Si él empieza en el centro, ve siempre a la esquina. En caso de que luego su ficha se ponga en línea tu ve de nuevo a una esquina.

Si empieza en una esquina nosotros cogemos el centro.  En caso de que él vuelva a colocar su ficha en línea entonces nosotros nos vamos a una posición que no sea esquina.

Si empieza en un lado cogemos el centro de nuevo. En caso de que él coga un lado contiguo debemos colocar nuestra ficha en la esquina común.

Ahora ya lo tenemos neutralizado.

Cómo intentar ganar

Intentar ganar viene a ser lo mismo pero al revés, con alguna variación más porque él no tiene por qué hacer de su primer movimiento los que yo he hecho antes.  Sólo tienes que esperar a que lleve 3 o 4 partidas y que ponga donde no toca en su segundo movimiento.

Aplicado al primer caso, si empiezas en el centro y él no pone en una esquina está muerto, en el caso de que lo haga tu colocas tu ficha haciendo línea. Ahora si él no se posiciona en una de las dos esquina restantes habrá perdido también.

Si tu contrincante se sabe esto, simplemente jugar será un while(true) hasta que uno de los dos se harte, y entonces, por supuesto, tiene razón el otro

P.S. Aprovecho este post para anunciar que TuXeD se ha comprado un dominio nuevo y pasa de /var/log/TuXeD a Limited Entropy Dot Com. ¡Ya estás actualizando tus feeds y bookmarks!

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

None Found

A día de hoy contamos con ordenadores chorrecientas veces más rápidos que hace pocos años y cuando se programa haces pruebas con sistemas de 3GHz, varios MB de cache y 2GB de RAM mínimo y todo tira para adelante. Bueno, todo tira hasta cierto punto, tus programas luego se van a estar ejecutando juntos con otras decenas de programas o simplemente se van a estar ejecutando constantemente y vas a perder un gran porcentaje de la capacidad de proceso de cómo lo podrías estar haciendo.

Bueno, y es normal, cosas de la comodidad, yo el primero. Ahora te quedas tranquilo con que funcione, en los 80 tenía que funcionar y caber en 64kB de RAM. No digo que se programe peor (seguramente sí xD) pero ya no nos fijamos en muchos detalles que antes eran totalmente necesarios (la de trucos que usaba la gente para poder aprovechar el 100% del hardware del Commodore64) y ahora desperdiciamos por todos lados y al final sí que pasa factura. La gente que programe sistemas embebidos lo tiene muy claro aunque casi se va a acabar el asunto también ahí porque ya los procesadores de los móviles/PDAs/cosas_pequeñas tirán mucho.

Me he encontrado con programas que están al 100% de CPU en idle, con programas que daban su salida en unos 12~15 minutos cuando otro para el mismo propósito lo hacía en aproximadamente 1 segundo (no daré nombres xD), programas en los que notas el ‘refresco’ de los elementos cuando lo usas cuando te sobra CPU para hacerlo bien, etc. Hay que intentar evitar marañas de bucles for anidados!

Al final todo pasa por conocer muy bien el lenguaje que usas, haber pasado horas y horas, pensar las cosas antes de hacerlas, incluso un poquito de sentido común, cosa que creo que es difícil de abstraer a veces cuando se programa.

Por ejemplo, en matlab es muy importante reservar el espacio para las variables antes y crear los vectores del tamaño que van a ser al final de las operaciones porque si aumentamos el tamaño de un vector[n], internamente lo que siempre hace es crear un nuevo vector[n+1] y copiar los datos del antiguo.

Hace unos meses me comentó un amigo que en el trabajo tenían un método númerico que disminuyó su tiempo de ejecución en más de un 20% (siendo su tiempo varias horas) al sustituir un resultado de una operación que siempre era el mismo por el valor guardado en una variable! Es de cajón pero hay que caer.

Y ahora vienen algunos ejemplos, por no meterme en un lenguaje tipo C en el que hay muchas posibilidades de hacer las cosas y hay que currarse más los ejemplo iré a algo más sencillo como es hacer scripts cerdos para administrar un máquinas o similares.

Un ejemplo sería un uso poco adecuado de las órdenes cat, grep, ls, awk y similares. Cuando manipulamos algo pequeño no pasa nada pero cuando se trata de varios ficheros logs y son decenas de MB pues la cosa empieza a tomar importancia.

Respecto a grep cuando una persona empieza y se plantea buscar una cadena lo primero que piensa es ‘muestro el archivo y luego saco las líneas coincidentes’:

# cat tinyproxy.log | grep remote
real    0m55.071s
user    0m24.477s
sys     0m0.727s

Luego descubres que en realidad lo puedes hacer ‘todo en uno’ y es bastantes más rápido:

# grep remote tinyproxy.log
real    0m36.024s
user    0m22.550s
sys     0m0.527s

Luego, sin querer, entras en el man y te das cuenta de que existen varios tipos: grep, egrep (similar pero no idéntico a grep -E ) y  fgrep (idéntico a grep -F). Así que pruebas:

# egrep remote tinyproxy.log
real    0m55.122s
user    0m25.029s
sys     0m0.659s

Joder, vuelve a ser lento a pesar de no hacer un cat. ¿Por qué? Porque es una función más compleja.

• grep: soporta expresiones regulares básicas.
• fgrep: no soporta expresiones regulares => el más rápido.
• egrep: soporta expresiones regulares avanzadas => el más lento.

Para los curiosos, el nombre grep viene de g/re/p y significa lo que hace tal cual, buscar una expresión regular y hacer print de las coincidencias. En realidad a una escala grande ni siquiera deberíamos usar grep sino sed que es más rápido.

Lo mucha gente desconoce es que hay otra manera de evitar el cat de antes y ganar tiempo, y es que en realidad las concatenaciones siempre están ahí… así que lo podríamos hacer del siguiente modo:

# <tinyproxy.log grep remote
real    0m43.931s
user    0m22.338s
sys     0m0.578s

Del mismo modo estos conceptos se puede usar en otras órdenes

# cat tinyproxy.log | wc -l
104265

real    0m0.088s
user    0m0.021s
sys     0m0.053s

# wc -l tinyproxy.log
104265 tinyproxy.log

real    0m0.021s
user    0m0.013s
sys     0m0.006s

Y del mismo modo:

# cat tinyproxy.log | tail -n 200
real    0m0.121s
user    0m0.026s
sys     0m0.056s

# tail -n 200 tinyproxy.log
real    0m0.010s
user    0m0.000s
sys     0m0.003s

Cambiando de tercio también solemos usar echo más veces de las que toca. Por ejemplo si tenemos :

var="valor_o_resultado_de_una_evaluacion"
command -options `echo $var`

en la mayoría de los casos podremos sustituirlo por:

var="valor_o_resultado_de_una_evaluacion"
command -options $var

Y así mil chorradas. Por cierto, el que sólo se conozca la opción de awk para coger columnas le recomiendo que se mire manules que termina siendo muy útil.

Creo que este post lleva más de 6 meses en drafts y no he añadido nada (de hecho tampoco tengo ganas), así que aunque es un tema que da mucho de sí ha quedado bastante descafeinado técnicamente, pero ajo y agua!

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Descodificar tonos DTMF usando Matlab
• Port-Knocking y Crypt-Port-Knocking
• Para los amantes de XKCD llega…