То, что описывается по ссылкам в вашем комментарии называют «photonic». Насколько я вижу — используется изменение свойств материала под действием излучения. Это не оптическая память в буквальном смысле слова. И частоты там соответственно указаны около 1ГГц (если бы она была чисто оптической, она не была бы такой медленной).
Сеть же, про которую речь в этом посте, авторы не называют «photonic». Пишут «all-optical». И это правильно.
По идее, всё что связано с сохранением состояния и памятью — не выйдет реализовать по такому принципу. Иначе бы уже давно сделали оптический компьютер, работающий со скоростью света.
Это конечно так, но ведь в данном случае нужна не просто какая-то интерференция, а требуется «согласованная» для разных частей изображения. Иначе не получится выполнить операцию и получить результат.
Насколько я понимаю, цель должна быть подсвечена когерентным светом. И вдобавок нужно будет озаботиться его усилением (в смысле, чтобы яркость образа на входе была достаточной), которое придётся делать электронным.
Да. До некоторого года (условно — где-то до Monkey Island II) авторы игр очень много внимания уделяли тщательности прорисовки изображений, как минимум из-за низкого разрешения и небольшого количества цветов. А потом пошло поехало, особенно с появлением 3D ускорителей…
Всё время покупаю только Philips (сначала CFL, потом LED). В надежде, что они дорожат своим именем. Надо сказать, пока что предположения всегда оправдывались (проблема только в том, что в Питере в магазинах они встречаются нечасто, особенно нужной цветовой температуры — тёплой). Интересно, попадались ли вам светодиодные Philips с низким CRi или высокой пульсацией?
> post-processed nibbles and bytes
> обрабатывая разные кусочки и биты
Nibble — не «кусочек», а половина байта. «Полубайт» можно написать. Хотя мы, помню, так и говорили — «нибл». Это устоявшийся термин. https://ru.wikipedia.org/wiki/%D0%9D%D0%B8%D0%B1%D0%B1%D0%BB
Кстати, а почему бы не передавать в commitChanges текущий редактируемый объект? Допустим, у меня дерево как описано выше в посте (тесты, вопросы, ответы к ним). И я хочу отредактировать вопрос. Чтобы после редактирования обновить информацию в базе соответствующим mutation'ом, мне надо знать, что отредактирован был именно вопрос (а не тест и не ответ). Сейчас я могу получить в commitChanges лишь id. Чтобы узнать тип (свойство __typename), мне придётся ещё искать этот объект в дереве по его id.
Вдогонку ещё один вопрос возник. Показывается-то всё отлично, но теперь при удалении (изменении) значения неясно, как внутри функции, вызываемой в EditingState onCommitChanges={commitChanges} понять, что именно мы удаляем (т.е. для какого объекта нужно выполнять, скажем, mutation delete).
В commitChanges передаётся только индекс (например, 68). Для плоского массива этого достаточно, но здесь-то уже не плоский массив…
А ключ обязательно должен называться одинаково на всех уровнях? Если поменять, скажем, на втором уровне item на item2, то уровень перестаёт отображаться.
В документации упоминается некий
getRowLevelKey — A function used to get a group row level key.
Но как его использовать — неясно.
Проблема в том, что как-либо модифицировать полученные GraphQL клиентом данные перед их передачей компоненту — очень кривой подход, хочется без этого обойтись.
Это там и в других примерах так…
Могу ошибаться (не использовал отметки) но, по-моему, у них дерево — это нахлобучка сверху на обычный grid. Соответственно, для выборки детей логику нужно самому дописывать, что для примеров посчитали лишним.
Скажем так — CFL Philips Tornado по CD диску отличалась от какой-то Noname CFL сразу и очевидным образом. Не говоря уже о накаливания против этих двух CFL.
Это я просто помню по личным экспериментам. LED тогда еще приличных не встречалось, так что их не сравнивал
Правда. Возьмите посмотрите, как в отражении в CD свет разлагается на составляющие — для лампы накаливания и для какой-нибудь дешевого светодиодной лампы. Разница сразу будет видна и понятна
Сеть же, про которую речь в этом посте, авторы не называют «photonic». Пишут «all-optical». И это правильно.
> обрабатывая разные кусочки и биты
Nibble — не «кусочек», а половина байта. «Полубайт» можно написать. Хотя мы, помню, так и говорили — «нибл». Это устоявшийся термин.
https://ru.wikipedia.org/wiki/%D0%9D%D0%B8%D0%B1%D0%B1%D0%BB
(кому интересно, вот тут пример)
В commitChanges передаётся только индекс (например, 68). Для плоского массива этого достаточно, но здесь-то уже не плоский массив…
(row ? (row.questions || row.answers) : rootRows)помогло, спасибо. В итоге, значит я всё-таки изобрёл велосипед.
В документации упоминается некий
getRowLevelKey — A function used to get a group row level key.
Но как его использовать — неясно.
Проблема в том, что как-либо модифицировать полученные GraphQL клиентом данные перед их передачей компоненту — очень кривой подход, хочется без этого обойтись.
Могу ошибаться (не использовал отметки) но, по-моему, у них дерево — это нахлобучка сверху на обычный grid. Соответственно, для выборки детей логику нужно самому дописывать, что для примеров посчитали лишним.
Это я просто помню по личным экспериментам. LED тогда еще приличных не встречалось, так что их не сравнивал