R은 가장 인기 있는 통계입니다. 언어와 여기에서 많은 사람들이 그것을 사용합니다. 따라서 여기에서 비교 질문이 제기됩니다.
구현 알고리즘 자체는 흥미롭고 그에 따라 그 효율성도 중요합니다. 그리고 어떤 언어로 - 그것은 중요하지 않습니다.
MT는 거래 터미널 입니다. 이에 따라 나, 여기 사이트, 이 스레드에서 TS의 개발에 대해 논의합니다. 그러나 거래 결과에 거의 영향을 미치지 않는 프로그래밍 트릭에 대해 논의하는 사람들이 항상 있습니다. 상관 함수 자체가 다른 알고리즘의 일부로 이해되기 때문에 귀하의 질문은 이 오페라에서 나온 것입니다.
이 기능은 거래 결정 블록에서 사용할 수 있지만(최소한 나는 그것을 사용), 거래 신호를 계산하는 주요 시간이 계산적으로 복잡한 다른 알고리즘에 의해 결정되기 때문에 실행 속도는 아무런 역할을 하지 않습니다. μl당 존재합니다.
이것은 실행 단계에 있습니다.
TS의 개발 단계를 고려하면 R은 인터프리터이기 때문에 기본적으로 μl보다 빠릅니다. 알고리즘이 완전히 명확하지 않고 많은 옵션을 시도해야 하는 단계에서 매우 편리합니다. 예를 들어 비교 통화 쌍의 상관 관계. R에서 상관 관계를 확인하는 시간은 초기 벡터의 매우 편리한 형성을 포함하여 clave와 몇 줄을 두드리는 시간입니다.
이러한 기능의 실행 속도와 일반적으로 μl 및 R에서 구현된 다른 기능의 실행 속도를 비교하는 것은 의미가 없다는 의미입니다.
MT는 거래 터미널 입니다. 이에 따라 나, 여기 사이트, 이 스레드에서 TS의 개발에 대해 논의합니다. 그러나 거래 결과에 거의 영향을 미치지 않는 프로그래밍 트릭에 대해 논의하는 사람들이 항상 있습니다. 상관 함수 자체가 다른 알고리즘의 일부로 이해되기 때문에 귀하의 질문은 이 오페라에서 나온 것입니다.
이전에는 TS가 일부 아이디어를 테스트할 수 없었습니다. 일부 알고리즘의 낮은 성능에 반했습니다. 이 경우, 이것이 정확히 일어났습니다. 대안 알고리즘을 통해 최적화 프로그램은 이전에는 합리적인 시간에 계산할 수 없었던 오래된 아이디어를 탐색할 수 있었습니다.
수천억 개의 패턴을 가진 수천억 개의 Pearson CC를 셀 필요가 있을 때 겉보기에 단순한 작업의 저속은 극복할 수 없는 병목 현상이 됩니다. 문제가 계산적 관점에서 너무 무거워 보인다면 이해도가 낮아 제대로 공식화되지 않은 문제라고 말할 수 있습니다. 당신이 옳은 것 같다. 하지만 할 일은 끝났습니다. 그리고 다른 사람들이 비슷한 것을 어떻게 구현하는지 보는 것은 항상 흥미롭습니다.
R은 가장 인기 있는 통계입니다. 언어와 여기에서 많은 사람들이 그것을 사용합니다. 따라서 여기에서 비교 질문이 제기됩니다.
구현 알고리즘 자체는 흥미롭고 그에 따라 그 효율성도 중요합니다. 그리고 어떤 언어로 - 그것은 중요하지 않습니다.
음, 길이가 1000000인 신호와 길이가 100000인 패턴에서 해당 구현은 합리적인 시간에 전혀 계산되지 않을 것입니다. 900001x100000 크기의 임시 행렬을 생성해야 합니다. :D 하지만 작성하는 데 30초도 채 걸리지 않았으며 특정 작업 크기까지 충분히 적용할 수 있습니다. fft / convolve를 통해 모두 동일하게 구현할 수 있습니다. 이 경우 더 많은 코드를 작성해야 하지만 작업 속도는 C 코드보다 훨씬 열등하지 않습니다.
R은 복잡한 모델을 프로토타이핑하는 데 매우 편리합니다. 이것이 R의 장점입니다. 코드 속도는 기술과 경험의 문제입니다.
1. 일부 R 구조 및 데이터 유형 은 다른 것보다 빠릅니다(변경 가능 유형 대 불변 유형(목록 대 환경), lapply/sapply/etc, S4 대 R6).
2. 일부 문제에 대한 R의 병렬화 용이성으로 인해 다른 언어 + 계산으로 빠른 코드를 작성하는 데 시간이 걸리는 것보다 더 빨리 느린 코드로 솔루션을 얻을 수 있습니다.
3. 언어의 개별 작업이 보편적으로 이루어지지만 비효율적입니다. C++에서 작지만 계산적으로 무거운 기능을 구현하면 모든 코드를 C와 유사한 언어로 작성하는 경우와 같이 개발 속도를 크게 줄이지 않고도 놀라운 결과를 얻을 수 있습니다. 예를 들어 R에서 행 또는 열별로 행렬의 요소를 합산하는 것은 rowSums/colSums/apply(, 1, sum)/apply(, 2, sum)보다 4~15배 더 빠르게 수행할 수 있습니다.
음, 길이가 1000000인 신호와 길이가 100000인 패턴에서 해당 구현은 합리적인 시간에 전혀 계산되지 않을 것입니다. 900001x100000 크기의 임시 행렬을 생성해야 합니다. :D 하지만 작성하는 데 30초도 채 걸리지 않았으며 특정 작업 크기까지 충분히 적용할 수 있습니다. fft / convolve를 통해 모두 동일하게 구현할 수 있습니다. 이 경우 더 많은 코드를 작성해야 하지만 작업 속도는 C 코드보다 훨씬 열등하지 않습니다.
R은 복잡한 모델을 프로토타이핑하는 데 매우 편리합니다. 이것이 R의 장점입니다. 코드 속도는 기술과 경험의 문제입니다.
1. 일부 R 구조 및 데이터 유형 은 다른 것보다 빠릅니다(변경 가능 유형 대 불변 유형(목록 대 환경), lapply/sapply/etc, S4 대 R6).
2. 일부 문제에 대한 R의 병렬화 용이성으로 인해 다른 언어 + 계산으로 빠른 코드를 작성하는 데 시간이 걸리는 것보다 더 빨리 느린 코드로 솔루션을 얻을 수 있습니다.
3. 언어의 개별 작업이 보편적으로 이루어지지만 비효율적입니다. C++에서 작지만 계산적으로 무거운 기능을 구현하면 모든 코드를 C와 유사한 언어로 작성하는 경우와 같이 개발 속도를 크게 줄이지 않고도 놀라운 결과를 얻을 수 있습니다. 예를 들어 R에서 행 또는 열별로 행렬의 요소를 합산하는 것은 rowSums/colSums/apply(, 1, sum)/apply(, 2, sum)보다 4~15배 더 빠르게 수행할 수 있습니다.
자세한 답변 감사합니다! 나는 항상 같은 문제를 가지고 있습니다 - 내 자신의 약한 능력.
적용(embed(패턴, 길이(신호)), 1, cor, y = 신호, 방법 = '피어슨')
고맙습니다! R이 몇 번째인지 궁금합니다. 신호 길이 1,000,000, 패턴 100,000 - 1초로 바이블 알고리즘을 측정했습니다.
백만 배 더 빠르게! 그래서 무엇? 거래 시스템은 프로세서로 측정됩니까?
백만 배 더 빠르게! 그래서 무엇? 거래 시스템은 프로세서로 측정됩니까?
당신은 콤플렉스가 있습니다.
아니요, 복잡하지 않습니다.
μl과 R은 완전히 다르며 겹치지 않는 시스템입니다. 그리고 무엇을 비교할 것인가? 그리고 당신은 혼자가 아닙니다!
μl과 R은 완전히 다르며 겹치지 않는 시스템입니다. 그리고 무엇을 비교할 것인가? 그리고 당신은 혼자가 아닙니다!
나는 희귀하지 않은 통계의 구현 속도에만 관심이 있었습니다. 모든 언어로 된 작업.
R은 가장 인기 있는 통계입니다. 언어와 여기에서 많은 사람들이 그것을 사용합니다. 따라서 여기에서 비교 질문이 제기됩니다.
구현 알고리즘 자체는 흥미롭고 그에 따라 그 효율성도 중요합니다. 그리고 어떤 언어로 - 그것은 중요하지 않습니다.
나는 희귀하지 않은 통계의 구현 속도에만 관심이 있었습니다. 모든 언어로 된 작업.
R은 가장 인기 있는 통계입니다. 언어와 여기에서 많은 사람들이 그것을 사용합니다. 따라서 여기에서 비교 질문이 제기됩니다.
구현 알고리즘 자체는 흥미롭고 그에 따라 그 효율성도 중요합니다. 그리고 어떤 언어로 - 그것은 중요하지 않습니다.
MT는 거래 터미널 입니다. 이에 따라 나, 여기 사이트, 이 스레드에서 TS의 개발에 대해 논의합니다. 그러나 거래 결과에 거의 영향을 미치지 않는 프로그래밍 트릭에 대해 논의하는 사람들이 항상 있습니다. 상관 함수 자체가 다른 알고리즘의 일부로 이해되기 때문에 귀하의 질문은 이 오페라에서 나온 것입니다.
이 기능은 거래 결정 블록에서 사용할 수 있지만(최소한 나는 그것을 사용), 거래 신호를 계산하는 주요 시간이 계산적으로 복잡한 다른 알고리즘에 의해 결정되기 때문에 실행 속도는 아무런 역할을 하지 않습니다. μl당 존재합니다.
이것은 실행 단계에 있습니다.
TS의 개발 단계를 고려하면 R은 인터프리터이기 때문에 기본적으로 μl보다 빠릅니다. 알고리즘이 완전히 명확하지 않고 많은 옵션을 시도해야 하는 단계에서 매우 편리합니다. 예를 들어 비교 통화 쌍의 상관 관계. R에서 상관 관계를 확인하는 시간은 초기 벡터의 매우 편리한 형성을 포함하여 clave와 몇 줄을 두드리는 시간입니다.
이러한 기능의 실행 속도와 일반적으로 μl 및 R에서 구현된 다른 기능의 실행 속도를 비교하는 것은 의미가 없다는 의미입니다.
추신.
그러나 당신의 도서관은 제가 MKL5를 공부하지 않아도 되도록 해주었습니다. 감사합니다.
MT는 거래 터미널 입니다. 이에 따라 나, 여기 사이트, 이 스레드에서 TS의 개발에 대해 논의합니다. 그러나 거래 결과에 거의 영향을 미치지 않는 프로그래밍 트릭에 대해 논의하는 사람들이 항상 있습니다. 상관 함수 자체가 다른 알고리즘의 일부로 이해되기 때문에 귀하의 질문은 이 오페라에서 나온 것입니다.
이전에는 TS가 일부 아이디어를 테스트할 수 없었습니다. 일부 알고리즘의 낮은 성능에 반했습니다. 이 경우, 이것이 정확히 일어났습니다. 대안 알고리즘을 통해 최적화 프로그램은 이전에는 합리적인 시간에 계산할 수 없었던 오래된 아이디어를 탐색할 수 있었습니다.
수천억 개의 패턴을 가진 수천억 개의 Pearson CC를 셀 필요가 있을 때 겉보기에 단순한 작업의 저속은 극복할 수 없는 병목 현상이 됩니다. 문제가 계산적 관점에서 너무 무거워 보인다면 이해도가 낮아 제대로 공식화되지 않은 문제라고 말할 수 있습니다. 당신이 옳은 것 같다. 하지만 할 일은 끝났습니다. 그리고 다른 사람들이 비슷한 것을 어떻게 구현하는지 보는 것은 항상 흥미롭습니다.
개발에 조금 더 시간을 할애하고 항상 빠르게 계산하는 것이 더 낫습니까? 아니면 빠르게 개발하고 항상 느린 계산을 참고 견디는 것이 더 낫습니까?
R에서 개발 속도는 빠르지만 계산 속도가 느린 경우 어디에서 계산해야 할까요? 천천히 달리는 슈퍼카를 빨리 개발하시겠습니까? 씨발 슈퍼카가 필요해.
나는 희귀하지 않은 통계의 구현 속도에만 관심이 있었습니다. 모든 언어로 된 작업.
R은 가장 인기 있는 통계입니다. 언어와 여기에서 많은 사람들이 그것을 사용합니다. 따라서 여기에서 비교 질문이 제기됩니다.
구현 알고리즘 자체는 흥미롭고 그에 따라 그 효율성도 중요합니다. 그리고 어떤 언어로 - 그것은 중요하지 않습니다.
음, 길이가 1000000인 신호와 길이가 100000인 패턴에서 해당 구현은 합리적인 시간에 전혀 계산되지 않을 것입니다. 900001x100000 크기의 임시 행렬을 생성해야 합니다. :D 하지만 작성하는 데 30초도 채 걸리지 않았으며 특정 작업 크기까지 충분히 적용할 수 있습니다. fft / convolve를 통해 모두 동일하게 구현할 수 있습니다. 이 경우 더 많은 코드를 작성해야 하지만 작업 속도는 C 코드보다 훨씬 열등하지 않습니다.
R은 복잡한 모델을 프로토타이핑하는 데 매우 편리합니다. 이것이 R의 장점입니다. 코드 속도는 기술과 경험의 문제입니다.
1. 일부 R 구조 및 데이터 유형 은 다른 것보다 빠릅니다(변경 가능 유형 대 불변 유형(목록 대 환경), lapply/sapply/etc, S4 대 R6).
2. 일부 문제에 대한 R의 병렬화 용이성으로 인해 다른 언어 + 계산으로 빠른 코드를 작성하는 데 시간이 걸리는 것보다 더 빨리 느린 코드로 솔루션을 얻을 수 있습니다.
3. 언어의 개별 작업이 보편적으로 이루어지지만 비효율적입니다. C++에서 작지만 계산적으로 무거운 기능을 구현하면 모든 코드를 C와 유사한 언어로 작성하는 경우와 같이 개발 속도를 크게 줄이지 않고도 놀라운 결과를 얻을 수 있습니다. 예를 들어 R에서 행 또는 열별로 행렬의 요소를 합산하는 것은 rowSums/colSums/apply(, 1, sum)/apply(, 2, sum)보다 4~15배 더 빠르게 수행할 수 있습니다.
음, 길이가 1000000인 신호와 길이가 100000인 패턴에서 해당 구현은 합리적인 시간에 전혀 계산되지 않을 것입니다. 900001x100000 크기의 임시 행렬을 생성해야 합니다. :D 하지만 작성하는 데 30초도 채 걸리지 않았으며 특정 작업 크기까지 충분히 적용할 수 있습니다. fft / convolve를 통해 모두 동일하게 구현할 수 있습니다. 이 경우 더 많은 코드를 작성해야 하지만 작업 속도는 C 코드보다 훨씬 열등하지 않습니다.
R은 복잡한 모델을 프로토타이핑하는 데 매우 편리합니다. 이것이 R의 장점입니다. 코드 속도는 기술과 경험의 문제입니다.
1. 일부 R 구조 및 데이터 유형 은 다른 것보다 빠릅니다(변경 가능 유형 대 불변 유형(목록 대 환경), lapply/sapply/etc, S4 대 R6).
2. 일부 문제에 대한 R의 병렬화 용이성으로 인해 다른 언어 + 계산으로 빠른 코드를 작성하는 데 시간이 걸리는 것보다 더 빨리 느린 코드로 솔루션을 얻을 수 있습니다.
3. 언어의 개별 작업이 보편적으로 이루어지지만 비효율적입니다. C++에서 작지만 계산적으로 무거운 기능을 구현하면 모든 코드를 C와 유사한 언어로 작성하는 경우와 같이 개발 속도를 크게 줄이지 않고도 놀라운 결과를 얻을 수 있습니다. 예를 들어 R에서 행 또는 열별로 행렬의 요소를 합산하는 것은 rowSums/colSums/apply(, 1, sum)/apply(, 2, sum)보다 4~15배 더 빠르게 수행할 수 있습니다.