Ainda não entendi porque, de repente, as pessoas começaram a me mandar email diretamente ao invés de postar aqui.
Sobre as notas do EP2, elas saem quando eu acabar de corrigir. Já comecei mas não vai sair antes da semana que vem. Como sempre, façam o EP3 e envolvam uma quantidade de trabalho razoável nele que vocês irão bem.
Não menosprezem o relatório e, por favor, passem um corretor ortográfico! É triste encontrar relatórios com erros de digitação ou erros de ortografia.
Olá, Hugo!
temos as seguintes duvias
-Devemos gerar as entradas teste aleatorias? Se sim, como? Ou elas serão geradas durante a correção do ep?
-Como fazer a analise das entradas geradas?
-Como deve ser a lógica para decidir qual desconto o cartão possui?
-Não entendemos se a verificação da efetivação do desconto deve vir antes da identificação do usuário ou o contrário(verificação do usuário antes do desconto)
vlww
temos as seguintes duvias
-Devemos gerar as entradas teste aleatorias? Se sim, como? Ou elas serão geradas durante a correção do ep?
-Como fazer a analise das entradas geradas?
-Como deve ser a lógica para decidir qual desconto o cartão possui?
-Não entendemos se a verificação da efetivação do desconto deve vir antes da identificação do usuário ou o contrário(verificação do usuário antes do desconto)
vlww
Nussa 
Relação 0 com o tópico da discussão mas tudo bem
- Dever? Não. Se vocês fizerem, acho muito legal mas não vou cobrar isso não. Uma nota sobre a tal aleatoriedade. Acho que me expliquei mal e peço desculpars. Não vou gerar um número de 20 bits qualquer e ver se ele pertence a algum grupo. Vou pegar um número válido e tentar fazer trocar de bits nesse número para descobrir a "distância" ao próximo número da mesma classe. Se essa distância for 1, isso é ruim (quer dizer que tem um bit que posso trocar e continua tudo OK). Se a distância for 3 ou 4, isso é muito bom, quer dizer que dado um número não adianta eu trocar 1 ou 2 bits que não vou conseguir achar outro número válido. Isso deixa mais difícil de gerar números válidos quaisquer.
- Acho que a resposta anterior ajudou um pouco nisso. Se não for o caso, por favor, explique melhor a dúvida.
- A lógica que decide o desconto fica por vocês. Uma idéia é depender do valor da verificação que vocês fizeram ou ter alguns bits para isso ou mesmo se basear num padrão de números para cada desconto. Fica a critério de vocês, só quero isso bem explicado no relatório para eu não ter que ficar adivinhando.
- A ordem não me importa muito. Só estou interessado na saída mesmo do valor do desconto. Se vocês identificarem um desconto válido sem precisarem dos dados do usuário, talvez o algoritmo de vocês não seja tão bom (no primeiro sentido que defini) quanto poderia. Mas ainda fica por vocês.
Por nada.
- Dever? Não. Se vocês fizerem, acho muito legal mas não vou cobrar isso não. Uma nota sobre a tal aleatoriedade. Acho que me expliquei mal e peço desculpars. Não vou gerar um número de 20 bits qualquer e ver se ele pertence a algum grupo. Vou pegar um número válido e tentar fazer trocar de bits nesse número para descobrir a "distância" ao próximo número da mesma classe. Se essa distância for 1, isso é ruim (quer dizer que tem um bit que posso trocar e continua tudo OK). Se a distância for 3 ou 4, isso é muito bom, quer dizer que dado um número não adianta eu trocar 1 ou 2 bits que não vou conseguir achar outro número válido. Isso deixa mais difícil de gerar números válidos quaisquer.
- Acho que a resposta anterior ajudou um pouco nisso. Se não for o caso, por favor, explique melhor a dúvida.
- A lógica que decide o desconto fica por vocês. Uma idéia é depender do valor da verificação que vocês fizeram ou ter alguns bits para isso ou mesmo se basear num padrão de números para cada desconto. Fica a critério de vocês, só quero isso bem explicado no relatório para eu não ter que ficar adivinhando.
- A ordem não me importa muito. Só estou interessado na saída mesmo do valor do desconto. Se vocês identificarem um desconto válido sem precisarem dos dados do usuário, talvez o algoritmo de vocês não seja tão bom (no primeiro sentido que defini) quanto poderia. Mas ainda fica por vocês.
Por nada.
também não entendemos o conceito de bits de verificação e identificação.
Alguns bits precisam estar lá para que você possa identificar qual o estudante qu está pedindo o café. É tipo um identificador.
Mas queremos que nem todo identificador seja válido. Por isso precisamos de alguns bits que vão olhar para os bits de identiicação e verificar que o identificador passaro está correto e é válido. Esses são os de verificacão.
Ficou mais claro? Se não, tentem explicar um pouco mais.
Hugo
Mas queremos que nem todo identificador seja válido. Por isso precisamos de alguns bits que vão olhar para os bits de identiicação e verificar que o identificador passaro está correto e é válido. Esses são os de verificacão.
Ficou mais claro? Se não, tentem explicar um pouco mais.
Hugo
Sim sim
Ajudo bastante, apesar da relação 0 ^^"
Valeu!
Ajudo bastante, apesar da relação 0 ^^"
Valeu!
Nada a ver com o tópico original, mas tem a ver com o que se está discutindo aqui...
"Mas queremos que nem todo identificador seja válido"
Putz, eu tava fazendo "se passa na verificação, ganha desconto (a ser definido), se não passa, sem desconto".
Você quer dizer que deve haver seqüencias que são inválidas, ou seja, retornam 0 em todos os bits? É isso? Num pode ser do outro jeito?
"Mas queremos que nem todo identificador seja válido"
Putz, eu tava fazendo "se passa na verificação, ganha desconto (a ser definido), se não passa, sem desconto".
Você quer dizer que deve haver seqüencias que são inválidas, ou seja, retornam 0 em todos os bits? É isso? Num pode ser do outro jeito?
Não. Pode considerar que se o identificador for inválido, ele tem desconto 0.