[Elixir | 왜 체인 시계를 사용합니까?]

나는 줄곧 데이터 구조가 매우 멋있다고 생각했지만, 너는 무엇이 더 멋있는지 아니?야외에서 봤어!
Elixir의 문서를 읽을 때, 나는 Elixir가 선형 데이터 구조에서 숨겨진 체인 테이블을 사용하는 것을 보았다.나는 이것이 매우 멋있다고 생각했지만, 나는 갑자기 무엇이 생각났다.나는 수조와 체인 시계를 이해하지만, 나는 그것이 프로그래밍 언어와 어떤 관계가 있는지 모른다. 그 이후로 나는 줄곧 매우 괴로웠다. 나는 체인 시계를 사용하는 원인을 찾아야 하기 때문에 본고!
이 문장으로 돌아가서 내가 현재 발견한 상황을 보면 왜 Elixir가 이렇게 했는지 설명할 수 있는 세 가지 이유가 있다.우리 하나하나 이야기합시다.

불변 데이터

Elixir에서는 데이터가 변경되지 않습니다.이것은 왜 체인 시계를 사용하는지 이해하는 중요한 첫걸음이다. 우리 한번 토론해 보자.

Immutable means that once a data is declared, it cannot be mutated/changed anymore.

엔진 덮개 아래에 진열된 작업 방식을 알고 있다고 가정하십시오. (복습이 필요하면 보십시오.)만약 우리가 수조로 불변성을 실현하려고 시도한다면 무슨 일이 일어날지 봅시다!
배열은 연속적인 메모리 블록으로 정의됩니다.문제는 다섯 개의 원소로 구성된 수조는 여전히 하나의 수조일 뿐, 우리가 원소를 추가하거나 삭제할 때, 우리는 그것에 대해 변이를 진행할 것이다.그렇다면 우리는 어떻게 수조에 대해 불변성을 사용합니까?불가능한 것은 아니지만, 왜 비현실적인지 봅시다.
만약 우리가 수조에서 진정한 불변성을 강제적으로 실현하고 싶다면, 이것은 우리가 수조에 추가/삭제하고 싶을 때마다 낡은 수조의 전체 복사본을 만들어야 한다는 것을 의미한다.
이것은 크기가 5인 그룹이 있다면, 그룹에 새 항목을 추가하려면, 메모리 사용량이 즉시 배로 늘어난다는 것을 의미한다. (낡은 그룹의 원형을 유지해야 하고, 같은 요소로 구성된 새 그룹을 만들어야 하기 때문이다.)이것은 단지 공간의 복잡성, 그리고 우리가 고려해야 할 시간의 복잡성!
체인 테이블은 같은 제약이 없다. 왜냐하면 노드가 메모리에 단독으로 저장되기 때문이다. 이것은 목록에 노드를 추가/삭제할 때 우리는 공간/시간의 복잡성을 걱정할 필요가 없다는 것을 의미한다.
이것은 우리에게 목록을 사용하는 첫 번째 이유를 주었다. 그러나 이것이 전부는 아니다. 여기는 귀속 구조/꼬리 공유가 시작되는 곳이다. 모든 것이 의미가 있기 시작했다.

귀속 구조

너는 체인 시계의 정의가 귀속적이라는 것을 알아차렸니?
예를 들어 A -> B -> C -> D는 하나의 체인 시계이지만 B -> C -> D, C -> D 등도 체인 시계이다. 각 체인 시계는 다른 체인 시계의 하위 구조일 뿐이다!
그 자체는 결코 사람을 흥분시키지 않지만, 이것은 다음 수수께끼에 매우 중요하다.

Fun Fact: The recursive nature coupled with the fact that datas have to be immutable (so you can't have a loop counter) is why functional languages are usually associated with recursions - they kinda have to!

구조/끝 공유

그래서 우리는 체인 시계가 본질적으로 귀속된다는 것을 안다.언어의 불변성을 결합하면 우리는 데이터가 영원히 변하지 않을 것이라는 것을 안다.
이것은 매우 흥미롭다. 왜냐하면 지금 우리는 A -> B -> C -> D과B -> C -> D가 다른 목록이라고 자신 있게 말할 수 있기 때문이다. (설령 그 중 하나가 귀착적으로 다른 것을 포함한다고 하더라도) 그리고 우리는 이 보증이 있기 때문이다. (목록이 변경될 수 없다는 사실) 우리는 같은 데이터를 두 번 정의할 필요가 없다. 우리는 기존의 링크 목록을 다시 사용할 수 있다.이를 구조 공유라고 합니다.
너무 좋잖아, 그렇지 않아?우리 예를 하나 봅시다.
예:

list = [5,6,7,8]
list_one = [1 | list]
list_two = [2 | list]

지금 저희가 세 개의 다른 리스트가 있어요!list,list_one,list_two, 그러나 그들은 모두 같은 인용(꼬리)을 공유하고 있으며, 그들 사이의 유일한 차이점은 머리 바늘이다.
이것은 메모리에 모두 6개의 요소가 있다는 것을 의미한다.목록에 추가하면 메모리 비용이 낮고 우리가 원하는 불변성을 보존할 수 있습니다.
중복 사용 가능한 아기!

만약 당신이 좀 더 읽고 싶다면, 연구해 보세요Trie trees. 그들은 완전히 같은 공유 데이터/접두사 개념을 가지고 있습니다!

쓰레기 수집과 캐시?

이 두 가지는 확실하지 않지만, 체인 테이블이 GCs에 좋다고 들었습니다. 꼬리 공유는 인용/캐시 부분적인 좋은 후보자입니다. (나는 어떻게 해야 할지 모르겠습니다. 왜냐하면 그들은 서로 다른 위치에 저장되어 있기 때문입니다.)만약 누군가가 끼어들고 싶다면, 나는 감격을 금할 수 없을 것이다.

폐막사

방주, 사실 Elixir는 Erlang으로 컴파일할 수 있기 때문에 Elixir와의 관계는 크지 않지만 Erlang과의 관계는 크지 않다. 모든 함수식 프로그래밍이 거의 같은 일을 하기 때문이다. 그러나 이것이 바로 나의 호기심을 불러일으키는 원인이다. 바로 Elixir와 Elixir의 관계이다.
이 글을 쓸 때 저는 불로장생의 약 부분을 깊이 연구하기 전에 수조의 작업 원리를 깊이 연구해야 한다는 것을 발견했기 때문에 이를 대체품으로 발표했습니다.이 문장을 반드시 읽어서 균형이 무엇인지 더욱 잘 이해해야 한다.

어레이 작업 방식

에디슨 아프・ 2019년 2월 12일・ 7분 읽기

#ruby #computerscience #c

나도 진정으로 O기호에 대해 이야기하지 않았다. 왜냐하면 나는 그것이 문장에 불필요한 읽기 시간과 복잡성을 증가시킬 수 있다고 생각하지만, 그것들은 컴퓨터 과학에 있어서 매우 중요하고 기본적인 것이기 때문에 나는 네가 다시 복습하는 것을 건의한다.
만약 당신이 팟캐스트 유형의 사람이라면 BaseCS 코드뉴비, 베이디시 조쉬와 사론이 공동으로 진행을 맡는다.
만약 네가 읽고 싶다면, Vaidehi Joshi의 블로그 포스트 버전 (나는 그것이 팟캐스트를 계발했다고 믿는다) 은 BaseCS Medium 에서도 매우 좋다.
동영상은 놀라운 것을 초월하고 실천 과정에서 제가 지금 알고 있는 모든 것을 배웠습니다. 강력히 추천합니다!
그 외에 당신들이 이 문장을 좋아하기를 바랍니다. 마치 내가 그것을 즐겨 쓰는 것처럼!

출처

https://elixir-lang.org/getting-started/basic-types.html#linked-lists - 본문을 일으킨 문장