Программный код vs. Математическая нотация

[Munin]

(Оффтоп)

Xaositect в сообщении #774335 писал(а):

По стандарту она может выполниться только в случае возникновения undefined behaviour.

Ещё можно функцию abs(int) подменить на свою :-)

[Aritaborian]

(Оффтоп)

#define true false

[EtCetera]

Xaositect в сообщении #774335 писал(а):

По стандарту она может выполниться только в случае возникновения undefined behaviour.

Вообще-то, очевидно, что abs(INT_MIN) > INT_MAX, поэтому abs(INT_MIN) == INT_MIN и, соответственно, abs(INT_MIN) < 0. А все из-за того, что целых чисел в компьютерном представлении $\text{---}$ четное число, а ноль $\text{---}$ только один. Поэтому положительных и отрицательных чисел разное количество, отрицательных на 1 больше. В компьютерной вещественной арифметике таких казусов не возникает (зато там возникают другие, еще более удивительные казусы ).

[Xaositect]

EtCetera в сообщении #774447 писал(а):

Вообще-то очевидно, что abs(INT_MIN) > INT_MAX, соответственно, abs(INT_MIN) == INT_MIN и, поэтому abs(INT_MIN) < 0. А все из-за того, что всего целых чисел в компьютерном представлении четное число, а ноль $\text{---}$ только один.

Я знаю. И так делают все известные мне компиляторы/библиотеки. Но тем не менее стандарт C99, пункт 7.20.6.1.2 говорит, что "If the result cannot be represented, the behavior is undefined." с примечанием "The absolute value of the most negative number cannot be represented in two’s complement."

[EtCetera]

Xaositect в сообщении #774448 писал(а):

И так делают все известные мне компиляторы/библиотеки. Но тем не менее стандарт C99, пункт 7.20.6.1.2 говорит, что "If the result cannot be represented, the behavior is undefined." с примечанием "The absolute value of the most negative number cannot be represented in two’s complement."

Угу. Это хороший пример того, как де-юре undefined оказывается де-факто вполне себе defined, причем весьма неприятным образом defined.

[Munin]

А undefined behaviour - это хорошее грамотное описание того, что происходит. И позволяет разработчикам библиотеки вести себя более свободно, чем если было прописано это defined, но нелепое behaviour.

[bin]

Neos в сообщении #774291 писал(а):

"Дебагер" Вас не спасет . Это средство поиска только программных ошибок.

Позвольте не согласиться! Не только "средство поиска ошибок". Изучение работы алгоритма в отладчике на конкретном частном примере очень способствует пониманию этого алгоритма. Вирт в "А+СД=П" приводит примеры работы разных сортировок (фактически "снимок" отладчика), похожее можем видеть в кн. Р.Седжвик, Фундаментальные алгоритмы на С. Сошлюсь и на свой опыт: в начале 1990х принимал участие в развитии IDE Dr Pascal (упомянута в ст. Pascal en-Wiki), центром там был аниматор (отладчик только пошагово, а тут с задержкой между шагами, кнопку каждый раз жать не надо). Эта система успешно использовалась для вводного курса по программированию в универах многих стран мира (США, Австралия, Индия и т.д.). Другое дело, что не всякий debug log достоин публикации...

-- Вт окт 15, 2013 05:16:14 --

mustitz в сообщении #774321 писал(а):

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

Позвольте уточнить: преобразования (м.б. неэквивалентные ) в программировании - стандартная задача. Пример, классический метод сортировки бинарным деревом:

procedure add (дерево; s : string);
if  дерево=nil then новый_узел 
else if узел.dat>s then
  add (левое_поддерево,s)
else if узел.dat<s then
  add (правое_поддерево,s)
else
  дубляж

Каждый без труда перепишет этот псевдокод на своем любимом языке. И каждый преобразует его для сортировки целых чисел, а не строк (string). Подобные задачи преобразования кода возникают очень часто.

[mustitz]

bin в сообщении #775321 писал(а):

mustitz в сообщении #774321 писал(а):

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

Позвольте уточнить: преобразования (м.б. неэквивалентные ) в программировании - стандартная задача. Пример, классический метод сортировки бинарным деревом:

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

[bin]

mustitz
Про ООП не говорил: не метод, а простая процедура. В старой версии умела сортировать строки и не умела целые числа, в новой умеет числа, но не умеет строки Во-вторых, почему не интересны? Хочу знать как автор делает сортировку. Почему выбран такой алгоритм, а не другой? И что с дубляжем (возможны разные решения)?

расширение функционала= преобразование

[Alexu007]

Сколько времени у вас займёт прочитать вот эту функцию и понять, что она делает? А потом я выложу математическую нотацию и сравним сложность понимания.

int unknown(int x, int e, int n)
{
int r = 1;

 while(e > 0)
  {
  if((e % 2 ) == 1) {r = (r * x) % n;}
  e = e / 2;
  x = (x * x) % n;
  }

return r;
}

[mustitz]

bin в сообщении #775326 писал(а):

mustitz
Про ООП не говорил: не метод, а простая процедура. В старой версии умела сортировать строки и не умела целые числа, в новой умеет числа, но не умеет строки Во-вторых, почему не интересны? Хочу знать как автор делает сортировку. Почему выбран такой алгоритм, а не другой? И что с дубляжем (возможны разные решения)?

расширение функционала= преобразование

А в математике нет расширения функционала. В математике эквивалентные преобразования. Например,

$y' - \frac{y}{x} = 0$,
$y' =\frac{y}{x}$,
$\frac{dy}{dx} = \frac{y}{x}$,
$\frac{dy}{y} = \frac{dx}{x}$,
$\int \frac{dy}{y} = \int \frac{dx}{x}$,
$ln |y| = ln |x| + C $,
$y = Cx$

При желании мы всегда можем проделать обратный путь от $y = Cx$ к дифференциальному уравнению. Ну а в программировании чаще всего все преобразования исходника имеют гранулярность по коммитам. Ну и для коммита часто выдвигается дополнительное условие, чтобы он не рушил билд. Как вносились изменения в пределах одного коммита можно только догадываться. Системы, которые отслеживают и сохраняют всю историю редактируемого файла не получили большой популятрности, хотя реализуются тривиально. Значит, не нужно?

[bin]

mustitz в сообщении #775374 писал(а):

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

Все зависит от применяемой технологии разработки и сопровождения программного продукта. Очень часто даже к пользовательской документации прикладывается история изменений. В документации разработчиков такая история обычно представлена гораздо полнее. Как осуществлять такое документирование - вручную или автоматически - принципиальной роли не играет. Выходя за рамки чистого программирования, можно привести пример широко известной системы, хранящей всю историю редактируемых файлов. Это Википедия Но я не понял, какое отношение история изменений имеет к обсуждаемой теме? Приведенный пример цепочки тождественных преобразований (решение диффура) естественным и очевидным образом записывается с помощью мат. нотации. Но выше я как раз и сказал, что

bin в сообщении #774215 писал(а):

одно другое дополняет, но не заменяет

О чем спор?