Hacker News 의견들
  • 작성자로서 말하자면, 바깥쪽 반올림은 정밀도 문제 대응으로 interval arithmetic에서 가장 유명하지만, 내 생각엔 그것만 주목받는 게 아쉬움. 연구 논문에서 말하는 포함 성질은 모든 스케일에서 작동하고, 그래서 50 * (10 + [-1, 1]) = [450, 550] 같은 결과가 자연스럽게 나옴. 여기에 union 레이어를 얹으면 제곱 함수의 진짜 역함수 같은 것도 다룰 수 있고, sqrt가 아니라 sqinv(64)를 해보면 느낌이 옴. 사실 이 interval calculator는 다른 프로젝트인 backwards updating spreadsheet를 위해 만들던 interval union arithmetic 구현을 시험하려고 만든 것이었음. 구현체는 not-so-float, 관련 프로젝트는 bidicalcHN 토론에 있음
    • 구현한 arithmetic이 IEEE 1788 표준과 어떻게 다른지 궁금함. 링크한 두 논문이 그 표준과 어떤 관계인지도 알고 싶음. 글에서 언급한 문제들을 해결하려면 완전히 새로 시작해야 했는지, 아니면 IEEE 표준 위에 쌓아 올릴 수 있었는지도 궁금함
    • 정말 멋져서 더 만져볼 생각임. 두 가지가 특히 궁금한데, 첫째로 다가 함수를 추가하기 얼마나 어려운지 궁금함. 예를 들어 asin(1)에서 Mathematica 없이도 [pi/2, pi/2] + n[2pi, 2pi] 전체 집합을 얻을 수 있으면 아주 좋겠음. 둘째로 사용자 입력 숫자를 해석하는 설명 문구가 좀 헷갈렸음. 내가 보기엔 입력값을 포함하는 가장 작은 구간의 출력 경계값이 입력값을 감싸는 가장 가까운 두 IEEE 754 수여야 할 것 같은데, 지금 문장대로면 IEEE754(input)+[-epsilon, epsilon]처럼 읽혀서 의미가 다르게 느껴졌음
  • 이거 정말 좋음. Matt Keeter의 implicit surfaces 작업과 interval math를 이용한 최적화도 흥미롭게 볼 만함. 이 발표에서 관련 내용을 확인할 수 있음
  • 나도 interval arithmetic로 만든 그래핑 계산기가 있어서 관심 있을 것 같음. 직접 써볼 수 있는 formulagraph가 있고, 동작 방식과 관련 코드 설명은 이 글에 정리해뒀음
    • 첫인상이 GrafEq와 비슷하게 느껴졌음. 옛날 GrafEq가 떠오름
  • 나도 이게 재미있어서 Raku로 간단한 Math::Interval 라이브러리를 써본 적 있음. raku-Math-Interval인데, Raku의 내장 Junction과 Range 클래스를 바탕으로 만든 실험이었고 꽤 흥미로운 경험이었음
  • 아주 좋고 공유해줘서 고마움. interval에서 상한·하한 포함 여부를 표시해주면 더 좋겠다는 생각임. 내가 익숙한 표기법은 값이 포함되지 않을 때 바깥을 향한 괄호를 쓰고, 무한대에도 항상 그렇게 적용함. 예를 들면 ]-∞, -1] U [0.5, +∞[처럼 쓰고, 중간의 제외 구간은 ]-1, 0.5[가 됨. 내가 이해한 바로는 min과 max도 이런 식으로 해석되는 것 같음. 그리고 결과 영역의 수식을 클릭하거나 탭하면 입력창으로 복사되는 UI 아이디어도 있으면 편할 것 같음
    • 링크된 논문을 읽어보니 여기서는 닫힌 구간만 설명하고 있었음. interval union은 닫혀 있고 서로 분리된 구간들의 집합이며, 양 끝 extreme interval의 경계만 ±∞가 될 수 있다고 정의되어 있었음
    • 그런 표기를 지원하는 건 가능하겠지만 코드가 훨씬 복잡해짐. 그래서 아주 이른 시점에 지원하지 않기로 결정했음. 그래도 멋진 추가 기능이 될 수는 있음
    • 나도 이 부분이 조금 헷갈렸음. 내가 알던 표준 표기법은 둥근 괄호였는데, 아마 ASCII 환경에서는 잘 안 맞을 수도 있겠다는 생각이 들었음
  • 아주 멋짐. 모든 연산을 완전히 이해한 건 아니지만, 이해한 부분만으로도 꽤 인상적이었음. 수업에서 구간에 대한 산술을 좀 더 일찍 접했으면 좋았겠다는 생각이 듦. 기초 통계의 신뢰구간이나 이차방정식의 ±처럼 이미 비슷한 개념이 나오는데, 결과를 하나의 데이터처럼 이어서 계산하지 못하고 매번 ±의 두 값을 따로 처리하는 게 늘 좀 아쉬웠음. 물론 교사는 응용으로 빨리 돌아가고 싶어 하니 깊게 다루지 않는 이유는 이해함. 그래도 이런 대상에도 일반적인 산술이 가능하다는 힌트 정도는 있었으면 좋았겠음. 지금 보여준 건 그보다 훨씬 더 나아간 형태지만, interval을 자체적인 동작을 가진 데이터로 보는 관점이 말이 된다는 검증처럼 느껴졌음
  • 예전에 Clojure로 시간 구간 라이브러리 tick을 처음 쓸 때 interval arithmetic를 알았더라면 좋았겠다는 생각임. 이 라이브러리에는 Allen's Interval Algebra 구현도 들어가 있고, 실무 계산에 유용한 이산 구간 집합 개념도 받아들였음. 예를 들어 어떤 해에 속하는 휴가 구간 집합을 계산하는 HR 업무 같은 데 잘 맞음. 나는 Allen의 작업 정도만 알고 있다가 이런 집합이 주는 장점을 우연히 발견한 셈이었음. 코드는 juxt/tick에 있음
  • 이 도구의 쓸모는 충분히 보이지만, 개인적으로는 확률적 계산기가 더 유용할 것 같다는 생각임. 예를 들어 1 / [-1, 2] 같은 결과는 어떤 값이 얼마나 그럴듯한지 알려주지 않고, 입력이 균등하다고 가정해도 출력은 분명 균등분포가 아닐 것 같음
  • 나도 최근에 비슷한 걸 구현했는데, 관점은 집합 소속성 쪽이었음. 그래서 interval membership에 대한 완전한 Boolean 분석을 하려면 여집합 연산이 필요했음. 여기 구간들은 모두 닫힌 집합이라 여집합은 열린 구간이 되는데, 내 용도에서는 끝점 포함 여부가 중요하지 않아서 열린 구간과 닫힌 구간을 굳이 구분하지 않았음. 게다가 부정확한 산술에서는 집합이 열린지 닫힌지 자체가 잘 정의되지 않을 수도 있다고 봄
  • union of intervals로 논리를 확장한 건 멋져 보이지만, 복잡도가 궁금함. 어떤 연산 하나가 구간 두 개를 만들 수 있게 되면, N번 연산 시 경우에 따라 지수적 증가가 생길 것 같음. 그러면 일정 개수 이상에서 근사를 도입하지 않는 한 abstract interpretation 같은 흔한 활용에는 비현실적일 수 있겠다는 걱정임
    • 맞는 지적이고, 이런 문제는 abstract interpretation 쪽에서 잘 알려져 있음. 말한 것처럼 보통은 객체 크기에 cap을 두고 한도를 넘으면 구간들을 합쳐버리는 방식을 씀. 다만 적어도 abstract interpretation에서는 interval보다 더 정교한 도메인을 쓰는 경우도 많은 것 같음