7 - OOP에 있는 모든 것의 트리 노드 묶음을 생각할 수 있으며 해시매핑 및 맛을 내기 위해 defans와 함께 솔트링하기 위한 이 모든 것을 생각할 수 있습니다.
8 - 이 모든 것이 프로그래밍이지만 유형별로 엄격한 액세스가 있습니다.
9 - 나는 포인트 7이 악(어두운 면)이고 세계에 문명화된 ood(템플릿과 같은)가 있다는 것을 이해합니다
10 - 내가 멋진 프로그래머라고 생각하는 사람들 중 "OOP는 사악하다"는 말을 점점 더 자주 듣습니다. 방법의 문명화된 사용이 있고 모든 것이 시민적인 방식으로 수행된다면 모든 것에 대한 필요성이 그다지 크지 않다는 것이 밝혀졌습니다. 예, 일상적이지만 코드 작성의 응용 프로그램 속도는 제 것보다 몇 배나 빠릅니다. (
11 - 현대 기능 언어에서 OOP가 특정 단계, 이러한 모든 기능 확장 등에서 모방된다는 것을 분명히 이해하고 있습니다. 즉, 함수형 프로그래밍 접근 방식을 이해하기 시작합니다(포인트 3).
일반적으로 나는 언어의 구문과 큰 차이가 없다고 생각합니다. 원칙은 변경되지 않으며 엄격한 언어가 있습니다. 엄격한 언어는 없습니다. 엄격하지 않은 코드를 작성하는 것은 문제가 됩니다. 그리고 C++ C# RQ GO JS Ruby란 무엇인가 큰 차이가 없다
낮은 수준의 코드가 더 빠를 것으로 예상됩니다(표준 코드보다 빠른 속도의 코드를 직접 작성할 수 있지만 그 이유는 무엇입니까?) - 예를 들어, 표준보다 빠르게 정렬을 작성하는 것은 매우 쉽지만 적시정렬의 본질은 속도가 아니다))))) 그러나 최소한의 행동수와 최소한의 행동이 항상 가장 빠른 방법은 아니지만 나름대로 아주 좋은 방법이다.
마이크로프로세서에 대해 - 글쎄, 일반적으로 그들은 이것으로부터 배우기 시작합니다. 언어의 본질은 그렇게 중요하지 않지만. 높은 수준의 코드는 많은 부분의 코드로 작업할 수 있도록 하고 낮은 수준의 코드는 더 보편적입니다.
아니, 아니. OOP 없음)) OOP는 절차에 대한 래퍼입니다. 즉, 절차적 언어 의 확장이지만 고유한 패러다임이 있습니다. 개인적으로 OOP가 이미 고급 언어를 어지럽히고 있다고 생각합니다)) 나열된 모든 언어는 Q를 제외한 고급 언어입니다. Q에 대해 생각하지 않았을 것입니다. Q는 언어 K의 연속입니다. KDB+ 데이터베이스는 Q 언어로 구현됩니다.
Kdb+, 부터 Kx 는
과거 시계열의 고성능 크로스 플랫폼 컬럼 데이터베이스
메모리의 컴퓨팅 엔진
실시간 스트림 프로세서
표현 쿼리 및 q라는 프로그래밍 언어
C와 완전히 다른 패러다임이 있습니다. 제 생각에는 벡터 논리가 있습니다. 그러나 여기 포럼에서 가장 존경받는 프로그래머조차도이 언어에 대해 들어 본 적이 없다고 생각합니다))
Arthur Whitney는 q 프로그래밍 언어와 kdb+ 데이터베이스를 개발했습니다. Kx Systems, Inc.에서 출시 2003년 q의 주요 디자인 목표는 표현력, 속도 및 효율성이었습니다. 그녀는 그들에게 상대가 되지 않습니다. 설계 절충점은 장황한 기존 데이터베이스 프로그래밍 환경에서 온 프로그래머를 혼란스럽게 할 수 있는 간결함입니다. 예를 들어, C++, Java, C# 또는 Python - 및 관계형 DBMS. q 프로그래밍의 신들은 ASCII 코어 덤프처럼 보이는 프로그램을 좋아하지만 이 튜토리얼은 우리 모두를 위한 것입니다.
Q에서 진화 APL (프로그래밍 언어) 수학적 표기법으로 처음 발명 케네스 아이버슨 1950년대 하버드 대학교에서 APL은 1960년대에 IBM에서 벡터 프로그래밍 언어로 도입했습니다. 즉, 단일 작업으로 숫자 목록을 처리합니다. 그는 많은 위기가 필요한 금융 및 기타 산업에서 성공했습니다.
미토콘드리아 DNA q는 APL에서 A로 추적합니다. A+ 그리고 k에게. 벡터에 대한 복잡한 계산을 빠르게 수행하도록 모두 잘 조정되었습니다. q/kdb+의 새로운 점은 관계형 패러다임에서 많은 양의 시계열 데이터를 매우 효율적으로 처리한다는 것입니다. 구문은 SQL 92와 유사한 "선택" 표현식을 허용하고 내장 함수 모음은 완전하고 강력한 저장 프로시저 언어를 제공합니다.
q 유전자는 또한 일부 lisp : q의 기본 데이터 구성은 목록입니다. 표기법과 용어는 다르지만 기호는 다이어그램의 해당 기호에서 가져옵니다.
APL q 가계도 함수형 프로그래밍의 영향을 보여줍니다. 순수 함수 프로그래밍을 소개한 그의 1977년 Turing Award 강의에서, 배후 APL의 영감을 인정합니다. q가 순전히 기능적이지는 않지만 기본 데이터 구조인 목록 및 사전조차도 수학적 매핑으로 취급된다는 점에서 매우 기능적입니다.
0.1 철학
숙련된 q 개발자는 현재 "전통적인 프로그래밍"이라고 불리는 C++, Java, C# 또는 Python과 같은 기존 프로그래밍 환경과 다르게 생각합니다. - 올바른 사고방식을 갖도록 하기 위해 우리는 초보자 q(이후 qbie로 알려짐)에 대한 몇 가지 잠재적인 휴식을 요약하고 있습니다.
기존 데이터베이스 프로그래밍에서 데이터와 관련된 몇 가지 문제를 상기하십시오.
개체 모음과 같은 메모리 내 표현은 유지하려면 테이블과 같은 다른 표현에 매핑되어야 합니다. 올바른 개체 관계 매핑을 얻으려면 상당한 노력이 필요합니다.
개체는 전송을 위한 다른 표현, 일반적으로 참조 체인을 평면화하는 일종의 이진 또는 XML 형식에 매핑되어야 합니다.
선택, 그룹화 및 집계와 같은 데이터 조작은 대규모 데이터 세트에 대한 데이터베이스 서버의 저장 프로시저에서 가장 잘 수행됩니다. 복잡한 수치 계산은 애플리케이션 서버의 데이터베이스와 별도로 수행하는 것이 가장 좋습니다.
GUI를 표시하기 위해 데이터를 변환하는 것은 브라우저의 HTML5 및 JavaScript와 같은 별도의 레이어에서 수행하는 것이 가장 좋습니다.
기존 프로그래밍 디자인의 대부분은 다양한 보기를 올바르게 가져오는 데 사용되며 리소스를 마샬링하고 다양한 보기를 동기화 상태로 유지하기 위해 많은 코드 줄이 필요합니다. q / kdb+에서는 놀라울 정도로 간단합니다.
해석 Q는 컴파일되지 않고 해석됩니다. 실행하는 동안 데이터와 기능은 메모리의 작업 공간에 있습니다. 테스트 및 디버깅에 필요한 모든 런타임 정보를 작업 공간에서 즉시 사용할 수 있기 때문에 개발 주기의 반복은 일반적으로 빠릅니다. Q 프로그램은 스크립트라는 일반 텍스트 파일로 저장되고 실행됩니다. 통역사 평가하고 구문 분석 루틴을 사용할 수 있으므로 제어된 방식으로 코드를 동적으로 생성할 수 있습니다.
유형 Q는 유형 검사가 대부분 눈에 거슬리지 않는 동적으로 유형이 지정된 언어입니다. 각 변수에는 현재 할당된 값의 유형이 있으며 대부분의 숫자 연산에 대해 유형 승격이 자동으로 발생합니다. 유형은 동종 목록에 대한 작업 중에 확인됩니다.
평가 순서 q가 왼쪽에서 오른쪽으로 입력되면 표현식은 오른쪽에서 왼쪽으로 또는 q 신이 선호하는 대로 왼쪽에서 오른쪽으로 평가됩니다. 즉, 함수가 오른쪽 인수에 적용됩니다. 연산자 우선순위가 없으며 괄호 없이 함수 응용 프로그램을 작성할 수 있습니다. 구두점 노이즈가 크게 줄어듭니다.
Null 및 Infinity 값 클래식 SQL에서 이 값은 NULL은 모든 유형의 필드에 대해 누락된 데이터를 나타내며 저장 공간을 차지하지 않습니다. q에는 null 값이 입력되고 null이 아닌 값과 같은 공간을 차지합니다. 숫자 유형에도 무한한 값이 있습니다. 무한 및 0 값은 (대부분) 예측 가능한 결과로 산술 및 기타 연산에 참여할 수 있습니다.
통합 I /O는 외부 세계에 대한 창 역할을 하는 함수 설명자에 의해 처리됩니다. 이러한 핸들이 초기화되면 핸들에 값을 전달하는 것이 쓰기입니다.
테이블 지향 아이템을 포기할 때, 여기에 들어오는 당신. 기존 언어와 달리 q에서는 클래스, 개체, 상속 또는 가상 메서드를 찾을 수 없습니다. 대신 q는 일급 객체로 테이블을 갖습니다. 항목의 부족은 언뜻보기에 보이는 것만큼 강력하지 않습니다. 개체는 기본적으로 q-사전으로 모델링되는 영광스러운 레코드(즉, 명명된 필드가 있는 엔터티)입니다. 테이블은 항목의 사전 목록으로 생각할 수 있습니다.
정렬된 목록 기존 SQL은 중복 없이 순서가 지정되지 않은 집합의 대수이므로 행 순서와 열 순서가 정의되지 않습니다. 이는 시계열 처리를 번거롭고 느리게 만듭니다. q에서 데이터 구조는 정렬된 목록을 기반으로 하므로 시계열은 생성된 순서를 유지합니다. 또한 단순 목록은 연속 저장 공간을 차지하므로 빅 데이터 처리 속도가 빠릅니다. 매우 빠릅니다.
열 지향 SQL 테이블은 스토리지 전체에 분산된 행으로 구성되며 해당 행 내의 필드에 작업이 적용됩니다. Q 테이블은 연속 스토리지의 열 목록이며 모든 열에 작업이 적용됩니다.
인메모리 데이터베이스 kdb+는 지속적으로 지원되는 인메모리 데이터베이스로 생각할 수 있습니다. 데이터 처리가 q로 이루어지기 때문에 별도의 저장 프로시저 언어가 없습니다. 사실, kdb+는 파일 시스템에 기록된 다음 메모리 매핑된 q 열의 직렬화된 목록을 포함합니다.
기능의 기능이 다릅니다. 배열 크기에 대한 좋은 예가 아닐 수도 있습니다. 이것은 메모리 사용 및 액세스 측면에서 변수와 동일하며 실제로 배열이 선언될 때 채워진 메모리 셀의 변수입니다. 그러나 배열의 최대값 또는 최소값, 또는 10개 변수의 주기 조건에서 계산하면 네, 그럴 가치가 없습니다. 먼저 계산하고 대입하는 것이 좋습니다.
그리고 내가 이해하는 한 배열 요소, 구조 요소는 메모리에 특정 주소가 있는 변수이며 이것은 표기의 편의일 뿐입니다. A[10] 및 10개의 변수 A1 A2 ... A10은 액세스 및 크기가 동일합니다. 종류는 동일)
그리고 내가 이해하는 한 배열 요소, 구조 요소는 메모리에 특정 주소가 있는 변수이며 이것은 표기의 편의일 뿐입니다. A[10] 및 10개의 변수 A1 A2 ... A10은 액세스 및 크기가 동일합니다. 종류는 동일)
물리적으로 CPU 명령에 있는 경우
배열은 메모리 조각이고 배열 요소에 대한 액세스는 이 메모리 조각의 시작 부분에서 요소 인덱스를 계산하고 저장된 유형에 따라 데이터(바이트)를 추출합니다.
이것이 알고리즘의 논리라면 예 - 이것은 인덱싱된 변수입니다.
일반적으로 연구 중인 문제에 대한 유일한 올바른 조언은 입력 매개변수의 유효성 을 검사할 수 있습니다. 저장 - 스택에서 데이터를 푸시합니다. 레지스터를 저장합니다. 레지스터를 복원합니다. 함수 호출 - 호출한 다음 반환합니다. 내 말은 백그라운드에서 많은 일들이 일어날 수 있고 우리는 그것을 볼 수 없다는 것입니다. 따라서 (int i=0; i<size; i++) for (int i=0; i<size; i++) 를 사용하는 것이 더 안전하고 우리가 기대하는 것을 수행하기 위해 컴파일러에 의존하지 않습니다.
하자. 먼저 - 실행 파일을 정의한 다음 - 실행 파일의 실행을 정의합니다.
나는 그것을 이해했다. defin은 대규모 프로젝트 의 어셈블리 속도만 높지만 실행 파일의 코드를 실행하지 않는 것과는 다릅니다.
일반적으로 독학의 경우 실행 속도 측면에서 하드웨어 수준에서 코드를 최대한 구현하는 데 관심이 있습니다.어떤 아키텍처나 영역에서 중요하지 않습니다.
메모리에서 완전히 실행되는 언어가 있다는 것을 알고 있습니다. 이것이 아마도 가장 빠른 솔루션이 될 것입니다.
나는 그것을 이해했다. 정의는 대규모 프로젝트의 어셈블리 속도만 높지만 실행 파일의 코드를 실행하지 않는 것과는 다릅니다.
일반적으로 독학의 경우 실행 속도 측면에서 하드웨어 수준에서 코드를 최대한 구현하는 데 관심이 있습니다.어떤 아키텍처나 영역에서 중요하지 않습니다.
메모리에서 완전히 실행되는 언어가 있다는 것을 알고 있습니다. 이것이 아마도 가장 빠른 솔루션이 될 것입니다.
정의는 가속을 전혀 제공하지 않습니다. #define FIVE 5와 같은 소수를 정의하는 작은 예외가 있을 수 있습니다.
기본값의 아이디어는 코드를 더 읽기 쉽고 변경하기 쉽게 만드는 것입니다. 모든 것. 그 후에 기능이 종료됩니다.
마이크로컨트롤러와 드라이버는 C 또는 어셈블러로 작성됩니다.
어떤 다른 옵션이 있습니까? Q 언어를 공부한 사람이 있습니까?
IMHO 프로그래밍 단계))
1 - 나는 아무것도 이해하지 못한다
2 - 절차적 스타일을 이해합니다.
3 - 기능에 대해서는 무엇이든 쓸 수 있다고 생각합니다)
4 - OOP를 이해하지 못한다는 것을 이해합니다.
5 - 나는 OOP를 이해한다
6 - OOP를 엄격하게 이해하고 있습니다.
7 - OOP에 있는 모든 것의 트리 노드 묶음을 생각할 수 있으며 해시매핑 및 맛을 내기 위해 defans와 함께 솔트링하기 위한 이 모든 것을 생각할 수 있습니다.
8 - 이 모든 것이 프로그래밍이지만 유형별로 엄격한 액세스가 있습니다.
9 - 나는 포인트 7이 악(어두운 면)이고 세계에 문명화된 ood(템플릿과 같은)가 있다는 것을 이해합니다
10 - 내가 멋진 프로그래머라고 생각하는 사람들 중 "OOP는 사악하다"는 말을 점점 더 자주 듣습니다. 방법의 문명화된 사용이 있고 모든 것이 시민적인 방식으로 수행된다면 모든 것에 대한 필요성이 그다지 크지 않다는 것이 밝혀졌습니다. 예, 일상적이지만 코드 작성의 응용 프로그램 속도는 제 것보다 몇 배나 빠릅니다. (
11 - 현대 기능 언어에서 OOP가 특정 단계, 이러한 모든 기능 확장 등에서 모방된다는 것을 분명히 이해하고 있습니다. 즉, 함수형 프로그래밍 접근 방식을 이해하기 시작합니다(포인트 3).
일반적으로 나는 언어의 구문과 큰 차이가 없다고 생각합니다. 원칙은 변경되지 않으며 엄격한 언어가 있습니다. 엄격한 언어는 없습니다. 엄격하지 않은 코드를 작성하는 것은 문제가 됩니다. 그리고 C++ C# RQ GO JS Ruby란 무엇인가 큰 차이가 없다
낮은 수준의 코드가 더 빠를 것으로 예상됩니다(표준 코드보다 빠른 속도의 코드를 직접 작성할 수 있지만 그 이유는 무엇입니까?) - 예를 들어, 표준보다 빠르게 정렬을 작성하는 것은 매우 쉽지만 적시정렬의 본질은 속도가 아니다))))) 그러나 최소한의 행동수와 최소한의 행동이 항상 가장 빠른 방법은 아니지만 나름대로 아주 좋은 방법이다.
마이크로프로세서에 대해 - 글쎄, 일반적으로 그들은 이것으로부터 배우기 시작합니다. 언어의 본질은 그렇게 중요하지 않지만. 높은 수준의 코드는 많은 부분의 코드로 작업할 수 있도록 하고 낮은 수준의 코드는 더 보편적입니다.
OOP는 절차에 대한 래퍼입니다.
즉, 절차적 언어 의 확장이지만 고유한 패러다임이 있습니다.
개인적으로 OOP가 이미 고급 언어를 어지럽히고 있다고 생각합니다))
나열된 모든 언어는 Q를 제외한 고급 언어입니다.
Q에 대해 생각하지 않았을 것입니다. Q는 언어 K의 연속입니다.
KDB+ 데이터베이스는 Q 언어로 구현됩니다.
Kdb+, 부터 Kx 는
C와 완전히 다른 패러다임이 있습니다. 제 생각에는 벡터 논리가 있습니다.
그러나 여기 포럼에서 가장 존경받는 프로그래머조차도이 언어에 대해 들어 본 적이 없다고 생각합니다))
0.0 진화 Q
Arthur Whitney는 q 프로그래밍 언어와 kdb+ 데이터베이스를 개발했습니다. Kx Systems, Inc.에서 출시 2003년 q의 주요 디자인 목표는 표현력, 속도 및 효율성이었습니다.
그녀는 그들에게 상대가 되지 않습니다. 설계 절충점은 장황한 기존 데이터베이스 프로그래밍 환경에서 온 프로그래머를 혼란스럽게 할 수 있는 간결함입니다.
예를 들어, C++, Java, C# 또는 Python - 및 관계형 DBMS. q 프로그래밍의 신들은 ASCII 코어 덤프처럼 보이는 프로그램을 좋아하지만 이 튜토리얼은 우리 모두를 위한 것입니다.
Q에서 진화 APL (프로그래밍 언어) 수학적 표기법으로 처음 발명 케네스 아이버슨 1950년대 하버드 대학교에서
APL은 1960년대에 IBM에서 벡터 프로그래밍 언어로 도입했습니다. 즉, 단일 작업으로 숫자 목록을 처리합니다.
그는 많은 위기가 필요한 금융 및 기타 산업에서 성공했습니다.
미토콘드리아 DNA q는 APL에서 A로 추적합니다. A+ 그리고 k에게. 벡터에 대한 복잡한 계산을 빠르게 수행하도록 모두 잘 조정되었습니다.
q/kdb+의 새로운 점은 관계형 패러다임에서 많은 양의 시계열 데이터를 매우 효율적으로 처리한다는 것입니다.
구문은 SQL 92와 유사한 "선택" 표현식을 허용하고 내장 함수 모음은 완전하고 강력한 저장 프로시저 언어를 제공합니다.
q 유전자는 또한 일부 lisp : q의 기본 데이터 구성은 목록입니다. 표기법과 용어는 다르지만 기호는 다이어그램의 해당 기호에서 가져옵니다.
APL q 가계도 함수형 프로그래밍의 영향을 보여줍니다.
순수 함수 프로그래밍을 소개한 그의 1977년 Turing Award 강의에서, 배후 APL의 영감을 인정합니다.
q가 순전히 기능적이지는 않지만 기본 데이터 구조인 목록 및 사전조차도 수학적 매핑으로 취급된다는 점에서 매우 기능적입니다.
0.1 철학
숙련된 q 개발자는 현재 "전통적인 프로그래밍"이라고 불리는 C++, Java, C# 또는 Python과 같은 기존 프로그래밍 환경과 다르게 생각합니다. -
올바른 사고방식을 갖도록 하기 위해 우리는 초보자 q(이후 qbie로 알려짐)에 대한 몇 가지 잠재적인 휴식을 요약하고 있습니다.
기존 데이터베이스 프로그래밍에서 데이터와 관련된 몇 가지 문제를 상기하십시오.
올바른 개체 관계 매핑을 얻으려면 상당한 노력이 필요합니다.
복잡한 수치 계산은 애플리케이션 서버의 데이터베이스와 별도로 수행하는 것이 가장 좋습니다.
기존 프로그래밍 디자인의 대부분은 다양한 보기를 올바르게 가져오는 데 사용되며 리소스를 마샬링하고 다양한 보기를 동기화 상태로 유지하기 위해 많은 코드 줄이 필요합니다.
q / kdb+에서는 놀라울 정도로 간단합니다.
해석 Q는 컴파일되지 않고 해석됩니다. 실행하는 동안 데이터와 기능은 메모리의 작업 공간에 있습니다.
테스트 및 디버깅에 필요한 모든 런타임 정보를 작업 공간에서 즉시 사용할 수 있기 때문에 개발 주기의 반복은 일반적으로 빠릅니다.
Q 프로그램은 스크립트라는 일반 텍스트 파일로 저장되고 실행됩니다. 통역사 평가하고 구문 분석 루틴을 사용할 수 있으므로 제어된 방식으로 코드를 동적으로 생성할 수 있습니다.
유형 Q는 유형 검사가 대부분 눈에 거슬리지 않는 동적으로 유형이 지정된 언어입니다.
각 변수에는 현재 할당된 값의 유형이 있으며 대부분의 숫자 연산에 대해 유형 승격이 자동으로 발생합니다. 유형은 동종 목록에 대한 작업 중에 확인됩니다.
평가 순서 q가 왼쪽에서 오른쪽으로 입력되면 표현식은 오른쪽에서 왼쪽으로 또는 q 신이 선호하는 대로 왼쪽에서 오른쪽으로 평가됩니다. 즉, 함수가 오른쪽 인수에 적용됩니다.
연산자 우선순위가 없으며 괄호 없이 함수 응용 프로그램을 작성할 수 있습니다. 구두점 노이즈가 크게 줄어듭니다.
Null 및 Infinity 값 클래식 SQL에서 이 값은 NULL은 모든 유형의 필드에 대해 누락된 데이터를 나타내며 저장 공간을 차지하지 않습니다.
q에는 null 값이 입력되고 null이 아닌 값과 같은 공간을 차지합니다. 숫자 유형에도 무한한 값이 있습니다.
무한 및 0 값은 (대부분) 예측 가능한 결과로 산술 및 기타 연산에 참여할 수 있습니다.
통합 I /O는 외부 세계에 대한 창 역할을 하는 함수 설명자에 의해 처리됩니다.
이러한 핸들이 초기화되면 핸들에 값을 전달하는 것이 쓰기입니다.
테이블 지향 아이템을 포기할 때, 여기에 들어오는 당신. 기존 언어와 달리 q에서는 클래스, 개체, 상속 또는 가상 메서드를 찾을 수 없습니다.
대신 q는 일급 객체로 테이블을 갖습니다. 항목의 부족은 언뜻보기에 보이는 것만큼 강력하지 않습니다.
개체는 기본적으로 q-사전으로 모델링되는 영광스러운 레코드(즉, 명명된 필드가 있는 엔터티)입니다. 테이블은 항목의 사전 목록으로 생각할 수 있습니다.
정렬된 목록 기존 SQL은 중복 없이 순서가 지정되지 않은 집합의 대수이므로 행 순서와 열 순서가 정의되지 않습니다.
이는 시계열 처리를 번거롭고 느리게 만듭니다. q에서 데이터 구조는 정렬된 목록을 기반으로 하므로 시계열은 생성된 순서를 유지합니다.
또한 단순 목록은 연속 저장 공간을 차지하므로 빅 데이터 처리 속도가 빠릅니다. 매우 빠릅니다.
열 지향 SQL 테이블은 스토리지 전체에 분산된 행으로 구성되며 해당 행 내의 필드에 작업이 적용됩니다. Q 테이블은 연속 스토리지의 열 목록이며 모든 열에 작업이 적용됩니다.
인메모리 데이터베이스 kdb+는 지속적으로 지원되는 인메모리 데이터베이스로 생각할 수 있습니다. 데이터 처리가 q로 이루어지기 때문에 별도의 저장 프로시저 언어가 없습니다.
사실, kdb+는 파일 시스템에 기록된 다음 메모리 매핑된 q 열의 직렬화된 목록을 포함합니다.
어떤 작은 여자도 문제를 위해 돼지를 사지 않았다 (c) 민속 지혜
토론에 들어갈 수 있었고 휴식은 없습니다 ))
더 많은 옵션을 테스트했지만 MQL5는 런타임 최적화를 매우 잘 수행하지만 여전히 .... 스마트 컴파일러에 의존하는 것은 옳지 않습니다. 추가 함수 호출은 최상의 솔루션이 아닙니다.
바로 IMHO
첫 번째 루프 - 배열 인덱스 를 내림차순으로 반복
하단 루프 - 오름차순 인덱스 반복
어떤 작은 여자도 문제를 위해 돼지를 사지 않았다 (c) 민속 지혜
토론에 들어갈 수 있었고 휴식은 없습니다 ))
더 많은 옵션을 테스트했지만 MQL5는 런타임 최적화를 매우 잘 수행하지만 여전히 .... 스마트 컴파일러에 의존하는 것은 옳지 않습니다. 추가 함수 호출은 최상의 솔루션이 아닙니다.
바로 IMHO
첫 번째 루프 - 배열 인덱스 를 내림차순으로 반복
하단 루프 - 오름차순 인덱스 반복
기능의 기능이 다릅니다. 배열 크기에 대한 좋은 예가 아닐 수도 있습니다. 이것은 메모리 사용 및 액세스 측면에서 변수와 동일하며 실제로 배열이 선언될 때 채워진 메모리 셀의 변수입니다. 그러나 배열의 최대값 또는 최소값, 또는 10개 변수의 주기 조건에서 계산하면 네, 그럴 가치가 없습니다. 먼저 계산하고 대입하는 것이 좋습니다.
그리고 내가 이해하는 한 배열 요소, 구조 요소는 메모리에 특정 주소가 있는 변수이며 이것은 표기의 편의일 뿐입니다. A[10] 및 10개의 변수 A1 A2 ... A10은 액세스 및 크기가 동일합니다. 종류는 동일)
그리고 내가 이해하는 한 배열 요소, 구조 요소는 메모리에 특정 주소가 있는 변수이며 이것은 표기의 편의일 뿐입니다. A[10] 및 10개의 변수 A1 A2 ... A10은 액세스 및 크기가 동일합니다. 종류는 동일)
물리적으로 CPU 명령에 있는 경우
배열은 메모리 조각이고 배열 요소에 대한 액세스는 이 메모리 조각의 시작 부분에서 요소 인덱스를 계산하고 저장된 유형에 따라 데이터(바이트)를 추출합니다.
이것이 알고리즘의 논리라면 예 - 이것은 인덱싱된 변수입니다.
일반적으로 연구 중인 문제에 대한 유일한 올바른 조언은 입력 매개변수의 유효성 을 검사할 수 있습니다. 저장 - 스택에서 데이터를 푸시합니다. 레지스터를 저장합니다. 레지스터를 복원합니다. 함수 호출 - 호출한 다음 반환합니다. 내 말은 백그라운드에서 많은 일들이 일어날 수 있고 우리는 그것을 볼 수 없다는 것입니다. 따라서 (int i=0; i<size; i++) for (int i=0; i<size; i++) 를 사용하는 것이 더 안전하고 우리가 기대하는 것을 수행하기 위해 컴파일러에 의존하지 않습니다.
물리적으로 CPU 명령에 있는 경우
배열은 메모리 조각이고 배열 요소에 대한 액세스는 이 메모리 조각의 시작 부분에서 요소 인덱스를 계산하고 저장된 유형에 따라 데이터(바이트)를 추출합니다.
이것이 알고리즘의 논리라면 예 - 이것은 인덱싱된 변수입니다.
일반적으로 연구 중인 문제에 대한 유일한 올바른 조언은 https://www.mql5.com/en/forum/354662/page4#comment_19039624 입니다.
저도 동의합니다. 컴파일러는 블랙박스라서 장담할 수 없습니다.
가장 중요한 것은 생각한 모든 것이 의도한 대로 작동한다는 것입니다)))