Continúo en esta la primera de las entradas que hice sobre el artículo Don’t Be Loopy: Re-Sampling and Simulation the SAS® Way.
Trata sobre lo siguiente:
Construir un cojunto de datos simples (dos vectores, x e y). Hacer una regresión de y sobre x y capturar los residuos. Crear 1000 vectores y' distintos añadiendo a $latex \hat{y}$ (la predicción de y) en el modelo anterior una reordenación de los residuos. Crear los correspondientes 1000 modelos haciendo la regresión de cada $latex \hat{y}$ sobre x.
Corre el rumor de una posible venta de SAS. Pueden ser un simple rumor pero se non è vero, è ben trovato: el máximo responsable y accionista mayoritario de SAS, Jim Goodnight, tiene ya 68 años y la empresa está sufriendo el acoso de la competencia en muchos frentes.
SAS quiso pasar de ser una compañía que especializada en herramientas de estadística a otra que proporcionase un entorno completo de herramientas del tipo de las denominadas de business intelligence.
Don’t be loopy! es el título de una presentación realizada en el SAS Global Forum de 2007. Tiene que ver con el motivo que me hizo en mi día abandonar SAS y buscar —entonces aún no lo conocía— el cobijo de R: sus limitaciones para todo lo que tiene que ver con simulaciones, remuestreos, jackknifes, _bootstraps _y similares.
El artículo muestra lo que debería ser el estado del arte para realizar este tipo de programas con SAS.
Por ser viernes, traigo a estas páginas un vídeo tan pedagógico como ameno. Es la conferencia de Dick De Veaux dentro la M2010 Data Mining Conference auspiciada por SAS.
El autor repasa los siete pecados capitales de la minería de datos, a saber
No realizar las preguntas adecuadas No entender el problema correctamente No prestar suficiente atención a la preparación de los datos Ignorar lo que no está ahí Enamorarse de los modelos Trabajar en solitario Usar datos malos Frente a ellas, propone las siguientes virtudes:
Acaba de llegarme la noticia de que la versión 9.3 de SAS (sí, el producto de esa empresa que no quiere saber nada de las III Jornadas de Usuarios de R a pesar de que las palabras de su director general en España nos hicieran creer a algunos lo contrario) que, como de costumbre, es lo mejor de lo mejor. Entre los cambios grandes y pequeños que aporta están:
No es necesario pasar de de SAS 9.
Recientemente tuvo lugar la conferencia del nosequé de SAS en algún lugar de EE.UU. Alguien decidió rodar el siguiente vídeo:
En él aparecen algunos de los participantes en las conferencias realizando comentarios simpáticos. Pero conforme iba viendo desfilar rostros, no dejaba de pensar en que existía un patrón en la muestra.
Y me pregunto, ¿cuál es la pirámide de edad de la comunidad de usuarios de SAS? ¿Y la los de R?
Los pocos usuarios de SAS que lo utilizan para hacer propiamente estadística con él cuentan con un chuletario muy útil que relaciona temas de estadística con funciones, código y documentación relativa al asunto (dentro del universo SAS, por supuesto). Por ejemplo, para el llamado Bivariate Tobit model remite al procedimiento SAS/ETS PROC QLIM.
¿Conocerá alguno de mis lectores un recurso similar para R? Más aún, ¿se animaría alguno a emprenderlo?
Quiero compartir con mis lectores dos enlaces relacionados. Puede que a alguno le interese su sustancia misma. A mí no tanto. A mí me interesan en cuanto que ilustran la emergencia de R y el papel protagónico que está asumiendo en el universo de las cosas analíticas. Tan protagónico que hasta dos viejos dinosaurios pasan voluntariamente por su aro.
Tradicionalmente, para analizar grandes bases de datos empresariales, se realizaba en primer lugar una extracción masiva de datos.
El reto lanzado por Revolution Analytics a SAS está relacionado con el lanzamiento por parte de la primera empresa de un paquete, RevoScaleR, diseñado para permitir el análisis de conjuntos de datos grandes. La lectura más detallada de uno de los pocos documentos técnicos que circulan sobre el paquete me invita a compartir con mis lectores mis impresiones más allá de las primeras y más someras que realicé hace unos días.
gplot2 es, sin duda, el paquete gráfico de moda en R. Hay quien lo ama, hay quien lo odia, pero cada vez son menos los que lo ignoran. Lo que igual no es tan sabido por los usuarios de R es el contexto en el que nació ggplot2, su relación con el motor gráfico de R y su relación con otros mecanismos de representación gráfica existentes en otros paquetes estadísticos.
Revolution Analytics ha disparado un torpedo apuntando bajo la línea de flotación de SAS. Se trata del SAS to R challenge, una muy inteligente campaña de publicidad por la que se compromete a reescribir en R gratuitamente código SAS de clientes potenciales si el primero es más eficaz que el segundo.
Más allá de lo que la campaña parece ser, se esconde lo que realmente es: la constatación de que el premio gordo en el mundo de análisis empresarial es la actual base instalada de SAS y de que Revolution va a por todas.
Al autor le preocupa de viejo el problema de la representación gráfica de datos. Piensa que tiene más de arte que de ciencia. Tal vez lo dice porque no se le da bien: confunde tonos y colores y desgarbado es el adjetivo que mejor describe sus trazos.
Y como casi todo diletante maltratado de las musas, ejerce de crítico. Y voto a Dios que su crítica es acerba. Le irritan todos los gráficos de tarta (menos éste), desea toda clase de malaventura al cretino que lleva lo de Excel en Expansión y vive prisionero de otras manías semejantes.
Previamente he hablado en este blog de las ventajas que ofrece PROC SQL en SAS sobre otros métodos más propiamente SAS de realizar ciertas manipulaciones de datos. Existen no obstante cierto tipo de manipulaciones que exigen pasos data: gran parte de las que hacen uso de la variable automática n.
No obstante, existe una función no documentada de SAS que permite implementar con SQL muchas operaciones de este tipo: monotonic.
