다른 구현 제안, 나는 반대하지 않습니다. 구현 아이디어를 게시하고, 토론하고, 비교하고, 어느 것이 더 나은지 결정하십시오.
한 열의 모든 데이터를 csv 텍스트 파일에 씁니다. 아키텍처에 따라 이 열에 대한 읽기/쓰기 규칙이 있습니다. 이제 그리드를 훈련 할 때 이렇게 합니다. 네트워크의 모든 설정과 가중치를 하나의 열에 저장합니다. 이것은 염색체를 나타내는 것과 동일하며 GA에서 읽기/쓰기가 쉽습니다.
주 : 한 열의 모든 데이터를 csv 텍스트 파일에 씁니다. 아키텍처에 따라 이 열에 대한 읽기/쓰기 규칙이 있습니다. 이제 그리드를 훈련할 때 이렇게 합니다. 네트워크의 모든 설정과 가중치를 하나의 열에 저장합니다. 이것은 염색체를 나타내는 것과 동일하며 GA에서 읽기/쓰기가 쉽습니다.
아키텍처 변경 규칙이 변경되었습니까?
그리고 만약 아키텍처가 프로그래머가 아니라 사용자에 의해 만들어진다면 누가 새로운 규칙을 작성할까요?
그러면 재채기할 때마다 몸이 좋지 않을 것입니다. 각 아키텍처에 대해 새로운 로딩 규칙을 작성하는 것은 (IMHO) 지겹습니다.
그리고 만약 아키텍처가 프로그래머가 아니라 사용자에 의해 만들어졌다면 누가 새로운 규칙을 정할 것인가?
그러면 재채기할 때마다 몸이 좋지 않을 것입니다. 각 아키텍처에 대해 새로운 로딩 규칙을 작성하는 것은 (IMHO) 지겹습니다.
아키텍처에 따라 로딩 규칙을 생성하는 알고리즘의 변형이 가능한가?
나는 이 문제를 더 단순하게 본다.
일반적으로 뉴런에서 추상화합시다. 블랙박스와 같은 블록 세트가 있습니다. 모든 블록의 설정 열을 만들어야 하므로 다음과 같습니다.
우리는 블록, 얼마나 많은 설정(설정, 가중치 또는 무엇이든 포함)을 요청하고 다음과 같이 대답합니다.
1위 -10
2위 -115
3위 - 214
....
다음으로, 우리는 한 열에 모든 것을 연속적으로 쓰고, 우리는 우리에게서 무엇이 나오는지 항상 알고 있습니다.
따라서 우리는 항상 어떤 설정이 어떤 블록에 속하는지 확인할 수 있습니다. 이를 위해 블록에 대해 "몇 개의 설정이 있습니까?"라고 요청하기만 하면 됩니다.
블록을 조사할 순서에 즉시 동의하면 됩니다. 그게 전부입니다.
위협 미래에 개별 블록 자체가 변경되더라도 아무 것도 깨지지 않으며 모든 것이 이전과 같이 작동합니다. 가장 중요한 것은 폴링 블록의 순서를 변경하지 않는 것입니다. 그러나 순서를 변경하더라도 아무 것도 중단되지 않으며 열을 다시 작성하여 새 블록을 폴링하기만 하면 됩니다.
다른 구현 제안, 나는 반대하지 않습니다. 구현 아이디어를 게시하고, 토론하고, 비교하고, 어느 것이 더 나은지 결정하십시오.
Varum niimand arbaitet? 우선
미샤. 뉴런을 원하십니까? 나는 그것들을 갖고있어.
당신은 아마도 당신 자신(프로그래머)을 위해 그것을 했을 것입니다. "여기에 깃발을 꽂았다가 빼야지, 여기에 청어를 넣었으니 아직 건드리지 마라"
그리고 "주전자용"이 필요합니다.
한 열의 모든 데이터를 csv 텍스트 파일에 씁니다. 아키텍처에 따라 이 열에 대한 읽기/쓰기 규칙이 있습니다. 이제 그리드를 훈련할 때 이렇게 합니다. 네트워크의 모든 설정과 가중치를 하나의 열에 저장합니다. 이것은 염색체를 나타내는 것과 동일하며 GA에서 읽기/쓰기가 쉽습니다.
아키텍처 변경 규칙이 변경되었습니까?
그리고 만약 아키텍처가 프로그래머가 아니라 사용자에 의해 만들어진다면 누가 새로운 규칙을 작성할까요?
그러면 재채기할 때마다 몸이 좋지 않을 것입니다. 각 아키텍처에 대해 새로운 로딩 규칙을 작성하는 것은 (IMHO) 지겹습니다.
아키텍처에 따라 로드 규칙을 생성하는 알고리즘의 변형을 가질 수 있습니까?
아키텍처 변경 규칙이 변경되었습니까?
그리고 만약 아키텍처가 프로그래머가 아니라 사용자에 의해 만들어졌다면 누가 새로운 규칙을 정할 것인가?
그러면 재채기할 때마다 몸이 좋지 않을 것입니다. 각 아키텍처에 대해 새로운 로딩 규칙을 작성하는 것은 (IMHO) 지겹습니다.
아키텍처에 따라 로딩 규칙을 생성하는 알고리즘의 변형이 가능한가?
나는 이 문제를 더 단순하게 본다.
일반적으로 뉴런에서 추상화합시다. 블랙박스와 같은 블록 세트가 있습니다. 모든 블록의 설정 열을 만들어야 하므로 다음과 같습니다.
우리는 블록, 얼마나 많은 설정(설정, 가중치 또는 무엇이든 포함)을 요청하고 다음과 같이 대답합니다.
1위 -10
2위 -115
3위 - 214
....
다음으로, 우리는 한 열에 모든 것을 연속적으로 쓰고, 우리는 우리에게서 무엇이 나오는지 항상 알고 있습니다.
따라서 우리는 항상 어떤 설정이 어떤 블록에 속하는지 확인할 수 있습니다. 이를 위해 블록에 대해 "몇 개의 설정이 있습니까?"라고 요청하기만 하면 됩니다.
블록을 조사할 순서에 즉시 동의하면 됩니다. 그게 전부입니다.
위협 미래에 개별 블록 자체가 변경되더라도 아무 것도 깨지지 않으며 모든 것이 이전과 같이 작동합니다. 가장 중요한 것은 폴링 블록의 순서를 변경하지 않는 것입니다. 그러나 순서를 변경하더라도 아무 것도 중단되지 않으며 열을 다시 작성하여 새 블록을 폴링하기만 하면 됩니다.
...
이 배열의 길이는 뉴런의 수와 유형뿐만 아니라 각 뉴런의 연결 수에도 의존한다는 것이 밝혀졌습니다.
결국 각 뉴런은 연결된 대상을 등록해야 합니다.
이 배열의 길이는 뉴런의 수와 유형뿐만 아니라 각 뉴런의 연결 수에도 의존한다는 것이 밝혀졌습니다.
결국 각 뉴런은 연결된 대상을 등록해야 합니다.
틀림없이. 길이는 블록이 응답하는 내용에 따라 다릅니다.
하지만... 당신은 아마도 아키텍처를 설명하는 데이터 형식에 대해 이야기하고 있습니까? - 여기에 쓰기 위한 자체 형식이 있는 별도의 파일이어야 한다고 생각합니다.
그리고 나는 모든 설정 / 가중치에 대해 이야기하고있었습니다.
당신은 아마도 당신 자신(프로그래머)을 위해 그것을 했을 것입니다. "여기에 깃발을 꽂았다가 빼야지, 여기에 청어를 넣었으니 아직 건드리지 마라"
그리고 여기에는 아무것도 없습니다. 일반적으로 나는 했습니다. dll 및 4k를 통해 사실입니다.
그리고 "주전자용"이 필요합니다.
틀림없이. 길이는 블록이 응답하는 내용에 따라 다릅니다.
하지만... 당신은 아마도 아키텍처를 설명하는 데이터 형식에 대해 이야기하고 있습니까? - 여기에 쓰기 위한 자체 형식이 있는 별도의 파일이어야 한다고 생각합니다.
그리고 나는 모든 설정 / 가중치에 대해 이야기하고있었습니다.
로딩 알고리즘은 저장 형식 에서 메싱 형식 + 메싱 알고리즘 으로의 변환기입니다.
우리는 의존성이 있습니다 ...
생성 알고리즘 은 메쉬 생성 형식 에 따라 다릅니다 [-] ...
그리드 생성 형식 은 스토리지 형식 에 대한 직접적인 의존[~]이 없으며 의존성은 최상의 것을 선택하는 형태로 간접적입니다.
AZ=FH ~> FS -> AC