더엑스퍼트 : 젠장 ... 어쩌면 내가 무엇을 이해하지 못합니까? 왜 엉덩이에 치질을 발명합니까?
당신은 오해의 군중에서 혼자가 아닙니다 :)
바이너리 형식인 IMHO는 데이터를 구현에 연결하는 족쇄이며, 유능한 설계 에서 가능한 한 빨리 폐기해야 하는 것입니다. 바이너리 형식은 데이터 패키징에 적합합니다. 예를 들어, MT4에서는 데이터가 저장되는 방식입니다. 그러나 거기에는 네트워크의 부하를 줄이기 위해 합리적으로 수행되며 작성자 / 리더조차도 내부 개발입니다.
그럼 뭐가 그렇게 까다롭습니까? 나중에 이 형식에 대한 나만의 편집기를 작성할 수 있고 더 많은 문제가 있습니까? xml, json, ini를 사용하는 것이 더 정확하더라도
바이너리 형식인 IMHO는 데이터를 구현에 연결하는 족쇄이며, 유능한 설계에서 가능한 한 빨리 폐기해야 하는 것입니다. 바이너리 형식은 데이터 패키징에 적합합니다. 예를 들어, MT4에서는 데이터가 저장되는 방식입니다. 그러나 거기에는 네트워크의 부하를 줄이기 위해 합리적으로 수행되며 작성자 / 리더조차도 내부 개발입니다.
그럼 뭐가 그렇게 까다롭습니까? 나중에 이 형식에 대한 나만의 편집기를 작성할 수 있고 더 많은 문제가 있습니까? xml, json, ini를 사용하는 것이 더 정확하더라도
다른 구현 제안, 나는 반대하지 않습니다. 구현 아이디어를 게시하고, 토론하고, 비교하고, 어느 것이 더 나은지 결정하십시오.
스레드(내)에서 하나의 제안을 보았지만 나머지는 "xml, json, ini를 만들자"만 말하고 아무도 그리드 로딩이 이 모든 것에서 어떻게 구현될지에 대해 말하지 않았습니다.
이진 링크 테이블은 이해하기 매우 간단합니다. 열을 살펴보고 배포할 대상을 확인하고, 받을 행을 확인합니다(테이블이 정사각형이므로 그것을 인식하는 방법에 동의).
...
그건 그렇고, xml은 바이너리 표현보다 유효성 검사가 훨씬 쉽습니다. 그리고 저장 \ 복원은 본질적으로 시간이 중요하지 않습니다.
관계의 이진 표현을 확인하는 것이 복잡하다고 생각하십니까?
어려운 경우의 예를 들어 주십시오.
ZY 그리고 나로서는 예가 생각되지 않은 것이 아니라 바이너리 테이블로 연결을 나타낼 때 어떤 연결의 유효성을 확인하는 것이 어렵다는 것이 어떤 토폴로지인지 상상조차 할 수 없다는 것입니다.
어려운 경우의 예를 들어 주십시오.
잘 봐. 저장 형식을 약간 변경했거나 데이터가 잘못되었으며 배열의 크기 대신 이중의 아래쪽 부분을 얻는다고 가정해 보겠습니다. 거대한 배열.
그리고 xml에는 태그로 싸인 크기가 있습니다.
1. 왜 안되지 .
보편적인 기반 이 없기 때문입니다. 3개의 그리드만 기억했습니다.
잘 봐. 저장 형식을 약간 변경했거나 데이터가 잘못되었으며 배열의 크기 대신 이중의 아래쪽 부분을 얻는다고 가정해 보겠습니다. 거대한 배열.
그리고 xml에는 태그로 싸인 크기가 있습니다.
"저장 형식이 약간 변경되었습니다."는 xml을 avi로 변경했는데 눈치채지 못한 것처럼 들립니다.
모든 형식 변경은 두 형식을 모두 잘 아는 사람이 처리합니다. + 형식을 변경할 때는 디버깅 및 테스트가 불가피합니다.
그래서 저장포맷을 조금 바꿔서 논할 수 없다.
손실되는 데이터에 관해서는(글쎄, double과 olong을 함께 저장하는 것은 권장되지 않고 정확함) 파일 읽기의 정확성을 확인하기 위해 해시 양을 쓰지 않기 위해 데이터가 잘못될 수 있을 때 다른 옵션을 예상하지 않습니다. .
따라서 그리드에 대한 정보가 포함된 Olong 배열을 저장하는 형식이 있습니다.
[해시 합계] [레이어 수]
[레이어 유형] [뉴런 수]
[레이어 유형] [뉴런 수]
[레이어 유형] [뉴런 수]
[레이어 유형] [뉴런 수]
[레이어 유형] [뉴런 수]바이너리 테이블을 지정하는 ulong'i 파일의 끝으로 더 이동합니다.
ulong을 부울 문자의 배열 [64]로 변환하는 방법, 내 기능은 이미 준비되었습니다.
보편적인 기반 이 없기 때문입니다. 3개의 그리드만 기억했습니다.
나는 동의하지 않지만 지금 논쟁하지 않을 것입니다. 나는 사실이 손에 잡히면 조금 후에 (하루 또는 이틀) 대답 할 것입니다.
한 번 내 이론을 폭파하려고 :)
젠장 ... 어쩌면 내가 무엇을 이해하지 못합니까? 왜 엉덩이에 치질을 발명합니까?
당신은 오해의 군중에서 혼자가 아닙니다 :)
바이너리 형식인 IMHO는 데이터를 구현에 연결하는 족쇄이며, 유능한 설계 에서 가능한 한 빨리 폐기해야 하는 것입니다. 바이너리 형식은 데이터 패키징에 적합합니다. 예를 들어, MT4에서는 데이터가 저장되는 방식입니다. 그러나 거기에는 네트워크의 부하를 줄이기 위해 합리적으로 수행되며 작성자 / 리더조차도 내부 개발입니다.
그럼 뭐가 그렇게 까다롭습니까? 나중에 이 형식에 대한 나만의 편집기를 작성할 수 있고 더 많은 문제가 있습니까? xml, json, ini를 사용하는 것이 더 정확하더라도
당신은 오해의 군중에서 혼자가 아닙니다 :)
바이너리 형식인 IMHO는 데이터를 구현에 연결하는 족쇄이며, 유능한 설계에서 가능한 한 빨리 폐기해야 하는 것입니다. 바이너리 형식은 데이터 패키징에 적합합니다. 예를 들어, MT4에서는 데이터가 저장되는 방식입니다. 그러나 거기에는 네트워크의 부하를 줄이기 위해 합리적으로 수행되며 작성자 / 리더조차도 내부 개발입니다.
그럼 뭐가 그렇게 까다롭습니까? 나중에 이 형식에 대한 나만의 편집기를 작성할 수 있고 더 많은 문제가 있습니까? xml, json, ini를 사용하는 것이 더 정확하더라도
다른 구현 제안, 나는 반대하지 않습니다. 구현 아이디어를 게시하고, 토론하고, 비교하고, 어느 것이 더 나은지 결정하십시오.
스레드(내)에서 하나의 제안을 보았지만 나머지는 "xml, json, ini를 만들자"만 말하고 아무도 그리드 로딩이 이 모든 것에서 어떻게 구현될지에 대해 말하지 않았습니다.
이진 링크 테이블은 이해하기 매우 간단합니다. 열을 살펴보고 배포할 대상을 확인하고, 받을 행을 확인합니다(테이블이 정사각형이므로 그것을 인식하는 방법에 동의).
그리고 다른 형식에서 이것이 모두 어떻게 구현되는지는 아무도 말하지 않습니다.
발언.
이 속도로 자녀는 동의하고 xml에서 중지하고 손주들은 구현을 시작합니다.
투표를 하거나 극단적인 연장자를 선택하세요.
이 속도로 자녀는 동의하고 xml에서 중지하고 손주들은 구현을 시작합니다.
투표를 하거나 극단적인 연장자를 선택하세요.
대안이 제공되지 않는 경우 투표할 내용은 그리드 로딩 알고리즘의 일반적인 아이디어에 대한 설명이 있습니다. 이 알고리즘을 bin에 저장하기 위한 가장 최적의 형식입니다.
로드 알고리즘에 대한 다른 제안은 본 적이 없으며 스토리지 형식에 대한 제안만 보았지만 스토리지 형식 자체는 로드 알고리즘을 기반으로 선택해야 합니다. 한 형식은 알고리즘에 더 유리하고 다른 형식은 다른 알고리즘에 더 유리합니다.
알고리즘에 대한 제안이 있을 것이며 무엇이 더 좋고 어떤 형식으로 저장하는 것이 더 좋은지에 대한 실질적인 토론도 있을 것입니다.