Hola, vengo a tirar una mano (?)

... y si utilizan la distancia de levestein?

"7 ) Distancia de Levenstein:

La distancia de levenstein es la cantidad de caracteres en los que difieren dos palabras. Ejemplo:

"pablo" "palo" -> 1 ("pablo" tiene una letra mas).

"aaab" "bbbb" -> 3 (Hay tres letras que son diferentes, y una en comun).

StringUtils.LevensteinDistance("pablo","palo") "

http://www.artfulsoftware.com/infotree/queries.php#552

Se podría llegar a usar algo así, ¿pero no importaría la distancia entre las letras? Digo, no es lo mismo la diferencia entre preparando final y aprobada que entre preparando final y pendiente.

Algo que podríamos seguramente implementar es la generación de esta información en un cron, como haríamos con BI. De esa forma reducimos riesgos de ataques por búsqueda de usuarios similares y obtenemos siempre información rápida. Es una idea, claro :-).

por que lo generarias en un cron?
el "hash"(o lo que sea que se implemente) se genera y guarda cuando alguien carga sus materias en el seguidor

(12-12-2011 21:49)nanuiit escribió:  

(12-12-2011 14:02)shadow_mx escribió:  upps

Entonces lo que se quiere es sacar los usurios que tengas mayor parecido en el estado de las materias??

Off-topic:

chorro de avatarrrrr
Decí que no lo posteaste en el concurso, así que delata que yo lo vi primero
Igual si encuentro uno más mejor, lo voy a sacar

Off-topic:

claramente no son iguales, el tuyo tiene el logo de la utn el mio no .
No lo habia visto.

Porque recorrer 9000 usuarios para comparar cada vez que querés ver quiénes están parecidos a vos puede ser pesado. Y sólo se correría en realidad para los usuarios que ese día/hora/período de tiempo hayan realizado cambios en su carga del plan de estudios.

podes tener todo precalculado y actualizarlo cada vez que alguien cambia algo en el seguidor de carrerras, calculas el hash, clave, afinidad lo que sea del usuario y buscas todos lo que tengan esa afinidad.

Esta tarde tenia una buena idea, pero me la olvide

Exacto, a eso apunto yo Shadow. El tema también es que ese precálculo no pese demasiado tampoco . Si para cada usuario guardo su relación con el resto, estamos hablando de 9000 usuarios... si la memoria no me falla sería:
\[\frac{n(n-1)}{2}\]

Y para 9000, daría 40.495.500, muchas relaciones. Seguramente lo ideal sería cada vez que se procese guardar los 50 usuarios más cercanos a cada uno, con lo cual tendríamos 9000x50 = 450.000, un 1.11% de las relaciones totales.

Mañana resuelvo el quilombo que deje pendiente hoy y me pongo a pensar esto.
Ya me cope

no es mas facil crear grupos de users deacuerdo a las materias que estan cursando y fin? hay varios foros que tienen ese tipo de herramientas

Otra opcion es ordenar por porcentaje de la carrera terminada. Obviamente no significa demasiado, pero si es mas probable que se parezcan los que tienen eso en comun que los que no.

Pero los porcentajes de completitud los basas en aprobados ? en regularizados ? cambia mucho, onda, hay gente que metio materias de tercero y hasta alguna de cuarto y no firmo analisis matematico I, ponele.
Capaz un porcentaje de completitud por año iria (como te propuse), pero son 5 años xD

Son x años dependiendo de la carrera.

(12-12-2011 17:50)Dem0 escribió:  ¿Con un árbol de materias simil árbol de skills de RPG?

this
hace un tiempo le habia dado vueltas a una idea asi.
quise hacer algo que te grafique la carrera asi, pero por falta de tiempo/conocimientos lo abandone

Apenas leí el 'requerimiento' que propuso gonnza se me vino a la mente el tp de tadp que hicimos este cuatri.

No voy a entrar en detalles de lo que pedía el tp, pero describo la idea básica.

Se trata de un sistema que imita las funcionalidades de las redes sociales y justamente una de las funciones era sugerir contactos/amigos (que se relaciona un poco con lo que queremos hacer acá).
Para ello se crean distintos perfiles (definidos por los admins dinámicamente a medida que se les ocurran jaja) y se calcula el nivel de pertenencia de cada contacto a los mismos (un contacto podría pertenecer a varios perfiles). Cada perfil está compuesto por un conjunto de criterios/condiciones que debe cumplir el contacto para pertenecer a dicho perfil. Además, cada criterio tiene asociado un peso determinado según la importancia de dicho criterio. Lo que se hace es calcular para cada contacto (se podría calcular de forma offline en nuestro caso) el nivel de pertenencia para cada perfil sumando los pesos de los criterios que cumplen los contactos.
De esta manera, a la hora de elegir los contactos a sugerir se seleccionan solo aquellos que tengan mayor peso (o que superen un umbral determinado). Con esto podemos ver que el perfil de un usuario es difuso ya que puede pertenecer (en mayor o menor medida según el peso) a distintos perfiles al mismo tiempo.

Trasladado a utnianos, se me ocurrió que los perfiles podrían ser justamente los perfiles que tenemos actualmente (por ej.: Ingresante, Arrancando la carrera, Con título intermedio en mano, etc). De hecho, cuando empecé a entrar a utnianos yo pensaba que dichos perfiles servían para esto jaja. Las condiciones/criterios habría que pensarlos (por ahí para Arrancando la carrera, el criterio con mayor peso sería tener 4 materias aprobadas o algo así jaja).
Lo que no sabría cómo hacer bien es el tema de la persistencia de los perfiles y las pertenencias de cada user. Una opción sería almacenar por cada perfil, los users que pertenecen al mismo ordenados por el peso. Otra sería que cada user tenga una lista de perfiles a los que pertenece. También se me ocurrió hacer como el patrón Observer, que cada user tenga una lista de perfiles a los que pertenecen y que cada vez que se cambia una materia en el user, llame a los perfiles para recalcular los pesos y las pertenencias a los mismos.

No se, por ahí no aplica bien a lo que queremos pero se me ocurrió recién a la pasada jaja. No se si es viable la implementación porque no tengo conocimientos de php, pero buen. Espero que sirva la idea!

Saludos!

Que copado tener otra mirada sobre el problema