UTNianos

Versión completa: [AYUDA][FIINAL ALGORITMOS 13/02/10]
Actualmente estas viendo una versión simplificada de nuestro contenido. Ver la versión completa con el formato correcto.
Haciendo el final de 13 de febrero, que lo subo asi no hay problemas...

Mi estrategia, pero extendida..
Crear dos listas
1) Lista con sublista
Lista
Username - sublista(puntero) - sigu(puntero = 16 (8 +4 +4)
Sublista
Fecha reporte - Idfile -Poskill - Sigu = 4 + 4 + 4 +4 = 16

2) Indexar
Idfile - Posfile -cantreportes - Sigu = 12

La primer lista es la que va a mostrar cosas exclusivas del listado y las que faltan las saco de "indexar" con la posicion y accesos directos al archivo "file"

Programa Principal:
Inicializar ( Creo las dos listas)
Procesar( Armo el listado y dps lo muestro)

Inicializar es simplemente lista<--- nil, por eso sigo con

Procesar
-Abri los tres archivos (asign y reset)
-Indexe el primero "file"
-Poskill <--- 0 (una de las cosas que te pide en el listado es el motivo, este son 100caracteres... no entra ni mamado en el nodo entonces hay que aceder a este en algun momento)
-Solo leo Kill, ya que es el que tiene los reportes... ademas dice que "un solo registro por cada idfilepub reportado. Y eso me dio a entender que por mas que se reporten 555 veces solo aparece un registro ademas de que cada idfilepub es unico.
-Mando una busqueda binaria al archivo Filexuser, busco por idfilepub y me traigo el username y ek idfile. Este segundo en ningun lado dicen que es pero en el medio del texto te dice " que un archivo puede pertenecer a muchos usuarios" con lo que, ese idfile puede repetirse, ya que se pudo haber subido muchas veces pero idfilepub nunca va a ser el mismo.
Como te pide en el listado que pongas los que fueron reportados mas de una vez, a mi se me ocurrio como ven en la estructura en "indexado" poner cantreportes 1 y 2 va a tener. Sirve para ver cuales fueron reportados mas de una vez, por que cada idfile puede coincidir con muchos, pocos o ningun idfilepub entonces cada vez que coincida si es la primera vez pongo uno y si no pongo dos. (nose si se entiende)
Lo cual esta idea me parece muy engorrosa( es la unica que se me ocurrio tambien y no quiero que si me pasa algo asi me bochen)
-Cuando yo me traigo ese idfile y username, me tengo que fijar si (para agregar a la lista y sub) si es la primera vez o no que ingreso el username y tambien este idfile segun la fecha. Con lo cual tengo que ingresarlo ordenado y usar las busquedas tambien.

De esa forma haria el llenado de las 3 listas, pero tendria que llamar a un metodo mostrar:
Donde voy a tener que ir recorriendo la primer lista pero solo mostrando aquellos que en index tengan un 2 en cantreportes. ESto requiere busquedas en lista y sub.

Como dije no me parece mal, pero si un tanto largo... no se me ocurre otra forma.
Caro recien puedo ponerme a ver esto =(

Cita:-Poskill <--- 0 (una de las cosas que te pide en el listado es el motivo, este son 100caracteres... no entra ni mamado en el nodo entonces hay que aceder a este en algun momento)

pregunta, que es postkill?

es un puntero para acceder directamente a un registro particular del archivo?

estoy medio oxidado todavia con esto =P
Estuve buscando si había algo de información de este fnial en el foro, porque recordaba haberlo bajado de acá justamente hace un tiempito, y me topé con que es la tercera vez que se sube al foro el mismo final

Más allá de eso, en el topic que te paso acá debajo, varios usuarios hablaron de dicho final y su resolución


http://www.utnianos.com.ar/foro/tema-ped...13-02-2010

Incluso hasta hay subida una resolución, y Aye comentó cómo lo resolvió ella y aprobó, etc

Espero que te sirva!
ahhh ya estaba =P


por lo que vi la estrategia de caro funciona bien, no le encontre nada que pueda fallar.
U si, nisiquiera se me ocurrio buscar pq tampoco me salto jaja pero buen yo tenia una duda en particular de una forma de hacerlo no era lo mismo =)

Poskill, es una posicion en el archivo to_kill pq dps en el listado te pide "motivo" y es un campo que esta en un registro del archvio kill, pero como son 100 caracteres y los bytes son 16 max... necesitas acceder cuando muestres=)

Como dijo nanuitt estuve leyendo lo que ella dejo pero note algunos errores que los dejaron pasar y como otras cosas tambien note que las tenemos igual.

Aye:

Yo lo que hice fue una lista principal que tenía el idFile de 4, la posición al archivo de 4, una sublista de 4, y el siguiente de 4... ahí tenías la lista principal, en esa cargabas todo el archivo files (todas las posiciones y todos los idfiles...

Luego recorrías FilesxUsr y hacías las sublistas, ponías TODOS los registros de filesxUsr, los nodos de la sublista sólo tenía el idfilepub (de 8 bytes) y el siguiente....

ahi decia que solo podias hacer busqueda binaria sobre esteConfused asique aca me parece que tiene un error

Por último recorrías el To_Kill, a medida que lo ibas leyendo recorrías la lista y eliminabas el nodo DE LAS SUBLISTAS en el cual esté el mismo idfilepub que el del registro leído... Acá venía la parte "Poco feliz"; ninjguno de los archivos tenían orden, las listas tampoco, nada de nada! por lo cual por cada registro de To_Kill había que recorrer toda la lista principal y sus sublistas... Una mierda..... (SIGO CON ESTA EXPLICACIÓN MÁS ABAJO)

por último lo que hacía era recorrer la lista principal y preguntar qué nodo tenía la sublista igual a NIL, aquel que así la tenía implicaba que todos sus idfilepub habían sido denunciados, y de ese nodo sacaba la posición en el archivo, y publicaba todos los datos.... Total podía hacer una entrada directa a cada registro...

Así fue mi resolución, y aprobé....

(SIGO CON LA EXPLICACION DE ARRIBA)

Justamente como eso en las sublistas quedaba como el totó, algunos (pocos) optaron por hacer una lista principal que tuviera los idfile, un contador, la posición y nada más... y otra lista que tenga idfilepub, idfilepos y siguiente... Lo que se hacía de esta manera era recorrer el archivo FilesXUsr y cargar todos los registros, a medida que se iban agregando nodos a la lista esta, también se incrementaba el contador correspondiente en la lista principal (Es decir, si el IdFile era 1, se iba a la lista principal, la recorría buscando el nodo en el que el IdFile sea igual a uno, y aumentaba el contador).. Por último, leían el archivo To_Kill y por cada registro volvían a recorrer la lista auxiliar (aunque esto es una mierda, evidentemente era mucho mejor que recorrer la lista de sublistas, aunque a la larga, las dos son una cagada total), cuando encontraban el IdFilePub que coincidía con el del nodo, agarraban el idfile del nodo y recorrían la lista principal para disminuír en uno el contador... Se mostraba en pantalla aquellos que el contador tengan en cero... esta era la estrategia que tomaban como BIEN....

En fin, espero que se haya entendido, cualquier duda avisennn

Esto ultimo no lo entendi mucho, capas por que estoy encerrada en mi resolucion u.u Ademas no todos tuvieron en cuenta que no podes mostrar todos los reportes, tenian que ser reportados mas deuna vez...


Pero shadown, vos dijiste que no ves error... pero no resulta hasta engorroso?
Pr que tengo que hacer como 3 busquedas en listas(3 llamados) o mas, encima las variaciones son minimas u.u

Pero bueno gracias!! =)
es un poco engorroso... pero en tu resolucion no encontre que te falte resolver algo, tampoco que no tuvieses en cuenta alguna restriccion. Por ende esta bien.

si es un poco complicado de entender, pero para mi se resulve lo pedido y creo que no usaste ciclos demas tampoco.

En este momento despues de no hacer ejercicios de algoritmos me cuesta pensar una solucion mejor (me cuesta mas de lo que esperaba, voy a tener que ponerme a estudiar antes de lo que pensaba), apesar de que laburo programando =P
este mas que dificil me parece muy muy largo. Muchisimas gracias!!
Me voy a fijar porque creo que lo resolvi a este final. Si encontro donde está, voy a ver si puedo meterme en clima con esto!
URLs de referencia