Re: registros aleatorios con al menos de una categoría

Francisco,

Creo que estamos en esta lista para ayudarnos mutuamente, y orientarnos de cómo resolver algunos problemas comunes que tenemos principalmente con postgresql, dependiendo de la relevancia del problema y el tiempo que tengamos podremos discutir mas/menos ampliamente del tema.

Lo que no me parece es el modo en que lo hacemos, y principalmente no comparto tu forma de regañar a las personas, y pienso que podría espantar a algunas personas de esta lista. No cuestiono la forma de ser de cada uno y sus particularidades!, la experiencia me ha enseñado a extraer lo positivo y valioso de las conversaciones por muy negras que se vean.

Ahora, dependiendo de la persona que consulte, podrá analizar en su mérito si el código enviado, si le sirve o no, al igual que las extensas explicaciones, dudas e hipótesis planteadas por tí. Ambos métodos podrían confundir a personas mas novatas, código “complejo” o texto extenso!.

No les parece raro q habiendo tanto hispano parlante llegue con suerte un par de correos semanales a esta lista?, vs otras listas de postgres que tienen decenas de interacciones diarias?. Los invito a revisar esto y a tratarnos con mejores forma, quizás aquí está la clave.

saludos

> El 15-05-2019, a las 06:01, Francisco Olarte <folarte(at)peoplecall(dot)com> escribió:
>
> Eduardo:
>
> On Tue, May 14, 2019 at 8:20 PM Eduardo Arenas <edomax(at)gmail(dot)com> wrote:
>> Ahí va el experimento con 1 millón de registros, y comprobación con una windows función de que el procedimiento entrega igual cantidad de días de la semana aprox en la muestra.
>
> Nadie duda que puedas hacer un query que genere un numero aleatorio, y
> una cantidad igual de dias de la semana, pero ...pero.....
>
>> drop table if exists random_semana;
>> create temp table random_semana as
>> with consulta as (
>> select generate_series(1,1000000) as q
>> )
>> select q,trunc(ran) as ran
>> from
>> (
>> select *
>> ,random()*7+1 as ran
>> from consulta
>> ) as a;
>
> Ese query parece hecho a posta pa confundir a alguien en una pregunta
> de examen, ¿ porque un CTE y un select anidado en lugar de dos del
> mismo tipo ?
> Eso parece generar sin mas una lista numerada de 1 millon de numeros
> aleatorios de 1 a 7...
>
>> select *,count(*) over (partition by ran) from random_semana order by 1;
>
> Y esto parece que los cuenta. No se que tiene que ver esto con el
> sacar una muestra aleatoria con unas caracteristicas dadas. Si lo que
> pretende es probar que el generador de aleatorios no es
> espectacularmente malo, parece correcto. Ahora bien, si cambias el
> limite de un millon a siete, por aquello de que sea divisible por 7,
> repites el experimento 100 veces, p.e., y en todas te salen 1 millon
> de cada clase yo me preocuparia ( por hacer experimentos estadisticos
> que tampoco solucionan el problema pero son algo mas truculentos ).
>
>> PS… Hay cosas que se puede resolver discutiendo, y otras q se puede resolver haciendo el experimento… esta es una de ellas. La documentación de un sistema es el código funcionando, que es lo que hace funcionar al sistemas, el resto es música!.
>
> Aqui no se discutia mucho, pero bueno. Dejando aparte que no se que
> intenta probar ese query, hay cosas que hay que mirar antes. Una
> solucion probabilistica puede ser suficientemente buena para lo que se
> quiere, pero hay que tener aprobacion de que lo es. Una seleccion
> aleatoria de muestras funcionando un millon de veces no te garantiza
> que funcione a la siguiente, lo sabes de sobra. Es como el tipico
> problema de "quiero mandar el user ID pero que no se vea que viene de
> un serial, voy a mandar el <insert favorite hash function>". Eso puede
> colisionar ( si no demuestras primero que tu funcion de hash no tiene
> colisiones en el dominio de los user id ), por lo que hay que usar una
> funcion de encriptacion. Puedes generar trillones de user ids y no
> tener colisiones, pero necesitas una funcion invertible para
> garantizar que no las tienes. O puedes decirle al jefe que vas a usar
> un codigo mas simple y barato, que lo has probado unas cuantos
> millones de veces, y que la probabilidad de colision es tan baja que
> no justifica el coste de hacer uno correcto.
>
> Francisco Olarte.