How to calculate z score to percentile conversion in Java

In order to calculate the conversion of z score to percentile we need to get the cumulative area under the normal distribution curve. We could manually calculate the numeric integral however  this might lead us to mistaken results. The best way to do it is by using existing modules written by some trusty source.

In the case of Java, I used NormalDistribution class which comes as part of the Apache Commons Math jar.

My code:

Sample result:

zScore: 1.6151417880272858 Percentile: 94.68600033649766

 

 

Advertisements

Assigning a vector to a matrix row in MATLAB

I spent one hour trying to figure out an error in MATLAB, I’ve learned something useful.

I had:

for c = 1:num_labels
initial_theta = zeros(n + 1, 1);
[all_theta(c)] = (fmincg(@(t)(lrCostFunction(t, X, (y == c), lambda)), ...
initial_theta, options))'
end

It was:

for c = 1:num_labels
initial_theta = zeros(n + 1, 1);
[all_theta(c,:)] = (fmincg(@(t)(lrCostFunction(t, X, (y == c), lambda)), ...
initial_theta, options))'
end

Explanation:

[all_theta(c)] is a scalar

[all_theta(c,:)] is a vector

Algunas cosas que he aprendido mientras programo

Me faltan muchos. Prometo que los voy a ir agregando a medida que los recuerde. Nótese la diferencia semántica. Así van saliendo mis recuerdos y es mejor apuntarlos antes de que regresen a sus vacaciones en algún lugar desconocido de mi memoria. Hay cosas de Perl, C, Project management, herramientas. Algunos no tienen punto final porque fuck the police.

  • strcat() de un char da segfault.
  • Es bueno salir a caminar o molestar al de al lado cuando algo sale bien, es como un premio. Supongo.
  • Nombre de las funciones de una librería debe comenzar por el nombre de la librería.
  • NAME->DESCRIPTION->PARAMETERS->RETURNS
  • EXPORT functions van con los comentarios en el .h
  • PRIVATE functions van con los comentarios en el .c
  • struct name{}; –> .c
  • typedef struct name name; –> .h
  • ¡Alinea tus variables!
  • Ver el r/dailyprogrammer es una buena costumbre, al igual que el tumblr de the coding love.
  • Ver pr0n en tumblr es bueno también.
  • :E
  • El formato, entendido como indentación (esa palabra ni existe en el español), alineación de definiciones y asignaciones, nombres de variables y espacios en los operadores aritméticos y lógicos; son como la buena ortografía que te enamora en una carta.
  • El código debe lucir hermoso, por supuesto, los comentarios no están excluidos y deben estar escritos de la misma manera. No hay que discriminarlos, ellos tienen el derecho de ser cool.
  • argv[i] + n da el puntero de argv[i] a partir del n
  • ** para paso por referencia &
  • El getopts de GNU no es portable.
  • Una buena documentación hace la diferencia.
  • Nunca son suficientes upgrades.
  • Siempre es bueno hacer ejemplos estúpidos y sarcásticos para probar tu código. El propio código se divierte. No puedes saber si tu computadora tiene vida y conciencia propia, es mejor darle el beneficio de la duda.
  • Hacer los pushes que sean necesarios.
  • Misteriosamente el dubstep/eurobeat hacen que acabes las cosas más rápido.
  • Nunca está mal andar de metiche en el código de los “pros” para darse un “quemón”.
  • PERL5LIB es tu amigo para crear paquetes.
  • Dumper y GetOpts en perl son la onda.
  • Sumarle 1 al resultado de strlen para hacer malloc huehue.
  • Las variables globales no son cool.
  • Fallo en la conexión de la base de datos: correr y gritar, y después ver los tns.
  • Si trabajas en una compañía loca por el varo, lo más seguro es que no puedas usar cosas open source.
  • Se puede hacer un contexto global, lo cual es pseudo cool.
  • Nunca está por demás escribir un pequeño wiki para documentar las cosas.
  • VirtualBox apesta.
  • expect puede ser muy -mamón- potente.
  • Hay expect para perl.
  • Siempre es bueno definir tus constantes y macros con define para reutilizar código.
  • Es mejor leer de argumentos de la línea de comandos que leer de un archivo o de una variable de ambiente.
  • Pero si es necesario, primero la variable de ambiente y después el archivo.
  • Para sacarle sus elementos a un struct por referencia: funcionhuehue(struct_type **miu){(*miu)->elem;}
  • Las regexp son más bondadosas que Jesucristo o Budha.
  • Operaciones bitwise para masking son siempre bienvenidas, las queremos mucho.
  • Nos gusta el backend development, no nos gusta el frontend development.
  • El text mining te puede ayudar en situaciones que jamás imaginaste.
  • Siempre es bueno saber python.
  • Resolver todos los problemas lógicos que puedas.
  • Los vatos que se creen super dioses en las entrevistas son puro brabra, ponles un ejercicio de strings en C.
  • VirtualBox no instala sobre un kernel XEN, huehue. Pero un XEN si instala sobre una VM de VirtualBox, aunque suene raro.
  • Nunca es bueno usar mucho VNC, no nos gusta el VNC, se ve feo y es lento. Preferimos NXMACHINE.
  • NXMACHINE.
  • Está cool NXMACHINE.
  • Las músicas de desarrollo son esenciales.
  • Nunca es bueno programar con el estómago vacío.
  • La verdad del universo la descubrirás a través de un pizarroncito tamaño carta.
  • Sin un pizarroncito no eres nadie. Y si por pura casualidad tienes unos plumones, ya la hiciste, el mundo es tuyo.
  • Seguir programando todo el tiempo. TODO EL TIEMPO.
  • También en vacaciones.
  • Si no hay nada que programar (siempre hay algo) existen cosas como codecademy o talentbuddy.
  • Cuando entrevistes usa cosas que te permitan ver lo que el dude está escribiendo. Es divertido.
  • El framework más hermoso del mundo siempre tiene algo para mejorar.
  • Es obligado que van a surgir bugs de tu código, trátalos bien, también son tus hijos.
  • Si tienes acceso a cosas de libros, úsalas, ahí está gran parte del conocimiento. Los libros son amigos y comida.
  • Agrégale un mes  de estimación a las cosas que no tengas ni idea de cómo hacerlas. En la mayoría de las ocasiones el tiempo es menor porque estás pro.
  • Hay que darle el avión a los managers de vez en cuando. Ellos también se estresan y así.
  • De alguna manera hay una consistencia lógica entre aprender un lenguaje de programación y uno hablado, aprender un idioma con una estructura completamente distinta a la que tiene tu idioma nativo va a propiciar que te cueste mucho menos esfuerzo el aprender un lenguaje de programación de otro paradigma.

De ahí en fuera sólo programar bien y ya. Espero que se me ocurran más cosas.

Running N finds in parallel. Bash

One of the most beautiful things about bash is that you can actually create any number of subshells and make them run in parallel. I needed to perform a very large find (believe me, it is huge, it’s huge goey) that would take “billions and billions” of years to finish. Thanks to subshells it finished way quicker.

The code inside ( ) will be executed in a subshell, if you put a & after that, it will run in the background. A ‘wait’ should be placed before the end to wait for the background processes to finish.

Code goes as follows:

#!/bin/bash

for i in `ls | grep folder_regex`
do
    # One process per folder
    (
        [ -d "$i/subfolder" ] || continue
        echo "Searching in $i/subfolder"
        find ./$i/subfolder/ -iname "regex" >> ~/results/$i"_results.lst"
    ) &
done

wait