Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что такое полноценные целые ? Google мне в поиске почему-то ничего о них не сказал.
Множество Z: https://ru.wikipedia.org/wiki/%D0%A6%D0%B5%D0%BB%D0%BE%D0%B5_%D1%87%D0%B8%D1%81%D0%BB%D0%BE
PD>Меня интересует именно возможность переполнения. Это ширина и высота прямоугольника и площадь его соответственно. Тип — uint. Ограничения на h и w — не более 100000, допустим. Других данных у меня нет. Если оно будет , то все последующие действия накроются медным тазом. Вот и скажите, как определить статическим анализом его возможность или невозможность в этом случае. Без рассуждений об аксиоматике и каких-либо дополнительных требованиях — повторяю. у меня больше ничего нет.
Переполнение — это когда результат произведения в uint отличается от результата "настоящего" произведения.
Это даёт нам два возможных способа записи постусловия:
— сравнением результата с честным произведением бесконечноразрядных целых
— сравнением результата с произведением в удвоенной битности.
Как только мы записали предусловие, постусловие, и сформулированы критерии верификации, любой SAT/SMT солвер вам сразу найдёт контрпример.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
PD>>Меня интересует именно возможность переполнения. Это ширина и высота прямоугольника и площадь его соответственно. Тип — uint. Ограничения на h и w — не более 100000, допустим. Других данных у меня нет. Если оно будет , то все последующие действия накроются медным тазом. Вот и скажите, как определить статическим анализом его возможность или невозможность в этом случае. Без рассуждений об аксиоматике и каких-либо дополнительных требованиях — повторяю. у меня больше ничего нет. S>Переполнение — это когда результат произведения в uint отличается от результата "настоящего" произведения. S>Это даёт нам два возможных способа записи постусловия: S>- сравнением результата с честным произведением бесконечноразрядных целых S>- сравнением результата с произведением в удвоенной битности. S>Как только мы записали предусловие, постусловие, и сформулированы критерии верификации, любой SAT/SMT солвер вам сразу найдёт контрпример.
А можно сказать все же, без "теоретических" соображений, что мне выдаст хоть статический верификатор , хоть ИИ на программу
void main()
{
unsigned int l,w,s;
sscanf("%d %d", &l, &w);
s = w * l;
printf("%d", s);
}
А то ведь у меня ничего, кроме этой программы, и нет.
Или я должен к каждой операции умножения приделать предусловие и постусловие в виде честного произведения бесконечноразрядных целых или же вычисления в unsigned long и сравнения ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Как мы любим обещать, что в будущем все сможет. А пока что (из этих слов явно следует) не может. И пока мне неясно, что вызовет качественный скачок от нынешнего "не может" к будущему "сможет". Тут должно нечто радикальное произойти, а пока неясно, что именно.
Пока в основном неясно, что вы называете "творить новое". И как отличить прямо новое-новое от "компиляции уже существующего".
Очень может быть, что у меня, у вас, и у Влада эти критерии существенно отличаются. Именно поэтому получаются разные ответы на один и тот же вопрос.
Как по мне, так эти инструменты уже сейчас делают то, что вполне отвечает критериям новизны, принятым, к примеру, в научной среде.
И ещё такая гипотеза или, скорее, метафора, мне приходит на ум: эти инструменты, не заменяют человека, а усиливают его способности.
Если человек — идиот, то LLM многократно усилит его способность делать глупости.
Если человек умён, то ИИ многократно усилит его способность получать интеллектуальные результаты.
Поэтому в сети так много разных мнений об одних и тех же агентах: одни говорят "этот инструмент заменяет мне половину лаборатории" и "90% моих научных результатов за последний год получены при помощи ИИ", а другие говорят "он способен только решать очевидные задачки, и то плохо". Люди смотрятся в этих агентов, как в зеркала
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>И ещё такая гипотеза или, скорее, метафора, мне приходит на ум: эти инструменты, не заменяют человека, а усиливают его способности. S>Если человек — идиот, то LLM многократно усилит его способность делать глупости. S>Если человек умён, то ИИ многократно усилит его способность получать интеллектуальные результаты.
А если ИИ тратит моё время, следует ли считать, что моя основная способность — тратить время?
ну вот примерно так
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sinclair, Вы писали:
PD>>Как мы любим обещать, что в будущем все сможет. А пока что (из этих слов явно следует) не может. И пока мне неясно, что вызовет качественный скачок от нынешнего "не может" к будущему "сможет". Тут должно нечто радикальное произойти, а пока неясно, что именно. S>Пока в основном неясно, что вы называете "творить новое". И как отличить прямо новое-новое от "компиляции уже существующего". S>Очень может быть, что у меня, у вас, и у Влада эти критерии существенно отличаются. Именно поэтому получаются разные ответы на один и тот же вопрос. S>Как по мне, так эти инструменты уже сейчас делают то, что вполне отвечает критериям новизны, принятым, к примеру, в научной среде.
Хороший вопрос. Коль скоро речь пошла о критериях новизны в научной среде, обсудим.
Вот когда-то я делал диссертацию в лаборатории термохимии. Я занимался расчетами, и не о них речь. А в основном лаборатория делала экспериментальную работу. Измеряли теплоты (энтальпии) сгорания органических веществ, определяли по ним энтальпии образования их, вот это и было основным профилем работы.
После получения данных по нескольким близким по структуре веществам публиковалась статья (или тезисы на конференции). Статью журнал бы не принял, не будет в ней научной новизны. Она и была — впервые получены значения энтальпий образования таких-то веществ.
После нескольких лет работы делалась кандидатская. В ней приводились все данные, полученные за эти годы, описывалась методика, прибор и т.д. В диссертации пункт "научная новизна" обязателен. Вот и писали — впервые определены значения энтальпий образования такого-то круга веществ, потом делались выводы. Все честною Никакой ВАК не придерется, потому что придираться не к чему.
Могла бы такая работа быть сделана без участия человека ? В принципе — вполне. Если все это автоматизировать, а потом результаты отдать ИИ, да еще скормить ему все, что есть в мире по термохимии — он вполне мог бы и отчет составить, и выводы сделать, а то и диссертацию написать.
А есть основы этой термохимии. Основа основ, конечно, закон сохранения энергии, ну не о нем речь. А конкретно для термохимии — закон Гесса. Вот это и было когда-то новое. Разумеется, сформулировать закон Гесса ИИ мог бы, но только если бы он до него "додумался". Чтобы додуматься, нужен был Гесс. Чтобы додуматься до закона сохранения массы, нужен был Лавуазье. Для первого закона Ньютона — Ньютон.
Любопытный , кстати, тут момент. И закон сохранения массы и первый закон Ньютона на первый взгляд противоречат здравому смыслу (== предыдущему накопленному опыту). Ну не движется же тело бесконечно, если его толкнуть. Останавливается. И какое уж там сохранение массы — сжег я вязанку дров массой в 10 килограмм, и осталось полкилограмма пепла. Нужны были Ньютон или Лавуазье, чтобы догадаться.
Ну а в информатике — чтобы додуматься до быстрой сортировки, нужен был Хоар. А сама задача сортировки понятна ребенку и решение он найдет. И ИИ отсортировать сможет
А если Вы меня попросите сформулировать точно, где граница между этими видами научной деятельности — я откажусь. Не удастся тут формально определить точную границу. Какое определение ни дай — всегда найдется к чему придраться. И тем не менее первое от второго на примерах отличить не сложно. Алгоритм Хоара — это новое в свое время, тут, я думаю, Вы спорить не будете. Идея статического анализа — тоже новое когда-то было, наверное. А провести статический анализ для данного кода — это на новое в этом смысле не тянет.
S>И ещё такая гипотеза или, скорее, метафора, мне приходит на ум: эти инструменты, не заменяют человека, а усиливают его способности. S>Если человек — идиот, то LLM многократно усилит его способность делать глупости. S>Если человек умён, то ИИ многократно усилит его способность получать интеллектуальные результаты.
Вполне согласен. Но это к многим инструментам относится.
На заре моей программистской карьеры интерактивных отладчиков не было. Какая уж там интерактивность при работе с перфокартами! Печатай промежуточные значения, а потом за столом анализируй, что получилось. И умели. Виртуозно некоторые умели.
Потом появились отладчики. В умелых руках они могли ускорять разработку в десятки раз. В неумелых — было бесконтрольное блуждание по коду, без какого-то плана исследования, а отладчик не распечатка, посмотреть, что делалось на предыдущих брекпойнтах зачастую невозможно, так что начинай все сначала.
S>Поэтому в сети так много разных мнений об одних и тех же агентах: одни говорят "этот инструмент заменяет мне половину лаборатории" и "90% моих научных результатов за последний год получены при помощи ИИ", а другие говорят "он способен только решать очевидные задачки, и то плохо". Люди смотрятся в этих агентов, как в зеркала
Да ради бога. Не надо думать, что я его противник. Вовсе нет. Хороший новый инструмент, вполне годится для решения многих задач. Со своими преимуществами и недостатками.
Меня лишь смущает тот ажиотаж, который вокруг него поднялся. Найдена новая золотая пуля. Завтра она заменит всех и будет везде. Вот тут у меня определенный скептицизм.
А кстати, можно Вам вопрос задать ? Какие неустранимые в принципе недостатки у него есть ? Что он в принципе не сможет сделать из того, что может сделать ЕИ (разумеется, о физических действиях речь не идет) ?
.Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А можно сказать все же, без "теоретических" соображений, что мне выдаст хоть статический верификатор , хоть ИИ на программу PD>
PD>void main()
PD>{
PD>unsigned int l,w,s;
PD>sscanf("%d %d", &l, &w);
PD>s = w * l;
PD>printf("%d", s);
PD>}
PD>
PD>А то ведь у меня ничего, кроме этой программы, и нет.
Статический верификатор — ничего. У вас нет требований к этой программе. PD>Или я должен к каждой операции умножения приделать предусловие и постусловие в виде честного произведения бесконечноразрядных целых или же вычисления в unsigned long и сравнения ?
Эмм, вообще-то преподаватель технического ВУЗа по айтишной специальности должен хоть краем глаза слышать о методах проверки корректности программ. В частности, о дедуктивной верификации.
А вот ИИ на эту программу выдаст следующее:
В программе есть несколько ошибок и неточностей. Разберём их по порядку.
❌ Ошибки
Неверное использование sscanf sscanf считывает данные из строки, а у тебя строка не передаётся.
Для ввода с клавиатуры нужно использовать scanf.
Несоответствие формата типу unsigned int
Используется %d, который предназначен для int, а переменные объявлены как unsigned int.
Для unsigned int нужно использовать %u.
void main() — некорректно
В стандартном C правильная сигнатура:
int main(void)
или
int main()
Нет подключения stdio.h
✅ Исправленная версия программы
#include <stdio.h>
int main(void)
{
unsigned int l, w, s;
scanf("%u %u", &l, &w);
s = w * l;
printf("%u\n", s);
return 0;
}
📌 Что делает программа
Считывает два числа (l и w)
Вычисляет их произведение
Выводит результат
Если хочешь — могу также объяснить разницу между scanf и sscanf.
Есть ли какие-либо проблемы в исправленной версии?
Да — в целом исправленная версия корректная, но есть несколько моментов, которые стоит учитывать.
✅ Что уже правильно
Используется int main(void)
Подключён stdio.h
Формат %u соответствует unsigned int
Добавлен return 0;
Есть перевод строки в printf
⚠ Возможные проблемы
Нет проверки результата scanf
Если пользователь введёт:
буквы вместо чисел
только одно число
ничего
переменные могут остаться неинициализированными.
Лучше проверить количество успешно считанных значений:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот когда-то я делал диссертацию в лаборатории термохимии. Я занимался расчетами, и не о них речь. А в основном лаборатория делала экспериментальную работу. Измеряли теплоты (энтальпии) сгорания органических веществ, определяли по ним энтальпии образования их, вот это и было основным профилем работы. PD>После получения данных по нескольким близким по структуре веществам публиковалась статья (или тезисы на конференции). Статью журнал бы не принял, не будет в ней научной новизны. Она и была — впервые получены значения энтальпий образования таких-то веществ. PD>После нескольких лет работы делалась кандидатская. В ней приводились все данные, полученные за эти годы, описывалась методика, прибор и т.д. В диссертации пункт "научная новизна" обязателен. Вот и писали — впервые определены значения энтальпий образования такого-то круга веществ, потом делались выводы. Все честною Никакой ВАК не придерется, потому что придираться не к чему.
PD>Могла бы такая работа быть сделана без участия человека ? В принципе — вполне. Если все это автоматизировать, а потом результаты отдать ИИ, да еще скормить ему все, что есть в мире по термохимии — он вполне мог бы и отчет составить, и выводы сделать, а то и диссертацию написать.
В каком-то смысле всё, что в мире есть по термохимии, в ИИ уже скормлено.
Сам ставить он эксперименты пока не может, но если задать ему вопрос в духе "я вот собираюсь исследовать то-то и то-то, будет ли в этом научная новизна" — то он легко ответит.
Можно быстро нащупать направление, которое ещё не слишком хорошо покрыто экспериментами — или, наоборот, убедиться, что все нужные значения уже кем-то получены.
Дальше можно попросить совета по дизайну будущего исследования — и он вполне толково расскажет, что и как нужно делать, и на что обращать внимание.
Потом поможет обобщить полученные результаты. Если будут какие-то аномалии — поможет найти им объяснения.
Потом поможет написать по результатам статью.
Ещё раз подчеркну: это не "если когда-нибудь", а прямо сейчас, с 2025 года начиная.
PD>А есть основы этой термохимии. Основа основ, конечно, закон сохранения энергии, ну не о нем речь. А конкретно для термохимии — закон Гесса. Вот это и было когда-то новое. Разумеется, сформулировать закон Гесса ИИ мог бы, но только если бы он до него "додумался". Чтобы додуматься, нужен был Гесс. Чтобы додуматься до закона сохранения массы, нужен был Лавуазье. Для первого закона Ньютона — Ньютон.
С естественными науками тут тяжело. В основном потому, что мы не знаем точного механизма возникновения гипотез в человеческом сознании. Метанаучная мысль в последние пару сотен лет в основном сосредотачивалась на механизмах отбрасывания неудачных гипотез. А вот откуда мы берём гипотезы — никто не знает. Большинство гипотез в этой области были опровергнуты — в частности, самая очевидная и популярная: "мы обобщаем результаты наблюдений". Нет, не обобщаем
PD>Ну а в информатике — чтобы додуматься до быстрой сортировки, нужен был Хоар. А сама задача сортировки понятна ребенку и решение он найдет. И ИИ отсортировать сможет
Вот тут уже лучше — нет "реального мира", с которым агент пока взаимодействовать толком не может.
Если мы ставим вопрос как "может ли ИИ придумать новый алгоритм", то ответ как раз и зависит от того, что мы называем новым.
Видов "быстрой" сортировки — как грязи. И большинство из них не изобретают чего-то принципиально нового, а собирают решение из отдельных кусочков.
Вот на такие вещи ИИ вполне способен — не просто найти благодаря эрудиции известную формулу, а построить новую формулу "на основе и по аналогии". Примерно так же, как это делает живой человек.
PD>Меня лишь смущает тот ажиотаж, который вокруг него поднялся. Найдена новая золотая пуля. Завтра она заменит всех и будет везде. Вот тут у меня определенный скептицизм.
Не всех, не всех. Компиляторы в значительной степени заменили знатоков низкоуровневого программирования. Не на 100%, но вытеснили этих специалистов на периферию профессии.
PD>А кстати, можно Вам вопрос задать ? Какие неустранимые в принципе недостатки у него есть ? Что он в принципе не сможет сделать из того, что может сделать ЕИ (разумеется, о физических действиях речь не идет) ?
Я не вижу никаких неустранимых недостатков. Естественный интеллект не имеет принципиальных отличий от искусственного. Ну, есть у нас ещё всякая биохимия, которая влияет на "рациональное сознание" — чувство голода, инстинкты размножения, эмоции там всякие, опьянение опять же. Но это всё — всего лишь очередные веса в очередных нейросетях. Надо будет — и это смоделируем.
А в остальном — нет никакой божьей искры. Есть достаточно сложно устроенный компьютер, который оперирует во вполне себе физическом мире.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Эмм, вообще-то преподаватель технического ВУЗа по айтишной специальности должен хоть краем глаза слышать о методах проверки корректности программ. В частности, о дедуктивной верификации.
Слышал.
S>А вот ИИ на эту программу выдаст следующее:
S>В программе есть несколько ошибок и неточностей. Разберём их по порядку.
<skipped>
Да, конечно, написал с ошибками. Писал прямо здесь. Увы, у меня не установлен сейчас С++ компилятор на машине, давно с ним не работал. Раньше я перед постингом обычно проверял работу кода.
Остальное skipped, потому что относится к ошибкам в коде, а не к основному вопросу про переполнение.
Кроме вот этого.
S>Возможное переполнение
S>Если l и w достаточно большие, произведение может переполнить unsigned int.
S>Если это учебная задача — всё нормально.
Это не учебная задача, а пример ad hoc, сделанный для иллюстрации вопроса.
В итоге имеем лишь одно замечание по существу — про возможность переполнения. То, что переполнение "в принципе" возможно при умножении 2 uint — для этого не надо никаких верификаций, это и так ясно. И из этого вовсе не следует, что так уж необходимо перейти к ulong.
Я ничего против того, что он на это указал, не имею. Пусть напомнит, верно. Но меня-то иное интересовало — может ли оно быть при тех данных, которые меня интересуют. А на этот вопрос у него ответа нет.
Если эти длина и ширина — размеры дисплея обычной машины в пикселях, то совершенно спокойно можно остаться с unit — пока что дисплеев с размерами, при которых переполнение возможно, в природе нет.
Если это что-то другое — надо знать, какие могут быть значения у этих величин. Вот я приводил 100000 как пример. Допустим, я не знаю, каков maxint. Делаю несколько простейших тестов — работает. Делаю тест 100000 на 100000 — проваливается. Все. Действительно, надо переходить к ulong.
Ну а если это размеры дисплея — ну сделаю тест 10000 на 10000, все будет в порядке, можно так и оставить.
Так что тест мне ошибку найти сможет, а этот анализ лишь говорит, что она в принципе возможна. Это и без него ясно.
Впрочем, можно и более простой пример привести. даже без умножения.
unsigned int population;
Это корректно или нет ?
Если это население страны, то я нелестно выскажусь в адрес того, кто мне скажет, что может не хватить. Нет таких стран с населением 4 млрд. человек и скорее всего не будет. А если когда-то и будет, то моей программы уже точно не будет
Если это население Земли, то не годится. Не хватит. Сейчас. А были бы компьютеры в 15 веке, сказали бы, что вполне хватит. И несколько веков бы вполне хватило.
Что мне тут статический анализ скажет ? Про потенциальную возможность переполнения при суммировании любых чисел ? Спасибо. Без него я бы не догадался
А тест скажет. Найдем население Земли как сумму населений стран — и все. Приехали. Сейчас. А в 15 веке все было бы в порядке.
Здравствуйте, Sinclair, Вы писали:
S>В каком-то смысле всё, что в мире есть по термохимии, в ИИ уже скормлено.
Наверняка.
S>Сам ставить он эксперименты пока не может, но если задать ему вопрос в духе "я вот собираюсь исследовать то-то и то-то, будет ли в этом научная новизна" — то он легко ответит.
Тут не надо никакого ИИ. Если для этих веществ измерения энтальпии сгорания никем не проводились, то научная новизна "будет". Такие тут правила. Определение характеристик вещества, если раньше эти характеристики не измерялись, по определению подходит под понятие научной новизны. Никто возражать не будет.
Так что просто достаточно по справочникам посмотреть, определялось ли для этого вещества , и если нет — делайте, научная новизна обеспечена.
S>Можно быстро нащупать направление, которое ещё не слишком хорошо покрыто экспериментами — или, наоборот, убедиться, что все нужные значения уже кем-то получены.
Ну это мы в термохимии и так хорошо знали. Были 2 справочника, в которых было все, что было до нас сделано. А для нового — мониторинг РЖХим и Chemical Abstracts. Пара дней работы в год. БД тогда не было, с ними было бы проще, часа бы хватило. Это весьма узкая область, в ней все серьезные исследователи друг друга знают.
S>Дальше можно попросить совета по дизайну будущего исследования — и он вполне толково расскажет, что и как нужно делать, и на что обращать внимание. S>Потом поможет обобщить полученные результаты. Если будут какие-то аномалии — поможет найти им объяснения. S>Потом поможет написать по результатам статью. S>Ещё раз подчеркну: это не "если когда-нибудь", а прямо сейчас, с 2025 года начиная.
Вопрос не в том, чем он сможет помочь, а в том, что Вы раньше говорили, что он может сделать то, что подходит под понятие научной новизны. Вот я и объяснил, что этот критерий весьма специфичен.
PD>>А есть основы этой термохимии. Основа основ, конечно, закон сохранения энергии, ну не о нем речь. А конкретно для термохимии — закон Гесса. Вот это и было когда-то новое. Разумеется, сформулировать закон Гесса ИИ мог бы, но только если бы он до него "додумался". Чтобы додуматься, нужен был Гесс. Чтобы додуматься до закона сохранения массы, нужен был Лавуазье. Для первого закона Ньютона — Ньютон. S>С естественными науками тут тяжело. В основном потому, что мы не знаем точного механизма возникновения гипотез в человеческом сознании. Метанаучная мысль в последние пару сотен лет в основном сосредотачивалась на механизмах отбрасывания неудачных гипотез. А вот откуда мы берём гипотезы — никто не знает. Большинство гипотез в этой области были опровергнуты — в частности, самая очевидная и популярная: "мы обобщаем результаты наблюдений". Нет, не обобщаем
В том-то и дело. Мы действительно не знаем, как возникают гипотезы в человеческом мозге. Даже как пресловутое яблоко привело Ньютона к закону всемирного тяготения — не знаем. Падающие яблоки и до него наблюдали. . А вот что должно было произойти в его мозгу, чтобы привести к открытию — непонятно. (О том, что это , возможно, лишь легенда — не будем).
Но если это непонятно — как можно предполагать, что ИИ сможет такое делать ? Ведь он, как ни будь сложен, все же лишь результат работы некоторого алгоритма. А в алгоритм вложить это ньютоновское озарение можно, только если его алгоритмизировать. А это мы сделать не можем, так как даже не понимаем, что оно такое.
PD>>Ну а в информатике — чтобы додуматься до быстрой сортировки, нужен был Хоар. А сама задача сортировки понятна ребенку и решение он найдет. И ИИ отсортировать сможет S>Вот тут уже лучше — нет "реального мира", с которым агент пока взаимодействовать толком не может. S>Если мы ставим вопрос как "может ли ИИ придумать новый алгоритм", то ответ как раз и зависит от того, что мы называем новым.
И возвращаемся на круги своя.
S>Видов "быстрой" сортировки — как грязи. И большинство из них не изобретают чего-то принципиально нового, а собирают решение из отдельных кусочков. S>Вот на такие вещи ИИ вполне способен — не просто найти благодаря эрудиции известную формулу, а построить новую формулу "на основе и по аналогии". Примерно так же, как это делает живой человек.
ИМХО алгоритм Хоара — это первый O(NlgN) для сортировки. Вот это и есть новое. Оно заключается в том, что впервые было доказано, что сортировку можно произвести за время, лучше , чем квадратичное. А вот когда это было открыто, дальнейшие варианты O(NlgN) — уже не принципиально новое, а просто модификации идеи путем разных реализаций. Тут и впрямь улучшать можно до бесконечности. И поэтому про алгоритм Хоара знают все, ну а про остальные — кто что.
Другой пример. Бинарные деревья поиска. Когда их придумали — это было новое. Сама идея. А потом новым было доказательство того, что можно сделать сбалансированное БДП так, чтобы и в худшем случае было O(logN). Это АВЛ деревья, и это новое. А вот красно-черное дерево новых идей не содержит. Идея та же — самобалансировка. Реализация иная, в чем-то лучшая, чем АВЛ.
PD>>Меня лишь смущает тот ажиотаж, который вокруг него поднялся. Найдена новая золотая пуля. Завтра она заменит всех и будет везде. Вот тут у меня определенный скептицизм. S>Не всех, не всех. Компиляторы в значительной степени заменили знатоков низкоуровневого программирования. Не на 100%, но вытеснили этих специалистов на периферию профессии.
+1
PD>>А кстати, можно Вам вопрос задать ? Какие неустранимые в принципе недостатки у него есть ? Что он в принципе не сможет сделать из того, что может сделать ЕИ (разумеется, о физических действиях речь не идет) ? S>Я не вижу никаких неустранимых недостатков. Естественный интеллект не имеет принципиальных отличий от искусственного.
Вы же только что сами сказали, что (цитирую) "мы не знаем точного механизма возникновения гипотез в человеческом сознании". Одного этого достаточно, чтобы признать наличие отличий. Для ИИ мы хотя бы в принципе механизм формирования его "идей" знаем — сами вложили.
>Ну, есть у нас ещё всякая биохимия, которая влияет на "рациональное сознание" — чувство голода, инстинкты размножения, эмоции там всякие, опьянение опять же. Но это всё — всего лишь очередные веса в очередных нейросетях. Надо будет — и это смоделируем.
А этот механизм возникновения гипотез в человеческом сознании тоже ? При том, что мы его не понимаем. . Как можно смоделировать то, что мы не понимаем ?
S>А в остальном — нет никакой божьей искры. Есть достаточно сложно устроенный компьютер, который оперирует во вполне себе физическом мире.
Вот тут и лежит основное наше с Вами разногласие. Я в этом не уверен. Точнее, я не уверен в том, что человеческое мышление чисто алгоритмическое, и что ничего другого в нем нет. Только, конечно, не надо меня к адептам религии причислять, не в этом дело. Я просто не уверен, что нет других механизмов, кроме алгоритмических.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да, конечно, написал с ошибками. Писал прямо здесь. Увы, у меня не установлен сейчас С++ компилятор на машине, давно с ним не работал. Раньше я перед постингом обычно проверял работу кода.
А я думал, что это намеренно — тест на то, какие ошибки сможет найти ИИ, ничего не зная о программе.
Ошибку с неверным количеством параметров ещё может найти компилятор (и то не всякий — в K&R, емнип, не было сигнатур функций, как таковых. Параметры перечислялись внутри тела, а не в заголовке).
А вот ошибку несоответствия типов аргументов форматной строке традиционный компилятор не найдёт — потому что для него семантика форматной строки скрыта. Просто какая-то строка, просто какие-то адреса в параметрах.
Тут уже нужно какое-то средство анализа, в которое заранее загрузили семантику функций стандартной библиотеки.
PD>Остальное skipped, потому что относится к ошибкам в коде, а не к основному вопросу про переполнение.
Ну так это у вас этот вопрос — основной. А в реальности, как видим, сделано больше ошибок, чем планировалось
PD>Это не учебная задача, а пример ad hoc, сделанный для иллюстрации вопроса.
Это и есть учебная задача.
PD>Я ничего против того, что он на это указал, не имею. Пусть напомнит, верно. Но меня-то иное интересовало — может ли оно быть при тех данных, которые меня интересуют. А на этот вопрос у него ответа нет.
Потому что он не знает, какие данные вас интересуют.
Вот вы только что сказали, что ничего, кроме этой программы, у вас нет. PD>Если эти длина и ширина — размеры дисплея обычной машины в пикселях, то совершенно спокойно можно остаться с unit — пока что дисплеев с размерами, при которых переполнение возможно, в природе нет.
И вдруг появляется контекст — оказывается, речь о длине и ширине экрана в пикселях. Если бы мы дали ИИ это как вводную, его ответ был бы другим. А так вы соврали исполнителю работ, скрыв важные детали.
Это примерно то же самое, что врать адвокату или врачу. Искусственный интеллект точно так же, как и естественный, дополнит вашу постановку недостающими деталями, подобрав самую правдоподобную для него картинку.
Если он угадал — то всё хорошо. Если нет — вы обманули сами себя.
PD>Если это что-то другое — надо знать, какие могут быть значения у этих величин. Вот я приводил 100000 как пример. Допустим, я не знаю, каков maxint. Делаю несколько простейших тестов — работает. Делаю тест 100000 на 100000 — проваливается. Все. Действительно, надо переходить к ulong.
Это очень наивный подход. Тестируем функцию is_prime(uint n) { return n&1==1;}: для 1 — корректно, для 3 — корректно, для 4 — корректно, для 5 — корректно, для 6 — корректно, для 7 — корректно, для 10 — корректно, для 11 — корректно, для 13 — корректно.
Действительно, можно переходить к реализации следующей функции. Ведь branch coverage у нас 100%, и все тесты зелёные.
PD>Ну а если это размеры дисплея — ну сделаю тест 10000 на 10000, все будет в порядке, можно так и оставить.
Если бы вы коммитили такой код в любом моём проекте, то он не прошёл бы review.
Потому что нет никакой гарантии, что пользователь не соберётся его использовать за пределами неявно подразумеваемых вами ограничений.
Завтра кто-то захочет использовать вашу библиотеку для рисования на виртуальном экране размером в 100000*200000 пикселов, и код начнёт делать фигню.
Если вы заложились на такое ограничение, будьте любезны
а) явно это задокументировать
б) выразить в коде.
А после этого мы посмотрим, нужно ли писать тесты и какие именно тесты.
PD>Так что тест мне ошибку найти сможет, а этот анализ лишь говорит, что она в принципе возможна. Это и без него ясно.
Ещё раз:
1. Тест может и не найти ошибку. От того, что ваши тесты зелены, уверенности в корректности кода не прибавляется.
2. Статический анализ ошибку совершенно точно найдёт, но для него нужны формальные критерии. То есть надо сесть и написать спецификацию для вашего кода на формальном языке. И вот после этого верифицирующий компилятор вам сможет (иногда) сказать "ошибок точно нет".
3. ИИ, как видим, не ограничен ни наличием тестов, ни наличием формальных спецификаций. Если бы вы снабдили ваш код хотя бы комментарием на естественном языке об ожидаемом диапазоне параметров, то ИИ смог бы точно сказать, есть ли в коде ошибка или нет.
PD>unsigned int population;
PD>Это корректно или нет ?
Это примерно такой же вопрос, как и "как правильно писать — Ирак или Иран". Не бывает никакой правильности
PD>Если это население страны, то я нелестно выскажусь в адрес того, кто мне скажет, что может не хватить. Нет таких стран с населением 4 млрд. человек и скорее всего не будет. А если когда-то и будет, то моей программы уже точно не будет
Да-да. Именно так и думали все авторы программ, у которых под номер года отводили 2 цифры.
PD>Если это население Земли, то не годится. Не хватит. Сейчас. А были бы компьютеры в 15 веке, сказали бы, что вполне хватит. И несколько веков бы вполне хватило.
PD>Что мне тут статический анализ скажет ? Про потенциальную возможность переполнения при суммировании любых чисел ?
Статический анализ скажет ровно то, чего мы от него потребуем.
Вот простой пример:
есть распределённая стейт машина, состоящая из N узлов. Каждый узел может находиться в одном из 4*K состояний, которые устроены как 1_A, 1_B, 1_C, 1_D, 2_A, 2_B.... K_A, K_B, K_C, K_D.
Все узлы стартуют в состоянии 1_A. При каждом изменении состояния узел рассылает всем остальным узлам сообщение "я перешёл в состояние Х".
У нас есть следующий алгоритм:
1. Если узел "видит", что все узлы (включая его) находятся в состоянях X_A или X_B, то он должен перейти в состояние X_B.
2. Если узел "видит", что все узлы (включая его) находятся в состоянях X_B или X_C, то он должен перейти в состояние X_C.
3. Если узел "видит", что все узлы (включая его) находятся в состоянях X_C или X_D, то он должен перейти в состояние X_D.
4. Если узел находится в состоянии X_D, то может перейти в состояние Y_A для любого Y.
5. Если узел находится в состоянии X_A или X_D, и видит любой другой узел в состоянии Y_A, где Y < X, он обязан перейти в состояние Y_A.
Обмен сообщениями делается по попарным однонаправленным FIFO-каналам с потерями. То есть любое сообщение может не дойти, может быть задержано, но не может прийти раньше, чем сообщение, отправленное до него.
Требований к алгоритму — два:
1. Ни один узел не должен увидеть "одновременно" пару узлов в состояниях X_B и X_D
2. Ни один узел не должен увидеть "одновременно" пару узлов в состояниях X_D и Y_D для X!=Y.
Удовлетворяет ли алгоритм этим требованиям? Если нет, то каким тестом мы это "поймаем"? Если да, то как мы это докажем?
PD>Спасибо. Без него я бы не догадался
Ну вы — может быть, и догадались бы. А среднестатистическому большинству С++ программистов вот такой код кажется вполне нормальным:
int avg(int a, int b) {return (a+b)>>2;}
PD>А тест скажет. Найдем население Земли как сумму населений стран — и все. Приехали. Сейчас. А в 15 веке все было бы в порядке.
Это просто означает, что вы пытаетесь описать спецификацию вашей программы в терминах тестов. Типа "программа должна корректно работать с population в пределах 2 миллиардов" вы записываете в виде теста, который запихивает в неё 2 миллиарда и проверяете результат.
Это — один из самых неудачных способов написания спецификаций, если что
Потому, что покрывающий набор тестов очень быстро становится непрактично большим.
То есть вы проверили работу программы в нескольких случайно выбранных точках, и на этом почему-то успокоились.
Один "специалист" написал функцию вычисления площади вот так: short area(short w, short h) { return w * h }.
Второй "специалист" почитал спецификацию:
Максимальное значение ширины экрана — 10000
Максимальное значение высоты экрана — 10000
Вроде и по спеке всё, и тесты зелёные. Тут, конечно, можно возразить, что такие тесты напишет только полный идиот, а реальный разработчик конечно же и тест напишет на (10000, 10000), и код не будет в шортах писать.
Но этот аргумент работает только для самых примитивных случаев. Чуть шире задача — всё, приплызд. Может оказаться наоборот — что если все параметры на максимуме, то работает, а если один не в максимуме — то не работает.
Это сильно затрудняет написание тестов баз заглядывания в код. А с заглядыванием — вы тестируете не соответствие требованиям, а соответствие кода самому себе.
Для учебных проектов и развлечения — нормальный подход.
И для примитивных задач с прямолинейной логикой тоже норм.
А вот для сложных проектов, в которых цена ошибки велика — нет, неприемлемый.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Наверное, пора закачивать. Поэтому ограничусь лишь небольшим.
PD>>Я ничего против того, что он на это указал, не имею. Пусть напомнит, верно. Но меня-то иное интересовало — может ли оно быть при тех данных, которые меня интересуют. А на этот вопрос у него ответа нет. S>Потому что он не знает, какие данные вас интересуют. S>Вот вы только что сказали, что ничего, кроме этой программы, у вас нет. PD>>Если эти длина и ширина — размеры дисплея обычной машины в пикселях, то совершенно спокойно можно остаться с unit — пока что дисплеев с размерами, при которых переполнение возможно, в природе нет. S>И вдруг появляется контекст — оказывается, речь о длине и ширине экрана в пикселях. Если бы мы дали ИИ это как вводную, его ответ был бы другим. А так вы соврали исполнителю работ, скрыв важные детали.
Я могу согласиться, что именно для этого случая можно приделать к программе какой-то файл с подробным описанием всех переменных. Правда, сдается мне, что если по каждой операции умножения мы будем писать такие объяснения в каком угодно виде, то программу мы напишем ко второму пришествию.
Но это ладно. Ну а если все же взять более серьезный код.
Например, вот такое. Сразу скажу — я не автор и не проверял его работу. Просто взял вот тут в качестве примера
#include <stdio.h>
#include <iostream>
#include <fstream>
#include <math.h>
#include <omp.h>
#include <cstdlib>
const double eps = 0.0001;
using namespace std;
void Mul(int N, double **A,double *x,double *y)
{
for (int i = 0; i<N; i++)
{
y[i] = 0;
for (int j = 0; j<N; j++)
y[i] = y[i] + (A[i][j] * x[j]);
}
}
void PrintMatrix(int N, double **A )
{
for (int i = 0; i < N; i++)
{
for (int j = 0; j < N; j++)
cout << A[i][j]<<" ";
cout << endl;
}
}
void PrintVec(int N, double *A)
{
for (int i = 0; i < N; i++)
{
cout << A[i] << " ";
}
cout << endl;
}
void Jacobi(int N, double**A, double* F, double* X)
{
double norm,* TempX = new double[N];
for(int k=0;k<N;k++)
TempX[k]= X[k];
int cnt = 0;
do {
for (int i = 0; i < N; i++)
{
TempX[i] = F[i];
for (int g = 0; g < N; g++)
if (i != g)
TempX[i] -= A[i][g] * X[g];
TempX[i] /= A[i][i];
}
norm = fabs(X[0] - TempX[0]);
for (int h = 0; h < N; h++)
{
if (fabs(X[h] - TempX[h]) > norm)
norm = fabs(X[h] - TempX[h]);
X[h] = TempX[h];
}
cnt++;
}
while (norm >= eps);
cout<<"Кол-во итераций = "<<cnt;
delete[] TempX;
}
void Load(int &N, double **&A, double *&F)
{
setlocale(0,"");
ifstream fin;
fin.open("primer");
fin >> N;
F = new double [N];
A = new double *[N];
for (int i = 0; i < N; i++)
A[i] = new double[N];
for (int i = 0; i < N; i++)
{
for (int j = 0; j < N; j++)
fin >> A[i][j];
fin >> F[i];
}
fin.close();
}
int main()
{
double **Matrix, *b,*y,*x;
int n;
Load(n, Matrix, b);
cout << "Матрица:\n";
PrintMatrix(n, Matrix);
cout << "\n"<<"b: ";
PrintVec(n, b);
x = new double[n];
for(int i=0;i<n;i++)
x[i]=1.0;
y = new double[n];
Jacobi(n, Matrix, b, x);
cout <<"\n"<< "Результат | x: ";
PrintVec(n, x);
cout << "A*x=b | b: ";
Mul(n, Matrix, x, y);
PrintVec(n, y);
delete x;
delete y;
system("pause");
return 1;
}
Допустим, мне надо использовать этот код. Верен ли он алгоритмически (то есть делает ли то, что ему положено) — не обсуждаем. Меня интересуют лишь два вопроса
Может ли произойти переполнение с плавающей точкой в этом коде ?
Не возникнет ли тут деление на 0 ?
Почему взял этот пример ? Дело в том, что в мои молодые годы я как раз реализовал (сам не писал, перевел на другую машину) код, внутри которого был алгоритм Якоби. И на исходной машине все вполне работало, а на той, на которую я переводил иногда нет.
Причиной было различие размеров переменных. На IBM-360 double занимает 8 байт, а на БЭСМ-6 — 6 байт.
Начал разбираться — оказалось, что в коде для IBM-360 в этом алгоритме в самом начале выполняется установка т.н. стандартного корректирующего действия. Суть ее в том, что если происходит переполнение, то в ячейку ответа засылается максимально допустимое число. Алгоритм вполне такое допускал, так как он итерационный, и на следующей итерации поправится сам. В общем, своего рода обработка исключения. Написано все было на Фортране, обработки исключений в нынешнем смысле слова в нем не было.
Для БЭСМ-6 возможности установить стандартное корректирующее действие не было. Вот тут-то я и покрутился, пытаясь понять, где это переполнение может возникнуть.
Если хотите знать, что в исходной матрице — пожалуйста. Сравнительно небольшие числа на главной диагонали и в ее окрестности. Остальные элементы нулевые. В векторе тоже небольшие числа.
Могу даже сказать, что это за числа. Опуская детали, это энергия взаимодействия атомов, прямо не связанных в молекуле органического соединения. Там взаимодействие убывает по алгоритму R^-6 и R^-12 (потенциал Леннард — Джонса)
U = Eo*[ (R0/R)^12 — (Ro/R)^6]
Поэтому если атомы находятся далеко друг от друга, то в матрице просто 0 ставится.
S>Это примерно то же самое, что врать адвокату или врачу. Искусственный интеллект точно так же, как и естественный, дополнит вашу постановку недостающими деталями, подобрав самую правдоподобную для него картинку.
Ну вот я Вам и не соврал. Все изложил, что знаю. Жду ответа
А пока что могу сказать, что было у меня. Просто убрал это стандартное корректирующее действие и стал ждать, что из этого выйдет. Примеры запускал (считайте, что тесты) Когда переполнение наконец произошло, нашел его место и поставил проверку. Вот и все. Место такое нашлось одно за все время, что я с программой работал. Нашлось бы еще одно — поставил бы проверку и там. И это при (будем так условно считать) полном непонимании этого алгоритма — я и впрямь в деталях той реализации разбираться не стал.
PD>>Ну а если это размеры дисплея — ну сделаю тест 10000 на 10000, все будет в порядке, можно так и оставить. S>Если бы вы коммитили такой код в любом моём проекте, то он не прошёл бы review.
Нет, не придется мне коммитить код в Ваш проект. Да и в любой другой тоже. Моя программистская карьера завершена. Но в ней я такое (да и не такое!) не раз коммитил, и как-то все потом благополучно работало и никто не жаловался.
S>Потому что нет никакой гарантии, что пользователь не соберётся его использовать за пределами неявно подразумеваемых вами ограничений. S>Завтра кто-то захочет использовать вашу библиотеку для рисования на виртуальном экране размером в 100000*200000 пикселов, и код начнёт делать фигню. S>Если вы заложились на такое ограничение, будьте любезны S>а) явно это задокументировать S>б) выразить в коде. S>А после этого мы посмотрим, нужно ли писать тесты и какие именно тесты.
Ну что же, выскажусь и по этому замечанию.
В теории Вы правы. Если мой код действительно в библиотеке, да еще рассчитанной на то, что ее будет использовать потом широкий круг пользователей, то такое недопустимо.
Но где я сказал, что этот код для библиотеки ? Я такого нигде не говорил.
Где я сказал, что этот код может быть, когда-то будет использоваться кем-то для иной цели ? Я такого тоже не говорил.
Или в моем примере с Якоби — меня абсолютно не интересует, что будет, если какой-то другой пользователь начнет использовать этот код для каких-то матриц, в которых иные данные (ну скажем, много больших элементов далеко от главной диагонали). Это его проблемы. В той задаче, что я сейчас решаю, данные именно такие и другими быть не могут — объяснение выше.
И , наконец, мне надо, чтобы программа как можно скорее заработала, а не провести теоретическое изучение поведения этого алгоритма при произвольных данных.
Не слишком ли мы заботится о том, что код, вовсе не предназначенный для массового использования , не будет совершенно корректно работать для случаев, которые мне при его написании для данной задачи совершенно неинтересны ?
S>1. Тест может и не найти ошибку. От того, что ваши тесты зелены, уверенности в корректности кода не прибавляется. S>2. Статический анализ ошибку совершенно точно найдёт, но для него нужны формальные критерии. То есть надо сесть и написать спецификацию для вашего кода на формальном языке. И вот после этого верифицирующий компилятор вам сможет (иногда) сказать "ошибок точно нет".
Я Вам все сказал , что мог, по этому Якоби примеру. Хотите еще что-то — скажите, что нужно, честно отвечу, если смогу.
S>3. ИИ, как видим, не ограничен ни наличием тестов, ни наличием формальных спецификаций. Если бы вы снабдили ваш код хотя бы комментарием на естественном языке об ожидаемом диапазоне параметров, то ИИ смог бы точно сказать, есть ли в коде ошибка или нет.
Я Вам дал на естественном языке информацию об ожидаемом диапазоне данных во входной матрице. Другой информации у меня нет.
PD>>unsigned int population;
PD>>Это корректно или нет ? S>Это примерно такой же вопрос, как и "как правильно писать — Ирак или Иран". Не бывает никакой правильности
PD>>Если это население страны, то я нелестно выскажусь в адрес того, кто мне скажет, что может не хватить. Нет таких стран с населением 4 млрд. человек и скорее всего не будет. А если когда-то и будет, то моей программы уже точно не будет S>Да-да. Именно так и думали все авторы программ, у которых под номер года отводили 2 цифры.
А вот тут как раз все немного иначе.
Те, кто отводил под это 2 цифры в 1960 или 1970 году — вполне были правы. Не дожили их машины и и их программы до 2000 года. И не могли дожить. А если какой-то их код и дожил года до так 1980, то его потом все равно переносили, там и должны были поправить. Там скорее всего многое пришлось бы править — ну хотя бы из-за разных размеров данных на разных машинах.
(В скобках. В Фортране до введения типа CHARACTER тексты хранили в INTEGER переменных. На IBM-360 — 4 символа в одной. На БЭСМ-6 — 6 символов в одной. Перенос программы с IBM на БЭСМ в этом плане тоже еще то было удовольствие. А там была символьная обработка — прежде чем матрицу для Якоби сделать, надо было формулу распарсить, а она давалась текстовой строкой)
Те, кто писал их в 1980 году — уже должен был подумать.
Те, кто писал такое в 1990 году — идиот.
Идиотов оказалось не так уж много, поэтому вокруг проблемы 2000 шуму было много, а реально ничего не произошло. Ну может, в ПО для конторы "Рога и копыта" копыта были помечены как полученные от коров 1901 года.
А то ведь можно и до абсурда довести. Как Ваша программа будет работать после 9999 года ? Не пора ли уже сейчас об этом подумать ?
То же и с населением. Ну не будет программа корректно работать, когда появится город с населением в 4 миллиарда человек. Вот только когда он появится (если он вообще когда-нибудь появится) — этой программы уже сотни лет как не будет.
В общем, как сказано в библии
Итак, не заботьтесь о завтрашнем дне, ибо завтрашний сам будет заботиться о своём: довольно для каждого дня своей заботы.
Остальное <skipped>, потому что повторяет то же самое.
PD>Например, вот такое. Сразу скажу — я не автор и не проверял его работу. Просто взял вот тут в качестве примера PD>Допустим, мне надо использовать этот код. Верен ли он алгоритмически (то есть делает ли то, что ему положено) — не обсуждаем. Меня интересуют лишь два вопроса
PD>Может ли произойти переполнение с плавающей точкой в этом коде ? PD>Не возникнет ли тут деление на 0 ? PD>Ну вот я Вам и не соврал. Все изложил, что знаю. Жду ответа
Да, оба риска в этом коде реальны, но зависят от входных данных (вашей матрицы). Разберём по пунктам.
1) Может ли быть переполнение double?
В вашем коде потенциально “опасные” места такие:
(а) Суммирование в Mul
y[i] = y[i] + (A[i][j] * x[j]);
Переполнение возможно, если либо A[i][j] очень большое, либо x[j] становится очень большим, либо сумма большого количества членов разгоняет y[i].
Но с вашей структурой матрицы (почти все элементы 0, небольшие числа около диагонали) само по себе Mul обычно не переполняет. Однако важно:
Метод Якоби может “разогнать” X, если матрица плохо обусловлена, не диагонально преобладающая, или есть маленькие диагональные элементы.
Тогда x[j] может стать огромным, и уже A[i][j] * x[j] / суммы могут уйти в inf.
Если A[i][i] маленькое по модулю, то деление сделает TempX[i] очень большим, и дальше это может быстро привести к inf.
А при Леннард–Джонсе?
Если вы уже записываете в матрицу готовые “небольшие” числа и для дальних пар ставите 0 — тогда переполнение именно из-за R^-12 в этом коде не случится, потому что здесь R не вычисляется.
Но если в другом месте вы считаете
U = E0*[(R0/R)12-(R0/R)6]
то переполнение возможно при очень маленьком R (почти совпадающие координаты, ошибка данных): (R0/R)12 может стать гигантским. Это уже не про Якоби, а про подготовку данных.
Итог по переполнению:
В этом коде переполнение double возможно если:
— Якоби расходится (что бывает часто, если нет диагонального преобладания/хороших свойств матрицы),
— или на диагонали очень маленькие числа → X улетает,
— или в матрице/векторе всё-таки встречаются большие значения.
2) Будет ли деление на 0?
Да, может. Единственное деление тут:
TempX[i] /= A[i][i];
Если хоть один диагональный элемент A[i][i] == 0, будет деление на ноль → получите inf или nan (в зависимости от платформы/режима FPU), а итерации дальше почти гарантированно “сломаются”.
Ещё важнее: даже если A[i][i] не ровно 0, но очень мал (например, 1e-300), то это практически то же самое по эффекту: TempX[i] станет огромным, и дальше возможны inf/NaN.
Что стоит сделать минимально (практично)
Перед итерациями (или внутри) проверять диагональ:
if (A[i][i] == 0.0) { /* ошибка */ }
лучше так:
if (fabs(A[i][i]) < 1e-15) { /* слишком близко к нулю */ }
Проверять появление nan/inf:
if (!isfinite(TempX[i])) { /* аварийно остановиться */ }
(Не по вашему вопросу, но критично) освобождение памяти у вас неправильное:
delete x; delete y;
для массивов нужно:
delete[] x;
delete[] y;
И для матрицы тоже нужно освобождение по строкам + массив указателей, иначе утечка.
PD>А пока что могу сказать, что было у меня. Просто убрал это стандартное корректирующее действие и стал ждать, что из этого выйдет. Примеры запускал (считайте, что тесты) Когда переполнение наконец произошло, нашел его место и поставил проверку. Вот и все. Место такое нашлось одно за все время, что я с программой работал. Нашлось бы еще одно — поставил бы проверку и там. И это при (будем так условно считать) полном непонимании этого алгоритма — я и впрямь в деталях той реализации разбираться не стал.
Как видно, запускать и ждать теперь необязательно
PD>Нет, не придется мне коммитить код в Ваш проект. Да и в любой другой тоже. Моя программистская карьера завершена. Но в ней я такое (да и не такое!) не раз коммитил, и как-то все потом благополучно работало и никто не жаловался.
Так же говорят тетеньки, которые пирожками на вокзале торгуют
PD>В теории Вы правы. Если мой код действительно в библиотеке, да еще рассчитанной на то, что ее будет использовать потом широкий круг пользователей, то такое недопустимо. PD>Но где я сказал, что этот код для библиотеки ? Я такого нигде не говорил. PD>Где я сказал, что этот код может быть, когда-то будет использоваться кем-то для иной цели ? Я такого тоже не говорил.
Это зависит не только от вас.
PD>Или в моем примере с Якоби — меня абсолютно не интересует, что будет, если какой-то другой пользователь начнет использовать этот код для каких-то матриц, в которых иные данные (ну скажем, много больших элементов далеко от главной диагонали). Это его проблемы. В той задаче, что я сейчас решаю, данные именно такие и другими быть не могут — объяснение выше.
Полностью с вами согласен. То, что вы описываете, называется "инженерная культура". Точнее — её отсутствие. Типа, давайте не будем клеить обои за шкафом. Если кто-то когда-то решит передвинуть шкаф — это будут его проблемы.
PD>И , наконец, мне надо, чтобы программа как можно скорее заработала, а не провести теоретическое изучение поведения этого алгоритма при произвольных данных.
Да, совершенно верно. Именно так пишут школьники: главное, чтобы программа как можно скорее заработала. Скомпилировалась — полдела сделано. Запустилась и не вылетела — всё, несём сдавать.
Если преподаватель не проверил, что она ещё и делает то, что нужно — это его проблема. После получения зачёта эта программа всё равно пойдёт в корзину.
Но поскольку мир разработки не исчерпывается одноразовыми студенческими программами, мы своих студентов стараемся учить, как делать правильно. Наш лозунг: "Делайте всё как следует. Стрёмно получится само".
PD>Не слишком ли мы заботится о том, что код, вовсе не предназначенный для массового использования , не будет совершенно корректно работать для случаев, которые мне при его написании для данной задачи совершенно неинтересны ?
Для начала стоит научиться писать код так, чтобы он хотя бы для интересных в данной задаче случаев работал корректно. Как видим, это не всегда тривиально.
PD>Я Вам дал на естественном языке информацию об ожидаемом диапазоне данных во входной матрице. Другой информации у меня нет.
Для традиционных формальных средств этого недостаточно. А для ИИ — вполне.
PD>Те, кто отводил под это 2 цифры в 1960 или 1970 году — вполне были правы. Не дожили их машины и и их программы до 2000 года. И не могли дожить.
Прекрасно дожили. То, что программы, разработанные в СССР, выбрасывали вместе с машинами — это не стандартная ситуация, а глобальная катастрофа.
В развитом мире код, написанный для IBM360, прекрасно работал в 2010 (и наверняка сейчас всё ещё работает).
PD>А если какой-то их код и дожил года до так 1980, то его потом все равно переносили, там и должны были поправить. Там скорее всего многое пришлось бы править — ну хотя бы из-за разных размеров данных на разных машинах.
Про вашу точку зрения ещё в 1981 году сняли анимационный художественный фильм. https://www.kinopoisk.ru/film/257212/
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Да, оба риска в этом коде реальны, но зависят от входных данных (вашей матрицы). Разберём по пунктам.
<skipped>
Ну что, неплохо. Кое-что лишнее, но в основном по сути.
А можно ему еще один вопрос задать ?
Уважаемый ИИ, Вы перечислили те места, где по анализу кода могут быть переполнения или деления на 0. Спасибо. Однако меня интересуют не столько те места, где потенциально они могут возникнуть, а те места, где они реально могут произойти при таких данных.
Поясняю
Дело в том, что когда я с кодом тогда работал (не этим, конечно, а тем, на Фортране) я потенциальные места переполнений определил и сам примерно таким же анализом. Но мне было ясно и другое. Стандартное корректирующее действие там явно было установлено для какого-то определенного места в коде. Именно в том месте занесение MAX_DOUBLE в ячейку ответа имело смысл. По сути, это просто часть алгоритма. Видимо, автор руководствовался какими-то соображениями, связанными с природой алгоритма, а реализовал их не проверкой условия, а "обработкой исключения". Увы, какими соображениями он руководствовался, я не знал.
Вот в этом месте и производилось стандартное корректирующее действие, и именно в это место надо было найти и поставить проверку, чтобы вручную произвести это действие, потому что "обработки исключения" на БЭСМ-6 не было. Если переполнение произойдет в другом месте, это будет означать просто ошибку в коде и делать такую засылку MAX_DOUBLE в ячейку ответа не имеет смысла. Там программа пусть лучше падает ,я хотя бы буду знать, что здесь что-то в алгоритме не в порядке, вместо того, чтобы там заслалось MAX_DOUBLE и дальше процесс шел с ним с непредсказуемыми последствиями.
S>Как видно, запускать и ждать теперь необязательно
Давайте для начала попросите ИИ ответить на мой дополнительный вопрос.
PD>>Нет, не придется мне коммитить код в Ваш проект. Да и в любой другой тоже. Моя программистская карьера завершена. Но в ней я такое (да и не такое!) не раз коммитил, и как-то все потом благополучно работало и никто не жаловался. S>Так же говорят тетеньки, которые пирожками на вокзале торгуют
Аргумент, прямо скажем, так себе, но вообще-то в годы моей юности на омском вокзале (я жил рядом, и почти каждый день через него проходил, чтобы выйти , как мы говорили "в город") продавали замечательные пирожки. Никто и не жаловался.
PD>>В теории Вы правы. Если мой код действительно в библиотеке, да еще рассчитанной на то, что ее будет использовать потом широкий круг пользователей, то такое недопустимо. PD>>Но где я сказал, что этот код для библиотеки ? Я такого нигде не говорил. PD>>Где я сказал, что этот код может быть, когда-то будет использоваться кем-то для иной цели ? Я такого тоже не говорил. S>Это зависит не только от вас.
Спорный вопрос. It depends, и прежде чем такое заявлять, стоило бы поинтересоваться, что за код, для чего предназначен. Ну, например, делал я код для своей диссертации в свое время, и вовсе не собирался его давать кому бы то ни было, и не давал. Так что не стоит столь категорично заявлять.
PD>>Или в моем примере с Якоби — меня абсолютно не интересует, что будет, если какой-то другой пользователь начнет использовать этот код для каких-то матриц, в которых иные данные (ну скажем, много больших элементов далеко от главной диагонали). Это его проблемы. В той задаче, что я сейчас решаю, данные именно такие и другими быть не могут — объяснение выше.
S>Полностью с вами согласен. То, что вы описываете, называется "инженерная культура". Точнее — её отсутствие. Типа, давайте не будем клеить обои за шкафом. Если кто-то когда-то решит передвинуть шкаф — это будут его проблемы.
Опять же it depends. В годы моего студенчества мы делали ремонт на кафедре и передвигали шкафы. Обоев за ними не было — обои в химлаборатории вообще не используют. Крашеные стены. А шкафы были, видимо, довоенные. Фундаментальные такие шкафы, мы их впятером с трудом передвинули. И за ними стены были покрашены иной краской, видимо, тоже довоенной. Не знаю, чем руководствовались те, кто их ставил, но едва ли вопросом о том, как за ними потом стены перекрашивать будут. И был они совершенно правы — шкафы до нашего передвижения полвека простояли. Ну а когда пришлось все же передвигать и красить (== вносить изменения в ПО) — это было уже проблемой другого поколения, нашего то есть.
PD>>И , наконец, мне надо, чтобы программа как можно скорее заработала, а не провести теоретическое изучение поведения этого алгоритма при произвольных данных. S>Да, совершенно верно. Именно так пишут школьники: главное, чтобы программа как можно скорее заработала. Скомпилировалась — полдела сделано. Запустилась и не вылетела — всё, несём сдавать.
Да. Что-то Вы сегодня какие-то примитивные аргументы выдвигаете. Если мне нужно, чтобы программа заработала, потому что сроки поджимают — ну все, либо делай по рецептам и в сроки не уложись, либо это как школьники делают. И почему только "запустилась и не вылетела" ? Может, добавим все же еще "выдавала правильные результаты хотя бы в большинстве случаев" ?
Ладно. Расскажу про еще один свой случай. В годы работы в пединституте подрабатывал я на хоздоговоре у физиков. Фортран, СМ-1420, Интернета еще нет , тематику не помню. И вот возникла ситуация. Через 5 часов коллега должен отвезти даже не программу, а просто результаты расчетов заказчику. У меня эти 5 часов есть на написание этой программы. Я совершенно уверен, что за 3 часа ее напишу и отлажу, программа совсем несложная, какие-то вычисления по формулам.
Делаю быстро и она падает. При вводе данных из файла падает. Ничего не понимаю. Банальный тут код. Нечему тут падать. А падает.
Разбираюсь и оказывается вот что. Входной файл текстовый. Строки заканчиваются CR/LF. И тот код, который их читает, падает, если CR оказывается последним байтом сектора, а LF — первым байтом следующего сектора. Вероятность такого, как Вы понимаете, невелика. Однако во входных данных такое есть, и все падает. А осталось 2 часа.
Ну конечно, я должен был действовать по правилам. Выяснить, почему падает. Написать код с учетом этой ситуации, предусмотреть ее и в случае возникновения обработать. Вот только осталось 2 часа, и за это время я никак не успею.
Что я сделал. Взял исходный файл, напустил на него текстовый редактор и добавил в разных местах по пробелу, благо они ни на что не влияли. Запустил и все прошло.
А в чем была причина падения — я так и не узнал. Больше эту программу и не требовалось запускать.
Так что it depends.
Меня, кстати сказать, до сих пор один феномен удивляет.
Вот есть некоторая область, в ней есть определенные правила. Не те, которые нарушать вообще невозможно, а общепринятые тут правила, которые нарушать в принципе можно, но это дурной тон, никто не поймет, так что никто и не нарушает. Назовем их "правила хорошего тона"
И вот есть близкая, но все же соседняя область. И специалист из первой области в ней никогда не работал, хотя, конечно, что там делается, более или менее понимает.
И вот этот специалист с апломбом начинает утверждать, что правила хорошего тона и тут должны быть тоже такими, а отступление от них есть сущая ересь и должно быть предано анафеме. Начинаешь ему мягко объяснять. что правла хорошего тона тут несколько иные — не понимает. Не могут они быть иными. Только те, которые я знаю, истинны, а все остальное да идет в ад.
Когда такое вчерашние студенты заявляют — еще ладно. Кругозор их достаточно узкий пока что, кроме своей области мало что знают. Но вот когда такое заявляют люди в возрасте 40+ — это уже странно. Могли бы понимать, что не во всех монастырях один и тот же устав при том, что конфессия одна и та же.
S>Но поскольку мир разработки не исчерпывается одноразовыми студенческими программами, мы своих студентов стараемся учить, как делать правильно. Наш лозунг: "Делайте всё как следует. Стрёмно получится само".
Да ради бога. В общем, я согласен, что надо учить делать правильно. Вот только потом в реальной работе делать иногда приходится по-разному. И порой отступать от всяких правил, если выигрыш от этого отступления компенсирует возможные проблемы, связанные с этим отступлением. It depends опять же. Разные бывают задачи.
Кстати, одноразовыми бывают не только студенческие программы. Я 3 года работал в проекте, который был одноразовым. Рассказывать подробно о нем не буду, просто скажу, что он не мог быть портирован ни во что другое — из-за отсутствия предметной области. Грубо говоря, иного такого объекта в мире нет и быть не может.
PD>>Те, кто отводил под это 2 цифры в 1960 или 1970 году — вполне были правы. Не дожили их машины и и их программы до 2000 года. И не могли дожить. S>Прекрасно дожили. То, что программы, разработанные в СССР, выбрасывали вместе с машинами — это не стандартная ситуация, а глобальная катастрофа. S>В развитом мире код, написанный для IBM360, прекрасно работал в 2010 (и наверняка сейчас всё ещё работает).
Вполне возможно. Вот только если там было что-то, связанное с годом, и использовались 2 цифры, то просто внесли изменения в году так примерно 1995. А тот, кто в 1960 году поставил 2 цифры — был вполне прав.
Или Вы считаете, что программы 1970 года без изменений работали 40 лет ? Вот как их в 1970 году откомпилировали тем компилятором, так они до сих пор и используются ? Как-то сомнительно, прямо скажем.
PD>>А если какой-то их код и дожил года до так 1980, то его потом все равно переносили, там и должны были поправить. Там скорее всего многое пришлось бы править — ну хотя бы из-за разных размеров данных на разных машинах. S>Про вашу точку зрения ещё в 1981 году сняли анимационный художественный фильм. S>https://www.kinopoisk.ru/film/257212/