Archivo de la etiqueta: SAS

Sigo migrando de SAS a WPS

Sigo con una hipotética migración de SAS a WPS. Fundamental, ¿qué sucede cuando leo tablas SAS? ¿Puedo leerlas, al fin y al cabo son propietarias? Ningún problema, podemos leer perfectamente tablas SAS. Si trabajamos en una librería con tablas SAS los ficheros generados serán .sas7bdat sin embargo si trabajamos en una librería sin tablas SAS los archivos generados serán .wpd; esto nos facilita trabajar conjuntamente con  WPS y SAS, esto nos facilita una hipotética migración de aplicaciones. Curiosamente una tabla .wpd es ligeramente más pequeña. Por supuesto compress=yes no es problema y WPS nos permite comprimir tablas.

Uno de los procedimientos más habituales con SAS es el PROC SORT. En SAS las ordenaciones requieren en espacio 2,5veces el tamaño del  fichero a ordenar si no utilizamos la opción tagsort. Esta opción nos permite optimizar el espacio ocupado, no facilita que la ordenación sea más rápida, como piensa mi amiga Sonia, lo que nos permite es que necesitemos aproximadamente 1,5 veces el tamaño de la tabla a ordenar. Fichero aleatorio de 79 MB, PROC SORT y analizamos el crecimiento de los ficheros temporales de la librería work. WPS ha generado 2 temporales de 42 MB y uno de 45 MB. Parece que las ordenaciones ocupan menos espacio. Punto a favor de WPS. En cuanto a la velocidad, imposible comparar porque SAS es muy caro y no estoy dispuesto a pagar su licencia.

Otra cosa que se me ha ocurrido es realizar n pequeño análisis univariante con graficos y demás. Quiero generar un html vía ods y no tengo prolemas. Si obtengo un error cuando no genero en mi pc la salida, si esta salida la dejo como parte de mi proyecto tengo un problema con java. Parece que el error no es importante, pero de momento no he podido solucionarlo. El reporting puede ser un punto flojo de WPS pero sed sinceros ¿quién emplea SAS como herramienta de reporting? ¿Y la realización de gráficos con SAS?

Acercamiento a WPS. Migrando desde SAS

Poco a poco comienzo a trabajar con el clónico de SAS WPS. Estoy trabajando con la versión 2.3.5. De momento las impresiones no pueden ser mejores. El interfaz me recuerda a Enterprise Guide, trabajamos con proyectos que pueden estar compuestos de scripts (códigos de SAS) o ficheros. En cuanto al interfaz tenemos un navegador de proyectos para explorar los elementos que añadimos. Acompaña a este explorador una ventana de propiedades del proyecto. En la parte central podemos ver los scripts o los ficheros que añadimos. Me ha gustado el poder linkar los ficheros añadidos  al proyecto a la aplicación del sistema asociada al fichero, me explico, si añades una hoja de cálculo ésta se abre en el proyecto de WPS con el programa asociado a ella. Otra de las ventanas está organizada en pestañas, una de ellas dispone del log y los resultados, otra un "server explorer" similar al explorador de SAS Base y una pestaña de progreso. Por último disponemos de otro navegador de procedimientos, resultados o log de ejecuciones al que particularmente no le encuentro mucho interés.

Al lío, en mi trabajo diario me pondría a picar código SAS y echo en falta algunas funciones  (perfectamente prescindibles). El PROC SQL funciona a la perfección. Ya sabéis que sin el PROC SQL no somos nadie con SAS (sobre todo yo). Al final programas como lo haces habitualmente en Enterprise Guide, me costaría muy poco migrar mis proyectos de Guide o mi codigos de SAS a WPS. Al no disponer de SAS no puedo comparar en tiempos las ejecuciones. Lo primero que se me ocurre es generar una "tablita" con 20 millones de registros en una libreria de mi PC. Las tablas se guardan con extension WPD no sé si son "tablas propietarias" o se pueden utilizar con otras herramientas, si me entero ya os diré. De momento no tenemos problemas con tablas de 800 MB. En una hora curioseando lo que más me gusta es el interfaz y la posibilidad de abrir archivos hojas de calculo desde el proyecto de WPS. De este modo me cuesta bien poco mantener una tabla de dimensiones. A la hora de importar ficheros de otro tipo veo que la gente de World Programing Software no me dejan evaluar el equivalente al modulo ACCESS TO PC FILES de SAS. No es mayor problema porque desde el mismo proyecto preparo el fichero para realizar la importación pero echo de menos un asistente. Con SAS desarrollé una metodología para importar ficheros de texto que me ha dado muy buenos resultados. Para la importación de archivos recomendaría tener UltraEdit y generar los input manualmente.

A simple vista me costaría muy poco migrar mis procesos de SAS a WPS y ahorraría a mi organización bastante dinero. Los códigos que se denominan scripts se almacenan con extension .sas y %include funciona a la perfección (menos problemas para una hipotética migración) También hay que destacar que no hemos probado el acceso a datos en Oracle ni las posibilidades estadisticas de este clónico. Pero en este primer acercamiento me ha dejado buen sabor de boca aunque de momento solo me estoy familiarizando con la herramienta. No esperaba que WPS fuera maravilloso pero me está costando muy poco sacarle partido.

Pocos euros de gasto en formación. Pocos euros de gasto en la herramienta. Pocos recursos en la migración (creo). En el primer año saldría rentable el cambio de herramienta. A no ser de tuvieramos un entorno SAS con gestor de campañas (si funciona) o una dependencia del Enterprise Guide o Miner; también es posible que no nos fiáramos del futuro de WPS pero siempre podríamos volver a SAS. Me parece que se puede acabar un monopolio. Seguiré informando.

Noticia interesante sobre WPS

Tocada de narices a SAS por parte de WPS:

A BLIGHTY BASED software outfit that is being sued by a big US company in a bid to shut it down has just scored a win with IBM.World Programming's WPS software has been approved as ready for IBM's Linux on its system z mainframes.

World Programming (WP) is being sued because its software supports the American software giant SAS Institute's Statistical Analysis System (SAS) programming language. The nod from IBM means that users' programs written using the SAS language can be run under Linux on IBM system z mainframes.

This is a poke in the eye for SAS Institute because it means that IBM mainframe users don't have to use its software to run their applications under IBM's z/OS.

Instead the IBM mainframe community can use Linux to run their SAS workloads.

The WPS software undercuts the SAS Institute on price which is one of the main reasons that the US giant has been trying to shut it down.

A WPS spokesman told us that the the software uses the Integrated Facility for Linux (IFL) hardware for IBM z9 and z10 mainframe systems. IFL provides the advantage of increased Linux performance while reducing operating and software licensing costs.

IBM's thumbs up indicates that as far as Big Blue is concerned the little British company's WPS software does the same things as SAS Institute's far more expensive packages of z/OS based mainframe software, which is the message that the small outfit wants to get out. µ

Uso de CASE en PROC SQL

Vamos a estudiar como funciona CASE en un PROC SQL. Son palabras que aparecen en las búsquedas de Google y también he observado que el número de visitas al blog ha descendido en los últimos días y no sólo es debido a las vacaciones navideñas. El 60% de los clicks a AyD vienen por temas de SAS y en los últimos días tengo muy olvidados los mensajes de esta categoría. Además en el plazo de 2 días voy a dejar de trabajar con esta herramienta por lo que, es posible, que se reduzcan aun más. En fin, a lo que voy, CASE en el PROC SQL. Case nos permite crear campos condicionales dentro del bloque SELECT de una query de PROC SQL:


*DATASET ALEATORIO;
data aleatorio;
do i=1 to 200;
grupo1=1;
if mod(i,2)=0 then grupo1=2;
if mod(i,3)=0 then grupo1=3;
grupo2=rand("binomial",0.05,5);
normal=rand("normal");
uniforme=rand("uniform")*1000;
if grupo1=1 then uniforme=.;
poisson=ranpoi(34,25);
output;
end;
run;

Partimos de un dataset aleatorio de 200 observaciones con 2 variables de grupo y 3 variables aleatorias. Sigue leyendo Uso de CASE en PROC SQL

Migrando de SAS a R

Estoy ayudando a unos colegas a migrar de SAS a R. Están lejos, en un país de vino y carne al que alguna vez he de ir. Hemos quedado en que si alguna vez borran el último de sus SAS del disco duro, los ayudo gratis. Si no, cuando vaya, me tendrán que pagar hasta el último peso en lifaras y libaciones.

Tienen procesos que ejecutaban en SAS. Algunos los iban reescribiendo en R. Se sienten más cómodos en SAS pero cuando éste se queda corto, recurren a R. Es una aproximación "todo o nada".

Existe una estrategia más eficiente y más, término de moda, vírica. Porque es posible correr R y SAS conjuntamente en un mismo proceso. El objetivo es muy evidente: ir sustituyendo progresivamente código SAS por código de R hasta que no quede nada del primero.

Hay manuales de migración de Windows a Linux y multitud de descripciones de casos de éxito.  A ver cuándo podemos crear una guía similar (junto con multitud de casos de éxito) de migraciones a entornos de trabajo analíticos libres y verdaderamente productivas.

Funciones de ventana, SAS y bases de datos

Hace unos meses padecí (eso sí, brevemente) un proyecto que consistía en la migración de cierto código en SAS (¡nos lo pasaron como un documento de 20 hojas de Word!) a otro lenguaje de programación.

Esencialmente, desde la nueva plataforma habrían de lanzarse consultas a cierta base de datos (cuando el código SAS permitiese resolver los cálculos como una consulta de SQL) y procesarse los resultados procedimentalmente desde el nuevo lenguaje de programación cuando SQL ,declarativo, no fuese suficiente. Surgió el problema de que el lenguaje procedimental era incapaz de procesar bloques tan grandes de información. Pero ésa es otra historia.

En esencia, lo que SQL era incapaz (¿lo era realmente? sigamos leyendo...) de procesar eran pasos data muy simples pero que contenían llamadas a la función lag. Esta función, en esencia, ordena a SAS en un paso data recordar el valor de cierta variable en la línea anterior para compararlo con el de la presente. Se usa principalmente para calcular incrementos cuando los datos están ordenados temporalmente.

Las nuevas especificaciones de SQL (la 2003 y la 2008) introdujeron y detallaron el uso de funciones de ventana. Las funciones de ventana son extensiones de las clásicas consultas con "group by". Éstas últimas sólo permiten devolver una fila por cada nivel de agrupamiento. Las funciones de ventana permiten operar sobre el bloque completo que define un nivel y:

  • Devolver tantas filas como contiene el bloque
  • Devolver valores basados en la totalidad de las filas del bloque
  • Si los bloques, además, se ordenan, tener acceso al primer valor (o último, o enésimo) de cada bloque; o a la fila anterior (mediante lag).

Puede leerse más al respecto aquí y aquí.

Estoy seguro de que el uso de este tipo de extensiones ahorrará a muchos desarrolladores kilómetros de líneas de código y eones de tiempo de depuración.

Trucos SAS. Identificar registros duplicados

Muy rápido, para identificar registros duplicados existen múltiples formas. Seguramente haré un monográfico sobre este tema pero de momento dejo una píldora:


data aleatorio;
do i=1 to 100000;
id=ranpoi(23456,56781);
if ranuni(5)>=0.3 then output;
end;
run;
proc sql;
create table repes (where=(rep>1)) as select
id, count(id) as rep
from aleatorio
group by 1;
quit;
proc sql;
create table repes (where=(rep=1)) as select
id, count(id) as rep
from aleatorio
group by 1;
quit;

Contamos registros y empleamos where como opción de escritura. Muy fácil y perfectamente entendible. No puedo entretenerme más que mi hija me reclama...

Lista de los lengajes de programación mas populares

Hacía mucho tiempo que no me daba una vuelta por TIOBE para conocer los lenguajes de programación más populares. Este estudio se realiza mensualmente y la verdad es que he encontrado pocos cambios con respecto a 2008. De los lenguajes que se tratan en este blog tenemos en el puesto 15 a SAS y en el puesto 30 a R. Vemos pocas cosas de Visual Basic y hemos rozado el PL/SQL. Debería de empezar a trabajar con MATLAB y Python.

Siempre tengo que plantear nuevos retos y probablemente comencemos a trabajar desde 0 con Python (no tengo ni idea de como funciona) el PL/SQL ya no lo utilizo profesionalmente así que lo tengo muy oxidado, sería muy interesante dedicarle algún espacio en el blog. De todos modos el lenguaje que es imprescindible es el MATLAB, pero me encuentro en la misma situación que con Python, no lo utilizo profesionalmente y tendría que empezar de 0. Esta misma situación es la que tuve con R, empecé desde 0 y ahora poco a poco lo voy introduciendo en algunas de las compañías más grandes que hay en España.

Truco SAS. Identificar el proceso en Unix con SYSJOBID

Un truco SAS muy rápido y que a algún compañero le ha venido muy bien y por eso lo pongo. La macro variable &sysjobid nos idenfica el job de Unix que está corriendo en ese momento. Es una macro del sistema y se haya en el diccionario de macros de SAS.  Tenemos una vista en SASHELP VMACRO de cuales son estas macros AUTOMATIC. Curiosead SASHELP, tiene algunas vistas muy interesantes, creo que ya he comentado algo sonbre ellas.

Vuelvo con &sysjobid. sólo con poner PUT &SYSJODID. podremos ver en el log el ID del proceso Unix que se está ejecutando. De este modo podremos identificarlo para hacerle un kill -9 en la máquina Unix para parar un proceso colgado. También nos permite identificar que proceso no vamos a matar. Este truco que parece una tontería nos ha librado a muchos de muchos disgustos.