Questao Dimensão de um Ficheiro

O

Onomus

Membro
Boa tarde! Estou a preparar-me para a entrada na faculdade, e tenho de realizar uma prova. Estou preso nesta questão e não consigo entender o método de pensamento e a forma de chagar a solução. Agradecia a vossa ajuda.

Questão:
Considere a necessidade de armazenar num ficheiro de texto, com codificação ASCII, um
histograma de ocorrências do sorteio do Euro Milhões, contendo a seguinte informação: o
caracter ‘N’ ou ‘E’ concatenado do seu número (como por exemplo N12 e E10, respetivamente
para representar o Número 10 e a Estrela 12); e o número de ocorrências, considere um máximo
de 8 dígitos. Cada informação deve ser armazenada por linha do ficheiro e os campos separados
por ‘;’. Considere que os Números variam de 1 a 50 e as Estrelas de 1 a 12. Qual será a
dimensão máxima do ficheiro?
 
@Onomus antes de começares a fazer contas, recomendo que escrevas alguns exemplos de linhas válidas desse ficheiro (de preferência os extremos, "números especiais" como 0, 12, 50, 99999999...), tal como definido pelo enunciado. Escreve-as aqui, como resposta, para te podermos dizer se estás a interpretar bem o enunciado.
 
Kayvlim disse:
@Onomus antes de começares a fazer contas, recomendo que escrevas alguns exemplos de linhas válidas desse ficheiro (de preferência os extremos, "números especiais" como 0, 12, 50, 99999999...), tal como definido pelo enunciado. Escreve-as aqui, como resposta, para te podermos dizer se estás a interpretar bem o enunciado.
Clicar para expandir...
N1 99999999;
E1 99999999;
N2 99999999;
E12 99999999;
...
É isto que percebo do inunciado

Ace-_Ventura disse:
Tens de saber quanto espaço ocupa cada caracter no disco e depois multiplicas pelo máximo de carateres de acordo com o enunciado
Clicar para expandir...
Pelo meu teste no bloco de notas, cada carácter ocupa 1 byte, mesmo assim não consigo entender. Obrigado pela atenção
 
@Onomus o que escreveste não cumpre a seguinte regra do enunciado:
Onomus disse:
Cada informação deve ser armazenada por linha do ficheiro e os campos separados por ‘;’.
Clicar para expandir...
Tens dois campos, número/estrela e número de ocorrências. O ';' é para estar no meio dos campos (a separá-los), e não no fim da linha. O enunciado não diz que podes usar um espaço ;)

Para além disso, convém teres noção dos limites mínimos e máximos daquilo que vai ser cada linha do teu ficheiro:
  • Colocaste "E12", e esse está certo - é a maior estrela que podes ter (o exemplo do enunciado está ao contrário).
  • Também colocaste "N1" e "E1". Esses são os menores números que podes colocar em números e estrelas, portanto também estão bem.
  • Já o "N2" não é o maior número que podes colocar, de acordo com o enunciado. É um exemplo válido, mas quando quiseres fazer as contas que te pedem, convém teres em conta o maior número que podes ter.
Quanto ao número de ocorrências, colocaste sempre o mesmo número, que corresponde ao limite máximo (8 dígitos, o maior dígito é o 9). É o que precisas para responder ao enunciado, mas não te esqueças que "0" também é válido.

Onomus disse:
Pelo meu teste no bloco de notas, cada carácter ocupa 1 byte, mesmo assim não consigo entender. Obrigado pela atenção
Clicar para expandir...
Cada carácter ocupa de facto 1 byte, mas não sei como é que chegaste lá pelo bloco de notas: quem te diz isso é o enunciado, com a seguinte frase:
Onomus disse:
Considere a necessidade de armazenar num ficheiro de texto, com codificação ASCII
Clicar para expandir...
Na codificação ASCII, todos os caracteres ocupam 1 byte[*]

Portanto: podes tentar de novo dar as (pelo menos) quatro combinações que resumem todos os casos possíveis do enunciado? Para cada uma, indica também quanto é que essa linha ocupa (em bytes, e contando com o carácter de newline). Podes considerar que o número de ocorrências é o maior número possível.


[*] isto é só para efeitos do teu enunciado! Existe toda uma discussão sobre codificações de 7-bits, 8-bits ou múltiplos bytes, que não interessa agora enquanto estás a aprender as bases, mas se o teu futuro passar por engenharia de software, convém leres isto um dia destes, que tem coisas que não ensinam na faculdade mas são fundamentais. O mundo de hoje em dia não trabalha em ASCII, trabalha principalmente em UTF-8, e em UTF-8 um carácter pode ocupar mais de 1 byte.
 
Kayvlim disse:
@Onomus o que escreveste não cumpre a seguinte regra do enunciado:

Tens dois campos, número/estrela e número de ocorrências. O ';' é para estar no meio dos campos (a separá-los), e não no fim da linha. O enunciado não diz que podes usar um espaço ;)

Para além disso, convém teres noção dos limites mínimos e máximos daquilo que vai ser cada linha do teu ficheiro:
  • Colocaste "E12", e esse está certo - é a maior estrela que podes ter (o exemplo do enunciado está ao contrário).
  • Também colocaste "N1" e "E1". Esses são os menores números que podes colocar em números e estrelas, portanto também estão bem.
  • Já o "N2" não é o maior número que podes colocar, de acordo com o enunciado. É um exemplo válido, mas quando quiseres fazer as contas que te pedem, convém teres em conta o maior número que podes ter.
Quanto ao número de ocorrências, colocaste sempre o mesmo número, que corresponde ao limite máximo (8 dígitos, o maior dígito é o 9). É o que precisas para responder ao enunciado, mas não te esqueças que "0" também é válido.


Cada carácter ocupa de facto 1 byte, mas não sei como é que chegaste lá pelo bloco de notas: quem te diz isso é o enunciado, com a seguinte frase:

Na codificação ASCII, todos os caracteres ocupam 1 byte[*]

Portanto: podes tentar de novo dar as (pelo menos) quatro combinações que resumem todos os casos possíveis do enunciado? Para cada uma, indica também quanto é que essa linha ocupa (em bytes, e contando com o carácter de newline). Podes considerar que o número de ocorrências é o maior número possível.


[*] isto é só para efeitos do teu enunciado! Existe toda uma discussão sobre codificações de 7-bits, 8-bits ou múltiplos bytes, que não interessa agora enquanto estás a aprender as bases, mas se o teu futuro passar por engenharia de software, convém leres isto um dia destes, que tem coisas que não ensinam na faculdade mas são fundamentais. O mundo de hoje em dia não trabalha em ASCII, trabalha principalmente em UTF-8, e em UTF-8 um carácter pode ocupar mais de 1 byte.
Clicar para expandir...
Obrigado, acho que estou a começar a entender. Vamos ver se estou mais perto do que antes:

E12;99999999; 12 byts+1parágrafo=13 byts (máximo)
E1;0; 5 byts+1paragrafo=6byts (mínimo)
N50;12345678; 12+1=13byts (máximo)
N1;1; 5+1=6byts (mínimo)

Sabemos que temos E1-E9 que ocupam 9 linhas, no máximo 12 byts por linha, e N1-N9 que ocupam mais 9 linhas de 12 byts por linha no máximo. O que totaliza (9×2)×12=216 byts

E ainda temos E10-12, que ocupam 3 linhas, 13 byts por linha, e N10-50, que ocupam 41 linhas de 13 byts por linha, no máximo.
O que dá 41+3×13=572byts

572+216=788

O resultado está errado, logo ainda não percebi alguma coisa, apesar da excelente explicação.
 
O raciocínio é esse, portanto vamos ver o que pode ter corrido mal.

O maior ficheiro possível - dentro da minha interpretação do enunciado - tem este aspecto:
Código: 
N1;99999999
...
N9;99999999
N10;99999999
...
N50;99999999
E1;99999999
...
E9;99999999
E10;99999999
E11;99999999
E12;99999999

Portanto:
Código: 
# números com 1 algarismo
9 * (3+8+1)
# números com 2 algarismos
(50-9) * (4+8+1)
# estrelas com 1 algarismo
9 * (3+8+1)
# estrelas com 2 algarismos
(12-9) * (4+8+1)

A soma disto tudo:
9 * (3+8+1) + (50-9) * (4+8+1) + 9 * (3+8+1) + (12-9) * (4+8+1) = 788.

Chegámos ao mesmo resultado, portanto imagino os seguintes cenários:
  • (improvável) talvez não estejam a considerar o newline - subtrais (50+12) a 788.
  • (muito provável) talvez estejam a considerar que o newline tem dois bytes em vez de um (em Windows usa-se CR+LF; em Unix apenas se usa LF) - somas (50+12) a 788
  • (improvável) talvez estejam a considerar que há mais um ';' no final de cada linha - somas (50+12)
  • (não me parece) talvez estejam a considerar que não há números com 1 algarismo (i.e. E01 em vez de E1) - o enunciado parece-me negar isso, mas se quiseres tentar, somas (9+9)
Se não for nada disto, não estou a ver de que forma este resultado está errado.
 
Última edição:
Kayvlim disse:
O raciocínio é esse, portanto vamos ver o que pode ter corrido mal.

O maior ficheiro possível - dentro da minha interpretação do enunciado - tem este aspecto:
Código: 
N1;99999999
...
N9;99999999
N10;99999999
...
N50;99999999
E1;99999999
...
E9;99999999
E10;99999999
E11;99999999
E12;99999999

Portanto:
Código: 
# números com 1 algarismo
9 * (3+8+1)
# números com 2 algarismos
(50-9) * (4+8+1)
# estrelas com 1 algarismo
9 * (3+8+1)
# estrelas com 2 algarismos
(12-9) * (4+8+1)

A soma disto tudo:
9 * (3+8+1) + (50-9) * (4+8+1) + 9 * (3+8+1) + (12-9) * (4+8+1) = 788.

Chegámos ao mesmo resultado, portanto imagino os seguintes cenários:
  • (improvável) talvez não estejam a considerar o newline - subtrais (50+12) a 788.
  • (muito provável) talvez estejam a considerar que o newline tem dois bytes em vez de um (em Windows usa-se CR+LF; em Unix apenas se usa LF) - somas (50+12) a 788
  • (improvável) talvez estejam a considerar que há mais um ';' no final de cada linha - somas (50+12)
  • (não me parece) talvez estejam a considerar que não há números com 1 algarismo (i.e. E01 em vez de E1) - o enunciado parece-me negar isso, mas se quiseres tentar, somas (9+9)
Se não for nada disto, não estou a ver de que forma este resultado está errado.
Clicar para expandir...
Isto é um exercício de escolha múltipla, e não tem explicação de como se chegou ao resultado. O resultado deve ser 869 byte
 
Sim, fui ver as Soluções.
As opções são:
A: 745 byte
B: 869 byte
C: 801 byte
D: 601 byte
E: 701 byte

Eu consegui chegar perto do resultado, mas não sei se está correto, a lógica por trás.

Este foi o método (o não me parece):
E01;12345678; 14 bytes com o parágrafo.

Sendo que agora todos têm 14 bytes, fiz (50+12)×14=868 bytes, fica a sobrar 1 para os 869.

Aqui está a prova: Prova

Aqui está as Soluções: Soluções
 
Isso está a parecer-me um "qual é a resposta menos incorrecta" e não "qual é a resposta correcta".
O enunciado diz que variam de 1 a 12 e de 1 a 50, não diz 01 em lado nenhum. Se fosse para prefixar o número, ao menos diriam "de 01 a 12".
A definição do problema parece-me estar bastante completa, portanto também não há muito por onde pegar sem inventar.

Para tirar a teima, corri isto:
Código: 
$ for i in {1..12}; do echo "E$i;99999999"; done > numbers.txt
$ for i in {1..50}; do echo "N$i;99999999"; done >> numbers.txt
$ ls -l numbers.txt
-rw-r--r--  1 kayvlim  kayvlim  788 Jul  1 16:17 numbers.txt
                                ^^^
ou seja, o ficheiro final ocupa 788 bytes, como seria de esperar.

Conclusão - não faço ideia como é que chegaram aos 869, sem terem inventado coisas que não estão no enunciado (como o prefixo 0 nos números, ou dois newlines no fim do ficheiro, ou a sequência de BOM "FEFF" no início do ficheiro, que não faz sentido em ASCII). Na minha opinião, a resposta certa a esse enunciado é 788.

Portanto, cenários actualizados:
  • quem escreveu o enunciado não o cumpriu (falta de atenção nos enunciados não é novidade para mim)
  • interpretámos mal o enunciado de uma forma que não consigo imaginar
É só isto. Não imagino nenhuma "rasteira" possível que não implique quebrar a definição do enunciado, portanto se alguma vez vieres a descobrir o porquê dessa ser a resposta certa, põe aqui!
 
Kayvlim disse:
Isso está a parecer-me um "qual é a resposta menos incorrecta" e não "qual é a resposta correcta".
O enunciado diz que variam de 1 a 12 e de 1 a 50, não diz 01 em lado nenhum. Se fosse para prefixar o número, ao menos diriam "de 01 a 12".
A definição do problema parece-me estar bastante completa, portanto também não há muito por onde pegar sem inventar.

Para tirar a teima, corri isto:
Código: 
$ for i in {1..12}; do echo "E$i;99999999"; done > numbers.txt
$ for i in {1..50}; do echo "N$i;99999999"; done >> numbers.txt
$ ls -l numbers.txt
-rw-r--r--  1 kayvlim  kayvlim  788 Jul  1 16:17 numbers.txt
                                ^^^
ou seja, o ficheiro final ocupa 788 bytes, como seria de esperar.

Conclusão - não faço ideia como é que chegaram aos 869, sem terem inventado coisas que não estão no enunciado (como o prefixo 0 nos números, ou dois newlines no fim do ficheiro, ou a sequência de BOM "FEFF" no início do ficheiro, que não faz sentido em ASCII). Na minha opinião, a resposta certa a esse enunciado é 788.

Portanto, cenários actualizados:
  • quem escreveu o enunciado não o cumpriu (falta de atenção nos enunciados não é novidade para mim)
  • interpretámos mal o enunciado de uma forma que não consigo imaginar
É só isto. Não imagino nenhuma "rasteira" possível que não implique quebrar a definição do enunciado, portanto se alguma vez vieres a descobrir o porquê dessa ser a resposta certa, põe aqui!
Clicar para expandir...
Obrigado! Já pelo menos aprendi algo novo, quando for realizar o exame no dia 5, vou questionar, caso eles saibam o porquê ^^
Vou avançar e continuar a praticar as outras questões.

Abraço
 
Kayvlim disse:
Isso está a parecer-me um "qual é a resposta menos incorrecta" e não "qual é a resposta correcta".
O enunciado diz que variam de 1 a 12 e de 1 a 50, não diz 01 em lado nenhum. Se fosse para prefixar o número, ao menos diriam "de 01 a 12".
A definição do problema parece-me estar bastante completa, portanto também não há muito por onde pegar sem inventar.

Para tirar a teima, corri isto:
Código: 
$ for i in {1..12}; do echo "E$i;99999999"; done > numbers.txt
$ for i in {1..50}; do echo "N$i;99999999"; done >> numbers.txt
$ ls -l numbers.txt
-rw-r--r--  1 kayvlim  kayvlim  788 Jul  1 16:17 numbers.txt
                                ^^^
ou seja, o ficheiro final ocupa 788 bytes, como seria de esperar.

Conclusão - não faço ideia como é que chegaram aos 869, sem terem inventado coisas que não estão no enunciado (como o prefixo 0 nos números, ou dois newlines no fim do ficheiro, ou a sequência de BOM "FEFF" no início do ficheiro, que não faz sentido em ASCII). Na minha opinião, a resposta certa a esse enunciado é 788.

Portanto, cenários actualizados:
  • quem escreveu o enunciado não o cumpriu (falta de atenção nos enunciados não é novidade para mim)
  • interpretámos mal o enunciado de uma forma que não consigo imaginar
É só isto. Não imagino nenhuma "rasteira" possível que não implique quebrar a definição do enunciado, portanto se alguma vez vieres a descobrir o porquê dessa ser a resposta certa, põe aqui!
Clicar para expandir...

O mais perto que cheguei foi 866 bytes.. n sei se ainda respondem a este problema mas.. era bom saber a resposta mesmo
 
Inicie sessão ou registe-se para poder participar.
Back
Topo