Hacker News 의견

• Monte-Carlo 방법의 빠른 무시는 큰 실수임

  • Monte-Carlo 방법은 정확성과 속도를 교환할 수 있는 점이 특징임
  • 알고리즘을 오래 실행할수록 더 정확해짐
  • 반대로 빠르게 부정확한 결과를 얻을 수도 있음
  • 모든 경로를 탐색하는 대신 무작위로 선택된 하나의 경로만 탐색함
  • 알고리즘의 가장 중첩된 루프에 Monte-Carlo를 사용하면 효과적임
  • 예를 들어, 신경망을 학습할 때 외부 루프는 신경망 매개변수를 업데이트하고 내부 루프는 그래프를 통해 경로를 계산함
  • Monte-Carlo를 사용하면 내부 루프의 정확성을 1회 반복으로 줄일 수 있음
  • 이는 직관적으로 항상 올바른 결정을 내리는 정책을 구축할 수 있게 함
  • 체스나 바둑에서 Monte-Carlo 트리 탐색 변형을 사용하여 최적의 경로를 계산할 수 있음

• "자동 라우터를 믿지 마라"는 입장에 있음

  • eCAD 분야에서 레이아웃 속도를 높일 수 있는 큰 기회가 있음
  • 전체 자동화 도구보다는 공동 창작 도구를 사용할 가능성이 높음
  • 설계 시작 시 배치가 설정되지 않아 라우팅에 큰 영향을 미침
  • 페이지에서 배치가 알고리즘의 일부인지 확인하지 못함
  • JavaScript로 작성된 AR에 대한 계획이 궁금함

• 기사는 시각화와 캐시 효과에 대한 중요한 점을 언급함

  • 재귀 알고리즘은 깊이 우선 탐색임
  • DFS와 BFS는 반복적이거나 재귀적으로 작성될 수 있음
  • A*는 경로 탐색에 유용함
  • BFS는 모든 인접 노드를 탐색하고 A*는 목적지에 가까운 노드를 우선 탐색함
  • A*는 동적 알고리즘으로, 최단 경로를 자신 있게 조기에 종료할 수 있음

• 자동 라우팅에 대한 훌륭한 논의임

  • 라우팅 자체는 쉬움
  • 새로운 것을 맞추기 위해 이미 라우팅된 것을 제거해야 할 때 복잡해짐
  • KiCAD의 자동 라우터가 그리움

• 95%의 초점은 반복 횟수를 줄이는 데 있어야 함

  • 성능이 여전히 중요하다면 저수준 언어로 다시 작성해야 함
  • numpy, pandas, OpenCV, TensorFlow는 고성능 C++/어셈블리/CUDA로 구현됨

• QuadTree와 일반적인 트리 데이터 구조는 매우 느림

  • 트리는 데이터의 정보 표현이 아님
  • 해싱 접근법은 점이 고르게 분포된 경우에만 적합함
  • 무작위 알고리즘은 검색 공간이 매우 큰 경우 유용함

• 거의 모든 것이 게임 개발의 휴리스틱과 일치함

  • A*, Lee의 알고리즘 등은 모두 멋짐
  • 시각화 없이 플러드필을 작성하는 것은 범죄임
  • 공간 해싱은 특히 경험과 일치함

• "공간 해시 인덱싱 > 트리 데이터 구조"는 이 도메인에서는 좋지만 전 세계적으로 진리로 받아들여져서는 안 됨

  • 포인트가 고르게 분포되지 않은 경우 해시 함수가 나쁠 수 있음

• 대학에서 배운 키워드를 기억함

  • fancy한 알고리즘을 사용할 기회가 없음
  • 대신 UI 구성 요소와 REST API를 구축함

• 2D/3D 공간 문제에 직접적으로 관여하지 않는 사람으로서 시각화의 가치가 가장 큰 교훈임

  • 인간은 그림을 이해하고 분석하는 데 뛰어남
  • 문제의 형태를 이해하기 위해 확률적 또는 무차별 방법을 사용하는 아이디어가 중요함