Warrior

Consegues resolver em O(m+n) com uma árvore de sufixos (suffix tree). Julgo que também deve ser possível com o vector de sufixos (suffix array), mas tinha que pensar melhor. Se calhar tens que meter um log(m) aí no meio.

Exacto. Qual seria a resposta para [1,2,3,7,11]? E porquê?

A dificuldade deste problema está em identificares exactamente o que pretendes, não está na implementação. Consegues descrever aquilo que achas que o algoritmo deve fazer em texto? Ou seja, naquele exemplo (([16, 15, 23, 24, 28, 23, 29, 45, 12, 67], 3)), porque motivo é que pretendes dividir entre o 16 e o 23 e entre o 29 e o 45? Porque não outros dois locais? Repara que existem várias respostas possíveis perfeitamente razoáveis, mas isso é algo que só tu podes responder. Por exemplo, suponho que ([1, 2, 3, 7, 9], 2) deve ser particionado em [1,2,3] e [7,9]. E se o vector inicial for [1, 2, 3, 7, 100]? Provavelmente [1, 2, 3, 7] e [100]. E se for [1, 2, 3, 7, 15]? Onde é que "traças a linha"? Porquê? Sem conseguires explicar para ti próprio o que deve o algoritmo fazer nestes casos, não o vais conseguir implementar.

Qual é o problema exactamente? Dados N números agrupá-los em K conjuntos? Porque motivo é referida uma matriz no "enunciado"?

Óptimo! Deixa o código completo se quiseres comentários.

Vais ter que usar as duas coisas, arrays e funções 🙂. O teu objectivo é encontrar um algoritmo que resolva o problema. O problema do caixeiro viajante é NP-hard, o que significa que (em alguns casos) só tentando todas as soluções possíveis é que consegues descobrir qual o caminho mais curto. De que forma é que podes tentar todas as soluções possíveis? Pensa em algo recursivo. Pela forma como colocas as questões e a linguagem que usas, temo que o problema seja um pouco puxado para o teu nível actual. Vais ter que te aplicar.

Podes ser mais claro na tua dúvida?

O facto do spam existir não prova a existência de lobbying, isso é uma falácia argumentativa. Investi parte do meu tempo a explicar o motivo de não arranjares ninguém disposto a desenvolver: porque a ideia tem falhas graves. Não tenho tempo para ler a patente, até porque sei por experiência própria que são documentos difíceis de compreender devido ao legalês necessário. Se conseguires perceber o motivo da tua ideia não funcionar, então podes poupar tempo no futuro. Se pretendes ignorar os seus problemas, então boa sorte, mas um inventor ou empreendedor devia ser o maior crítico, nunca o maior defensor.

Mas isto já foi feito. Acontece que desistindo da backwards compatibility com o email, deixas de lhe chamar email. Passas a chamar snapchat, ou hangouts, ou whatsapp, ou telegram, ou qualquer uma de outras aplicações que alteraram a stack e desistiram de ser compatíveis com o email. Esse caminho já foi trilhado variadíssimas vezes, e na minha opinião é o que vai acontecer a médio prazo. Lobies a favor do spam? Longe disso, nem quem faz software nem que gere a rede tem interesse em defender o spam. Voltamos ao problema que levantei: se vai ser backwards compatible com email, então de que maneira resolves o problema do spam? O spam pode ignorar o protocolo novo.

redinpais: acho que não estás a compreender o impacto dos problemas que já foram identificados e que a postura na discussão é demasiado defensiva. Os comentários do Rui Carlos foram bastante detalhados e valem ouro; numa situação normal seria necessário pagar por uma análise deste género. Eu vou sumarizar em dois pontos simples qual o motivo de uma abordagem deste género estar condenada ao fracasso: A solução não é uma alternativa ao email. Neste momento já existem soluções alternativas onde o spam é nulo, portanto esta solução não tem qualquer interesse se assumirmos uma stack tecnológica toda nova. A solução não funciona como complemento ao email. Uma pergunta simples: o que faz a caixa de entrada se uma mensagem não obedecer ao protocolo? Ou a mostra tal como agora, de modo que não impede spam. Basta quem envia o spam ignorar as mudanças. Não a mostra, pelo que obriga todos os remetentes a obedecer ao protocolo. Se vamos obrigar os remetentes a fazer algo diferente, então mais vale criar uma alternativa decente de raiz em vez de um "patch" ao email actual. Sem ser possível resolver este problema de base, não existe nenhuma possibilidade desta solução ver a luz do dia.

Isto já existe.

Concordo com muito do que disseste, mas há um passo grande entre não ser preso e ser presenteado com um contrato. Ética e um comportamento moral acima do irrepreensível é uma exigência para este tipo de funções, algo que claramente não possui. A última coisa que precisamos é de recompensar este tipo de ataques.

Só há uma forma correcta de o fazer: guardar tempos universais, mostrar tempos locais. Qualquer outra solução é uma dor de cabeça monumental.

As baterias estão bastante melhores, mas há não muito tempo duravam 1 ano ou 2. Quantas pessoas trocam de telemóvel somente por não poderem trocar de bateria? Não espero trocar a correia de distribuição ao final de 1 ano ou 2. Onde é que se traça a linha entre manutenção e reparação? Podemos considerar como manutenção todas as reparações habituais?