Hay 5 formas de comunicar una idea matemática, y aunque algunas de ellas se han compartido anteriormente, una no lo ha sido. Es un parche, por lo que su ausencia no es sorprendente.
Los 5 modos son: palabras (problemas de palabras), tablas de números, gráficos/diagramas, diagramas de flujo/programas y estructuras algebraicas/simbólicas. Aquí, estoy viendo el estilo programático de interactuar con el problema.
También, al ser un estudiante de secundaria, un enfoque accesible puede beneficiarte a lo largo de tu vida.
Piensa en lanzar una moneda. ¿Sales con cara o sales con cruz? Algunas personas eligen quién comienza los juegos deportivos lanzando una moneda.
Para una moneda sin trampa, la proporción de la tasa de ocurrencia de cada cara es muy cercana al 50% frente a todos los resultados. Si la lanzas aleatoriamente 1000 veces, esperarías alrededor de 500 caras y alrededor de 500 cruces. NO es exactamente lo mismo, y NO es exactamente 500 cada vez.
Entonces, usemos el lenguaje R y hagamos un lanzador de monedas numérico que lance monedas realmente justas para ver cuántas salen de un lado en 1000 pruebas. Supondré que has trabajado en "empezar con R".
Aquí tienes un código aproximado:
coin_weight <- 0.5
num_trials<- 1000
coin_faces <- c("cara","cruz") %>% as.factor()
y <- sample(x = coin_faces,
size = num_trials,
replace=TRUE,
prob = c(coin_weight, 1-coin_weight) )
summary(y)
La salida que da, para mí, en esta ocasión, es la siguiente:
> summary(y)
cara cruz
504 496
Si vuelvo a ejecutar el código, los resultados son diferentes.
Así que lo envolvamos en un bucle, y ejecutemos esto 30 mil veces, para tener una idea de cómo varía el número de "caras". Agregaremos una variable para el número de repeticiones e inicializaremos un almacenamiento para los conteos. Luego también necesitaremos una forma de visualizar los resultados, y usaré un ggplot para eso.
Aquí está el código actualizado:
coin_weight <- 0.5
num_trials <- 1000
num_repeats <- 30000
coin_faces <- c("cara","cruz") %>% as.factor()
store <- data.frame(prob=coin_weight %>% as.character(),
count_heads=(1:num_repeats))
for(i in 1:num_repeats){
y <- sample(x = coin_faces,
size = num_trials,
replace=TRUE,
prob = c(coin_weight, 1-coin_weight) )
store$count_heads[i] <- summary(y)["cara"]
}
ggplot(store, aes(count_heads)) +
geom_histogram(bins=35 ) +
xlab("número de caras encontradas") +
ylab("número de veces dibujadas")
Aquí está el gráfico: ![ingresa la descripción de la imagen aquí]()
No estamos exactamente en tu situación, pero ajustemos algunos números. ¿Qué pasa si ha habido 10 pruebas de la máquina sin fallas?
La "prevalencia" de fallas es del 0%, pero el intervalo de confianza binomial incluye números que no son cero. El "prior de Jeffreys" dice que el IC del 95% para la proporción incluye el 21.72%. Esto significa que algo con una tasa de falla de ~20% rara vez (pero no nunca) puede fingir no tener defectos con solo 10 pruebas.
Me gusta usar esta página web. https://epitools.ausvet.com.au/ciproportion
Entonces actualicemos la probabilidad para que sea del 10%, la mitad del intervalo, y actualicemos el número de lanzamientos a 10, y veamos qué fracción de tiempo el resultado es cero caras.
Aquí está el código:
coin_weight <- 0.1
num_trials <- 10
num_repeats <- 30000
coin_faces <- c("cara","cruz") %>% as.factor()
store <- data.frame(prob=coin_weight %>% as.character(),
count_heads=(1:num_repeats))
for(i in 1:num_repeats){
y <- sample(x = coin_faces,
size = num_trials,
replace=TRUE,
prob = c(coin_weight, 1-coin_weight) )
store$count_heads[i] <- summary(y)["cara"]
}
ggplot(store, aes(count_heads)) +
geom_histogram(bins=35 ) +
xlab("número de caras encontradas") +
ylab("número de veces dibujadas")
summary(store$count_heads %>% as.factor())
Estos son los resultados gráficos: ![ingresa la descripción de la imagen aquí]()
Este es el resultado del "resumen":
> summary(store$count_heads %>% as.factor())
0 1 2 3 4 5 6
10513 11528 5832 1744 333 45 5
En 30 mil repeticiones, un sistema que tenía una tasa de falla del 10% (muy mala para el uso humano) puede tener 0 fallas en 10 pruebas aproximadamente un tercio del tiempo.
Así que hay momentos en los que un sistema imperfecto puede actuar perfectamente durante un corto tiempo. La naturaleza del sistema, en general, no tiene que cambiar para que eventualmente demuestre que es imperfecto.
Y al trabajar en el proceso para llegar aquí, puedes desarrollar una intuición basada en datos sobre cómo funciona. El código puede ser modificado para otros problemas, por lo que puedes extenderlo. Además, cuando te adentres en cosas más avanzadas, este enfoque lateral es bueno para verificar los resultados de los enfoques más analíticos.