Portada
mis comunidades
otras secciones
#17:
#7 no fue culpa del proveedor, fue culpa del equipo de diseño del proveedor
No fue culpa del equipo de diseño del proveedor, fue culpa del informático que metió los datos al sistema
No fue culpa del informático, fue culpa del becario que escribió mal esos datos, que seguramente no cobraba por ello y trabajaba en mcdonalds por las tardes
En resumen, no fue culpa de la NASA, fue culpa del becario de un proveedor, que no se tomaba su trabajo en serio
No fue culpa del equipo de diseño del proveedor, fue culpa del informático que metió los datos al sistema
No fue culpa del informático, fue culpa del becario que escribió mal esos datos, que seguramente no cobraba por ello y trabajaba en mcdonalds por las tardes
En resumen, no fue culpa de la NASA, fue culpa del becario de un proveedor, que no se tomaba su trabajo en serio
#2:
A veces no todo es fallo de números. Cuando estudiaba la carrera de ingeniería informática, los professores siempre nos exponían este ejemplo:
La "Mars Climate" se estrelló en Marte porque la NASA no tradujo kilómetros a millas.
https://elpais.com/diario/1999/10/02/sociedad/938815207_850215.html
La "Mars Climate" se estrelló en Marte porque la NASA no tradujo kilómetros a millas.
https://elpais.com/diario/1999/10/02/sociedad/938815207_850215.html
Comentarios
A veces no todo es fallo de números. Cuando estudiaba la carrera de ingeniería informática, los professores siempre nos exponían este ejemplo:
La "Mars Climate" se estrelló en Marte porque la NASA no tradujo kilómetros a millas.
https://elpais.com/diario/1999/10/02/sociedad/938815207_850215.html
#2 No fue culpa de la Nasa, sino de un proveedor.
Por cierto, creo que este libro lo mencioné hace algún tiempo.
#7 no fue culpa del proveedor, fue culpa del equipo de diseño del proveedor
No fue culpa del equipo de diseño del proveedor, fue culpa del informático que metió los datos al sistema
No fue culpa del informático, fue culpa del becario que escribió mal esos datos, que seguramente no cobraba por ello y trabajaba en mcdonalds por las tardes
En resumen, no fue culpa de la NASA, fue culpa del becario de un proveedor, que no se tomaba su trabajo en serio
#17 Fue culpa del gobierno estadounidense por no querer implantar el sistema decimal y emperrarse en usar un sistema arcaico por puro patriotismo.
#22 Justamente fue la NASA (Gobierno) la que impone trabajar en el Sistema internacional, y las empresas privadas la que quieren seguir en el imperial.
#25 Y las empresas privadas estadounidenses usan la imperial porque el gobierno estadounidense no quiere implantar el decimal.
#17 La NASA había puesto en sus especificaciones contractuales que las mediciones iban en S.I., siempre van así.
El proveedor no cumplió con ello.
Punto. Tu comentario es demagógicamente karmawhórico pero nada más.
#31 Quien sería el responsable del testeo del conjunto? Sería la NASA,no?
En Airbus, por poner un ejemplo, le puedes pedir al supplier o el proveedor una parte, pero al final tienes que testear la integración del mismo con tu avión. Intuyo que la NASA sería igual y serían los responsables últimos de que lo que tenían funcionaba bien (testado en modo simulación)
cc #17
#32 Si tú firmas con tu proveedor X, asumes que te dan X. Desconozco hasta qué punto se puede probar todo eso y hasta qué punto se puede uno encontrar con ese tipo de errores en fase de chequeo.
Pero eso no cambia que el que no ha cumplido es el proveedor. El fallo es del proveedor. El responsable ante los contribuyentes podrá ser la NASA, no lo sé porque ese no es el tema, pero el culpable es el proveedor.
#32 No se que paso con Airbus con el 380, pero el cableado de las alas hecho en Alemania se quedo corto por poco y tuvieron que rehacerlo entero. Usaban sofware diferente, pero no tienen sistema de medidas diferente. No se cual fue el fallo.
#33 Cuantos antes encuentres un fallo, menos caro saldrá. Puede que en algunos casos no merezca la pena hacer un teste de calidad. Ademas, el receptor no necesita testar todo. Si encuentran X cantidad que no cumple, le devuelven el pedido al proveedor.
#2 No se si el fallo fue asi o fue un fallo de decimas al hacer la conversion. A veces tambien pasa.
Cada vez se puede simular mas y encontrar los errores antes de que se mas caro.
#17 Resultaría muy convincente si no fuese por el No fue culpa del informático.
Le pasa como a Cthulhu, no existe un humano capaz de pronunciar esas palabras.
#2 Eso sigue siendo un fallo de números, me parece.
#14 Yo creo que no, ejemplo: el programa funciona a 8 km/h, si lo dejas en km/h, no tienes que tocar nada, pero por otro lado si cambias la escala, sí tienes que corregir los números, pero porque previamente has cambiado de escala. En definitiva, 8km/h != 8 m/h.
#18 Si cambias la escala tienes que multiplicar por algo, ¿no?
Eso son números. Pero tienes razón, es una diferenciación irrelevante, mi comentario sobraba.
#19 Que va hombre, ningún comentario sobra 😊 Es cierto que cambiar la escala te obliga a cambiar los números.
#14 #18 ¿unidades de medida?
Distinto se pondría =/=
#26 O en excel
#2 Eso recuerdo un caso similar que comentaba el profesor de estadística.
Un transbordador que exploto, el Challenger.
Los de la NASA habían echo un estudio de las juntas toricas, pero solo habían tenido en cuenta los resultados de los lanzamientos exitosos, si hubiesen ampliado la muestra con los fallidos, hubieran descubierto que había una probabilidad muy alta de que explotase, como finalmente ocurrió.
https://es.wikipedia.org/wiki/Accidente_del_transbordador_espacial_Challenger
La moraleja era que había que tener en cuenta la muestra que se tomaba para el estudio y debía ser representativa y no sesgada
#30 La junta falló porque con el frío se dregadaba. Poco tuvo que ver la estadística ahí. De hecho los ingenieros avisaron a la NASA que podría fallar con esas condiciones de lanzamiento.
#2 Estudiaste la carrera en Donosti?
#34 No, la estudié en la universidad de las islas baleares.
#39 Pues entonces sí que es verdad que nos cuentan lo mismo a todos los estudiantes de informática!
"Fallos de cálculo que dan risa"
....provocaron la muerte de 114 personas.
Menudas risas, si.
#11 ¿Spanair fue un fallo de matemáticas?
#12 https://es.wikipedia.org/wiki/Spanair#Accidente_a%C3%A9reo
El titular habla de fallos de calculo y los responsables de Spanair no calcularon el leñazo que se iban a dar que fue el resultado de sumar errores. ¿Una suma es un calculo?.
Publireportaje.
#4 además pide suscripción.
La mayoría de los casos citados ya han pasado por Menéame y tal como está redactado el artículo no merece estar en portada...
#5 ¿Que no merece estar en portada? Quizás no por ser de El País, pero el redactor me ha caído bien: usa millardos.
¿Sale el submarino español o los tuneles de Pajares?, a lo mejor ganamos.
#6, ¿a cuántos dices que ha matado los errores del submarino español?
#9 Ahhhm, perdon, que no sabia que la puntuacion era por cadaveres. Pues.... ¿Spanair vale?.
#6 Lo del submarino fue un bulo que incluso se comentó por aquí https://web.archive.org/web/20180726232442/http://www.ejercitos.org/2018/07/22/malentendido-periodistico/
#16 igual que la famosa historia del ascensor de Benidorm al que supuestamente habían olvidado meterle ascensores
#23 Al ascensor lo que se olvidaron es de meterle edificios
#23 Ríete, pero mi jefe, que trabajó en las Torres Colón (Madrid) me contó que de los cuatro ascensores que debían llevar, al final tuvieron que poner uno menos porque los cableados del edificio no cabían en el espacio previsto, así que tuvieron que usar el hueco de un ascensor.
#16 ¿Un bulo?, anda ya...
#16 Tengo una duda, el hecho de que pases el enlace por web.archive.org, ¿es porque pide registro en la original?
#42 El enlace original no lo encuentro.
Os va el humor negro
Los fallos más brillantes son los que incluyen confusiones con magnitudes o conversión de unidades. Grandiosos.
A ver, tenéis que elegir un titular caray
Noticia con regusto a publireportaje para que te compres el libro...
Quiero aprovechar este meneo para recordar al hingeniero Patxi y su "variable pi".
#1 ¿De qué estás hablando?
#38 De que uno que trabajó en un proyecto mio tenía que documentar un procedimiento, y en el texto no hablaba de la constante, sino de "la variable pi". Menos mal que lo revisé, si no los clientes todavía estarían descojonandose.
Aparte de iniciativas como https://es.wikipedia.org/wiki/Proyecto_de_ley_de_Indiana_sobre_pi
#41 "... sus soluciones de la trisección del ángulo, la duplicación del cubo y la cuadratura del círculo"
Echo en falta una mención a su inestimable colaboración en la teoría del punto gordo.
Cada día me gusta más este entrenador ... aquí en nuestras teles estamos llenos de toreros, futbolistas y titiriteros dando lecciones de todo.
El autor, Matt Parker, es uno de mis favoritos del canal de youtube Numberphile .
Muy recomendable el vídeo donde habla sobre los "cuadrados mágicos"