Julia: 제프 베잔슨 박사

이 미해결 문제에 관심이 있는 cc @fperez

첨부된 지원 정보입니다.

절차상의 문제로 이것을 닫으려면 별도의 저장소에서 작업해야 할 수 있습니다. 다른 사람들이 더 쉽게 기여할 수 있도록 논문을 Base에 포함해야 합니다.

또한 마지막 작업의 순서는 오해의 소지가 있습니다. 실제로 프로세스 전반에 걸쳐 자주 반복됩니다.

Base에 포함하거나 적어도 julia/doc/thesis 에 포함하면 +1입니다. 또는 향후 요구 사항을 고려하여 theses 수 있습니다.

(제프, 논문 분기를 열어주세요.)

또한 마지막 작업의 순서는 오해의 소지가 있습니다. 실제로 프로세스 전반에 걸쳐 자주 반복됩니다.

*또한 이미 재발했습니다.

저는 _Close issue_ 행사에 참석하기를 고대하고 있습니다.

이 문제를 로컬에서 재현할 수 없습니다. MIT 전용인가요?

Julia의 핵심 저자 중 한 명인 @JeffBezanson 은 문제가 있는 개발자 학자가 되었습니다.

이것은 PHD 논문의 github 버전입니까? Jeff는 제안서로 PR을 시작해야 하고 위원회에서 합병 여부를 결정합니다...

+이것의 빠른 해결을 위한 정보!

몇 달 전에 IPython repo에서 동일한 문제가 발생했으며 32일 전에 해결되었기를 바랍니다.
나는 그것이 커피, 성가신 서류 작업 및 착암기로 인한 마지막 순간의 계획 변경과 관련이 있다고 확신합니다.

행운을 빕니다 !

업데이트됨: Jeff는 논문 위원회를 만나 대략적인 개요를 제공했습니다.

진행되고 있다는 소식을 듣게 되어 기쁩니다!

그러나 git log --date=short --all --since=22.days.ago --author="Jeff Bezanson" 는 여전히 그가 논문을 작성할 시간이 있는지 궁금하게 만듭니다. 그게 아니면 그는 슈퍼히어로입니다. 사실, 긁적입니다. 우리 모두는 그가 슈퍼히어로라는 것을 알고 있으므로 신경쓰지 마십시오.

juliatypes.jl과 관련된 커밋은 논문 작업과 직접적인 관련이 있는 Julia의 유형 시스템을 설명하려는 시도를 기록합니다.

유형 시스템 작업은 이미 일부 신경을 건드리는 것 같습니다: https://twitter.com/plt_hulk/status/535045242920378369

내가 틀릴 수도 있지만 Jeff의 작업에 대한 직접적인 응답인지 의심스럽습니다. 어쨌든 재미있는 트윗.

@jiahao , 제 댓글은 대부분 혀를 내두를 정도였습니다 --- 저는 바로 그 부분이 궁금했습니다. 예를 들어, 저는 프레젠테이션을 위해 무언가를 다듬을 때 커밋을 많이 하는 경향이 있습니다.

@timholy 유머가 언급되었습니다. :)

우리 지역 이론 협력자 인 @jeanqasaur 가 트위터에 게시한 아름다운 Magritte 경의 를 언급하지 않는 것은 태만한 일이 될 것입니다.

"유형의 배신"에는 멋진 반지가 있습니다. 그렇죠?

정말 재미있네요.

사랑해!

도움 요청: Jeff는 다중 디스패치(및 아마도 단계적 기능)를 보여주는 좋은 예를 찾고 있습니다. 이러한 기능이 없는 언어에서는 훨씬 더 어렵거나 느릴 것입니다.

는, show ?

(그리고 아마도 단계적 기능)

subarray.jl 및 subarray2.jl 는 꽤 훌륭하게 제공되어야 합니다. 디자인 문서는 http://docs.julialang.org/en/latest/devdocs/subarrays/ 에 있습니다.

나는 Distributions 패키지가 정말로 다중 디스패치를 ​​유용하게 보이게 한다고 생각합니다. rand(Gamma(1, 1), 5, 5) 대 rand(Normal(0, 1), 3) 와 같은 것이 있으면 다중 디스패치로 인해 성능 비용 없이 표현력이 크게 향상됩니다.

나는 그것이 실제로 과시하기 때문에 그것이 가장 좋은 예라는 것을 알지 못합니다.
단일 디스패치. 당신이 가지고 있는 Gamma(1,1).rand(5,5) 와 어떻게 다릅니까?
Python이나 Java와 같은 보다 전통적인 OO 언어로 할 것인가?

2014년 12월 19일 금요일 오후 1시 39분, John Myles White 알림 @github.com
썼다:

나는 Distributions 패키지가 실제로 여러 디스패치를 ​​보이게 한다고 생각합니다.
유용한. rand(Gamma(1, 1), 5, 5) 대 rand(Normal(0, 1),
3) 다음으로 인해 성능 비용 없이 표현력이 크게 향상됩니다.
다중 파견.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67678367.

확인. kl(Normal(0, 1), Normal(0, 1)) vs kl(Normal(0, 1), Gamma(1, 1)) $ 와 같은 분석 결과를 사용하여 KL-divergence를 계산하는 예제로 대체하십시오.

나는 또한 추가했어야 했다. #8235의 내 초기 게시물에서 인생이 _없는_ 준비된 함수와 같을 것이라는 잠재적으로 유용한 통계가 있었습니다. 테이크 홈 메시지: 차원 8을 통해 모든 메서드를 생성하면 5000개 이상의 개별 메서드가 생성되고 4분 이상의 구문 분석 및 감소 시간이 필요합니다(즉, julia를 컴파일하는 동안 4분 지연). 그에 비해 stagedfunction 구현은 순식간에 로드되며 물론 8차원을 넘어설 수도 있습니다.

단일 디스패치와 비교하여 여전히 다른 OO 언어가 설명하는 기능 대 메서드의 통합을 보여줍니다. 파이썬의 sorted(a) 대 a.sort()와 대조할 수 있습니다. "전통적인" 객체지향 언어와 비교할 때, 그것은 함수가 클래스와 "연관"된다는 의미를 극적으로 바꿉니다.

인스턴스 또는 유형에 대해 디스패치할 수 있으므로 정적 대 인스턴스 변수의 필요성을 대체하는 방법을 지적할 수 있습니다. 컴퓨터를 사용할 수 있게 되면 최근 IRC 대화에서 아이디어를 더 얻을 수 있을 것입니다.

fmap 의 구현이 있습니다. 이것은 여러 배열을 순회하고
각 요소 집합에 기능을 적용합니다. 이 구현은 실제로
배열 수가 임의적일 수 있으므로 매우 느립니다. 이를 유용하게 사용하려면
다양한 수에 대해 이 전문화를 수동으로 만들었습니다.
인수 yss . 나는 항상 이것을 위해 단계적 함수를 작성하고 싶었습니다.
하지만 아직 하지 않았습니다.

준비된 함수는 특히 map 호출을 평가해야 합니다.
f 에 대한 인수를 생성합니다.

-에릭

function fmap{T,D}(f::Function, xs::Array{T,D}, yss::Array...;
                   R::Type=eltype(f))
    [<strong i="18">@assert</strong> size(ys) == size(xs) for ys in yss]
    rs = similar(xs, R)
    <strong i="19">@simd</strong> for i in 1:length(xs)
        <strong i="20">@inbounds</strong> rs[i] = f(xs[i], map(ys->ys[i], yss)...)
    end
    rs::Array{R,D}
end

2014년 12월 19일 금요일 오후 12시 46분, Steven G. Johnson <
[email protected]>은 다음과 같이 썼습니다.

도움 요청: Jeff는 여러 가지를 보여주는 좋은 예를 찾고 있습니다.
디스패치(및 아마도 단계적 기능),
해당 기능이 없는 언어에서는 더 어렵거나 더 느립니다.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67671331.

에릭 슈 네터 [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

죄송합니다. 내 코드의 함수 서명에서 eltype(f) 에 대한 호출을 무시하십시오.
그것은 비표준입니다.

-에릭

2014년 12월 19일(금) 오후 3시 88분, Erik Schnetter [email protected]
썼다:

fmap 구현했습니다. 이것은 여러 배열을 순회하고
각 요소 집합에 기능을 적용합니다. 이 구현은 실제로
배열 수가 임의적일 수 있으므로 매우 느립니다. 이를 유용하게 사용하려면
다양한 수에 대해 이 전문화를 수동으로 만들었습니다.
인수 yss . 나는 항상 이것을 위해 단계적 함수를 작성하고 싶었습니다.
하지만 아직 하지 않았습니다.

준비된 함수는 특히 map 호출을 평가해야 합니다.
f 에 대한 인수를 생성합니다.

-에릭

function fmap{T,D}(f::Function, xs::Array{T,D}, yss::Array...;
                   R::Type=eltype(f))
    [<strong i="26">@assert</strong> size(ys) == size(xs) for ys in yss]
    rs = similar(xs, R)
    <strong i="27">@simd</strong> for i in 1:length(xs)
        <strong i="28">@inbounds</strong> rs[i] = f(xs[i], map(ys->ys[i], yss)...)
    end
    rs::Array{R,D}
end

2014년 12월 19일 금요일 오후 12시 46분, Steven G. Johnson <
[email protected]>은 다음과 같이 썼습니다.

도움 요청: Jeff는 여러 가지를 보여주는 좋은 예를 찾고 있습니다.
디스패치(및 아마도 단계적 기능),
해당 기능이 없는 언어에서는 더 어렵거나 더 느립니다.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67671331.

에릭 슈 네터 [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

에릭 슈 네터 [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

@timholy , Matlab과 NumPy에도 하위 배열/슬라이스가 있기 때문에 여기서 다중 디스패치가 필수적이라고 주장할 수 있는 이유는 무엇입니까?

구현 용이성? 내가 말할 수 있는 한 모든 언어로 다중 디스패치를 ​​시뮬레이션할 수 있으므로 어떤 것에도 필수적인 것은 아닙니다.

아직 결정하지 않은 것을 제안하는 것은 좋지 않을 수 있습니다. https://github.com/JuliaLang/julia/issues/9297 에는 효율적인 UTF-8 버퍼 위치와 구멍 없는 편리한 인덱싱을 모두 허용하여 원할 때 편리한 산술 연산을 수행할 수 있도록 하는 제안이 있습니다. Regex 및 검색은 래핑된 내부 인덱스를 반환하지만 s[2] 는 첫 번째 인코딩에 사용된 바이트 수에 관계없이 두 번째 문자를 제공할 수 있습니다.

AbstractArrays 의 효율적인 하위 배열/슬라이스를 만들 수 있습니까? 아니면 해당 구현이 인접한 메모리 블록에 대해서만 작동합니까? 부모 배열에 연속 메모리가 있다고 가정할 수 있다면 이것은 해결하기 매우 어려운 문제가 아닙니다. 그런 가정을 하지 않을 때 더 흥미로워집니다.

예, 이것이 우리가 찾고 있는 핵심 기능입니다. 다중 디스패치 및/또는 단계적 기능으로 무언가를 훌륭하게 수행할 수 있을 뿐만 아니라 다른 언어에 이러한 기능이 없으면 기능 구현이 훨씬 더 어려워집니다(이상적으로는 아무도 시도하지 않은 것보다 더 어렵습니다).

@timholy , NumPy 배열은 각 차원에 대해 고정된 보폭으로 특징지어지며 반드시 연속성은 아닙니다(본질적으로 DenseArray 와 동일). 이 속성은 슬라이싱 시 유지되므로 슬라이스 자체를 슬라이싱할 수 있습니다.

aberrant는 이러한 라인을 따라 IRC에 대해 몇 가지 좋은 질문을 했습니다. 나는 아래에서 관련 없는 댓글(관련 없는 대화 및 알림 중에서)만 추출하려고 했습니다.

2014-12-10 (EST)
11:41 aberrant: “Organizing methods into function objects rather than having named bags of methods “inside” each object ends up being a highly beneficial aspect of the language design.”
11:41 aberrant: why?
12:20 Travisty: aberrant: I can’t speak for them, but I imagine that the argument is that it’s a nice separation of concerns. I have data (which I will represent with types) and routines for operating on that data (which I will represent as functions), and rather than having some routines belong to specific types, they are kept separate
12:21 aberrant: Travisty: I sort of understand the argument, but I’m not sure I agree with it :)
12:22 Travisty: aberrant: Yeah, sure. This is the sort of thing that may be hard to argue about from first principles, and it may be useful to look at examples. I think one place where this design simplified things was in impementing the standard mathematical functions on all of the numeric types, and dealing with conversion
12:22 Travisty: I’m not sure, but I think the solution in julia is quite elegant because of this design and it would be a bit trickier to do it in the traditional OOP setting
12:23 aberrant: Travisty: perhaps. I need to think about it some more. I really like pure OO, and this is a bit of a change that I need to wrap my head around.
...
12:54 vtjnash: julia has a convention that a method name will end in a ! to signify that the method will mutate one of it's arguments
12:56 aberrant: that’s one thing I sorely miss in python. foo.sort() vs foo.sorted() always confused me.
12:57 vtjnash: except that in python, isn't it sort(foo) vs sorted(foo) ?
12:57 aberrant: it might be :)
12:58 aberrant: no
12:58 aberrant: it’s foo.sort vs sorted(foo)
12:58 vtjnash: ah
12:58 aberrant: foo.sort modifies foo in place.
12:58 aberrant: see?
12:58 aberrant: that’s what I mean.
12:58 vtjnash: well, anyways, that's an unintentional example of why . oriented programming is a pain
12:58 aberrant: sort(foo) vs sort!(foo) makes much more sense.
12:59 vtjnash: python made a reasonable choice there
12:59 vtjnash: and tries to help you remember
12:59 vtjnash: but it still was forced to make some decision

2014-12-14 (EST)
15:25 aberrant: there’s no way to do type constants, I guess?
15:25 aberrant: http://dpaste.com/18AEHBG
15:25 aberrant: like that
15:27 vtjnash: no. that declares a local variable inside the type (can be seen by the constructors and other methods in there)
15:27 vtjnash: instead, define `y(::Foo) = 6`
15:28 aberrant: is that mutable?
15:29 aberrant: hm, yeah, that’s not what I want though.
15:29 aberrant: but I guess I can use it.
15:30 vtjnash: not what you want, or not what other languages do?
15:31 vtjnash: multiple dispatch in julia allows you to collapse 4 or 5 or more different constructs needed by other OO languages into one abstraction
15:33 aberrant: oh, I see how it works.
15:33 aberrant: well, it’s a function and therefore more overhead
15:33 aberrant: basically, I want to set the “bitwidth” of an IPv4 address to be 32, and the “bitwidth” of an IPv6 address to be 128, and then be able to write a function that takes ::IPAddr and uses the appropriate bitwidth.
15:34 aberrant: I can do this with the function, but it seems like overhead to have a function return a constant.
15:35 aberrant: e.g., http://dpaste.com/3RXRCAG
15:36 vtjnash: don't assume that a function has more overhead
15:36 vtjnash: in this case, it would actually have less overhead
15:54 aberrant: wow, ok
15:54 aberrant: I don’t see how, but I’ll take your word for it :)
15:59 vtjnash: inlining
...
18:04 aberrant: there’s no way to associate a constant inside a type?
18:04 aberrant: it would make my life a whole lot easier.
18:04 mlubin: aberrant: t.constant or constant(t) is just a syntax difference
18:04 mlubin: julia uses the latter
18:05 aberrant: mlubin: the issue is that you have to instantiate the type first.
18:05 aberrant: mlubin: I need the equivalent of a class property.
18:05 mlubin: constant(::Type{Int32}) = 10
18:05 mlubin: constant(Int32)
18:05 aberrant: oh. wow.
18:06 Travisty: The only member of Type{T} is T, which is why this works
18:06 mlubin: mind=blown? ;)
18:06 aberrant: yeah
18:06 aberrant: that’s jacked up
18:07 aberrant: there’s NO WAY I would have ever thought of that on my own :(
18:07 mlubin: once you see it for the first time it becomes a lot more intuitive
18:07 aberrant: ipaddrwidth(::Type{IPv4}) = uint8(32)
18:08 aberrant: w00t
18:10 aberrant: can I do a const in front of that?
18:11 Travisty: I don’t think so, but usually when julia generates code, it should be inlined so that just the constant uint8(32) appears, instead of a function call

더 많은 예를 찾고 있다면: https://github.com/JuliaLang/julia/pull/7291

순 코드 감소는 6K C++에서 약 1K Julia까지 좋습니다. 초기 성능 벤치마크에 따르면 네이티브 C++의 2배 미만입니다.

연산자(+-*/, Int, Float)에서 숫자 출력 형식에 이르기까지 언어 자체에서 printf의 구현을 주장할 수 있고 libc 버전의 작은 여백 내에서 벤치마킹할 수 있는 언어가 얼마나 되는지 알고 있습니까? 아마도 C++? C는 이것을 주장할 수도 없습니다(연산자 오버로딩이 없습니다).

파이썬/MATLAB/등. 이 중 일부를 주장할 수는 있지만 MATLAB에서 문자열 연산자를 사용해 본 적이 있습니까?

이것은 매우 흥미로운 토론이며 몇 가지 요점을 추가하고 싶습니다.

• 실제로 답변되지 않은 것으로 보이는 것은 Julia가 C++의 다형성과 속도 측면에서 비교하는 방법입니다. C++에서는 템플릿을 통한 정적 다형성 또는 OO를 통한 동적 다형성을 가질 수 있습니다. 그러나 나중에는 vtable이 필요하며 특히 빡빡한 루프에서 이러한 것을 호출할 때 항상 약간 느립니다. 이러한 이유로 배열 액세스 연산자는 빠르지 않기 때문에 절대 과부하되지 않습니다. 예를 들어 Eigen은 정적 다형성을 사용합니다.
• Julia에는 가상 기능과 비가상 기능 사이에 목적지가 없으며 여전히 성능 저하가 없습니다. 내가 이해하는 것은 Julia가 "즉시" 코드를 생성할 수 있으므로 C++ 런타임에서 생성된 코드를 더 이상 수정할 수 없음을 의미하는 빠른 코드를 계속 생성할 수 있다는 것입니다. 또한 Julia에서는 런타임에 인라인을 수행할 수 있습니다. 따라서 함수 호출 오버헤드가 없습니다. Julia에서는 자동으로 수행되기 때문에 이 모든 것에 대해 생각할 필요가 없습니다.
• 한 가지 큰 점은 (다시) 오버헤드가 없고 C++가 가지고 있는 모든 고통이 없는 제네릭입니다(컴파일 시간 보기) 제네릭을 구현하는 방법이 다르고 IMHO Julia는 C#과 동일한 모델을 사용하므로 이것이 완전히 새로운 것은 아닐 수도 있습니다( 제프스 테제). 그러나 여전히 이것은 논문에서 논의할 수 있는 문제라고 생각합니다.

다중 디스패치가 얼마나 효과적인지 설명하기가 얼마나 어려운지 자체가 상당히 흥미롭습니다.

이제 같은 페이지에 있게 되어 기쁩니다. 예, 우리의 새로운 하위 배열은 보폭에 의존하지 않으며 선형 인덱싱이 필요하지도 않습니다(비록 사용할 수 있고 효율적인 경우 기본적으로 수행함). 따라서 모든 AbstractArray에 대해 효율적으로 작동하고 "비스트라이드"( Vector{Int} 인덱스) 보기도 지원합니다.

명확히 하기 위해 저는 주로 다중 디스패치가 아닌 단계적 기능의 예로 새로운 SubArray를 제시했습니다. 즉, 현재 체계는 다중 디스패치 없이 구성 단계에서 무너질 것입니다. slice(::AbstractArray, ::UnitRange{Int}, ::Int, ::Vector{Int}) 및 slice(::AbstractArray, ::Int, ::UnitRange{Int}, ::UnitRange{Int}) 등에 대해 완전히 다른 생성자 메서드를 호출합니다. 이러한 생성자는 단계적 함수에 의해 생성되지만 우리는 시스템이 작동하려면 여러 디스패치가 필요합니다.

별도의 함수가 없으면 varargs 생성자는 인덱스 튜플의 항목을 반복하는 것이 유형이 안정적이지 않다는 사실에 직면해야 합니다. 루프에서 개별 인덱스를 처리하려면 명명된 스칼라 변수에 할당해야 하며 해당 변수는 입력 튜플이 가능하더라도 잘 입력되지 않는 것이 보장됩니다. 물론, staged 함수는 훨씬 더 많은 일을 합니다. 거의 모든 "어려운" 결정은 이것을 슬라이스 차원으로 삭제할 것인지 아니면 유지할 것인지, 그리고 객체의 내부 표현에 대한 결과는 무엇입니까? ---컴파일 타임에 만들어 런타임 생성자를 매우 사소한 작업으로 줄일 수 있습니다. 입력 유형의 각 조합에 대해 특정 사소한 작업이 다르기 때문에 이 사소한 것을 이용하고 빠르게 구성하려면 입력 유형의 각 조합에 대해 사용자 정의된 다른 메소드를 호출해야 합니다. 이것이 단계적 기능과 다중 디스패치 모두가 필요한 이유입니다.

개인적으로, 나는 우리가 했던 일을 단계적 기능과 다중 디스패치의 조합 없이 수행할 수 있을지, 그리고 julia가 이제 모든 언어 중 가장 유연하고 효율적인 배열 보기를 갖게 되었는지 의심스럽습니다. 그러나 나는 이 문제에 대해 어떤 종류의 실제 연구를 수행한 척하지 않습니다.

이것은 출판을 위해 SubArray를 작성해야 하는지 궁금하게 만듭니다. ---여기에 새로운 것이 있는 것 같습니다.

@StefanKarpinski : 자기 비판적이어야 합니다. 어쩌면 아직 작성하지 않았을 수도 있습니다.

@timholy 저는 실제로 여기에서 두 가지를 볼 수 있습니다. 단계적 기능(완전히 이해하지 못했다는 점을 인정해야 함)과 Julia가 C++ 가상 기능 대 템플릿 유니버스(여기서 C# 및 Java와 유사함)에 적합한 방법입니다.

C++ 비교를 위해 타이밍을 수행하고 컴파일 시간 다형성에 도달할 수 있다는 것을 실험적으로 증명하는 것은 매우 흥미로울 것입니다.

내가 한동안 공식화하고 싶었던 또 다른 것은 Julia가 C++ 개념(라이트)과 관련하여 C++와 어떻게 비교되는지입니다. 우리가 가지고 있는 하위 유형은 C++ 개념의 큰 부분입니다.

이것을 확인하기 위해 많은 C++ 코드를 작성하고 타이밍을 실행해야 합니까?

A = rand(3,5)
<strong i="6">@code_llvm</strong> slice(A, 2, :)
<strong i="7">@code_llvm</strong> slice(A, :, 2)

기본적으로 로드 및 저장 작업(즉, 메모리 액세스) 외에는 아무 것도 없습니다.

@timholy 나는 이것을 쓸 가치가 있다고 생각합니다. 나는 Nd 배열을 구현하는 많은 시스템이 처음 몇 차원에 대해 특수 구현을 가지고 있으며 일반적으로 그렇지 않으면 느린 것으로 대체되며 새로운 구현의 경우에는 그렇지 않아야 한다고 믿습니다(검증되지는 않음).

또 다른 관련 사례는 효율적인 희소 Nd 저장소를 작성하는 것입니다(배열은 일반적인 특수 사례임).

팀,

예, 실제로 결과 어셈블리 코드를 보는 것은 훌륭한 도구입니다. 그러나 여전히 이것은 (C++ 구현에서) 가상 기능을 고려해야 하는 더 큰 맥락에서 비교되어야 한다고 생각합니다.

내 생각에 실제로 그렇게 빠른 것은 multiple dispatch 가 아니라 런타임에 인라인할 수 있으므로 가상 함수(일반 함수가 있음)를 함수 호출 간접 지정 없이 효율적인 명령어로 변환할 수 있다는 것입니다.

이것이 사실이라면 (제가 틀렸다면 정정해주세요 @JeffBezanson @vtjnash @stevengj @timholy ) multiple dispatch 의 배수는 Julia가 그렇게 빠른 이유가 아니라 특정 코드를 공식화할 수 있는 깔끔한 측면 영향입니다 nicer(단일 디스패치가 제한되는 경우)

나는 아마도 이해하지 못할 것입니다. 그러나 당신이 만들고 있는 구별이 확실하지 않습니다. Julia에서 "인라인"과 "런타임"은 실제로 함께 가는 것 같지 않습니다. 인라인은 형식 유추 중에, 즉 컴파일 타임에 수행됩니다. 다중 디스패치는 유추된 유형에 대해 적절한 방법을 선택하는 데 사용됩니다.

여기서 혼란은 C++의 "컴파일 시간"과 "런타임"이 Julia와 비교할 수 없다는 것입니다. Codegen은 "런타임" 중에 발생할 수 있으므로 include("myscript.jl") 하면 인라인이 수행되는 것 같습니다. 그리고 "런타임"이 C++ 관점에서 적절한 단어가 아니더라도 "런타임"입니다.

그리고 다른 유형에 대한 디스패칭은 vtable과 비슷하지만 더 일반적이지 않습니까?

이것은 출판을 위해 SubArray를 작성해야 하는지 궁금하게 만듭니다. ---여기에 새로운 것이 있는 것 같습니다.

표준 주제와는 조금 거리가 있지만 JSS에 제출하는 것을 고려할 수 있습니다. Julia 기사가 더 필요합니다.

Tim이 이 작업을 설명하는 블로그 게시물을 작성하면 많은 사람들이 속도를 낼 수 있기 때문에 시작하는 것이 좋습니다. JSS는 훌륭한 아이디어이며 데이터 프레임 및 배포판에서 수행된 기본 작업 중 일부도 쓸 가치가 있습니까? 나는 확실히 그것을 읽는 것을 즐긴다.

글쎄, 내가 그것에 대해 생각하게 만든 것은 많은 부분이 http://docs.julialang.org/en/latest/devdocs/subarrays/에 작성되었다는 것입니다. 출판물의 경우 훨씬 더 자세히 설명하고 싶지만 이것은 주요 큰 그림 요점의 상당 부분을 차지합니다.

@stevengj 가 다중 디스패치에 대해 제기한 질문에 대해 다중 디스패치 없이는 julia에서 기본 라이브러리를 작성하기가 꽤 어렵다고 말하고 싶습니다. 나는 여기 있는 모든 사람들이 이미 알고 있는 것을 말하고 있으며 이것이 여기에서 제기된 이유에 대한 설득력 있는 예가 아닌지 궁금합니다.

숫자 연산 및 전환/프로모션과 같은 세부 사항은 여러 디스패치와 복잡하게 연결되어 있습니다. 다중 디스패치는 코드에서 유형이 사용되는 방식에 대해 컴파일러의 유형 추론을 본질적으로 노출하기 때문에 일반적이고 빠른 숫자 기반 라이브러리를 작성할 수 있습니다. 당신이 한 말을 인용하자면 - 정책을 컴파일러에서 라이브러리로 분리하는 데 도움이 됩니다. 예를 들어 @JeffBezanson 은 Scheme 사양이 수치적 세부 사항에 공간의 1/3을 사용하는 방법을 한 번 보여주었습니다.

해석된 많은 시스템은 종종 일반 유형을 갖게 되며 실행할 코드에 대한 결정을 내리기 위해 런타임에 해당 개체의 유형을 검사하게 됩니다. 그런 다음 각 유형에 대한 기본 라이브러리의 C/C++/Fortran에 별도의 구현이 있는 경우가 많으며 이로 인해 코드베이스가 크고 디버그하기 어렵습니다. 종종 이들은 외부 매크로 시스템을 통해 생성되지만 C++ 템플릿을 점점 더 많이 사용하여 이 특정 문제를 피할 수 있습니다. 두 가지 언어 및 형식 유추 문제는 이러한 경우에도 여전히 남아 있습니다.

어떤 수준에서 벡터화는 얼마나 많은 과학 언어가 런타임에 유형을 결정하고 적절한 코드 선택을 수행하는 비용을 상각하는가입니다. Julia에서는 형식 유추, 다중 디스패치 및 일반 프로그래밍을 결합하여 두 가지 비용을 모두 크게 낮추어 형식 없는 일반 역벡터화된 코드(C)를 작성할 수 있습니다.

한 가지 예는 PR #9198에서 MathConst (무리수를 나타냄)와의 불평등 비교입니다.

https://github.com/JuliaLang/julia/pull/9198/files#diff -e247e18c426659d185379c7c96c1899dR29

• FloatingPoint 대 MathConst 는 부동 소수점을 상수 위/아래 부동 소수점과 비교합니다.
• Rational{T} 대 MathConst (제한된 정수 유형의 경우 T )은 유형으로 표현할 수 있는 가장 가까운 유리수를 찾습니다. 그런 다음 그것이 진정한 비합리적 유형 위인지 아래인지에 따라.

이것을 가능하게 만드는 것은 컴파일 타임에 Rational 및 BigFloat 기능에 쉽게 액세스할 수 있기 때문입니다. 매크로 전처리기와 같은 것을 사용하는 것이 가능할 수도 있지만 기본적으로 모든 기능의 두 가지 구현이 필요합니다.

이 문제에 대한 작은 업데이트가 있습니다. 이 문서는 이제 대중에게 공개됩니다: https://github.com/JeffBezanson/phdthesis

오늘 저는 일종의 드래프트를 자체적으로 정한 기한에 맞춰 공개합니다. 그것은 초안이 아닙니다. 많은 조각이 완전히 누락되었습니다. 또한 TeX 주석 내부에 있거나 과거 버전 기록에만 존재하는 모든 것에 대해 책임을 지지 않습니다. :)

모든 피드백을 환영합니다! 특히, 언어를 잘 보여주는 줄리아 코드의 좋은 예가 있는 경우, 특히 언어 없이는 하기 힘든 모든 작업이 그렇습니다. 항상 중요하지 않은 다중 디스패치 예제를 찾고 있습니다.

공개해주셔서 감사합니다. SGJ가 사용한 링크를 따라가려다가 404를 눌렀을 때 놀랐습니다.

삼각행렬 산술 은 Julia의 다중 디스패치의 유용성에 대한 예가 될 수 있습니다. 여기 UpperTriangular+UpperTriangular=UpperTriangular 이지만 UpperTriangular+LowerTriangular=Matrix 입니다.

또한 요소 유형의 프로모션에 대해서도 이야기했습니다. 나는 당신이 필요하지 않을 때 승진을 피할 수 있다는 것을 좋아합니다. 예를 들면

julia> Base.LinAlg.UnitLowerTriangular(ones(Int, 3, 3))\[1,2,3]
3-element Array{Int64,1}:
 1
 1
 1

julia> Base.LinAlg.UnitLowerTriangular(ones(Int, 3, 3))\[1,2,3.0]
3-element Array{Float64,1}:
 1.0
 1.0
 1.0

이것이 Julia에게 얼마나 구체적인지 말할 수는 없지만, 우리가 보았듯이 최소한 Eigen은 승격을 관리하지 않을 것이지만 선형 대수 연산에서 요소 유형이 안정적이어야 합니다.

Jeff는 이제 마지막 단계로 접어들고 있으므로 그의 논문에 대한 피드백과 수정 사항(위에 언급된 github 저장소 참조)이 특히 환영받을 것입니다.

오타, 누락된 참조 등에 대한 PR을 자유롭게 제출하십시오.

@stevengj 여기에서 방어 일정 발표를 예상해야 하나요?

네.

그가 MIT에서 이미 일을 하고 있기를 바랍니다... (또는 그가 Julia의 훌륭한 작업을 계속할 수 있는 곳이면 어디든지)... 지금 그의 논문을 읽고 있습니다... 훌륭한 자료, IMO!

@andreasnoack 조금 난해하지만 어쨌든 재미있습니다. 화살표 행렬 링 유형을 정의하고 밑으로부터 Cholesky 인수분해를 적용하여 화살표 행렬의 화살표 행렬의 촐레스키 인수분해 구조가 어떻게 생겼는지 확인합니다. https://gist.github.com/mschauer/c325ff89cd378fe7ecd6 ("A" 화살표 행렬, "F" 전체 행렬, "L" 아래쪽 절반 화살표").

@ScottPJones 감사합니다!!

방어 예정: 5월 13일 수요일 오후 1시 Stata D-463.

@JeffBezanson replay.csail.mit.edu 를 통해 녹음할 계획인가요?

...아마 잊어버리는게 나을지도... :)

이것이 마지막 체크박스의 용도가 아닌가요?

주소를 알려야 하는 _정말_ 확신합니까? 당신은 당신의 논문의 서명된 사본을 원하는 팬 보이즈에 의해 붐비게 될 수도 있습니다! :웃음이 넘치는:

나는 이미 내 티켓을 얻었다. 가격이 암시장에서 이미 800달러까지 올랐다고 들었습니다.

내 시대에는 Stata D-463이 없었습니다... (나는 단지 친구를 방문하기 위해 그리고 NE Database Day를 위해 거기에 갔을 뿐입니다)... 충분히 커질까요? 확실히 그는 10-250이 필요할 것입니다!

공식적으로 D-463은 48개의 의자에 맞습니다. 그것으로 충분하지 않다고 생각되면 더 큰 방을 구할 수 있습니다.

나는 진지하게 당신이 한 일에 대해 정말로 감사하다고 생각하지 않습니다! 팬이 모두 모였다면 10-250명이 충분하지 않았을 것입니다... 지금 Kresge를 예약하세요!

테크니컬 컴퓨팅의 추상화

• 박사 후보: 제프 베잔슨
• 논문 감독: Alan Edelman 교수
• 논문위원회: Steven Johnson 교수, Saman Amarasinghe 교수, Gerry Sussman 교수
• 날짜: 2015년 5월 13일 수요일
• 시간: 오후 1시
• 위치: MIT 캠퍼스, 32-D463

_배열 기반 프로그래밍 환경은 과학 및 기술 컴퓨팅에 널리 사용됩니다. 이러한 시스템은 상호 작용을 위한 고급 언어와 쌍을 이루는 내장 함수 라이브러리로 구성됩니다. 라이브러리가 잘 수행되지만 이러한 언어로 된 스크립팅은 반드시 느리고 엔지니어링의 영웅적인 업적만이 이 문제를 부분적으로 개선할 수 있다고 널리 알려져 있습니다._

_이 논문은 실제로 필요한 것은 이 기능을 위한 보다 일관된 구조라고 주장합니다. 하나를 찾으려면 테크니컬 컴퓨팅이 실제로 무엇에 관한 것인지 물어봐야 합니다. 이 논문은 이러한 종류의 프로그래밍이 연산자 복잡성과 코드 전문화에 중점을 둔 것이 특징이며 언어가 이러한 요구 사항에 더 잘 맞도록 설계될 수 있음을 시사합니다._

_핵심 아이디어는 코드_ _선택 _ _코드 와_ _전문화 _ , _일반 함수 및 데이터 흐름 유형 추론을 통합하는 것입니다. 이와 같은 시스템은 비효율적인 컴파일이나 무엇을 전문화해야 하는지에 대한 불확실성으로 인해 어려움을 겪을 수 있습니다. 충분히 강력한 유형 기반 디스패치가 이러한 문제를 해결함을 보여줍니다. 결과 언어인 Julia는 기술 컴퓨팅 사용자가 기대하는 많은 생산적인 기능의 Quine 스타일 "제거를 통한 설명"을 달성합니다._

관중이 사용할 수 있는 그의 논문의 인쇄된 사본이 있습니까?

서명된 사본 일 수 있음

그것이 내가 바라는 것입니다... 10-15년 안에 Ebay에서 싸인된 사본을 판매하여 큰 돈을 벌 수 있다고 생각합니다. 가고 싶다고 말한 곳으로 가면... :웃는다:)

행운을 빕니다, 제프!

행운을 빕니다! 내가 그 지역에 있었다면 @ScottPJones가 언급한 팬보이 중 한 명일 것입니다.

@ScottPJones :+1:

다리를 부러뜨려, 제프!

행운을 빕니다, 제프!

행운을 빕니다! @JeffBezanson

@JeffBezanson 행운을 빕니다!!

자리를 잡을 수 있기를 바랍니다.

행운을 빕니다

나는 그가 10-250을 예약했어야 한다고 그에게 말했다!

내 iPhone에서 보낸

2015년 5월 13일 오전 11시 53분에 Yichao Yu [email protected] 이 다음과 같이 썼습니다.

@JeffBezanson 행운을 빕니다!!

자리를 잡을 수 있기를 바랍니다.

—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

행운을 빕니다!

같게!

운 좋게도 나는 자리에 앉을 수 있을 만큼 일찍 들어갔고... 내 말이 맞았다.

축하합니다

결정된.

아직 선택하지 않은 확인란이 하나 있습니다. 더 나은 작업을 얻을.

:shipit: :tropical_drink: :맥주: :칵테일: :타다: !

:엄지손가락:

베잔슨 박사님 축하합니다!

축하합니다, 제프!

+1

브라보

마지막 확인란은 이제 켄터키 버번 위스키로 채워졌습니다.

축하합니다 제프!

2015년 5월 13일 수요일 오후 1:44 Mike Nolta [email protected]
썼다:

+1

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/8839#issuecomment -101772806.

축하합니다!

축하합니다 제프! :맥주: :맥주: :스마일:

이것은 훌륭합니다! 축하합니다, 제프. :불꽃:

좋은 소식. 축하합니다, 제프!

축하합니다!

축하 해요

웁 웁 제프 축하합니다!

축하합니다, 베잔슨 박사님!

사진을 올려주셔서 감사합니다. @ScottPJones. @jiahao , 사진도 좀 있는 것 같은데요?

축하합니다 제프. 이 PHD로 끝난 당신의 작업은 우리 중 많은 사람들에게 영향을 미쳤습니다. 그것은 과학 컴퓨팅에 엄청난 영향을 미치고 있을 것이며 이미 영향을 미치고 있습니다! 바위에!

축하합니다.

엄청난!

축하합니다 제프!!

훌륭합니다, 축하합니다!!

베잔슨 박사님 축하합니다!

살펴보고 싶은 사람들을 위한 논문:

https://github.com/JeffBezanson/phdthesis/blob/master/main.pdf

축하 해요!

축하합니다!

축하합니다!

축하합니다:+1:

GitHub에서 내 모든 사진을 회전하기로 결정한 이유는 모르겠지만 여기 있습니다.

이슈 폐막식 영상: http://youtu.be/hGpLOZX6CEY

Aleph-zero 축하합니다, 제프! 시애틀에 계시다면 축하 음료를 사 드리겠습니다. :)

축하합니다 제프. 커뮤니티로서 귀하의 작업을 축하하게 되어 매우 기분이 좋습니다.

축하합니다!

@jiahao , 감사의 페이지에 대한 보충 자료 로 Julia의 최신 세계를 다시 실행할 가치가 있습니다. :)

모두 감사합니다.

불행히도 내 논문은 실제로 완료되지 않았지만 곧 이루어지기를 바랍니다.

몇 장의 사진이 더 있습니다. 깨어난 후에 Jeff에게 보내겠습니다(그의 어머니, 아주 좋은 여성을 위해!) _Dr._ Bezanson은 원한다면 여기에 사진을 게시할 수 있습니다...

안 끝났어??? Gerry가 그 빌어먹을 "구문"을 모두 제거하고 s-표현식으로 작성하게 하라고 요청했습니까?

@JeffBezanson 이 Mac을 사용하는 모습은 내가 예상한 사진이 아닙니다!

야!

축하합니다

이 연못의 모든 팬 여러분 수고하셨습니다.

안 끝났어??? Gerry가 그 빌어먹을 "구문"을 모두 제거하고 s-표현식으로 작성하게 하라고 요청했습니까?

니가 끝냈어! 농담이 아냐. 그러나 그는 선택적 s-expr 모드에 만족할 것입니다.

프레젠테이션이 끝난 후 그와 이야기를 나누었습니다... 그는 당신의 내용을 좋아했지만 모든 구문에 대해서는 전혀 신경 쓰지 않았습니다... 너무 많은 부분이 있습니다... 그는 나에게 Scheme 매뉴얼이 얼마나 작은지를 상기시켰습니다 :웃는다: 6.001[첫 학기에 배웠다]에 그를 시켰을 때, 우리는 MacLisp에서 작은 Scheme 인터프리터를 구현해야 했습니다... Scheme이 너무 작았기 때문에 꽤 할 수 있었습니다...

그리고 나는 당신이 회사를 위한 그 버번 병으로 꽤 빨리 그것을 녹일 수 있다고 확신합니다(남은 것이 있다면! ;-))

스킴 매뉴얼의 길이에 대해 이야기하자면 재미있습니다. 많은 부분이 숫자의 동작을 문서화하는 데 사용되는 반면 Julia에서는 라이브러리에 정의되어 있습니다. Julia는 잠재적으로 scheme보다 작은 핵심 언어일 수 있습니다(물론 LLVM 사양을 스테이플링하지 않는 한).

찬성이든 반대이든 문법이 너무 강조됩니다! 또한 http://www.schemers.org/Documents/Standards/R5RS/HTML/의 섹션 7.1을 확인하십시오. 스키마 구문은 사람들이 생각하는 것보다 더 복잡합니다!

Julia는 잠재적으로 scheme보다 작은 핵심 언어일 수 있습니다(물론 LLVM 사양을 스테이플링하지 않는 한).

예, Julia는 좋은 뼈를 가지고 있습니다!

이전 @sexpr 매크로를 파헤칠 시간입니까?

졸업을 축하하고 Julia와 함께 무엇을 했는지 축하합니다!

:케이크: 축하합니다!

@JeffBezanson을 축하합니다!

축하합니다 :)

:+1:

@소년! 오랜만 이네요!

그리워요 여러분 :)

축하합니다!

질문: PDF에는 ToC의 링크나 pdf 메타데이터의 탐색 가능한 색인이 없습니다.
MIT를 졸업한 컴파일러 작성자가 서문에 \usepackage{hyperref}를 추가하는 것이 왜 그렇게 어려운가요?

그냥 지나치지 않고 전체를 읽어야 하기 때문입니다. ;-)

하지만 예, hyperref는 이것을 훨씬 더 쉽게 만들 것입니다.

링크를 추가하면 전체 내용을 읽을 것을 약속합니다 :P

축하합니다. 자유가 기다리고 있습니다.

베잔슨 박사님, 축하합니다!

@nicola-gigante, 풀 리퀘스트를 할 수 있습니다: 스마일:.

최우수 논문상을 위해 로비할 수 있습니까?

http://awards.acm.org/doctoral_dissertation/nominations.cfm

축하해!!!

@jpfairbanks - 좋은 생각입니다! 그의 논문 지도교수가 제출해야 하지만... 페스터 앨런 에델만, 제 생각에는...

예, 고문의 추천과 5개의 지원 서신이 필요합니다. 기반으로
이 문제는 적어도 5명이 그가 그럴 자격이 있다고 생각한다고 생각합니다.

지원은 5글자로 제한되나요? 또한, 그가 그럴 자격이 있다고 생각하는 사람들의 실제 수는 적어도 몇 자릿수 이상 더 많습니다!

@JeffBezanson : 축하합니다!

@alanedelman : @jpfairbanks 가 좋은 지적을 하고 있다고 생각합니다. Jeff는 ACM 박사 학위 논문 상 후보로 지명되어야 합니다.

@JeffBezanson 수고했고 그럴 자격이 있습니다!

@ScottPJones "또한 논문의 영향에 대한 추가 통찰력이나 증거를 제공할 수 있는 해당 분야 전문가의 지원 서신이 최소 3개에서 5개 이하로 포함되어야 합니다."

아마도 Gerry가 그에게 하나를 쓸 것입니다(그가 s-expr 모드를 추가한 후!).

Hacker News 첫 페이지 :-) 축하합니다, Jeff.

@nicola-gigante 맞습니다. 하이퍼 참조를 추가하겠습니다.

다시 한 번 모든 분들께 감사드립니다. 모든 감사가 최고의 상입니다.

@jiahao 브라우저가 신경 쓰지 않는 EXIF ​​회전 데이터가 있기 때문입니다. 대부분의 경우. Chrome은 사진이 자체 창인 경우에만 EXIF ​​데이터에 관심을 갖습니다. 올바른 방향을 보려면 마우스 오른쪽 버튼을 클릭하고 "새 탭에서 열기"를 클릭하십시오.

EXIF 메타데이터 스트리퍼를 사용하여 이를 제거하고 "적절한" 방식으로 회전할 수 있습니다.

ACM 논문상 후보에 +1.

추천 마감일은 2015년 10월 31일입니다.

http://awards.acm.org/doctoral_dissertation/nominations.cfm

나는 ACM이 그들에 대한 저작권 양도와 독점 출판권을 요구한다는 것이 마음에 들지 않습니다. 어떤 경우에도 여전히 가치 있고 권위 있습니다.

축하 해요!

독점출판권!!?! 나는 싸인 사본을 가지고 있습니다 (또는 두 ... 10-15 년 안에 e-bay에서 판매하기 위해 하나가 필요하고, 나 자신을 위해 보관해야 할 또 하나가 필요합니다 :웃고 있습니다:)... ACM!
(당연히 ACM의 디지털 라이브러리에서 회원들에게 제공된다는 의미일 수도 있습니다.)

논문이 나에게 전달되면 서명하기 위해 모든 의도가 있습니다.
다양한 수상 경력에 빛나는 논문 :-)

2015년 5월 17일 일요일 오전 8:49, Scott P. Jones 알림 @github.com
썼다:

독점출판권!!?! 나는 싸인 사본에 dibs를 가지고 있습니다 (또는
둘... 하나는 10-15년 안에 e-bay에서 판매하고 다른 하나는 나 자신을 위해 보관해야 합니다. [이미지:
:웃으면서:])... ACM에 의해 가두어지기 전에 잡아야 합니다!
(물론 ACM에서 사용할 수 있다는 의미일 수 있습니다.
회원용 디지털 도서관)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/8839#issuecomment -102801616.

@JeffBezanson의 댓글이 없습니다... 저는 그가 축하하고 있고(마지막 상자를 더 확인하고 있음) s-expr 모드가 작동할 때까지 GJS가 방 어딘가에 갇힌 적이 없었으면 합니다!

축하합니다!

축하합니다, @JeffBezanson!

(뒤늦게) 축하합니다!

업데이트: 방금 문서를 제출했습니다. 제출된 버전은 https://github.com/JeffBezanson/phdthesis/tree/876be73a5aab9b034fac3eb9ea9d8f96713f786f 입니다.

여러모로 부족하다고 확신합니다. 오 글쎄. 그곳에 정말 나쁜 일이 없기를 바랍니다.

멋진. 진정으로 박사 학위를 마치신 것을 축하드립니다.

축하합니다, 제프! 대단한 성취입니다. 나는 당신이 그것이 끝난 것을 기뻐할 것이라고 확신합니다.

나는 이미 당신의 논문이 Julia의 문서에서 몇 가지 허점을 채우는 것을 발견했기 때문에 분명히 매우 유용할 것입니다. 모든 문서에는 결함이 있습니다. 나머지 우리는 강점에 깊은 인상을 받았습니다! 축하 해요!

그리고 공유해주셔서 감사합니다!

쯧쯧! 방어와 논문, 그리고 그들이 의미하고 대표하는 다른 모든 작업을 마치신 것을 축하합니다. 당신이 성취한 모든 것을 인정하기 위해 이 이정표를 갖는 것이 좋습니다. 당신이 자랑스러워하기를 바랍니다!

@JeffBezanson 나는 당신이 진정하고 축하하기 위해 며칠을 휴가를 낼 계획이거나 아마도 유형 시스템 점검 등으로 축하할 계획이기를 바랍니다. :-)

새로운 pdf에 hyperref가 있다는 것은 좋은 일입니다. 탐색하려는 사람들을 위한 것입니다. 줄리아 출판물 목록에도 올려야 합니다.