Речь не идет о поиске оптимального. Скорее, о поиске равновесного (раз уж вы начали пользоваться математической терминологией :)
Тут надо представлять себе пространство, о котором идет речь. Гугл не пишет, какими биомаркерами он собирается пользоваться.
Но вот пара цифр:
— число пар оснований ДНК у человека — 3 млрд.
— число других макромолекул, которые могут служить «биомаркерами» оценивается в 20 000
Понятно, что речь идет о пространстве бешеных размерностей. Практически каждый «здоровый» (что бы это ни значило) человек будет отдельной точкой в этом пространстве.
Тут могли бы спасти всякие меры «близости». Но пока ничего подходящего придумать не удалось. Мутации в очень небольшом количестве нуклеотидных пар (если правильно выбрать) могут погубить жизнь человека.
Поэтому обычно и «пляшут» от патологий, а не от нормы. Т.к. патология, на практике является гораздо более узким понятием.
В самом начале поста есть ссылка на основную новость. Тот же самый Гугл поможет найти еще кучу публикаций на эту тему.
Плюс новость была представлена в этом же хабе: habrahabr.ru/company/medgadgets/blog/231063/
Про цели проекта — вопрос хороший. Но пока никто толком этого не понимает. И это тоже служит поводом для критики. Не объявлены измеримые цели.
Что мы находим методом банкира, например? Т.е. каков физический смысл получаемой оценки?
Наихудшее время работы алгоритма будет O(N^2). Чему соответствует линейная оценка? Среднее время по случайным запускам с равномерно распределенными параметрами? Или чему-то другому?
Не совсем понимаю, как именно вы восприняли этот фрагмент, но основная мысль такова (по Бабаяну): язык высокого уровня должен иметь адекватную аппаратную поддержку. Я думал, эта мысль проглядывается через весь текст. Возможно, я где-то не доработал.
В указанном смысле можете приписать Хаскель рядом с Джавой. Сути бабаяновской позиции это не изменит.
Проблема в том, что разработчики первого и второго Эльбрусов сейчас довольно пожилые люди, причем все еще активно работающие. Сами заниматься обработкой и продвижением материалов они не будут. Так что нужны именно рабочие руки. Но есть надежда, что они найдутся. Вроде бы, у хороших людей назревает идея написать симулятор Эльбруса.
Если у вас студенты, готовые повозиться с Эльбрусом?
На данный момент у меня есть такая информация:
1) найден рабочий Эльбрус-2 (в Софрино)
2) найден человек, который утверждает, что сохранил всю информацию по проекту (но есть неуверенность относительно кодов ОС). В любом случае есть бинарии ОС, поэтому можно поднять ее на симуляторе (который нужно будет разработать).
Если вы настроены серьезно, могу свести вас с людьми.
1) Я не верю, что владелец аккауна не смог доказать хост-провайдеру право на вледение аккаунтом
2) Злоумышленник рассказал жертве столько, что взять его за «шарики» не составит никакого труда. Таких болтунов даже в сказках не бывает…
Я думаю, вам надо обратиться в МЦСТ (контакты есть на их сайте). Там работают очень интересные и отзывчивые люди. Если вы сможете четко объяснить, что вам нужно и, главное, зачем, то они, вполне возможно, пойдут вам навстречу.
С другой стороны, я не уверен, что они прямо бросятся шарить исходники. Все-таки это проприетарная вещь, которая (теоретически) может представлять коммерческий интерес. Так что не знаю… Но поговорить стоит.
С этой позиции Бабаян 432-ую не критикует. Он критикует именно реализацию. А высокоуровневые идеи у эльбрусовцев у самих те же самые (только возникли гораздо раньше).
Вообще, судя по по тем фрагментам, которые вы здесь выложили (еще раз большое спасибо!), думается, что Бабаян провел неплохой для условий того времени анализ.
В письме тоже делается (как мне показалось) акцент на неэффективность разделения указателей и данных:
«The original design — where data segments and Access segments were separate object was very, very in-efficient in hardware»
Интересно также отметить, что недостатки, о которых говорится в письме, — это недостатки машины, а достоинства — это достоинства организации работы в проекте.
Из возможных достоинств архитектуры (я ориентируюсь только на фрагменты, которые вы дали, так что ни в коем случае не претендую на полноту анализа) можно было бы отметить гибкую ISA. Но я не уверен, что в условиях того времени из этого можно было получить хорошую производительность.
В письме разработчик указывает лишь «административный» плюс: легко было вносить изменения в проект. В принципе, с хорошей ISA — это почти очевидно. Простая ISA — значит, можно посторить эффективный симулятор, который можно пределывать «на лету». Похоже, так у них и было.
А вот в плане производительности, скорее всего, ожидались большие проблемы. Простая ISA — громоздкая ISA (условно). Значит, нужна хорошая подкачка, нужен большой кеш. А с этим у них было плохо…
Видимо, еще нужно отметить, что в то время Бабаян вряд ли мог знать о проблемах с разводкой и ограничениях американского техпроцесса. Поэтому ему приходилось концентрироваться на логике. Что удивительно, он смог по косвенным признакам или из общих соображений вывести некоторые интересные вещи (например, очереди сегментов для переиспользования в процедурах и пр.) В беседе со мной он дал некоторый набросок того, как проводил анализ. Но я пока не могу об этом писать, т.к. совсем не знаю 432-ой машины. Боюсь неправильно что-то понять и налажать.
Ошибку, возможно, не обнаружили, потому что алгоритм не практичный. Наверное, никто особо не хотел его реализовывать.
А может, обнаружили, но забили. Дыры в алгоритмах иногда проще найти практику, нежели теоретику. Но практики не сильно заинтересованы в публикациях.
У меня коллеги как-то реализовывали алгоритм (точнее, целый комплекс алгоритмов) из одной очень продвинутой и котируемой американской диссертации.
В результате применения этих наработок в рамках большого промышленного проекта, выяснилось, что в диссертации огромная дырень, из-за которой вся диссертация должна лететь в трубу. Опровержения они не выпустили. Наверное, потому, что не было конструктива: как латать дыру, никто не знал. Писали автору, но он проигнорировал их письма :)
Когда сперли исходники Винды, народ тоже думал, что все сразу бросятся с красными глазами их копать. Но никто особо не стал влезать. Слишком много всего и слишком оно чужое…
Много ли найдется студентов, желающих освоить Эль-76 и изучить операционную систему на нем?
Хотя думаю, что у любого студента, работающего в МЦСТ, такая возможность есть.
Тут надо представлять себе пространство, о котором идет речь. Гугл не пишет, какими биомаркерами он собирается пользоваться.
Но вот пара цифр:
— число пар оснований ДНК у человека — 3 млрд.
— число других макромолекул, которые могут служить «биомаркерами» оценивается в 20 000
Понятно, что речь идет о пространстве бешеных размерностей. Практически каждый «здоровый» (что бы это ни значило) человек будет отдельной точкой в этом пространстве.
Тут могли бы спасти всякие меры «близости». Но пока ничего подходящего придумать не удалось. Мутации в очень небольшом количестве нуклеотидных пар (если правильно выбрать) могут погубить жизнь человека.
Поэтому обычно и «пляшут» от патологий, а не от нормы. Т.к. патология, на практике является гораздо более узким понятием.
Плюс новость была представлена в этом же хабе: habrahabr.ru/company/medgadgets/blog/231063/
Про цели проекта — вопрос хороший. Но пока никто толком этого не понимает. И это тоже служит поводом для критики. Не объявлены измеримые цели.
Наихудшее время работы алгоритма будет O(N^2). Чему соответствует линейная оценка? Среднее время по случайным запускам с равномерно распределенными параметрами? Или чему-то другому?
В указанном смысле можете приписать Хаскель рядом с Джавой. Сути бабаяновской позиции это не изменит.
if v == None:
return None
if key == v.key:
return splay(v)
if key < v.key and v.left != None:
return find(v.left, key)
if key > v.key and v.right != None:
return find(v.right, key)
return splay(v)
Завершающий функцию return гарантирует, что если поиск неудачен, то последняя просмотренная вершина будет «выдернута» наверх. Это зачем такое?
Если у вас студенты, готовые повозиться с Эльбрусом?
На данный момент у меня есть такая информация:
1) найден рабочий Эльбрус-2 (в Софрино)
2) найден человек, который утверждает, что сохранил всю информацию по проекту (но есть неуверенность относительно кодов ОС). В любом случае есть бинарии ОС, поэтому можно поднять ее на симуляторе (который нужно будет разработать).
Если вы настроены серьезно, могу свести вас с людьми.
1) Я не верю, что владелец аккауна не смог доказать хост-провайдеру право на вледение аккаунтом
2) Злоумышленник рассказал жертве столько, что взять его за «шарики» не составит никакого труда. Таких болтунов даже в сказках не бывает…
С другой стороны, я не уверен, что они прямо бросятся шарить исходники. Все-таки это проприетарная вещь, которая (теоретически) может представлять коммерческий интерес. Так что не знаю… Но поговорить стоит.
В письме тоже делается (как мне показалось) акцент на неэффективность разделения указателей и данных:
«The original design — where data segments and Access segments were separate object was very, very in-efficient in hardware»
Интересно также отметить, что недостатки, о которых говорится в письме, — это недостатки машины, а достоинства — это достоинства организации работы в проекте.
Из возможных достоинств архитектуры (я ориентируюсь только на фрагменты, которые вы дали, так что ни в коем случае не претендую на полноту анализа) можно было бы отметить гибкую ISA. Но я не уверен, что в условиях того времени из этого можно было получить хорошую производительность.
В письме разработчик указывает лишь «административный» плюс: легко было вносить изменения в проект. В принципе, с хорошей ISA — это почти очевидно. Простая ISA — значит, можно посторить эффективный симулятор, который можно пределывать «на лету». Похоже, так у них и было.
А вот в плане производительности, скорее всего, ожидались большие проблемы. Простая ISA — громоздкая ISA (условно). Значит, нужна хорошая подкачка, нужен большой кеш. А с этим у них было плохо…
Видимо, еще нужно отметить, что в то время Бабаян вряд ли мог знать о проблемах с разводкой и ограничениях американского техпроцесса. Поэтому ему приходилось концентрироваться на логике. Что удивительно, он смог по косвенным признакам или из общих соображений вывести некоторые интересные вещи (например, очереди сегментов для переиспользования в процедурах и пр.) В беседе со мной он дал некоторый набросок того, как проводил анализ. Но я пока не могу об этом писать, т.к. совсем не знаю 432-ой машины. Боюсь неправильно что-то понять и налажать.
Ошибку, возможно, не обнаружили, потому что алгоритм не практичный. Наверное, никто особо не хотел его реализовывать.
А может, обнаружили, но забили. Дыры в алгоритмах иногда проще найти практику, нежели теоретику. Но практики не сильно заинтересованы в публикациях.
У меня коллеги как-то реализовывали алгоритм (точнее, целый комплекс алгоритмов) из одной очень продвинутой и котируемой американской диссертации.
В результате применения этих наработок в рамках большого промышленного проекта, выяснилось, что в диссертации огромная дырень, из-за которой вся диссертация должна лететь в трубу. Опровержения они не выпустили. Наверное, потому, что не было конструктива: как латать дыру, никто не знал. Писали автору, но он проигнорировал их письма :)
А вы в связи с чем разработчиков опрашивали? Что-нибудь публиковали на эту тему?
Не могли бы вы дать ссылку на работу, в которой описан «чистый» вариант?
Спасибо!
Много ли найдется студентов, желающих освоить Эль-76 и изучить операционную систему на нем?
Хотя думаю, что у любого студента, работающего в МЦСТ, такая возможность есть.