Здравствуйте, Sinclair, Вы писали:
MH>>на здравый смысл стоит полагаться. если вывод из цепочки рассуждений противоречит здравому смыслу, значит в рассуждениях ошибка.
S>Всё как раз наоборот. Когда мы видим "неожиданный" вывод, то всегда дополнительно проверяем цепочку рассуждений.
S>А вот когда мы видим что-то "очевидное", то есть искушение пропустить этам проверки. Поэтому в IT "очевидные" утверждения гораздо чаще оказываются неверными, чем "неочевидные".
не соглашусь. единственно где здравый смысл подводит, это квантовая механика
в IT не припомню случаев где бы здравый смысл подводил.
MH>>а в sql 1999 есть
S>Где вы там это нашли?
цитата из статьи
Другим новым типом является тип BOOLEAN, который дает возможность в SQL непосредственно записывать истинностные значения true, false и unknown. Сложные комбинации предикатов можно также выразить способами, которые в чем-то более дружественны к пользователям
MH>>дело как раз в примере. если нет понятного конкретного примера когда одно и тоже не равно само себе, то значит нет примера нарушения закона тождества.
MH>>Вы апелируете к принятым формальным правилам вычислений, при которых точность вычислений загрубляется. Я же говорю о самой сути, когда одна и та же неизвестность равна сама себе. х=х.
S>В алгебре никакой сути нет. Нас интересует не суть, а формальные правила вычислений.
меня интересовали причины по которым формальные правила вычислений приводили к нарушению закона тождества.
для себя ответ я нашел, в том числе и благодаря вашим аргументам, спасибо за дискуссию
MH>>примерно тоже когда в случае сложно выражения мы не смогли бы его упростить и также дали бы результат null.
S>Ещё раз: "формальные правила вычислений" дают согласованные друг с другом результаты.
S>Я всё ещё не вижу никакой альтернативы этим правилам, которые бы по-прежнему давали согласованные друг с другом результаты, но при этом (x=x) давал бы true при x is null.
очень вероятно что это так, чтоб синтезировать эти альтернативные правила надо нехило напрячься и потратить время, что лично мне делать пока нехочется, хотя и интересно.
S>>>А у вас получается, что (x+y) неравен (x+z), несмотря на то, что оба дают null.
MH>>нет, результат их сравнения null. я предлагал ограничиться только кэйсом когда сравнивается сама с собой одна и таже неопределённость.
MH>>когда с неопределённостью производится любой другое действие, то возникает уже новая и её можно трактовать также как сейчас в sql и есть.
S>Ок, то есть (x+1) всё же не равен (x+1)? Это же подходит под "любое другое действие"?
да. если под "не равен" вы имеете ввиду "будет не истина", то да будет не истина, будет нул.
MH>>ещё раз: не между произвольными нул значениями, а для одной и той же неопределённости. при любом действии с какой-то исходной неопределённостью (с х), возникает новая, отличающаяся от исходной.
S>Для этого вам придётся ввести формальное понятие "одна и та же неопределённость".
да, и что?
S>Если вы собираетесь ограничиться тривиальностями типа (x=x), то непонятна мотивация — таких случаев очень мало
соглашусь что их не много.
S>усложнение оптимизатора мало что даст с точки зрения эффективности.
такая оптимизация вообще исключит необходимость доступа к полю х, эффект может быть заметен. это одна из мотиваций.
S>Зато усложнит жизнь программистам — теперь эквивалентные "на первый взгляд" преобразования становятся опасными.
S>До этого у нас сложности были только с плавающей точкой: там никого не удивишь тем, что (x+a+b)==y, но (x+a)!=(y-b).
да, есть такое.
S>Теперь начинаются неожиданности на ровном месте: незначительное изменение кода ломает семантику. Если раньше у нас lowercase(x)=lowercase(x) давало такой же результат, что и x=x, то теперь — другой.
по моему, это ломка того же порядка, чем 1=1 отличается от x=x при текущем положении дел. просто она сдвинута в область более сложных выражений с х.
и это зависит от того насколько шагнуть в сложности анализа выражений оптимизатором. для выражений вида f(x)= f(x) вроде как нет проблем, но понятно что рано или поздно не сможем доказать равенство (что уже ранее обсудили), и в таких случаях сравнение будет давать null. это ведет к понижению точности вычисления, как сейчас в sql уже и есть.
насколько это будет неожиданным — сказать трудно. я исхожу из посыла, что повышение точности вычислений, это хорошо.
в целом соглашусь, что на текущий момент, текущие формальные правила вычислений с нул (с учетом сложностей реализации более продвинутых) для практических нужд кажутся оптимальны.
Здравствуйте, MadHuman, Вы писали:
MH>не соглашусь. единственно где здравый смысл подводит, это квантовая механика в IT не припомню случаев где бы здравый смысл подводил.
Да постоянно. Классический пример:
for(int i=0; i<a.Count, i++) // ой-ой, вызов safe-метода в tight loop.
s+=a[i]
"Здравый смысл", унаследованный из C, подсказывает ввести временную переменную по соображениям производительности:
int l = a.Count;
for(int i=0; i<l, i++)
s+=a[i]
Увы — обращения к Count устраняются джитом вместе с проверкой; а вот обращения к временной переменной — нет. Вопреки "здравому смыслу" этот код менее оптимален.
MH>цитата из статьи
MH>MH>Другим новым типом является тип BOOLEAN, который дает возможность в SQL непосредственно записывать истинностные значения true, false и unknown. Сложные комбинации предикатов можно также выразить способами, которые в чем-то более дружественны к пользователям
Ок, тут вы правы.
MH>меня интересовали причины по которым формальные правила вычислений приводили к нарушению закона тождества.
MH>для себя ответ я нашел, в том числе и благодаря вашим аргументам, спасибо за дискуссию
MH>очень вероятно что это так, чтоб синтезировать эти альтернативные правила надо нехило напрячься и потратить время, что лично мне делать пока нехочется, хотя и интересно.
Ну, в целом-то всех очень парит писать
where name = @name or (@name is null and name is null), поэтому альтернативная алгебра была бы востребована. Увы — проблема именно в том, что она начинает давать неожиданные результаты в случаях типа where
x*2 = x + 5. В современном SQL такой предикат найдёт только x = 5, в гипотетическом его устроит и null.
S>>Ок, то есть (x+1) всё же не равен (x+1)? Это же подходит под "любое другое действие"?
MH>да. если под "не равен" вы имеете ввиду "будет не истина", то да будет не истина, будет нул.
Ну вот это как раз и нарушает здравый смысл: результат сравнения x с x и x+1 с x+1 получается разным.
Более того, мы можем нарваться и на ещё более неожиданные вещи, типа
where x+@a = x*@b внезапно получает unknown даже при @a=0 и @b=1. Хотя прямая подстановка даёт x=x, а он у нас по определению всегда возвращает true.
MH>да, и что?
Попробуйте
MH>такая оптимизация вообще исключит необходимость доступа к полю х, эффект может быть заметен. это одна из мотиваций.
Вопрос не только в том, какие операции устраняются. Вопрос в том, насколько часто это происходит.
S>>Теперь начинаются неожиданности на ровном месте: незначительное изменение кода ломает семантику. Если раньше у нас lowercase(x)=lowercase(x) давало такой же результат, что и x=x, то теперь — другой.
MH>по моему, это ломка того же порядка, чем 1=1 отличается от x=x при текущем положении дел. просто она сдвинута в область более сложных выражений с х.
Проблема в том, что трудно описать, почему прямое вычисление x=x отличается от "оптимизированного" по результатам.
MH>и это зависит от того насколько шагнуть в сложности анализа выражений оптимизатором. для выражений вида f(x)= f(x) вроде как нет проблем, но понятно что рано или поздно не сможем доказать равенство (что уже ранее обсудили), и в таких случаях сравнение будет давать null. это ведет к понижению точности вычисления, как сейчас в sql уже и есть.
Не к понижению точности, а просто к непредсказуемым результатам.
MH>насколько это будет неожиданным — сказать трудно. я исхожу из посыла, что повышение точности вычислений, это хорошо.
Термин "повышение точности" тут неприменим. Вам
кажется, что сравнение x=x должно давать true, если x = null. Нельзя назвать этот результат "более точным".
MH>в целом соглашусь, что на текущий момент, текущие формальные правила вычислений с нул (с учетом сложностей реализации более продвинутых) для практических нужд кажутся оптимальны.
Пока что речь не столько о сложностях, сколько о невозможности реализации "более продвинутых".
