Pull to refresh

Comments 38

Выглядит забавно. Единственное что — когда у меня возникает вопрос, как это сделать, обычно я прихожу либо к Regex, либо к какой нибудь строгой формуле. CallSharp мне Regex не построит, я так понимаю? =)
Конечная идея какая, генерация тестов, улучшенная версия Pex and Moles?
Нет, просто подсказывать возможные цепочки вызовов по входным-выходным данным. Использовать можно прямо у себя в проекте.
UFO landed and left these words here
Это в каком-то смысле реально: мы ведь можем получить IL для цепочки — соответственно можем посчитать примерную стоимость.
Ой, я имел ввиду наоборот, по коду теста, генерировать код, который будет проходить тест.
Ну так это по сути оно и есть. Только тест — это еще более сильная форма. Я пока хочу сделать наборы входных-выходных значений.
Кхм, а как вы это себе представляете?
Идея интересная, однако слабо представляю, как это будет нормально работать без серьезного машинного обучения.

У меня возникала идея, чтобы алгоритм генерировал код и тесты для проверки граничных значений при разработке других алгоритмов или программ. Потому что это и не очень интересно и бывает непросто.
Как альтернативу AI методам можно продолжать делать полный перебор, но уже кластерно/распределенно.
Скачал исходники, запустил… Мда, сейчас невозможно пользоваться, т.к. нереально тормозит даже для простейших случаев (не смог дождаться завершения). Для того же abc — cba, указанного в статье.
Этот случай не работает вообще — программа пока не поддерживает. Сорри.
Может «тулина» лучже бы звучало? :)
инструмент или утилита звучит куда лучше.
Да, это все от термина developer tools. Наверное «инструмент» правильнее, но дольше писать.
У вас интересная идея, но разумеется любой разработчик представляет как использовать на практике. Что мы будем делать, например с файлами и БД? Почти в любой проге есть конфиг, есть DAL, и допустим нам в простейшем случае нужно считать всех Customers из базы. На входе (он же ожидаемый выход) — список из Customer, а перебирать как?
Как в целом вы видите решение ресурсоемких задач, которые бывают на практике?
Мое предположение
Разумеется есть замечательное понятие — эвристики. И некоторые настройки, которые внесет пользователь.
Пpoблeмa в ocнoвнoм в иcпoльзoвaнии reflection (в чacтнocти, МеthоdInfо.Invоkе()) a тaкжe в кoмбинaтopныx взpывax cвязaнныx c глубинoй вызoвoв и кoличecтвoм apгумeнтoв и иx вapиaций.

По быстрому прошелся профилировщиком и заметил, что действительно на InvokeWithArguments тратится около четверти процессорного времени. А разве нельзя просто ввести большой switch-case на все поддерживаемые сигнатуры методов без использования T4? Тем более что некоторые из них избыточны. Например, вместо двух методов
input.ToUpper()
input.ToUpperInvariant()

можно использовать один из них практически без потери общности.
Уже на 70% реализован статический обход через T4, бегает очень резво. А два варианта выше — они может и почти-эквивалентны, но все же не совсем. Я не думаю их можно сворачивать в один.
Стоит добавить возможность предлагать варианты не по одной паре ввод-вывод, а по нескольким.
Так в последнем примере можно дать две пары «a b c» > «abc», «a b c d» > «abcd»
И сразу большинство экзотических решений отпадет.

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

А если по самой теме, получается тут важно, чтобы компьютер смог сделать какое-то действие, и если не рассматривать логичность метода с точки зрения человека, и неважно, чтобы код был красив, то может и не нужно перебирать все доступные способы? Имею ввиду, что если важен только бинарник, который выполняет определенную задачу, то выполнить «abc » > «ABC», можно даже через string.Concat(input.Split()).ToUpper(), если оно буде первым в результате поиска. Ну или, учитывая, что что-то может быть неефективним, если это вызывается много раз подряд в программе или создает много объектов, то как-то фильтровать сложность цепочки по каких-то статических анализах, как возможные boxing/unboxing и тд
Тут вот в чем дело: программа может дать первичный набор вариантов, из которых можно фильтровать двумя способами. Один — это предоставить более одной пары входных-выходных данных, я это планирую реализовать. Второй — это просто «использовать голову», т.е. смотреть на то, что тебе выдают, и решать что из этого подходит лучше всего. Конечно, какие-то эвристики в плане «сложности» можно и в программе реализовать, я думаю над этим.
Ну я больше к тому, что странно предоставлять такое человеку, который считает себя программистом, иначе это все превратиться в рабочего на конвейере, который только и делает, чтобы проверять логику результатов, как можно что-то написать. А потом и сам контроль пропадет, поскольку как этот человек уже будет знать, если он обучался с помощью такого помощника.

Ну а если говорить о быстрых решениях, где нужно «на вчера» мелкий инструмент, который будет считать некую формулу, а потом можно просто выбросить его, то тогда уже становиться интересней. Где будет все равно, как реализована каждая строчка алгоритма (разумеется, это я о том, какие функции были вызваны в определенном API).

Ну или если говорить в понятиях регулярных выражений, о которых шла речь в докладе, то опять же если оно выдает результат по отношению к заданным данным, то вряд ли можно как-то гарантировать правильность, оно все же будет только выдавать некий шаблон, и нужно прекрасно понимать синтаксис, чтобы разобраться, что можно это было сделать красивее. Но в этот момент вступает в игру, что 95% людей, кто захочет так сгенерировать регулярку, начнут дальше решать свои проблемы в коде, а не думать об эффективности этого результата. В ровном счете, как и процессору будет все равно, как оно посчитает что-то из бинарника, куда даже не смотрел человеческий глаз.
с помощью этой программы можно попробовать найти зрительно комбинации, который человек может в голове не представить, потом пробежаться по этому большому списку комбинаций, всей фирмой, выбрать красивые и/или типичные, затем засунуть в решарпер те цепочки, до которых не додумались или забыли.
Так и не понял для чего это может понадобится. Обычно задачи более конкретно ставятся — удалить пробелы, проверить регистр первого символа… Чтобы получить одно значение из другого без дополнительных условий и информации можно просто писать If (a==«abc») return 3; //profit

Ну смотрите, допустим у вас есть 4.5 а нужно 4. Должно быть, какая-то функция есть, которая округляет, но как она называется? Забиваете и то и то в программу и смотрите, что вам предлагают.
Может это не результат округления, а первый символ? Или вырезание подстроки ".5", или вычитание 0.5? Даже если будут предложены все эти варианты — без доп. информации всё равно не получится выбрать нужный вариант. А если известно, что требуется округлить — легче и быстрее забить запрос в гугл, мне кажется.
Да, но в будущем я планирую давать возможность забивать несколько пар значений, дабы удалить неоднозначности.
А кто будет генерить эти пары значений? Пользователь, зная, что ему надо округлить число будет вводить:
4.5: 4
-4.5: -4
345: 345
345.9: 345
122.6: 122
...?
И то это не устранит всех неоднзначностей: может строка после точки обрезается, может заменяются ".6", ".5" и ".9", может удаляются два последних символа, если предпоследний точка?
А если пользователь даже не знает что ему надо получить, а просто дан набор данных, то нет гарантии что он полный для того чтобы определить нужную комбинацию кода, который бы работал на прочих данных.
Но мы точно сузим общее количество вариантов.
Чтобы сузить бесконечное число вариантов до конечного нужно бесконечно много ограничений)
Ну и это не даёт ответа на вопрос как пользователь узнает который вариант ему выбрать — округление или первый символ, если он не знает постановки задачи.
А нет планов прикрутить бенчмарки полученных вариантов и сортировать список вариантов по быстродействию?
Sign up to leave a comment.

Articles