The idea I had after the second part but didn't see here is to step out of the linear search. If you put a series of doublechests (say 15 for upto 810 types), you can redirect the minecart to its corresponding subencoder (for example, if the second doublechest has the item type you go to the second encoder). Then the resulting code is the concatenation of the main module and the subencoder (in the running example that would be 0x234 if the subencoder gives 0x34). If you have 15 6-bit encoders with 54 types each, that would give the same 10-bit encoding space. Comparing it to the first solution you presented, it works at O(l+w) instead of your O(l*w).
Your video just showed on my screen unexpectedly, and you just got a new subscriber cuz your contents are good. Who doesn't like Minecraft and who doesn't like redstone builds!
I quit studying computer science (informatics to be specific) a few years ago and switched to a field I now kind of regret having switched to. These videos combine my lingering interest in computers, numbers and Minecraft. Thanks
Thanks for the encoding series, it's been super helpful in starting to understand item encoding and storage halls. Is there any chance you could do another series on how the storage system would read the encoded value and return or store something?
At the moment, I don't know enough about bulk storage to do any videos on it. But I've been binging some videos by Kahyxen recently who has some explanations on decoders and instant wires (czcams.com/video/w26cQ-WfQy4/video.html). And another person, T1, has some showcases of big encoded storage facilities (czcams.com/video/wfjbyX7sGk0/video.html). That's all I got at the moment
When you said this video was about compressing your codes I imagined a totally different video. I thought you were either going to choose a canonical order for the encodings and simply convert from the encoding representation to the order number, which would make the final amount of bits passed be dependent only on the number of encodings being used, and not on amount of chests of items Ex: For 4 bits you'd have [1000, 0100, 0010, 0001, 1100, 1010, 1001, ... ] so 0010 would be compressed to 3 since it's the 3rd encoding Or that you would use the fact that the number of tokens was decreasing to represent only the amount of 0s between each token, so you'd message t+1 numbers where t is the maximum of tokens. Ex: For 16 bits and a max of 2 tokens you'd have 0000010000001000 -> 5,6,3 (you wouldn't really need the last number because you'd know the amount of bits, but it's more readable that way) The video was still a lot of fun, but I had to share my ideias somewhere
but if you connect a lot of filters, then their efficiency will drop, because when you add a new bit, the number of solutions doubles, and when you add new mechanisms, it multiplies by their number. I'm not saying that this is bad, I just don't understand where 90% came from when it at ~1.75%.
40 chests is the minimum and would give you 1006 distinct codes. You'd have 40 one-token codes, 780 two-token codes, and you'd pick out 186 of the three-token codes. That would require most of the chests to use all 54 slots (= 1 + 39 + 14 slots from the one/two/three-token codes respectively)
Не знаю, будет это в тему. Но почему нельзя использовать кодирование порядковыми номерами? Возьмём шалкер (потому что их можно положить в двойной сундук, а это 27*54)
А как задать порядковый номер отдельному предмету? А точнее, как система определит этот номер? Компаратор может считать лишь изменение заполненности контейнера, но не номер слота, в котором изменилось кол-во фильтр-предметов
@@stonehenge1 как обычный сортировку. В какую воронку (слой) попал предмет, на том и будет сигнал, которому ты можешь дать любое значение. Допустим в шалкере есть слиток железа Он 5 по порядку (в шалкере) После чего мы разгружаем шалкер по сортировке На слой №5 у нас фильтр "железный слиток" Воронка засекает, что в неё попал предмет и даёт сигнал. В данном случае 5. Это больше подходить для "кодирования" Да и схема там сложная, по сравнению с двоичным кодом.
Этот метод работает хорошо, но становится очень большим и медленным, когда вы кодируете сотни различных элементов. Это единственный известный мне метод, который может кодировать 1000 различных элементов за несколько секунд. (Возможно, я вас неправильно понял, Google переводчик не самый лучший)
@@whitestonejazz Видели видео Lummie? (V 2.0) Я сейчас занимаюсь реконструкцией его системы. И уже на финальном этапе. (на создании слоёв) Как доделаю работу, покажу обоим.
The idea I had after the second part but didn't see here is to step out of the linear search. If you put a series of doublechests (say 15 for upto 810 types), you can redirect the minecart to its corresponding subencoder (for example, if the second doublechest has the item type you go to the second encoder). Then the resulting code is the concatenation of the main module and the subencoder (in the running example that would be 0x234 if the subencoder gives 0x34). If you have 15 6-bit encoders with 54 types each, that would give the same 10-bit encoding space.
Comparing it to the first solution you presented, it works at O(l+w) instead of your O(l*w).
Your video just showed on my screen unexpectedly, and you just got a new subscriber cuz your contents are good. Who doesn't like Minecraft and who doesn't like redstone builds!
I'm glad to have run into you then. Please LMK what you think as you browse (or "browsed" as I'm a few weeks late to going through my comments :-)
I quit studying computer science (informatics to be specific) a few years ago and switched to a field I now kind of regret having switched to. These videos combine my lingering interest in computers, numbers and Minecraft. Thanks
Thanks for the encoding series, it's been super helpful in starting to understand item encoding and storage halls. Is there any chance you could do another series on how the storage system would read the encoded value and return or store something?
At the moment, I don't know enough about bulk storage to do any videos on it. But I've been binging some videos by Kahyxen recently who has some explanations on decoders and instant wires (czcams.com/video/w26cQ-WfQy4/video.html). And another person, T1, has some showcases of big encoded storage facilities (czcams.com/video/wfjbyX7sGk0/video.html). That's all I got at the moment
When you said this video was about compressing your codes I imagined a totally different video.
I thought you were either going to choose a canonical order for the encodings and simply convert from the encoding representation to the order number, which would make the final amount of bits passed be dependent only on the number of encodings being used, and not on amount of chests of items
Ex: For 4 bits you'd have [1000, 0100, 0010, 0001, 1100, 1010, 1001, ... ] so 0010 would be compressed to 3 since it's the 3rd encoding
Or that you would use the fact that the number of tokens was decreasing to represent only the amount of 0s between each token, so you'd message t+1 numbers where t is the maximum of tokens.
Ex: For 16 bits and a max of 2 tokens you'd have 0000010000001000 -> 5,6,3 (you wouldn't really need the last number because you'd know the amount of bits, but it's more readable that way)
The video was still a lot of fun, but I had to share my ideias somewhere
These videos are so comprehensive and the visualizations are awesome. Great job!
perfect timing
but if you connect a lot of filters, then their efficiency will drop, because when you add a new bit, the number of solutions doubles, and when you add new mechanisms, it multiplies by their number. I'm not saying that this is bad, I just don't understand where 90% came from when it at ~1.75%.
Wait wtf this has only 400 views?? This is great!
The algorithm giveth and the algorithm taketh away
Cool series. What do you think the least amount of chests you could use for 1000 item types and get a unique code for each?
40 chests is the minimum and would give you 1006 distinct codes. You'd have 40 one-token codes, 780 two-token codes, and you'd pick out 186 of the three-token codes. That would require most of the chests to use all 54 slots (= 1 + 39 + 14 slots from the one/two/three-token codes respectively)
Happy New Years, Chris
(great first name btw)
same and same haha
Не знаю, будет это в тему. Но почему нельзя использовать кодирование порядковыми номерами? Возьмём шалкер (потому что их можно положить в двойной сундук, а это 27*54)
А как задать порядковый номер отдельному предмету? А точнее, как система определит этот номер? Компаратор может считать лишь изменение заполненности контейнера, но не номер слота, в котором изменилось кол-во фильтр-предметов
@@stonehenge1 как обычный сортировку. В какую воронку (слой) попал предмет, на том и будет сигнал, которому ты можешь дать любое значение.
Допустим в шалкере есть слиток железа
Он 5 по порядку (в шалкере)
После чего мы разгружаем шалкер по сортировке
На слой №5 у нас фильтр "железный слиток"
Воронка засекает, что в неё попал предмет и даёт сигнал. В данном случае 5.
Это больше подходить для "кодирования"
Да и схема там сложная, по сравнению с двоичным кодом.
Этот метод работает хорошо, но становится очень большим и медленным, когда вы кодируете сотни различных элементов. Это единственный известный мне метод, который может кодировать 1000 различных элементов за несколько секунд. (Возможно, я вас неправильно понял, Google переводчик не самый лучший)
@@whitestonejazz Вы всё правильно поняли.
Да, этот способ медленный и он был "создан" для "кодирования".
@@whitestonejazz Видели видео Lummie? (V 2.0)
Я сейчас занимаюсь реконструкцией его системы.
И уже на финальном этапе.
(на создании слоёв)
Как доделаю работу, покажу обоим.