외부 참조 https://github.com/JuliaLang/julia/issues/11557#issuecomment -339776065 이하 및 @Sacha0 의 PR #24389

나는 이 효과를 위해 진행 중인 작업이 있는데, 이 작업을 다음 하루나 이틀 안에 게시할 수 있기를 바랍니다. :). 최상의!

나에게 fill(oneunit(T), sz) 는 ones(T, sz) 와 비교하여 가독성에서 사소하지 않은 손실처럼 보입니다.

fill(oneunit(T), sz) 와 같은 장황한 것을 작성할 필요는 거의 없습니다. 일반적으로 oneunit(T) 대신 리터럴 또는 이와 유사한 간결한 것으로 충분합니다. 배열 생성자에 대한 향후 변경으로 더 짧은 주문이 가능할 수도 있습니다. 또한 fill 로 전환하면 점점 더 좋아하게 될 것입니다. 최상의!

ones 가 one 또는 oneunit 사용하는지 여부를 선택할 수 있습니다. ones 및 zeros 는 편의 기능으로 간주되어야 하며 보다 일반적인 기능 측면에서 명확한 의미가 있는 한 괜찮습니다.

분류별 계획: 특히 ones 및 zeros 를 MATLAB 호환성 계층으로 이동하고 기본에서 fill 로 이동하는 것을 고려하여 다음 주에 다시 방문하십시오. 최상의!

ones 및 oneunits 는 두 옵션을 구분합니다.

이 zeros 를 MATLAB 호환성으로 옮기는 것에 대해 어떻게 느끼는지 잘 모르겠습니다. Mathworks가 발명했다고 해서 이것이 우리가 자랑스러워 할 수 있는 편리한 API가 아니라는 의미는 아닙니다. 간단히 말해서 -이 생각의 이유는 무엇입니까? (죄송합니다. 분류가 훨씬 더 효율적으로 보이지만 추론이 제공되지 않을 때 훨씬 덜 투명해 보입니다.)

저도 감격스러운 변화는 아니지만 논리적 모순이라 올려봤습니다. ones(T, sz) fill(one(T), sz) 의미한다고 말하는 것이 공정하다고 생각하지만 실제로 내부에서 수행하는 작업은 fill(oneunit(T), sz) 입니다.

한 가지 옵션은 이름을 oneunits 로 바꾸는 것입니다. 대안은 one -> algebraic_one 및 oneunit -> one 끔찍한 스왑을 수행하는 것입니다. 이것은 중단되고 지원 중단을 통해 수행할 수 없기 때문에 "끔찍하다"고 말합니다.

네, 추가 말할 것 oneunits 하고 변경 ones 주고 fill(one(T), ...) 아니, 그에 대한 명백한 수정 될 것이다?

난 괜찮을거야. 궁금해서 fill(one(T), sz) 의 용도는 무엇입니까? ones 가 필요합니까?

하하 :) 제가 fill(oneunits(T), sz) 를 무엇에 사용하는지 묻고 싶었습니다. (예: 1미터, 1킬로그램 또는 1초로 채워진 어레이는 무엇에 사용됩니까?)

fill(one(T), sz) 는 zeros(T, sz) 와 같은 이유로 사용자 정의 축소 유형 작업에 대한 배열을 초기화하는 데 사용된다고 생각합니다. 배열 z = zeros(T, sz) 함께 첨가 그것의 요소가 준비 z[i] += x 로 반면 o = fill(one(T), sz) 그것의 요소가 준비 승산 o[i] *= x . 예를 들어, 배열 요소가 (상대) 확률을 나타낼 수 있는 상황을 생각하고 있습니다. 이 두 경우에서 각각 + 또는 * 연산자(가산 생성기가 아님)의 ID를 찾고 있습니다.

참조 #23544

하하 :) 무엇을 위해 fill(oneunits(T), sz)를 사용합니까? (예: 1미터, 1킬로그램 또는 1초로 채워진 어레이는 무엇에 사용됩니까?)

ODE에 대한 종속 변수입니다. T 유형의 배열을 요청할 때 단위가 무작위로 잘린 경우 이상할 것입니다.

fill 를 선호하는 근본적인 이유는 강력하고 직교하며 구성 가능한 도구 세트가 ones / zeros 와 같은 임시적이고 제한적이며 중복되는 도구 모음보다 더 잘 작동하기 때문입니다. trues / falses . 위의 논의는 이 점을 강조합니다. fill 위의 모든 사용 사례를 모호하지 않고 (대부분의 실제 사용에서) 간결하게 수용하지만 ones / zeros / trues / falses 접근 방식에는 각 사용 사례에 대한 새로운 기능이 필요합니다.

base에서 재작성한 몇 가지 관련 예:

complex.(ones(size(Ac, 1)), ones(size(Ac, 1)))

된다

fill(1.0 + 1.0im, size(Ac, 1))

그리고

2ones(Int, 2, 2, 2)

된다

fill(2, (2, 2, 2)) # or fill(2, 2, 2, 2) if you prefer

이러한 fill 주문은 fill 아닌 주문보다 더 간단하고 읽기 쉽고 간결하며 효율적이며 base/ 및 test/ 는 이와 같은 예가 만연합니다. 모든 변경 사항과 마찬가지로 fill 하려면 초기 정신적 조정이 필요합니다. 그러나 조정 후에는 손끝에서 더 강력하고 우아함을 발견할 수 있습니다. :). 최상의!

@Sacha0 : trues / falses 는 fill 직접 대체할 수 없지만 BitArray 이니셜라이저와 함께 fill! 를 사용해야 합니다. one 와 oneunit 사이의 모호성에도 포함되지 않습니다. 따라서 나는 그들이 이 논의에 전혀 적합하지 않다고 생각합니다.

ones 관해서는, 나는 일반적으로 어쨌든 그것을 더 이상 사용하지 않는 것에 반대하지만 이점을 보지 못합니다. fill 하여 일부 표현식을 더 효과적으로 작성할 수 있다는 주장은 제 생각에 그다지 설득력이 없습니다. 이러한 모든 예제는 다른 작업을 수행하기 위한 중간 단계로 ones 를 사용하기 때문입니다. 그러나 실제로 배열을 원할 때는 어떻습니까? 그러면 fill 를 사용해야 하는 것이 더 길고 덜 명확하며 더 짜증납니다. @JeffBezanson 의 제안이 가장 마음에 base 또는 test 보다 효율적으로 사용하여 다시 작성 될 수 fill 대신 ones 지금 것을 방지 아무것도 없다.

@carlobaldassi 그것이 사실이지만 빠른 GitHub 검색에 따르면 ones 의 거의 모든 사용은 중간 할당을 피하기 위해 실제로 fill 를 사용해야 합니다...

이러한 경우에 fill 를 사용하는 것이 합리적입니다. ones 등의 해당 메소드를 대체하기 위해 새로운 fill(x, A) = fill!(x, copymutable(A)) 메소드가 필요합니다.

@TotalVerb 해당 검색의 처음 10페이지에 대한 간단한 훑어보기에서 "거의 모두"가 공정한 평가라고 말하지는 않습니다. 기껏해야 "상당한 부분"입니다. 거기에는 ones 대한 합법적인 사용 사례가 많이 있으며 아마도 대다수가 될 것입니다(20%라고 해도 내 주장은 여전히 ​​유효하다고 생각합니다).

(나는 또한 가독성 논쟁에 대해 사실 유보가 있습니다. 예를 들어 fill(2, 2, 2, 2) 이 2 * ones(Int, 2, 2, 2) 보다 더 읽기 쉽다거나 fill(k * 1.0, 3) 가 더 많을 것이라고 주장하는 것은 의심스럽습니다. k * ones(3) 보다 가독성 ; 나는 그것이 단지 습관의 문제라는 것을 전혀 확신하지 못합니다. 이것은 사소한 요점입니다.)

참/거짓은 채우기로 직접 대체할 수 없지만 채우기를 사용해야 합니다! BitArray 이니셜라이저를 사용합니다. 그들은 또한 하나와 하나의 단위 사이의 모호성에 포함되지 않습니다. 따라서 나는 그들이 이 논의에 전혀 적합하지 않다고 생각합니다.

실제로 trues 및 falses 는 fill 직접 대체할 수 없습니다 :). 오히려, trues 및 falses 는 위에서 설명한 / #11557과 관련된 일반적인 문제의 추가 인스턴스입니다(그리고 배열 생성자의 최근 방향이 잘 해결되기를 바랍니다). 다른 예로는 BandedMatrices.jl 및 이에 상응하는 bones , bzeros , brand , brandn 및 beye 의 존재가 있습니다. DistributedArrays.jl의 d 접두사.

그것들에 관해서는, 나는 일반적으로 어쨌든 그것을 더 이상 사용하지 않는 것에 반대합니다. 나는 이점을 보지 못합니다. 채우기를 사용하여 일부 표현식을 더 효과적으로 작성할 수 있다는 주장은 내 생각에 그다지 설득력이 없습니다.

ones 를 기본으로 수백 번 다시 작성하여 @TotalVerb 의 진술을 확인할 수 있습니다.

빠른 GitHub 검색에 따르면 거의 모든 사용은 중간 할당을 피하기 위해 실제로 채우기를 사용해야 합니다...

(편집: 나는 거의 전부라기 보다는 대략 절반이라고 말하고 싶지만, 적절한 재작성은 fill 이외의 것일 수 있습니다.) 게다가, 그 재작성 경험은 저에게 가르쳐 주었습니다...

그러나 실제로 배열을 원할 때는 어떻습니까? 그러면 채우기를 사용해야 하는 것이 더 길고 덜 명확하며 더 짜증납니다.

... 반면에 fill 는 이 경우에 종종 더 짧고 간단합니다. 요청된 항목은 종종 Float64 아닙니다(예: ones(Int, n...) 및 ones(Complex{Float64}, n...) ), 이 경우 fill 는 리터럴을 허용하여 더 짧고 간단합니다(예: fill(1, n...) 및 fill(1.0 + 0im, n...) ). 측정 가능한 용어로, base에서 ones 호출을 재작성한 분기는 ones -> fill 재작성에서 문자 수만큼 ~5% 더 짧습니다. 최상의!

ones 가 야생에서 어떻게 나타나는지에 대한 객관적인 감각을 얻기 위해 Julia 코드에서 ones 에 대한 GitHub 검색의 처음 10페이지에 나타나는 모든 ones 호출을 수집했습니다. 이러한 각각의 호출을 적절하게 분류하고 해당 변경 사항을 분류한 다음( 이 요지 참조) 분류 데이터를 다음 요약으로 줄였습니다.

분석에는 156개의 ones 통화가 포함되었습니다. 그 통화 중,

• 84개의 통화(~54%)가 임시 fill . (예를 들어 ones(100)/sqrt(100)*7 는 fill(7/sqrt(100), 100) 또는 fill(.7, 100) ones(100)/sqrt(100)*7 단순화됩니다. 내가 가장 좋아하는 것은 kron(0.997, ones(1, J*J*s) -> fill(0.997, 1, J*J*s) 입니다.)

• 3개의 통화(~2%)는 임시 방송이었습니다. (예를 들어, A - ones(n,n) 는 A .- 1. 단순화됩니다.)

• 5개의 호출(~3%)은 임시 벡터 리터럴이었습니다. (예를 들어, ones(1) 는 [1.] 단순화됩니다.)

• 1 호출(~0.5%)은 의미상 정크 매트릭스 구성이었습니다. (야생에서는 비교적 드물지만 이 패턴은 test/ 에서 매우 일반적입니다. 예를 들어 <strong i="32">@test_throws</strong> DimensionMismatch BLAS.trsv(...,Vector{elty}(n+1)) 대 <strong i="34">@test_throws</strong> DimensionMismatch BLAS.trsv(...,ones(elty,n+1)) 와 같이 초기화되지 않은 Array 대한 간결한 편의 생성자가 없기 때문입니다. <strong i="34">@test_throws</strong> DimensionMismatch BLAS.trsv(...,ones(elty,n+1)) .)

나머지 호출은 ones 로 의미론적으로 합당하지만 one 가 특별히 필요하기 때문이 아니라 ones 가 단순히 짧기 때문에 사용하는 경우가 많습니다. 남은 통화 중,

• 13번의 호출(~8%)은 fill 로 약간 더 짧았습니다. (예: ones(Int, n, n) -> fill(1, n, n) 또는 ones(Float64, n) -> fill(1., n) .)

• 50회의 호출(~32%)은 fill 로 약간 더 길었습니다. (예: ones(n, n) -> fill(1., n, n) .)

전반적으로 ones 호출의 ~60%는 다른 방법으로 더 잘 작성되었으며 ~8%는 의미상 합리적으로 ones 이고 fill 로 약간 더 짧으며 ~32%는 합리적으로 의미상 ones 및 fill 로 약간 더 깁니다.

추가 관찰:

배열 인수를 수락하는 ones 호출의 한 인스턴스만 만났고, 둘러싸는 스니펫이 실제 코드인지 여부는 분명하지 않았습니다. 따라서 배열 인수를 수락하는 ones 메서드는 실제로 사용되는 경우가 거의 없습니다.

정말 흥미로운 토론 ... 또한 다른 언어의 선례로, R 사용 ... 측의에 측면에 대한에있는에서 갔다 rep 및 matrix 에 해당하는 방식으로 fill (1d 및 2d 경우에만 해당) 및 매우 빨리 익숙해집니다. 비록 제가 0/1의 세계에서 왔음에도 불구하고.

와우, 노력해 주신

" zeros 어떻습니까?"라는 질문이 자연스럽게 떠오릅니다. 나는 훨씬 더 많은 사용과 몇 가지 더 많은 사용 범주가 있을 것이라고 생각합니다("초기화되지 않은 배열을 신뢰하지 않습니다" 또는 " Array 생성자를 사용하는 방법을 모릅니다. ").

이유가 무엇이든( one 및 zero 의 대칭인 것 같습니다), 저는 ones 및 zeros 둘 다를 ones 으로 바꾸는 데 다소 끌립니다 fill 또는 둘 다.

0이 있는 것은 다음 상황 중 하나에 있는 것처럼 보일 수 있다는 것입니다.

1. 대부분의 0을 덮어써야 합니다. 이 경우 이해력을 사용하는 것이 좋습니다.
2. 대부분의 0을 바꿀 필요가 없습니다. 이 경우 희소 행렬을 사용하는 것이 좋습니다.
3. 실제로는 모두 0인 행렬이 필요합니다. 이 경우 0I 사용하는 것이 좋습니다.

실제로 조밀한 0으로 구성된 행렬을 할당하는 것이 실제로 좋은 생각인 사용 사례는 없습니다.

그것은 아마도 선형 대수학에 해당될 것입니다. 컴파일러 및 기타 데이터 구조에 대한 작업에서 0으로 초기화된 컬렉션이 필요한 것은 드문 일이 아닙니다. 아마도 그것들은 종종 희소하지만 그것들을 간결하게 표현하는 것은 성능에 영향을 줄 가치가 없습니다.

충분히 공정합니다. 때로는 밀도에 신경 쓰지 않고 단순함이 그만한 가치가 있습니다.

분류: zeros(dims...) 및 ones(dims...) 및 zeros(dims) 및 ones(dims) 와 같이 완전히 제네릭이 아닌 메서드만 유지하는 것으로 해결되었습니다.

@StefanKarpinski 사용 권장 사항은 일반 코드에 대해 fill(0.0, 3, 3) 보다 zeros(3, 3) 를 권장한다는 의미입니까(밀도 배열이 필요한 경우 등)? 효율성 등의 세부 사항 중 일부는 제 손이 닿지 않는 범위에 있습니다. 앞으로 줄리아에서 최선의/관용적 관행을 어떻게 가르칠 것인지 생각하고 있습니다.

이 결정은 나에게 매우 놀라운 것 같습니다. 특히 일반성을 방지하기 위해 기본적으로 그렇게 일반적이지 않습니다. 그 이유는 무엇입니까? 이 함수는 일반적이지 않은(그리고 float에서만 작동하는) matlab에서 가져온 것입니까?

Triage: 완전히 일반이 아닌 메서드만 유지하는 것으로 해결됨

그 이유는 무엇입니까?

이에 더하여, 이 문제는 현재 고려 중인 것으로 보이는 배열을 구성하는 일반적인 문제와 어떻게든 관련이 있으며, 그렇다면 이것이 어떻게 도움이 됩니까? 아니면 Base 에서 내보낸 메서드의 수를 줄이려고 합니까? (또는 완전히 다른 무엇인가?)

https://github.com/JuliaLang/julia/issues/24595에서 작성 예정 :). 최상의!

24595의 OP는 이 문제의 광범위한 컨텍스트를 자세히 설명했으며 이제 #24595의 후속 작업에서는 편의 생성자 ones , zeros 및 fill 에 대해 자세히 설명합니다. 전자를 읽는 것은 후자를 감상하는 데 가치가 있습니다. 최상의!

글쎄, 최소한 Float64 케이스를 저장하는 것이 없는 것보다 낫습니다.
정수 0의 경우도 상당히 관련이 있다고 생각합니다. 이는 기본적으로 @vtjnash 가 여기 에서 만든 요점입니다.

또한 zeros 에는 3 * ones(n) 안티 패턴을 허용하는 "문제"가 없습니다. 사실, 편의 생성자라는 넓은 의미를 제외하고는 ones 와 zeros 를 함께 사용해야 하는 이유를 잘 모르겠습니다. 그 둘 사이에는 진정한 '대칭'이 없습니다.

통계 분석 에 대한 몇 가지 추가 의견은 다음 토론과 #24595의 작성의 기초인 것 같습니다. 첫째, 10페이지로는 무슨 일이 일어나고 있는지에 대한 세밀한 결론을 내리기에 충분하지 않으며 기껏해야 대략적인 아이디어를 제공할 수 있습니다. 일부 파일은 예를 들어 이름/스타일에서 명확하기 때문에 matlab에서 직접 가져왔습니다. 둘째, 내가 의심한 대로 그 분석에서도 ones 사용의 약 절반이 "합법적"인 것으로 나타났습니다. 셋째, 이와 같은 코드를 보면 3 * ones(...) 작성할 때 실제로 성능 문제를 일으키는 안티 패턴이거나 성능에 전혀 영향을 미치지 않는 코드 조각에 대해 아무 것도 알 수 없습니다(작성자는 그런 식으로 작성된 것이 더 읽기 쉽다고 결정했습니다. 이 경우 달리 결정하는 것은 다른 사람의 일이 아닙니다.)

마지막 요점과 관련하여, 그리고 더 중요한 것은 github 검색에서 볼 수 있는 내용이 Julia에서 탐색/예비 작업을 수행하는 사람들의 REPL에서 무슨 일이 벌어지고 있는지 고려하지 않는다는 것입니다. 편의 기능이 가장 편리하게 사용되는 곳이 바로 여기이며, 식별할 수 없는 이유 없이 이를 제거하는 것이 가장 성가신 일입니다. 제 요점은, 일반적이고 효율적인 코드를 작성할 수 있도록 하는 일관된 직교 프리미티브 세트를 갖는 것이 큰 목표이며, 거기에 도달하기 위한 노력은 정말 칭찬할 만하다는 것입니다. 모든 코드가 아름답고 일반적이며 구성 가능한 라이브러리 코드가 되어야 하는 것은 아닙니다. 그냥 내 2 센트.

에 관하여

저는 정수 0의 경우도 상당히 관련이 있다고 생각합니다. -- 제 생각에는 -- 기본적으로 @vtjnash 이 여기에서 만들고 있는 요점입니다.

를 참조하는

컴파일러 및 기타 데이터 구조에 대한 작업에서 0으로 초기화된 컬렉션이 필요한 것은 드문 일이 아닙니다. 아마도 그것들은 종종 희소하지만 그것들을 간결하게 표현하는 것은 성능에 영향을 줄 가치가 없습니다.

fill 는 fill(0, shape...) 대 zeros(Int, shape...) 와 같은 경우에 더 잘 작동합니다.

다른 요점에 관해서는 #24595를 읽을 가치가 있습니다. 최상의!

나는 단순히 zeros(Int, 10, 10) 가 fill(0, 10, 10) 보다 더 읽기 쉽고 명확하고 zeros(T, k) 가 fill(zero(T), k) 보다 낫다는 것을 알았습니다. 왜 우리는 둘 다 가질 수 없습니까? 나는 zeros 가 ones 와 같은 모호성 문제를 겪는다는 주장을 믿지 않습니다.

다른 요점에 대해서는 #24595를 읽을 가치가 있습니다.

나는 그것을 읽었다. (심지어 링크했습니다.)

나는 그것을 읽었다. (심지어 링크했습니다.)

#24595 전체를 읽고 충분히 고려했다면 #24595: (1) 편의 생성자가 일부일 뿐이라는 훨씬 더 광범위한 문제에 관한 것임을 알 수 있습니다. (2) 위에 게시된 통계 분석과 여기에서 중점을 둔 요점 그 이상을 고려합니다.

ones 및 zeros 대해 강하게 느끼신 점에 감사드립니다. 당신의 감정은 크고 명확하게 전달되었습니다 :). 따라서 현재의 형태로 이 대화를 계속하는 것보다 다른 전선을 추진하는 데 우리의 대역폭이 더 나을 가능성이 있습니다. 최상의!

zeros 변경과 함께 일반 fill 수신이 있습니까? zeros 는 similar 보다 훨씬 안전하기 때문에 일반 프로그래밍에 매우 합법적으로 사용했습니다. 그래서 모든 DiffEq, 그리고 최근에 Optim과 NLsolve가 similar 할당에서 다음으로 이동했다는 것을 알고 있습니다. zeros 모든 것이 0을 갖도록 할당된다는 것을 아는 것은 많은 버그를 멈추게 합니다. 그러나 이제 다음과 같은 방법이 없을 것 같습니다.

zeros(X)

더 이상, 다음 이외의:

similar(X); fill!(X,0)

현재 fill 는 Array fill 만 빌드하므로 similar 또는 zeros 와 같은 유형 일치가 되지 않기 때문입니다. 어떤 사람들은 할당하지 않아야 할 때 zeros 를 오용하지만 많은 경우에 zeros 로 할당하는 것은 매우 합리적인 일이라는 것을 알고 있습니다. 이 공백을 채우기 위해 fill(0,X) 속기가 추가되기를 바랍니다.

사려 깊은 게시물 Chris에 감사드립니다! :) 임시 속기 대체로 zero(X) 가 트릭을 수행합니까?

이러한 사용 사례 정확하게 것을 참고의 모호성 zeros 및 ones 문제가 될 수 있습니다합니까에게 zeros(X) 산출와 객체 eltype(X) 와 가득 eltype(X) 의 덧셈 아이덴티티(예: fill!(similar(X), 0) ), 아니면 eltype(X) 대한 곱셈 0으로 채워진 객체( eltype(X) 아닐 수도 있음)? (확장에 대해서는 #24595를 참조하십시오.)

fill(0, X) 개념은 #11557에서 약간의 논의를 볼 수 있으며 fill 의 유용한 일반화일 수 있다는 데 동의합니다. 감사하고 최고입니다!

다른 문제는 비전통적인 인덱스가 있는 배열이 zeros(inds...) 와 같은 것으로 생성되기를 원할 수 있다는 것입니다( 인덱스 유형이 배열 유형을 결정 하기 때문). 그러나 1차원의 경우 X "닮고 싶은 배열"입니까 아니면 "원하는 배열의 인덱스"입니까? (결국 AbstractUnitRange <: AbstractArray .) 구체적으로 zeros(3:5) 는 fill!(similar(3:5), 0) 또는 fill!(OffsetArray(Vector{Float64}(3), 3:5), 0) 합니까?

{ones|zeros }(A::AbstractArray, ...) 편의 생성자에 대한 추가 논의가 포함된 https://github.com/JuliaLang/julia/pull/24656 연결. 최상의!

#24656에 따라 캐시 변수를 만들기 위해 zeros 를 사용하는 것이 이상한 것으로 간주된다는 사실에 놀랐습니다. 나도 그 생각 것 zeros 제로 오버 헤드에 가까운 사람들이 사용하는 거의 모든 사건을 감소 similar 대신해야 zeros 그건 꽤 많은 문제를 해결하는 경향이 있기 때문에 버그. similar 는 매우 안전하지 않을 수 있고 기능이 없고 대신 fill! + similar 하면 다음이 덜 명확해지기 때문에 더 많은 사람들이 이 작업을 수행하도록 권장해야 한다고 생각합니다 fill! 사람들이해야 할 일. 다음은 Optim.jl에 나타나는 이 항목에 대한 설명입니다.

https://github.com/JuliaNLSolvers/NLsolve.jl/issues/89#issuecomment -294585960

그러나 나는 @timholy 가 어떻게 해석되어야 하는지가 분명하지

https://github.com/JuliaDiffEq/MultiScaleArrays.jl

MultiScaleArrays.jl은 diffeq 솔버에서 사용할 수 있는 순환 그래프와 같은 구조인 추상 배열을 만들었습니다(지금 Optim.jl 및 NLsolve.jl과 호환될 수 있다고 생각합니다). 그것은 무엇보다도 생물학적 모델에 대한 좋은 편의입니다. 그것을 ODE 솔버에 던질 때 질문이 있습니다. 캐시 배열을 무엇으로 만들어야 할까요? 어떤 경우에는 사용자가 ODE 함수 f(t,u,du) 되고 그에 따라 처리하기를 원할 것이기 때문에 사용자가 원하는 배열을 다시 가져오는 것이 중요합니다. 그러나 다른 경우에는 내부적으로 방송되는 것으로만 나타납니다. 따라서 두 가지 유형의 캐시 변수가 있습니다.

이를 처리하려면 알고리즘 중 하나에 대한 캐시를 살펴보십시오.

https://github.com/JuliaDiffEq/OrdinaryDiffEq.jl/blob/master/src/caches/low_order_rk_caches.jl#L224 -L234

여기서 rate_prototype = similar(u,first(u)/t,indices(u) 는 비슷하지만 단위에 대해 잠재적으로 다른 eltype이 있습니다. 그러나 여기에는 similar(u) 대 similar(u,indices(u)) 의 두 가지 개별 유형이 있습니다. 나는 그것들을 "유형과 모양 일치" 대 "모양과 eltype 일치하지만 동일한 유형일 필요는 없음"을 의미하는 것으로 해석했습니다. 따라서 AbstractMultiScaleArray 의 경우 첫 번째는 또 다른 AbstractMultiScaleArray 를 만들고 다른 하나는 사용자에게 표시되지 않기 때문에 속도를 위해 적절한 Array 만 만듭니다. 크기. 그런 다음 similar(u,T) 및 similar(u,T,indices(u)) 됩니다.

그것은 이미 존재하는 것을 말장난하는 것일 수도 있지만 이것이 중요한 차이점이라고 생각합니다. 일반 프로그래밍을 수행할 때 두 개의 개별 캐시가 있습니다. 유형을 예상에 맞게 일치시키려는 사용자 대면 캐시와 알고리즘에서 사용하고 가능한 한 빠른 속도를 원하는 내부 캐시입니다.

내가 너무 게으른 zeros 버전을 생각해내지 못했기 때문에 이것들이 similar 사용하고 있음을 주목하십시오. 사용자가 f(t,u,du) 파생 계산에서 du 만 설정하면 암시적으로 "내가 설정하지 않은 것의 의미 zero", 이것은 zeros 로 할당되었을 때만 사실이므로 가능한 한 zeros 를 사용하여 사전 할당하려고 합니다(이를 위해 NLsolve.jl에서 동일한 문제가 나타남) .

그 설명이 따라가기에 너무 혼란스럽지 않기를 바랍니다. 내 모든 경우에 similar 다음에 fill! 로 전환할 수 있지만 일부 패키지는 그렇지 않고 이것이 버그의 원인이 된다는 것을 알고 있습니다.

흥미로운. similar(A, inds) 가 similar(A) 와 다른 유형을 생성할 수 있다는 말이 옳았지만 일반적으로 저는 항상 동일한 유형을 생성하지만 인덱스는 다른 것으로 생각했습니다. 예를 들어, 2차원 개체에 대한 열 단위 연산을 위해 1차원 캐시가 필요한 경우 similar(A, first(inds)) 합니다. (물론 차원이 유형 매개 변수이기 때문에 다른 유형이지만 같은 추상적 인 컨테이너 유형이 될 수 있습니다.) 당신은 또한 작은 타일 등 5 × 5 캐시를 생성하는 데 사용할 수 있습니다

전반적으로 이것은 어려운 문제인 것 같습니다. 조금 늦었지만 same 할까요? similar 와 동일한 인수를 가질 수 있지만 계약은 동일한 추상 컨테이너를 반환해야 한다는 것입니다.

same 의 단일 인수 형식을 지원할 수 있지만 이것도 까다롭습니다. a 가 setindex! 지원하지 않으면 same(a) 는 동일한 배열 유형을 반환할 수 없습니다 setindex! same 및 similar 는 나중에 배열에 쓸 경우에만 유용하기 때문입니다. 변경할 수 없는 a 대해 이것을 오류로 만들 수 있지만 AbstractArray 대한 인터페이스로서 이것은 정확하고 일반적인 코드를 만드는 데 불필요해 보입니다(아마도 도움이 되지 않을 수 있음).

마찬가지로 모든 AbstractArray 가 다른 eltype 또는 인덱스를 지원할 수 있다고 가정할 수 없습니다. 나에게 same 의 두 개 또는 세 개의 인수 형식을 사용하면 사람들에게 일반 코드가 모든 AbstractArray 대해 잘 작동할 것이라는 잘못된 보안 감각을 주는 동시에 여러 위치에서 런타임 오류가 발생할 수 있습니다

그러나 1차원의 경우 X는 "닮고 싶은 배열"입니까 아니면 "원하는 배열의 인덱스"입니까?

이것은 내가 찬성입니다 또 다른 이유입니다 keys 이 요구하고 다음 동일한 인덱스와 값 및있는 컨테이너 반환 similar (하나 (일부) 정수 (S를 제공하지 않는 한)에서 이 경우 Base.OneTo (CartesianRange)가 가정됨).

이 토론은 #18161을 향하고 있으며 아마도 계속되어야 합니다 :).

가장 최근의 분류는 ones 유지하는 방향으로 기울었습니다.

그것들을 유지하는 것이 고통스럽습니까? numpy에서 온 사람들이 Julia에서 집과 같은 편안함을 느끼는 데 도움이 된다고 생각합니다.

ones 및 zeros 유지하므로 종료합니다.