Dúvidas e discussões sobre o projeto 1.
Fórum: Programação Multiparadigma
Projeto 1
- Na definição circular e directa da matrix temos de usar a 1a linha e depois definir apartir dai ou temos também que definir a 1a linha da forma directa e circular?
Se nada mais fosse dito, em rigor a primeira linha também teria de ser gerada das duas formas diferentes, em cada um dos casos.
Mas eu só estou interessado na geração das sucessivas linhas. Por isso a forma como a primeira linha é gerada não importa. Não vale mesmo a pena o esforço de gerar a 1ª linha de duas formas diferentes.
- É considerada definição circular se aplicar um map à estrutura que estou a definir e a função que passo é a que constrói a linha seguinte a essa?
Uma definição circular duma entidade X é uma definição que usa efetivamente X para definir o próprio X. Tudo o que se enquadre nisto é circular e está tudo dito.
Uma vez que só e possivel adicionar ou multiplicar matrizes com mesmos nº de colunas e nº de linhas, pergunto se temos de preparar as operações para a eventualidade de receberem como argumentos 2 matrizes que não reunam as condiçoes enunciadas.
Adicionei ao enunciado um esclarecimento. Ver o Changelog do enunciado.
Bom dia, professor.
No que toca à definição revista do find, que considera que se deve também funcionar com matrizes finitas, mantém-se a frase:
"if z does not occur in the matrix, then the method will fail to return a result" ?
No caso de uma matriz ser finita, é possível retornar um valor inválido, do tipo (-2,-2), para indicar que de facto não foi encontrada uma solução. Ou é preferível que o comportamento da função seja igual para os dois casos, isto é, entre em ciclo e não consiga devolver nenhum resultado, tal como está na especificação?
Obrigado.
Não existe nenhuma penalização em usar métodos do scala para definir os nossos metodos ou constantes ?
Pelo contrário. Na aula teórica 04 está escrito: "IMPORTANT: You must get used to the high-order methods an use them in our programs as much as possible". Se ficar mais simples usando as funções de biblioteca (como geralmente fica) e isso não for feito, é melhor apresentar dar uma razão em comentário: por exemplo, a solução ficar com complexidade temporal pior (por exemplo ficar exponencial ou quadratica em vez de linear).
Boa tarde, professor,
Devemos considerar que os elementos das matrizes têm os índices a começar em 1 (isto é, o 1º elemento de uma matriz A é o elemento a1,1), como é habitual em Matemática, ou 0?
Olhando para o enunciado da conversão/função make, parece-me implícito que a indexação começa em 0, mas está omisso no resto do enunciado e achei melhor confirmar.
Obrigado pela atenção.
Como fazer um find que também funcione para o caso finito?
Quando me falaram que havia uma certa ambiguidade do enunciado relativamente ao caso finito (permitido pela estrutura de dados Matrix), percebi que a função 'find' iria ficar mais desafiante. Decidi que uma versão elegante do find que funcione só para o caso infinito teria pelo menos 70% da cotação do find.
Posso dizer que a minha solução para o problema geral (finito + infinito) tem 4 linhas, incluindo esta linha que define uma função auxiliar:
def defined(m: Matrix, i: Int, j: Int) = m.isDefinedAt(i) && m(i).isDefinedAt(j)
O que vais ser mais valorizado, eficiência ou elegância?
Deve ter reparado que na mensagem anterior eu coloquei eficiência entre parêntesis...
Na ausência de requisitos especiais, a legibilidade é sempre o critério número 1. Só perante duas solução igualmente legíveis se usa a complexidade para desempatar.
Mas, e se a tal solução muito legível for exponencial ou cúbica, o que fazer? Nesse caso vale a pena fazer um grande esforço por encontrar um solução com menor complexidade.
E se a solução legível for apenas quadrática? Então depende: Se existir outra solução bastante simples, mesmo à mão, de complexidade inferior, então não há desculpa para não a usar. Mas se a melhor solução de complexidade inferior for muito complicada, estamos numa zona cinzenta e nesse aceito as duas em pé de igualdade, desde que a solução complicada venha com uma justificação.
De qualquer forma, os algoritmos sobre Streams tendem a ter complexidade inferior comparando com os mesmos algoritmos sobre Lists, em virtude da avaliação lazy.