다른 팀원들은 아을 사용해서 번역을 진행 하였지만, 제가 아스키독을 사용하는 방식이 능숙하지 못하고, 번역이 능숙하게 불가능 하기에, 교수님께 여쭤본 결과 그냥 텍스트로 번역을 해도 괜찮다고 말씀해 주셨기 때문에 이번 번역과제를 진행하게 되었습니다. 그래서 다른 팀원들과 번역 형태가 조금 다를수 있다는 것을 말씀드리고 싶습니다.
...
...
@@ -7,17 +7,17 @@ NNEF 1.0.5 표준 문서 번역참여. (23~40 page)
1. 작업 순서: 유효한 순서가 유일하지 않고, 연산들은 재배열 되거나 병렬로 실행될 수 있다는 것을 배웠다.
2. 그래프 본문 문법: 각 텐서가 개별적인 이름으로 식별되도록 한다.
4. 인수 유효성: 연산은 매개변수 집합을 추가로 제한할 수 있으며, 특정 범위 내에 속성을 제한할 수 있다.
5. 표현식 작성: 확장된 구문을 사용하여 특정 작업의 단축 표기법 또는 작업의 속성 값을 구축하거나 계산하는 데 사용된다.
6. 내장 연산자: 각 연산자에 대한 허용된 인수 유형 및 해당 연산자의 결과 유형을 요약한다.
7. 배열 구성: 항목을 나열하거나, + 연산자를 사용하여 배열을 연결하거나, * 연산자로 배열을 복제하는 방법을 설명한다.
8. 첨자 표현식: 배열에서 하나의 항목 또는 항목의 범위에 액세스하는 방법을 설명한다.
9. 튜플 사용: 튜플은 연산자로 구분된 항목들을 나열하여 구성되며, 튜플을 unpack하는 방법을 설명한다.
10. 문자열 작업: 문자열은 + 연산자를 사용하여 연결하거나, 범위 인덱싱을 사용하여 부분 문자열을 생성할 수 있다.
11. 내장 함수: tensor 배열 및 문자열에서 정보를 조회하는 데 사용되며, 선언에 대한 편의를 위해 동일한 표기법을 사용한다.
12. 컴파일 시 분기 및 루프 처리: 컴파일 시간 분기는 조건부 표현식을 사용하여 달성되며, 루프를 수행하는 방법은 재귀 또는 배열 내포를 사용한다.
13. 호출 연쇄: 연산 호출은 연쇄적으로 이루어질 수 있으며, 하나의 연산의 결과는 다른 연산의 입력이 될 수 있다.
14. 내보낸 식별자: 그래프에 추가적인 정보를 연결하기 위해 변수 또는 활성 텐서로 참조되는 특정 텐서들에 대해 설명한다.
3. 인수 유효성: 연산은 매개변수 집합을 추가로 제한할 수 있으며, 특정 범위 내에 속성을 제한할 수 있다.
4. 표현식 작성: 확장된 구문을 사용하여 특정 작업의 단축 표기법 또는 작업의 속성 값을 구축하거나 계산하는 데 사용된다.
5. 내장 연산자: 각 연산자에 대한 허용된 인수 유형 및 해당 연산자의 결과 유형을 요약한다.
6. 배열 구성: 항목을 나열하거나, + 연산자를 사용하여 배열을 연결하거나, \* 연산자로 배열을 복제하는 방법을 설명한다.
7. 첨자 표현식: 배열에서 하나의 항목 또는 항목의 범위에 액세스하는 방법을 설명한다.
8. 튜플 사용: 튜플은 연산자로 구분된 항목들을 나열하여 구성되며, 튜플을 unpack하는 방법을 설명한다.
9. 문자열 작업: 문자열은 + 연산자를 사용하여 연결하거나, 범위 인덱싱을 사용하여 부분 문자열을 생성할 수 있다.
10. 내장 함수: tensor 배열 및 문자열에서 정보를 조회하는 데 사용되며, 선언에 대한 편의를 위해 동일한 표기법을 사용한다.
11. 컴파일 시 분기 및 루프 처리: 컴파일 시간 분기는 조건부 표현식을 사용하여 달성되며, 루프를 수행하는 방법은 재귀 또는 배열 내포를 사용한다.
12. 호출 연쇄: 연산 호출은 연쇄적으로 이루어질 수 있으며, 하나의 연산의 결과는 다른 연산의 입력이 될 수 있다.
13. 내보낸 식별자: 그래프에 추가적인 정보를 연결하기 위해 변수 또는 활성 텐서로 참조되는 특정 텐서들에 대해 설명한다.
3.3.2. 그래프 및 프래그먼트 정의: 신경망 구조를 정의하는 데 사용되는 그래프와 프래그먼트의 구조 및 구성을 설설명한다.
...
...
@@ -57,4 +57,3 @@ NNEF 1.0.5 표준 문서 번역참여. (23~40 page)
그리고 PDF문서를 번역할때는 word로 번역을 진행하기에는 형식같은 부분을 맞춰서 나가는게 조금 어려웠던 것 같습니다. page를 맞추기 위해서 많은 공간을 비워야 했던 부분이 아쉬움으로 많이 남는 것 같아서, 아스키독에 대한 공부를 조금 해야겠다고 느꼈습니다.
또한 NNEF에 대해서 모두를 이해하지 못했지만 번역에서 배웠던 것들을 얼추 이해하면서 공부 할 수 있었던 것 같습니다.
다음번에 과제를 하게 된다면 더 잘알고 수행할 수 있는 부분으로 과제를 진행해야 한다는 것을 느꼈습니다.
기존 교수님께서 권장해주신 바와 같이 아스키독을 통한 번역물을 작성하려 했으나 문서에 포함된 다양한 수식들을 아스키독 문법 형식으로 나타내는 데 어려움이 있어 불가피하게 워드 및 PDF 형식으로 결과물을 작성하였습니다.
```
4.3.2. 박스 필터 (Box Filter)
4.3.3. 인덱스 기반 샘플링 (Index Based Sampling)
4.3.4. 업 & 다운 샘플링 (Up and Down-Sampling)
4.4. 축소 연산 (Reduce Operations)
4.5. 텐서 형상 조작 연산 (Tensor Shape Operations)
4.5.1. 재구성 (Reshaping)
4.5.2. 전치(Transposing)
4.5.3. 분할 및 연결 (Splitting and Concatenation)
4.5.4. 슬라이싱 (Slicing)
4.5.5. 패딩 (Padding)
4.5.6. 틸링 (Tiling)
4.5.7. 합산 (Gathering)
4.5.8. 형변환 (Casting)
```
### 후기
사실 교수님 추천 과제에 번역을 지원했던 이유는 어느정도 자신이 있었기 때문이다. 금학기에 기계학습을 수강중이기도 하고 이전 학기에 인공지능을 수강하였으니 어느정도 배경지식이 있다고 생각했기 때문이다. 하지만 공식 문서를 들여다보니 예상과는 다소 상이하였다. 학부 과정에서 배운 간단한 지식을 넘어서 보다 본격적인 내용들이 즐비해 있었고, 기존 배경지식만으론 번역이 매끄럽게 되지 않아 보다 심화적인 공부를 필요로하게 되었다.
특히나 이러한 문서의 경우 기계학습에 대한 기술적인 지식을 다루는 문서이다보니, 일반적으로 통용되는 단어를 활용해야 다른 사람들도 이해하는데 수월할 것이기 때문에 더욱이 부담되었다. 다만 이번 번역에 참여하면서 기계학습, 인공지능 과목을 수강하면서 머리에 쌓인 지식들을 다시 한 번 정리할 수 있는 기회가 된 것 같아 만족스럽다.
크로노스 그룹(Khronos Group)이 개발한 NNEF 1.0.5는 신경망 모델 교환을 위한 표준화된 형식을 제공하여 다양한 딥러닝 프레임워크 간의 상호 운용성을 향상시키도록 설계된 사양입니다. 이 버전은 프레임워크에 구애받지 않는 방식으로 모델을 표현하기 위한 구문, 구조 및 규칙을 간략하게 설명하여 원활한 상호 교환을 촉진합니다.
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
## 참여 학생 및 담당 파트
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
-[ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
-[ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
해당 문서는 기계학습에 대한 기술적인 내용을 다룬 문서로, 참여 학생별로 파트를 나누어 번역을 진행한 만큼 번역된 문서 전체적인 흐름을 매끄럽게 하기 위하여 기술 용어를 통일하였습니다.
-[ ] [Set up project integrations](https://git.ajou.ac.kr/jm991014/foss-2023-2-final/-/settings/integrations)
## Collaborate with your team
-[ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
-[ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
-[ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
Use the built-in continuous integration in GitLab.
-[ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
-[ ] [Analyze your code for known vulnerabilities with Static Application Security Testing(SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
-[ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
-[ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
-[ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
***
# Editing this README
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thank you to [makeareadme.com](https://www.makeareadme.com/) for this template.
## Suggestions for a good README
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
## Name
Choose a self-explaining name for your project.
## Description
Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors.
## Badges
On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
## Visuals
Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method.
## Installation
Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection.
## Usage
Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README.
## Support
Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc.
## Roadmap
If you have ideas for releases in the future, it is a good idea to list them in the README.
## Contributing
State if you are open to contributions and what your requirements are for accepting them.
For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self.
You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser.
## Authors and acknowledgment
Show your appreciation to those who have contributed to the project.
## License
For open source projects, say how it is licensed.
## Project status
If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers.
번역하는데 있어 [텐서플로우 공식 가이드](https://www.tensorflow.org/guide?hl=ko)를 참고하여 진행하였습니다.