Первый программируемый компьютер на ДНК

[AxisPod]

А какова скорость работы? Зачем он нужен, если вручную будет не особо медленее.

[EvilGenius18]

Как это «зачем он нужен»?

В разработке прорывных технологий неважно насколько быстро работает первая версия прототипа (как впрочем и его стоимость/размер/объем).

Когда создавались первые диски объемом несколько мегабайт, они и мечтать не могли, что 50 лет спустя у нас будут диски объемом в несколько терабайт, размером 1 см² (SD диски) — 10 см² (NVMe диски), имеющие скорость записи/чтения 3500 МБ/с

[AxisPod]

Скорость синтеза белков ну очень не быстрый процесс, как ускорять? Где здесь потенциал?

[HellKaim]

Скорость синтеза, кстати, огромна и хорошо запараллеливается.
Эти машины как раз и могут решить классическую проблему множественного доступа "by design"

[AxisPod]

20 аминоксислот в секунду, о да, очень быстро ) Уж простите, в любом случае химическая реакция по скорости будет куда медленее. Как параллелить? Особенно учитывая тот факт, что белок — нить. В разных «банках» запускать? Если всё в «одной», как контролировать это?

[HellKaim]

Эм.
"Репликационная вилка движется со скоростью порядка 100 000 пар нуклеотидов в минуту у прокариот и 500—5000 — у эукариот".

Обычно запускают чтение подряд или, если записано несколько раз подряд — одновременно несколько фрагментов.
Физику не изменить: читать и писать можно только в 1 поток что кремнием, что магнитом, что светом, что молекулой.

Вопрос только в том, на сколько компактно можно хранить данные.

ЗЫ. В суперспирализированнлм состоянии ДНК действительно очень компактно, но для чтения ее разворачивают в месте начала чтения и идут далее по молекуле (напоминает сломанную молнию, которая движется, но не открывает при этом шва).

[HellKaim]

Погуглите такое понятие как секвенирование ДНК.
То, что представлено на рисунке — похоже хроматография (вернее ее фото).

[EvilGenius18]

Прогресс в любой области/технологии так всегда и происходил, не так ли?

1. Мы создаем что-то новое
2. Многим людям кажется что это будет невозможно существенно улучшить в ближайшие сотни лет
3. В течении нескольких лет исследователи находят несколько способов улучшить изобретение в десятки — миллионы раз, применяя открытия из других научных областей

К примеру:

— Устройства хранения информации за 50 лет были улучшены в миллионы раз (килобайты => терабайты)

— Алгоритмы распознавания изображений за несколько десятков лет улучшились с «не существуют» до «лучше, чем люди». Многие даже и не мечтали, что ИИ будет лучше ученых в распознавания рака и управлении машинами.

— Микро чипы за несколько десятков лет также были усовершенствованы в тысячи раз (1 ядро@20mhz@микрометры => 64 ядер@3,000mhz@7нм)

— Ракеты только за последние 16 лет были улучшены в десятки 1-й компанией (SpaceX), мы перешли от 1 запуска до десятков запусков (Falcon), хотя об этом даже и не мечтали, многие думали что это невыполнимая задача (даже Nasa не осмелились начать решать эту проблему, до сих пор летают на одноразовых ракетах)

[amarao]

Он не нужен. Ни какое научное достижение не нужно, потому что его создание стоило безумных денег, оно медленное и неудобное.

Надо просто обесценивать всё. Художник начал рисовать — самое время подойти и сказать «ну и нафига снова это рисовать, уже же всё нарисовали, и получше чем это». Писатель начал писать — можно заметить, что есть куда более известные и талантливые произведения.

Искусство обесценивания, одним словом.

[HellKaim]

Интересно другое: мы ни как не можем добиться модели памяти и формирования нейронных связей, но, как топором, пытаемся программировать на ДНК.
Вопрос, конечно, что раньше случится… Но то, что это не эффективный метод, очевидно уже сей час (но самый доступный).

[pallada92]

Проблема подхода реализации компьютеров в духе Wang tiles «в лоб» на ДНК в том, что при таких вычислениях часто возникают ошибки. В этой статье указана частота 1 ошибка на 3000 плиток (я мог что-то напутать т.к. читал только abstract по диагонали). С учетом того, что число используемых плиток для самых простых алгоритмов пропорционально размеру входа в битах, умноженному на «число тактов» работы алгоритма, т.е. >100 – это довольно часто.

Вот картинка из одной из первых статей на эту тему от этих же авторов, где делали треугольник Серпинского

Если увеличить правильный кусок, то складывается впечатление, что все работает идеально, однако вокруг происходит хаос из-за этих самых ошибок

Теперь представьте, что вы реализовали на них алгоритм, который работает с бинарными данными и некоторые биты в процессе вычислений произвольно инвертируются. Алгоритмов, которые устойчивы к таким ошибкам крайне мало.

Тем не менее, эти проблемы решаемы и я как раз недавно читал ряд интересных статей от этих авторов.

[HellKaim]

Именно, я выше об этом писал.
Наиболее целесообразно — базы данных, хранилища и т.п. где мало записи, но много чтения.
А вот "считать" так не очень выгодно.

[HellKaim]

Еще интересно попробовать синтез белков с люминисценцией. Тогда можно лазером читать.
Если запрограммировать синтез белка, части которого имеют разную люминисценцию, результат читать будет на порядок проще.
А вот как программировать процесс вычислений тут вопрос.

[HellKaim]

Даже не белка можно, а РНК. Это на 2 такт аменьше, но РНК не такая живучая.