Стопами Дейкстры

Язабан

Любитель перекладывать байтики ручками?

Как-то раз была у меня на руках программа на Fortran 90, напичканная циклами. Автор программы не хотел использовать операции с массивами (не помню, как уж они там в Fortran называются). Вроде как ему просто для понимания было лучше.

Я попробовал всё-таки переделать её на более «продвинутый» способ. Занятие единоразовое и бессмысленное, так как программа меняется, а поддерживать форк — та ещё радость. Но всё-таки было интересно, сколько же мы теряем из-за такого подхода. В итоге вышло ускорение где-то на 30%.

А вот что самое интересное, так это то, что потом я попробовал собрать код Intel Fortran. И вот тогда уже разницы между оригинальной и моей версией не было, они работали с одинаковой скоростью. Примерно на уровне моей версии.

Вывод: используй хороший компилятор.

Вывод: используй хороший компилятор

Вот-вот, 21 век, кококо, а мы всё руками какую-то хероту пишем.

Вывод: используй хороший компилятор.

Проблема в том, что i может изменяться и в теле цикла. В случае хорошего компилятора, конечно, это проблема компилятора. А есть ведь еще и интерпретируемые языки, где с распараллеливанием for еще груснее. Но в случае тех же итераторов такой проблемы не возникает - оператор/блок операторов применяется к каждому элементу списка, который формируется до первой итерации.

Да :)

Дейкстра запретил оператор goto

Линусу забыли об этом рассказать!

Ты говоришь правильные вещи, но смотришь на проблему однобоко. Ситуации, когда нужен именно последовательный for, не так уж редки.

А по мне так это наоборот в зад всё пошло. Были понятные ассемблеро подобные языки. Конечно не совсем и не всё. А потом понеслось - доверь компилятору жизнь свою, гото плох, циклы плохи и тд. А чем плохи, тем что не умеете программировать, тем что железо не эволюционирует, а только растёт в ширь? Тем что данные хранят не только отдельно от кода, но ещё в специальных базах данных, потом ещё в специальных осях и тд? Не в том месте ищете затык, затык в умах и квалификации. А на чём писать дело десятое.

распараллеливание - миф

Мудростью данного джентльмена предмет разговора исчерпывается.

давай лучше про биологию и вещества

Ну так Линус пишет ведро с болтами. Там такие вещи как реализация исключений ручками бывают нужны.

Циклы и переменные не нужны, да.

анонiмус, перелогинься.

Бейсик <...> все циклы работали через метки.

Упрлс? FOR / NEXT

условный переход и безусловный переход

Ещё часто встречались «процедуры» GOSUB / RETURN. ;-) Что позволяло создавать процедуры с множеством точек входа.

Причём в классических бейсиках GOTO/GOSUB был не на метку, а не номер строки, что позволяло делать переход по значению переменной и даже вычислять её (строку). Такое вот внезапное приближение к ассемблеру. :)

Если осилить haskell то да.

Ну так GOSUB это переход по метке с запоминанием точки вызова. Номер строки это именно метка, он не обязан был соответствовать фактическому номеру строки.

Упрлс? FOR / NEXT

Это лишь доказывает архаичность FOR.

если язык в 21м веке требует для сложения двух матриц писать цикл, а не складывать их тупо как два числа - a+b, то язык говно

А что, реализация внутри этого не подразумевает цикла for?

Ну так в конечном итоге все сводится к машинному коду. Пиши сразу в hex-редакторе.

Так какое отношение «ненужный» цикл for имеет к перегрузке операторов?

Почему for, долой вообще всю императивщину!

Вспоминаем Вирта

В разных языках for реализовывали по разному: без возможности изменения параметра цикла (для скорости) и с оной (для гибкости). Не знаю как сейчас, но в стародавние времена for в pascal'e выполнялся быстрее, чем for в С, в С, Карл!!!111 :)

Это такой закос под "no raw loops"?

Номер строки это именно метка, он не обязан был соответствовать фактическому номеру строки.

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

Это лишь доказывает архаичность FOR.

Куда древнее. Циклы были описаны ещё Адой Байрон.

Почему for, долой вообще всю императивщину!

В принципе годная идея. Только с ней ещё бы ещё и функциональщину.

переопределять операторы

Спасибо, не надо.

Спасибо, кэп. Я уже и не помню, когда в высокоуровневом коде использовал циклы. Функции высших порядков как правило позволяют всё желаемое выразить яснее, проще и короче. Так что Америку ты нам не открыл.

Проблема в том, что i может изменяться и в теле цикла.

что-то мне подсказывает, что изменение счетчика цикла внтури цикла — дурной стиль и делать так не надо.

Будто это плохо. Мне за это ещё и платят.

А что, реализация внутри этого не подразумевает цикла for?

Нет.

В большинстве случаев, цикл for нужен исключительно для реализации итеративного прохода по структуре данных.

Если язык позволяет более элегантно реализовывать итератор, то конечно for лучше не использовать.

Например, в swift 3 выпилили c-style for loop.

И что в сухом остатке?

Самое смешное, что в современных языках он не нужен и даже вреден.

Напишете heapsort без for? PBKDF? И более стопицот других алгоритмов. Язабан.

А чего ты удивляешься?

Выход из цикла в паскале осуществляется строго по условию <> и строго над целочисленным счётчиком цикла и строго с шагом 1(это потом step завезли, явно не в стародавние времена, даже в трубо-паскале его не было), когда в C продолжение цикла - полноценное условие над произвольными типами данных. И операции над счётчиком - тоже произвольные.

За универсальность всегда приходится платить производительностью.

Куда древнее. Циклы были описаны ещё Адой Байрон.

Всё зло от баб (С)

Напишете heapsort без for? PBKDF? И более стопицот других алгоритмов. Язабан.

Если понимать цикл for как синтаксическую структуру(ведь тут разговор за синтаксис) - легко. Из цикла типа while наваяю. С итераторами, конечно, придутся повозиться, но и это решаемо.

Господа, если язык в 21м веке требует для сложения двух матриц писать цикл, а не складывать их тупо как два числа - a+b, то язык говно.

Ты не поверишь, но в любом языке на существующих архитектурах это выливается в цикл, или несколько циклов, если компилятор/интепретатор умеет в параллельность и ему объяснили что надо попытаться оптимизировать. Маленький цикл, возможно, будет даже развёрнут полностью, но это очень частный случай очень простого цикла когда в теле не испольуются данные предыдущей итерации.

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

Хочется без циклов, goto, и прочих совершенно необходимых для обеспечения работы обычной архитектуры вещей - возьми себе, например, нейросеточки и играйся с ними. Если руки не в жопе - запили на FPGA, если в жопе - то можно софтово (там, правда, под капотом всё равно будут циклы, но ты туда не смотри). Вот и будет тебе архитектура без циклов. Собирай свою программу из специально обученных нейросеток делающих какие-то элементарные операции. Это один из вариантов того, как ты сможешь действительно обойтись без ненавистных конструкций из прошлого века.

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

у меня почему-то есть стойкое ощущение что либо я чего-то не понимаю, либо в это ваше «нейросеточки» каждый вкладывает что-то свое, причем достаточно эфимерное и два человека, оперирующие термином «нейросеточка» говорят о чем-то своем и разном.

Господа, если язык в 21м веке требует для сложения двух матриц писать цикл, а не складывать их тупо как два числа - a+b, то язык говно.

Так и запишем: ассемблер - говно. ;)

DNA_Seq> Любитель перекладывать байтики ручками?

Во встраиваемых системах и в некоторых задачах HPC это необходимость, так как выигрыш, скажем, в 10% на десктопе - это совсем не то же самое, что выигрыш в 10% на суперкомпьютере.

FOR в бейсике - это совсем не то же самое, что FOR в, скажем, C, и уж тем более в python или shell.

DNA_Seq> Ну так в конечном итоге все сводится к машинному коду. Пиши сразу в hex-редакторе.

Некоторые так и делают, когда задача располагает. И, в общем-то, правильно делают.

В простейшем и очень общем случае, нейросеть - это такой «серый ящик» у которого n входов и m выходов. На стадии обучения на n входов подаются некие входные паттерны, на m выходов (которые на этом этапе работают как входы) - некие паттерны которые должны быть на выходах при соответствующих паттернах на входе. После обучения. при подаче паттерна на вход, на выходе будет некий паттерн, которому обучена нейросеть.

Например, если взять нейросеть с 2 входами и 1 выходом, и обучить её что при входном паттерне 1;1 на выходе должен быть 0, а во всех остальных случаях 1, то мы получим элементарный логический элемент И-НЕ. Расширив этот пример на большее количество входов и выходов и не ограничиваясь логическими уровнями, можно получать нейросети разнообразнейшего назначения. Например для преобразования Фурье, или там для реализации логики какой-нибудь гуйни.

Таким образом, для решения произвольной задачи, если она описана в терминах «входов» и «выходов», можно создать и обучить нужные «элементы»-нейросети и собрать из них готовую софтину, которая будет работать согласно описанию. Самое интересное начинается, когда на вход будут подавться комбинации не описанные в ТЗ. :) В большинстве случаев оно справляется вполне адекватно, но иногда бывает веселье.

ЗЫ: В одной своей коммерческой софтине использую (пока в виде R&D) нейросеть для расчёта состава красок по спектру образца. Нейросеть обучена по образцам спектров отдельных пигментов из которых делают краски. В 99% случаев результат (рецепт краски и соответствие его спектра спектру образца) весьма удовлетворителен, и часто лучше результатов других методов. Чем хорош такой подход - не надо производить много матана и забивать себе голову всякой шнягой, как в случае конвенциональных методов расчёта рецептур. Вся задача сводится к обучению нейросети, без неоходимости осмысливать происходящие в ней процессы. В общем-то, последнее и есть её основное преимущество.

Счастье

Дейкстра запретил оператор goto

ШОК: методички запретили днасеку мозг

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

К тому что вместо того чтоб писать сложение массивов через циклы можно их просто сложить оператором +.

вместо того чтоб писать сложение массивов через циклы можно их просто сложить оператором +

Магически шоле? %)

Под капотом все равно будет перекладывание байтиков.

Мусье о функциональщине? И, да, язабан.