Hola a todos! El año pasado aprobé por fin la cursada de Algoritmos y me tiré al lanse de dar el final.... y dos veces lo rendí mal!
Como no quiero pasar de la tercera vez, quiero consultar algunas cosas que hoy me vienen en duda.

Estuve haciendo el último ejercicio del módulo 3, donde hay que desarrollar un sistema para un restaurant, donde se asignan platos para 48 mesas con 10 mosos como máximo (alguien lo hizo?).

Mi duda no es muy compleja, ustedes sabrán juzgarme (?):
El enunciado da como límite 250 bytes para arrays y 6 bytes para nodos. Entre los datos importantes, el precio unitario del plato está definida en REAL (6 bytes).
Al final del ejercicio hay que emitir dos listados... uno de ellos un resumen con lo que cobró cada uno de los mosos. Cada moso gana el 1% de cada plato que sirvió.

MI CONSULTA ENTONCES:
¿Puedo yo recalcular la ganancia de los mosos en formato SINGLE? ¿O si de entrada aparece REAL en el enunciado todos los datos flotantes deben ser de tipo REAL? En ningún lado dice que el resumen debe ser en Real o en Single... Si yo elijo Real, no me da la memoria de Arrays ni la memoria de nodos para poder continuar el ejercicio con un algoritmo simple (mi idea consta de usar un array de listas con las 48 mesas... esto me consume 192 bytes y si le sumo 60 bytes me excedo en 2 bytes del límite impuesto... en cambio si uso Singles no me excedo en nada).

¿Qué opinan?

Desde ya gracias por leerme

La verdad que no lo hice nunca este. Aver si el dato te dice que esta en formato REAL es por que asi va a morir, se puede dar que ocupe todos los digitos que el real deja o no, pero vos tenes que tomar la base de que es real si o si.

Yo te recomendaria, que busques otra forma... nunca me paso que los tipos de datos que dieran en el enunciado sean por demas. Siempre, esos datos y los bytes que ocupan dieron justo en la tecla de lo que te da la capacidad... capas vos crees queesa estrategia esta bien pero no.

Si qures poner el enunciado, capas te podemos aydar

Tratá de escanearlo, o sacarle una buena foto, porque se complica tirarte ideas sin verlo.

(15-02-2012 15:51)CarooLina escribió:  Yo te recomendaria, que busques otra forma... nunca me paso que los tipos de datos que dieran en el enunciado sean por demas. Siempre, esos datos y los bytes que ocupan dieron justo en la tecla de lo que te da la capacidad... capas vos crees queesa estrategia esta bien pero no.

Me consta que hubo veces que la solución podía ocupar menos memoria de la que te daban, pero como bien decís, nunca me tocó ninguno en los que se haya excedido.

Si tenes razon en eso, pero como me dijo mi profe: los requisitos son de modo orientativo para que sepas como viene la mano de la resolucion.

Hola Caro! Gracias por responder, creo que lo que decís es la posta... es un ejercicio rebuscado este
Les paso el enunciado por si quieren verlo:


Ej. MIII-22: Dado el siguiente enunciado
Un restaurant desea manejar en forma computarizada las adiciones de sus mesas. Para ello dispone de los siguientes datos:
a) un archivos de platos y bebidas, ordenado por código de plato con el siguiente diseño:
a.1 código de plato (1..200) a.2 descripción del plato (40 caracteres)
a.3 precio unitario (real) a.4 otros datos (100 caract)

b) número de factura inicial y fecha del día

c) Por cada producto servido se ingresan por teclado la siguiente información:
c.1 número de mesa (1..48) b.2 código de operación (‘A’, ‘B’, ‘F’)
c.3 código de plato (1..200) b.4 unidades pedidas (2 dígitos)

Operación A: significa plato servido
Operación B: significa devolución del plato
Operación F: fin del pedido, emitir la adición y el campo de código de plato contiene el número del mozo (1..10) que atendió esa mesa.

Cuando se ingrese nro de mesa igual a 0 indica fin del día. En caso de que queden adiciones pendientes, informar una leyenda.

Se pide realizar un programa que:
1) Imprima la factura de cada mesa que fue ocupada:
Restaurant Fecha :.................. Factura:.......................
Cant Descripción Precio Unitario Importe
....... ................... ............ ............
Mozo: .... Total:........................
Los platos deben estar ordenados por código de plato y acumuladas las unidades en caso de repetición.
2) Grabar un archivo de facturación con los siguientes datos: fecha, número de factura, mesa, mozo, e importe
3) Al final del día emitir un listado con el total a cobrar por cada mozo, ordenado por número de mozo (cobran el 1% sobre cada adición)

 Recursos y Restricciones:
 Máximo de Mozos: 10
 Memoria para arrays: 250 bytes.
 Memoria dinámica: nodo maximo de 6 bytes.
 Memoria en disco: solo para la grabación del nuevo archivo
_______________________________________

Ahora, que se me ocurrió a mi: Suponiendo que hay 48 mesas y que cada mozo puede atender varias mesas a la vez, lo que debería computar el sistema es un nodo por cada plato servido. Cada nodo estaría asignado a una mesa. Por ende, habría una lista por mesa.
Supongo que un cliente se sienta en una mesa y empieza a pedir platos para comer. Cada plato servido se registra en el sistema. Si un cliente no le gusta el plato, lo devuelve. Entonces el sistema busca el nodo del plato servido y lo elimina (o si dentro del nodo le agrego un contador, le resto uno).
Uno no sabe qué mozo atiende cada mesa hasta que se ingresa FIN como operación... recién ahí me informan sobre el mozo.
Ese es mi "ideal" para el sistema principal. Tendría que pensar otro esquema olvidándome de las 48 listas... quizás armando una mega lista con nodos que indiquen el plato servido y el nº de mesa. La paja de hacerlo así es que hay que recorrer la lista toodo el tiempo buscando valores para agregar ordenadamente, "vaciar" todos los nodos de esa mesa cuando le das a 'F', etc...
Tengo que seguir pensando

Hola, creo haber encontrado una solución al ejercicio (ya pensé suficiente jej).

Como no da la memoria estática para generar un super-vector con las 48 mesas que vayan a un puntero, decidí mejor que en esas 48 posiciones iría mejor un WORD (2 bytes) con la cantidad total de platos servidos hasta el momento. El array se inicializaría todo en cero.
Por otro lado, todos los platos se van generando como nodos dentro de una mega-lista lineal. Los nodos contienen el nº de plato y otro número que puede ser el nº de mesa (no lo tengo bien definido). La idea es que cada nodo se genere ordenado por nº de mesa, y sume uno al vector de la mesa. Antes de insertarlo, hacemos un barrido en el vector de la cantidad de platos servidos del nº de mesa hacia abajo.
Onda.... si hay que insertar un plato en la mesa 12, vamos sumando cuantos platos se sirvieron de la mesa 1 al 11, entonces ese número nos posiciona justo en el 1er nodo de la lista con platos de la mesa 12 (esto es para evitar el barrido de búsqueda, sino se puede hacer de la otra forma). Después, cuando quiero imprimir la factura, me posiciono en ese nodo y voy sacando nodos hasta que el contador del array llegue a cero. Si dos nodos consecutivos tienen el mismo nº, entonces acumulo antes de imprimir.
Una alternativa es que los nodos no lleven el nº de mesa sino la cantidad de platos pedidos. Esto me ahorra lo de acumular antes de imprimir y que se genere un solo nodo cada vez que ingreso datos por teclado. Ahí sí no queda otra que usar el método de búsqueda que expliqué antes.

Es un ejercicio rebuscado pero se puede Siempre rezo que en los finales se olviden de estos enunciados.

Me llama mucho la atención que no te permitan ningún acceso directo al archivo de platos y bebidas, porque te piden un listado en donde TENES que poner la descripción del plato (40 caracteres, cada plato, osea, imposible de guardar en memoria estática )

Y la única vuelta que le veo en ese caso es que en algún momento tendrás que guardar la posición de un determinado plato del archivo (osea, va a ser un número de 0 a 200) en algún lado, cosa de que cuando emitas el listado, uses el acceso directo con la posición que guardaste para sacar el registro correspondiente al plato, y de ahí la descripción y el precio (porque el importe lo calculás multiplicando precio*cantidad)

Igualmente, después seguís leyendo y te encontrás con que tenés que grabar un archivo con registros:
fecha, número de factura, mesa, mozo, e importe

Y la verdad que dan ganas de mandar todo al choto

Es más dificil que muchos de los que ví modelo 2003/2004, y mirá que eran jodidos esos eh!

(16-02-2012 20:15)H3rnst escribió:  Me llama mucho la atención que no te permitan ningún acceso directo al archivo de platos y bebidas, porque te piden un listado en donde TENES que poner la descripción del plato (40 caracteres, cada plato, osea, imposible de guardar en memoria estática )

Y la única vuelta que le veo en ese caso es que en algún momento tendrás que guardar la posición de un determinado plato del archivo (osea, va a ser un número de 0 a 200) en algún lado, cosa de que cuando emitas el listado, uses el acceso directo con la posición que guardaste para sacar el registro correspondiente al plato, y de ahí la descripción y el precio (porque el importe lo calculás multiplicando precio*cantidad)

Igualmente, después seguís leyendo y te encontrás con que tenés que grabar un archivo con registros:
fecha, número de factura, mesa, mozo, e importe

Y la verdad que dan ganas de mandar todo al choto

Es más dificil que muchos de los que ví modelo 2003/2004, y mirá que eran jodidos esos eh!

Perdón perdón perdón!!! Al final del enunciado me faltó copiar la linea donde dice "accesos a disco: optimice las búsquedas en el archivo de platos"
Al final resolví hacer lo siguiente: crear un mega-listado con platos ordenados por nºde mesa. Los nodos tienen el nº de mesa, así que hay un nodo por plato. Si la cantidad es 5, entonces ejecutás el inserta-nodo 5 veces con un for.
Cuando le dan a "F", lo que hago es: buscar la mesa en el listado con un aux^.sgte^.mesa ... tomo todos los datos de ese nodo y los inserto en una COLA auxiliar. Los nodos son iguales PERO en vez del campo mesa, uso el campo "cantidad". Si dos platos se repiten de corrido, entonces en Colafin^.cantidad le sumo uno. Por cada nodo que proceso, hago un aux^.sgte <- aux^.sgte^.sgte.. y después un dispose(aux^.sgte).
ASí ya tengo una cola lista para imprimir en pantalla. Por cada nodo que proceso, hago una búsqueda binaria en el archivo por código de plato. Los valores que traigo los imprimo en pantalla y los guardo en el archivo nuevo, y actualizo un campo con el monto total. Cuando se termina la cola, imprimo el monto total, el fuckin' mozo y actualizo el vector de los mozos. También seteo el vector de mesas a "cantidadplatos=0" (en este caso la cantidad no importa, solo sirve para informar al final de todo que mesas tienen cantidad de platos <> 0 )

Como lo explico parece tranca, pero es un bardo... se me fue más de una hora pensando esta estrategia, si fuera un final estoy in the oven

Che, 1 ocupaba el byte, no?. Ahí haces un vector de listas de 48 posiciones (1 por cada mesa, claro) y ahí almacenando en el nodo código de plato y cantidad pedida. El código de plato va de 1..200 (1 byte) y la cantidad pedida son 2 números (1 byte), el restante es para el sgte (4 bytes). Cuando tenes que informar haces una búsqueda binaria en el primero ya que está ordenado y listo.

(17-02-2012 16:08)Aivan escribió:  Che, 1 ocupaba el byte, no?. Ahí haces un vector de listas de 48 posiciones (1 por cada mesa, claro) y ahí almacenando en el nodo código de plato y cantidad pedida. El código de plato va de 1..200 (1 byte) y la cantidad pedida son 2 números (1 byte), el restante es para el sgte (4 bytes). Cuando tenes que informar haces una búsqueda binaria en el primero ya que está ordenado y listo.

Esta estrategia es la más sencilla. El problema es que no alcanza la memoria estática para compartir este vector con el otro vector para los mozos. En total hay 10 mozos con su respectiva ganancia final. Si la ganancia es REAL, entonces se me van 60 bytes en mem estática. No tengo chance de usar mem dinámica por la restricción del nodo. Para usar el super vector de 48 posiciones se necesitan mínimo 192 bytes (48 *4 bytes).
Sumando ambos arrays llegamos a los 252 bytes... o sea, nos excedimos en 2 bytes. Como el array de mozos no lo puedo sacrificar de ninguna forma, tengo que sacrificar el super array.
La única forma para que convivan ambos arrays es que el resultado para los mozos sea en formato SINGLE. Creo, CREO, que en pascal se puede hacer una conversión del tipo...

Pero buen, no se, si a la sra jefa de cátedra le gusta trollear a sus alumnos con los tipos de datos, queda aguantársela y hacer el camino más largo.

Pero no hagas un array de ganancia por cada mozo, hace un array de listas en donde cada nodo contenga el plato que le pidieron. O sea, Cuando te viene una 'F', vas a la posición correspondiente en este array y creas un nodo con el plato que le pidieron. Cuando te pidan el informe recorres las posiciones en orden y vas haciendo búsqueda binaria (sí, otra vez) en el primer archivo.

(17-02-2012 17:36)Aivan escribió:  Pero no hagas un array de ganancia por cada mozo, hace un array de listas en donde cada nodo contenga el plato que le pidieron. O sea, Cuando te viene una 'F', vas a la posición correspondiente en este array y creas un nodo con el plato que le pidieron. Cuando te pidan el informe recorres las posiciones en orden y vas haciendo búsqueda binaria (sí, otra vez) en el primer archivo.

Ah la mierda! Horas malgastando mi cerebro
Nunca pensé la alternativa de usar dos arrays con listas! Ahora entro en duda si mañana voy a rendir o no

No malgastas tu cerebro, al contrario, descubrís formas que te podrían servir en determinados casos, pero que no aplican a este lamentablemente. Consejo: No vayas a rendir sin estar ágil con la práctica.

Una única duda así en general...
Cuando recorremos una lista para imprimirla en pantalla o similar, ¿es necesario hacer un dispose de todos los nodos antes de terminar el ejercicio? ¿Resta puntos no hacer el dispose?

Saludos y gracias por todo!

si, la catedra pide que todas las listas que creas sean borradas. Podes aprovechar mientras mostras borras o sino pones el procedimiento de borrar. Es como no cerrar el archivo que abris, osea mal.!!

jaja sorry que no te ayude, pero me quede pensando uu