Esse conceito é usado para fazer sistemas ECS para jogos. Componentes para entidades são alocados em grandes arrays de dados e usamos uma técnica chamada Sparse Set onde usamos um outro array para indexar os componentes que estão sendo usados. Então em jogo você prevê que vai ter por exemplo no maximo 100 inimigos em uma cena e já aloca componentes suficientes para esses 100 inimigos. Pode parecer desperdicio de memoria, mas adicionar, remover ou ler componentes viam todas operações O(n) que são essenciais em jogos. Isso também facilita para jogos online que precisam fazer rollback e copiar constantemente buffers de dados entre um frame ou outro. Além disso, os dados ficam todos alinhados em memoria o que torna a cpu mais eficiente. O único problema dessa abordagem é que é bem mais complicado de se programar um jogo pois isso exige uso massivo de ponteiros e estruturas como listas dinâmicas ou dicionários são um terror para se implementar.
Sim, o calculo da array do prefix Sum vai ser sempre O(n). Porem, toda vez que for preciso acessar a array original mais de uma vez para calcular a soma dos elementos, usar o valores salvos ja vai ser vantajoso, pq so vai ser preciso acessar o valor e nao calcula-lo
Ótimo vídeo, porem brincadeiras a parte eu vi um Else ali e aprendi que em else você inverte o if, e cria um early return. Foi um cara bem pica que falou isso então eu confio.
Voce aprendeu parcialmente errado. Não existe bala de prata na programação. Inverter a logica do if e usar early return é criar uma guard clause. NEM SEMPRE é isso que você quer. As vezes você realmente quer decidir entre duas e apenas duas coisas que não são necessariamente opostas.
Normalmente você faz early return pra evitar códigos muito grandes indentados Não existe "regra" Eu uso sempre, mas não quer dizer que quem usa tá errado
Esse conceito é usado para fazer sistemas ECS para jogos. Componentes para entidades são alocados em grandes arrays de dados e usamos uma técnica chamada Sparse Set onde usamos um outro array para indexar os componentes que estão sendo usados. Então em jogo você prevê que vai ter por exemplo no maximo 100 inimigos em uma cena e já aloca componentes suficientes para esses 100 inimigos. Pode parecer desperdicio de memoria, mas adicionar, remover ou ler componentes viam todas operações O(n) que são essenciais em jogos. Isso também facilita para jogos online que precisam fazer rollback e copiar constantemente buffers de dados entre um frame ou outro. Além disso, os dados ficam todos alinhados em memoria o que torna a cpu mais eficiente. O único problema dessa abordagem é que é bem mais complicado de se programar um jogo pois isso exige uso massivo de ponteiros e estruturas como listas dinâmicas ou dicionários são um terror para se implementar.
Muito legal o conteúdo! Essa ideia é a de ter uma tabela ou array com as respostas é o paradigma de programação dinâmica, né?
Muito obrigado pelo seu canal, nao pare pf
Não entendo muito, mas não continuaria sendo O(n), já que pra armazenar as somas dos números ta fazendo um for?
Sim mas só pra montar, pra consultar é o(N)
Sim, o calculo da array do prefix Sum vai ser sempre O(n). Porem, toda vez que for preciso acessar a array original mais de uma vez para calcular a soma dos elementos, usar o valores salvos ja vai ser vantajoso, pq so vai ser preciso acessar o valor e nao calcula-lo
Pra montar é O(N). Pra consultar com prefix-sum será O(1)
bom demais seus videos!!!
qual app/site você usa para fazer as anotações? vídeo muito bom, como sempre!
A fonte lembra bastante o excalidraw
@@aquijazumcanal9863 valeuu!
Muito bom, vídeo!
Como você consegue pensar e saber disso, as vezes demora pra conseguir pensar em otimização ou é repido?
Qual o nome da aplicação que usa para mostrar a webcam?
Ótimo vídeo, porem brincadeiras a parte eu vi um Else ali e aprendi que em else você inverte o if, e cria um early return. Foi um cara bem pica que falou isso então eu confio.
Voce aprendeu parcialmente errado. Não existe bala de prata na programação. Inverter a logica do if e usar early return é criar uma guard clause. NEM SEMPRE é isso que você quer. As vezes você realmente quer decidir entre duas e apenas duas coisas que não são necessariamente opostas.
Normalmente você faz early return pra evitar códigos muito grandes indentados
Não existe "regra"
Eu uso sempre, mas não quer dizer que quem usa tá errado