Re: Crit�rios de corre��o

["Rubens Altimari" <rubens@bcc2000.net>]

>O desconto foi uniforme, ou seja, errou alguma coisa, perdeu um ponto.

De toda a discuss�o, acho que s� n�o concordo com isto aqui.

Que nomes diferentes, por exemplo, atrapalhem uma corre��o automatizada, �
�bvio e deve ser de fato enervante - al�m disso, concordo tamb�m que deva
ter algum decr�scimo na nota, j� que algu�m que acertou tudo "merece" (as
aspas s�o para outra discuss�o) ter uma nota maior. O mesmo vale para outros
problemas ou falhas ao cumprir a especifica��o.

Agora, n�o vejo rela��o entre "desconto uniforme" e um crit�rio justo. Pode
ou n�o haver. Afinal, "errou alguma coisa, perdeu um ponto" pode ser f�cil
de aplicar, e aparentemente muito l�gico, mas por que deveria ser assim? Por
que um erro, digamos, na apresenta��o, deveria ter o mesmo peso que um erro
na implementa��o? Ou na qualidade do algoritmo? Como contar quantos erros h�
em uma dada situa��o (depende de como se conta, etc.)?

Enfim, Nelson, acho que voc� poderia rever a pol�tica de descontos em busca
de algo que se aproxime mais de cumprir o objetivo prim�rio, seja ele qual
for (para mim, seria exercitar o conte�do da disciplina e demonstrar este
exerc�cio e a apreens�o de cada um). Lembro de um colega de minha turma,
quando foi monitor pela primeira vez, que argumentava: "vou tirar 3 pontos
por m� indenta��o - pombas, se o cara n�o sabe indentar, n�o sabe nem o
m�nimo!". Foi uma luta convenc�-lo a ser mais generoso... (que � a palavra
adequada, na minha opini�o).

Ali�s, aproveito o email para comentar e sugerir o seguinte: achei que este
EP acabou ficando na regra 80-20: 80% do tempo e esfor�o dedicados �s
quest�es perif�ricas, como I/O em C (que � um saco), formatos do Makefile
(idem, duas vezes), etc. De grafos, realmente, foram 20%... Este foi o
coment�rio, a sugest�o � a seguinte: que os EPs seguintes ao terceiro n�o
sejam assim, e fiquem mais nos grafos propriamente ditos. Ou, por exemplo,
que se continue a usar este Make, j� que a parte administrativa j� est�
pronta.

J� entendi que a disciplina � um laborat�rio de programa��o, mas grafos s�o
bem mais divertidos que fazer entrada e sa�da em C... Ali�s, n�o resisto a
comentar: o Knuth � um g�nio, etc., e do ponto de vista de algoritmos, n�o
h� o que ningu�m possa dizer (muito menos eu). Mas � um hacker, e quando ele
diz, a respeito daquele maldito gerenciamento de mem�ria, que "the
implementation of this scheme is almost ridiculously easy", tenho vontade de
jogar um grafo na cabe�a dele.

Tudo isto, claro, � s� uma opini�o...

Rubens