어제 당직서면서 계속 생각해봤는데 이 글이 접근은 맞는데 구현방법이 잘못된거 같아서 폰 받고 글 하나 써봄.
기존의 타이머 방식은 PWM (pulse width modulation) 제어라고 부르는데, N틱 중 k틱에만 공정을 가동해서 가동률을 k/N으로 맞추는 방식임.
(참고로 가동률이란 총 시간(스텝) 대비 공정이 가동하는 비율)
이 방식은 정밀한 가동률을 위해서는 사이클 주기가 길어지고 응답성이 떨어지는 단점이 있음.
예를들어 정확하게 48.391%의 가동률을 원한다면 48391/100000, 즉 펄스의 주기가 10만틱이 되어야 함.
따라서 이를 해결하기 위해 출력이 사이클 주기와 상관없이 균등하게 나오도록 할 필요가 있음.
다만 글에서 제시한 새로운 방식은 m과 x를 조절해서 원하는 가동률을 구하는 과정이 복잡함.
그래서 조건을 더 단순화해서 이런 수열로 만들었음.
이렇게 설정한다면,
위상학적으로 가동률을 a/(a+b) 로 표현 가능함. ㅎ
간단한 예시 ㅇㅇ
비직관적으로 보이긴 해도 항상 성립함.
기존 방식과 비교해서 변동성을 줄이도록 uptime을 균등하게 흩뿌리는거임.
원 글 예시처럼 스시벨트의 아웃풋을 최대화하기 위해서는 인풋의 변동성을 줄여야 하는데 그런 경우에 이런 방식이 필요할듯함.
gpt한테 물어보니까 이 메커니즘을 더욱 간단하게 구현한게 시그마 델타 제어라고 하더라.
시그마-델타 ADC 라고, 원래 회로설계 쪽에서 디지털 / 아날로그 변환할 때 사용하는 제어라고 함.
누적오차(시그마델타, r)를 쌓아가며 임계값(1)이 넘으면 출력하는 메커니즘임.
팩토 회로 신호는 소수점을 지원 안하니까 r을 a로, 임계값 1을 (a+b)로 설정하면 됨.
팩토 킬 수 있었으면 회로 예시 만들어보고 싶은데...
일단 조합기 두 개로 대충 구현해 봄.
목표 U = 48.931%
조건
Z=0
출력
U=U
U=48931
조건
U>100000
출력
U=-100000
A=1
모든 조합기 인풋 아웃풋 초록선으로 잇고
A=1일때 공정 가동하면 됨.
그럼 즐?팩
수량비교만 하고 공장도 저렇게까지 고민하면서 지어본 적이 없는데 이런거 볼 때마다 대단하다는 생각만 드네요 ㄷ
재밌잖아요 ㅎ
@paper 역시 팩고인물
잘 작동하긴 하는데 ups관리는 괜찮나?
사실 팩토는 템 하나하나 유체 하나하나 바이터 행동 하나하나 다 트래킹하는 연산을 매 틱 하는 중이고, 저 정도는 우리 겉보기에만 정신없어 보이는거라 괜찮음
컴퓨터는 우리 생각보다 훨씬 빠르게 연산함. 고작 조합기 두 개 따위야 뭐 걱정없지
저대로 작동하면 2틱마다 A출력하다가 잠시 비는구간 생기는건가? 매개변수화해놓고 여기저기 써먹을 수 있겠네
10만틱중에 48931틱만 거의 균일하게 껐다 켜지는거. 0.021%나 96.78% 같은 이상한 숫자에도 정확하게 대응 가능하다는게 장점
내가 머리 나쁘다고 생각한적은 없었는데 이건 중간부터 잘 이해가 안되기 시작한다... 역시 현실은 대단해
이런건 머 깊게들어가면 전자공학, 컴퓨터공학이니까 전공 영역이긴 하지
나도 시그마델타 머시기는 오늘 처음알았음 ㅋㅋ
이거 원글에도 달긴 했는데 이거 정확히 알고싶으면 브레젠험 알고리즘 찾아보면 되긴 함. 이 시그마 델타는 구현 방식에 대한 내용인데 어쨌든 게임에 접목시킨다는게 의미가 크네.
브레젠험 찾아보긴 했는데 그건 선형 연산에서 소수점 배제하고 정수만 연산해서 연산량 줄이는게 핵심 컨셉 아닌가? 어떤 점에서 비슷한지 궁금함
오 둘이 용도는 전혀 다른데 식이 똑같네 ㄷㄷ
ㅇㅇ 보면 내용은 같아. 그냥 적용 대상의 차이인거고. 이미 정립된 이론들은 거의 완벽하게 만들어진거라 응용만 하면 됨
선형적인 증가값을 만들어야 하는데 틱이나 격자 시스템 같은 경우 본문에 적은거처럼 오차값이 누적되는데, 이걸 시그마 델타처럼 분리해서 일정 구간마다 보상해주는거임. 결국 식이 다 똑같이 나올 수밖에 없어서
나 원글쓴인데, 역시 현실박사님들이 만든 알고리즘이 개입하니 훨씬 최적화가 잘 되네 당장 구현하러 간다.뭔가 잘하면 조합기 하나로도 될것같은데?
공부하면 할수록 원글의 방식이랑 같은것같은데.. 차이라고 하면 정수냐 실수냐의 차이이고, 조합기 개수를 줄인 최적화부분도 가능은 하겠지만 문제가 생김, 예상한 범위를 초과하는 입력이 들어올때 누적기값이 폭주하는 현상이 생기고 입력이 정상으로 복구되면 서서히 정상으로 돌아오긴 하지만, 잘못된입력이 입력된시간에 준하는 시간이 소요됨. 그걸 제어하는 조합기가 또 들어가야하고..
누적오차로 보정하는건데 밖에서 입력(추가 오차)을 넣어주면 안되지
@paper On 빈도를 결정하는 r 이 1>r>0 일경우에는 문제없이 작동하지만 r 이 1을 넘어서는순간부터 누적변수 e 의 값은 무한히 증가함, 만약 r이 0보다 작다면 e의 값은 무한히 감소하고, 회복되기위해선 정상적인 값이 잘못된입력이 들어온시간에 준하는 만큼의 시간이 필요함. 밖에서 추가입력을 준다는 얘기가 아냐. 보통이라면 이 회로에 r값을 공급하는 외부회로의 잘못이긴 하겠지만 팩토리오 환경에서는 정규화회로가 꽤 조합기가 많이 필요하니 가능하면 맞춰주고싶어서 말야
https://m.dcinside.com/board/factorio/85331
@paper 엥? 이거 내글인데? 맞아, 어제 그 글은 이걸 개선하기위한 회로지 이 회로는 단순한 타이머식 회로를 썼었거든
@팩붕이4(123.199) 어제 내글에 있던 우주선 gif랑 비교해보면 옛날거보다 많이 개선됐을걸 꽤 옛날에 올렸던건데 기억나네 ㅎㅎ
헐
컴붕이용 for(every_tick){accum+=activation_per_tick;if(accum>=1){accum-=1;dothing()}} - dc App
팩붕이용으로 주세요
게임에서 자주 쓰는 트릭인데 안쪽 if를 while로 바꾸면 재밌는 일이 일어남 - dc App
조건 Z=0은 뭘의미하는거지? Z가 다른곳에서 안쓰이고 있는데
true 깔쌈하게 만드는거 생각안나서 막 넣음
@paper 아 항상 참 ㅋㅋ 혹여라도 z가 다른값이 유입되면 오작동 할수도 있으니 z=z가 좀더 안전할듯하고 나같으면 항상 참 만드는거는 모두!=0 으로 조건 거는걸 좋아함
수상할정도로 공돌이가 많은 게임
on off 제어기를 극한까지 활용하는 건가 - dc App