156 votos

R vs SAS, ¿por qué las empresas privadas prefieren SAS?

Aprendí R, pero parece que las empresas están mucho más interesadas en la experiencia de SAS. Cuáles son las ventajas de SAS sobre R?

19 votos

Es trágico, pero me temo que es cierto...

1 votos

Hace un tiempo discutí esto con algunos amigos en facebook, y encontré dos enlaces que eran particularmente agradables sobre el tema: linkedin.com/groups/SAS-versus-R-35222.S.65098787 thejuliagroup.com/blog/?p=1757

23 votos

Un estadístico médico me dijo una vez que utilizaban SAS porque si cometían errores debido a los fallos del software y llegaban a las demandas, SAS les recompensaba. R viene sin garantía.

146voto

Sean Hanley Puntos 2428

Creo que hay varias cuestiones (en orden ascendente de posible validez):

  1. Tradición / hábito : la gente está acostumbrada a SAS y no quiere tener que aprender algo nuevo. (Hacerlo más difícil, la forma en que piense en en SAS y R es diferente). Esto puede aplicarse a cualquier persona que tenga que enviarle código, o que lea/utilice su código, incluidos los directivos y los colegas.
  2. Desconfianza en el freeware : Varias personas me han dicho que no están dispuestas a aceptar los resultados de R porque no hay una empresa con ánimo de lucro que revise el código para asegurarse de que da resultados correctos antes de enviarlo a los clientes, para que no acaben perdiendo el negocio.
  3. Datos masivos : R realiza operaciones con todo lo que hay en la memoria, mientras que SAS no lo hace necesariamente. Por lo tanto, si sus datos se acercan a los límites de su memoria, habrá problemas.

Personalmente, sólo creo que el número 3 tiene algún mérito legítimo, aunque hay enfoques de big data que se han desarrollado con R. Los problemas con el número 1 hablan por sí mismos. Creo que el número 2 ignora varios hechos: hay una cierta investigación que se lleva a cabo con R, muchos de los principales paquetes están escritos por algunos de los nombres más grandes en la estadística, y ha habido estudios que comparan la precisión de diferentes software estadístico y R ha sido ciertamente competitivo.

44 votos

El punto 1 adquiere mayor legitimidad si también se incluye la "infraestructura existente" en esa inercia. Si existen procesos empresariales que ya utilizan SAS, el cambio tiene un coste de transición. Si este es el caso, no se trata de elegir entre SAS y R, sino de elegir entre quedarse con SAS y cambiar a R, lo que puede tener una conclusión diferente.

0 votos

@BrianDiggs, ese es un punto razonable, +1, aunque las empresas están pagando un brazo y una pierna para mantener sus licencias SAS al día. Creo que la base empieza en \$8k, but it can easily exceed \$ 20k por máquina al año; en algún momento, te preguntas si valdría la pena pagar a los programadores para reescribir ese código en algún programa gratuito, ya sea R o Python.

1 votos

He tenido esta conversación con gente de algunas grandes empresas financieras. Creo que el número 2 es, con mucho, el factor más importante para todas las personas con las que he hablado. La mayoría de ellas tienen políticas específicas que prohíben el uso de software de código abierto. También creo que las actitudes están cambiando lentamente en ese frente.

119voto

Loren Pechtel Puntos 2212

Además de las buenas respuestas hasta ahora, yo añadiría el factor de la vergüenza. Si el año pasado se gastaron cientos de miles de dólares en SAS y en el soporte de SAS, y se propone no gastar nada en R, con precios de soporte extremadamente bajos (Revolution, etc.), alguien de la cadena va a preguntar por qué. ¿Fue un error gastar tanto dinero el año pasado cuando R ya existía? ¿O es un error abandonar el software profesional por algo creado por un grupo de voluntarios?

Una vez que el problema se enmarca de esa manera, es una propuesta en la que todos pierden, así que tal vez sea mejor no sacar el tema.

54 votos

Esta es quizás la respuesta más cínica sobre la cruz validada. +1

12 votos

@probabilityislogic: ¡Gracias! Para que quede claro, esto es más un comentario sobre la mala gestión de alto nivel que sobre las personas que usan el software. He trabajado en lugares donde realmente existía la actitud (en los niveles superiores), "Hmmm... no has gastado todo el dinero que te hemos presupuestado este año. Evidentemente, puedes arreglártelas con menos dinero, así que vamos a recortar tu presupuesto para el año que viene y dar el extra al departamento que gastó de más." Las reglas de Dilbert.

11 votos

"No has gastado el dinero..." -- Así es exactamente como funcionaba el sistema de planificación soviético, por lo que sé de primera mano.

62voto

StasK Puntos 19497

Además de lo que gung ha identificado correctamente aquí El mayor problema en el mundo empresarial es la herencia. Y cuando se tiene un código de producción de buena calidad que se sabe que hace el trabajo, no se cambia. SAS existe desde la década de 1970, y en ese momento era el único lenguaje estadístico de secuencias de comandos eficaz, según los estándares de entonces. La cantidad de código de producción acumulado desde entonces en SAS en la industria farmacéutica y el gobierno es inimaginable, decenas de miles de años humanos. Reescribir esto en R o Stata llevaría unos cuantos años, el código resultante será más flexible, más eficiente, más transparente, más fácil y más barato de mantener, pero nadie pagará por esa refactorización. (Mi experiencia al hacer esto es que mi código de Stata es generalmente unas tres veces más corto; una vez tuve un proyecto de conversión de código de SPSS a Stata en el que lo hice unas 20 veces más corto. Para aquellos que han trabajado en el mantenimiento de sus paquetes estadísticos... bueno, ya saben lo que eso significa).

En cierto sentido, se trata de una historia similar a la de las editoriales académicas: están montando una marea de usuarios finales que mantienen sus suscripciones por necesidad; una universidad sin suscripción a Nature no es realmente una universidad. La publicación gratuita a través de las sociedades profesionales será más barata, la gente prepara sus envíos en LaTeX hoy en día, por lo que están preparados para la cámara, y la misma gente proporcionará la revisión por pares, por lo que no habrá un retroceso de calidad en ninguna de las dimensiones. Pero... no hay marca ni factor de impacto detrás de las revistas online.

Esto lo resume todo: http://scatter.wordpress.com/2011/06/28/stata-12/ . Stata es el preferido en los círculos económicos y políticos, y cuanto más aprendo de SAS, más me gusta Stata.

42 votos

SAS tiene una sintaxis horrible que comenzó con algo similar al JCL (Lenguaje de Control de Trabajos de IBM) para presentar trabajos por lotes con tarjetas perforadas en su día. Es sorprendente que la gente siga utilizándola, la verdad.

6 votos

+1 Me ha gustado especialmente la analogía BlackBerry:iOS:Android:Nokia como SAS:Stata:R:SPSS en el post de los gráficos de dispersión.

6 votos

Wayne, si alguna vez ha pensado en la declaración CARDS, se dará cuenta de que SAS es el paquete de software estadístico que trabaja con tarjetas perforadas. Stata trabaja con conjuntos de datos rectangulares. R trabaja con objetos. Así que, dependiendo del tipo de formato de datos con el que tengas que tratar, uno puede ser mejor que otros.

49voto

Kim Puntos 1853

He trabajado como programador de SAS durante los últimos siete años, a mi lado un compañero de trabajo ha estado programando SAS más tiempo del que yo he vivido. Como se ha señalado aquí, hay una cantidad masiva de inercia/legado detrás de SAS; pero SAS al igual que R es un camino a un medio, no el medio mismo.

SAS es extremadamente eficiente en el acceso secuencial a los datos, y el acceso a la base de datos a través de SQL está muy bien integrado. Los PROC están muy bien documentados, pero lamentablemente no están totalmente estandarizados con la notación (PROC OPTMODEL e IML son dos ejemplos). Es un poco torpe cuando se trata de escribir código complicado, y no tan elegante para el código paralelo. También he encontrado que la importación de archivos csv es una fuente de gran miseria a veces y prefiero simplemente volcarlo a R primero y luego a una base de datos.

Aunque SAS tiene interfaces para objetos compartidos y dll's no tienes un buen acceso a ningún archivo de cabecera ni nada por el estilo, y la distribución de código tampoco está disponible a través de paquetes felices.

Sin embargo, hay poca preocupación de que alguien incluya algún paquete esotérico ahora desaparecido o roto en su código que ahora necesita mantener, y la calidad del código en SAS tiende a ser uniformemente excelente (el código del núcleo de R también es excelente, y también está disponible libremente para cualquiera).

Como se ha mencionado antes, SAS también es extremadamente caro, pero es una buena herramienta a la que acudo cuando sé que hay un procedimiento enlatado que funciona bien para mis necesidades.

R + SAS + mysql con un poco de perl para pegarlos funciona increíblemente :)

11 votos

El comentario sobre el mantenimiento de los paquetes antiguos es igualmente válido para una macro escrita por el usuario o un proc antiguo que sas no ha actualizado.

4 votos

R también tiene un muy buen soporte de SQL obtenido recientemente a través de dplyr traduce literalmente la sintaxis de R/dplyr a SQL y llama a la base de datos, puedes decidir qué operaciones hacer en el servidor de la base de datos y cuáles localmente usando la misma sintaxis: cran.r-project.org/web/packages/dplyr/vignettes/databases.html

44voto

samiq Puntos 1128

Nadie ha sugerido que la razón por la que se prefiere es una simple idiotez. Aquí hay dos citas que encontré recientemente:

"El uso de software de código abierto, como R, estaba descartado. no podíamos garantizar un resultado perfectamente repetible".

y

"No podemos ofrecer ningún tipo de soporte para esto, ya que es un software de código abierto". de código abierto".

Dos minutos con esta gente les demostraría lo equivocados que están.

4 votos

¿Dos minutos con qué personas? Sin referencias es casi como si te hubieras inventado esas citas.

2 votos

sas.com/noticias/preleases/castle.html para el primero, y el segundo fue de un ayuntamiento tras la petición de un estudiante de tener R en su portátil subvencionado por el ayuntamiento.

4 votos

la segunda cita parece bien para un departamento de TI del ayuntamiento, no se puede esperar que apoyen todo el software de código abierto que un cliente pueda utilizar, de ahí la advertencia general. Creo que la peor frase contra el código abierto que he oído fue la de SAS, que decía algo así como "¿confiarías en un jumbo diseñado en código abierto?

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X