Здравствуйте, MadHuman, Вы писали:
MH>ну ок, допустим такое поведение ничего не нарушает. тогда допустим, что если поведение интуитивно (когда тождество x=x всегда истинно), то что нарушится?
Тебе же уже написали. Закон тождества нарушится, хоть ты и не знаешь, что это такое.
Твоя основная проблема в том, что ты от балды употребляешь понятия, которых не понимаешь. Ты явно не знаешь ни что такое "закон тождества", ни что такое "тождество".
х = х будет тождеством только в случае, если это равенство будет выполнятся (будет истинным) при любом значении х. Очевидно, что в случае троичной логики это условие не выполняется. null == null даст null, а не true, как в случае с другими значениями x. Не менее очевидно, что в этом случае о тождестве не приходится говорить.
Здравствуйте, MadHuman, Вы писали:
Д>>А каким образом описать, что данные из одного источника? MH>В случае тождества x=x, это видно.
Вот я крайне не рекомендую полагаться на рассуждения типа "это видно" в CS.
Давайте так: (x + 1) = (x + 1) — видно?
А так? (1 + x) = (x + 1)
А так? (1 + x) = (y + 1) where x = y
А так? x*x = x*x
Эти примеры показывают, что мы не можем просто "сравнить выражения посимвольно", иначе сломаются какие-то другие тождества.
Для этих примеров мы могли бы ввести "tagged null". То есть оборудовать null признаком "источника". Тогда у нас "null x" и "null y" будут различны, при этом всё ещё давая тождество при сравнении null x с null x.
Но тогда у нас вот такие примеры будут давать контр-интуитивные результаты: (x + 1) = (x + 2) // оба null помечены тегом "x", так что TRUE
В общем, сделать lifted operators на значениях, расширенных null-ом, можно более-менее одним непротиворечивым способом.
И в этом способе x вполне может быть неравен самому себе.
Выражение х = х упрошается не в true, а в x is not null.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, MadHuman, Вы писали:
Д>>>А каким образом описать, что данные из одного источника? MH>>В случае тождества x=x, это видно. S>Вот я крайне не рекомендую полагаться на рассуждения типа "это видно" в CS.
меня интересовала более математическая сторона за этим поведением.
S>Давайте так: (x + 1) = (x + 1) — видно?
если сделать упрощение — убрать одинаковое слагаемое с обоих частей равенства, то да, получаем опять x=x
S>А так? (1 + x) = (x + 1)
аналогично
S>А так? (1 + x) = (y + 1) where x = y
аналогично, плюс вместо x подставляем y, получаем y=y
S>А так? x*x = x*x
также можно упростить до x=x
если вернутся к примеру, который приводил ранее, то видно что эти упрощения логичны и тождество соблюдается.
ещё раз пример — с возростом конкретного человека. допустим мы его не знаем (то есть это x, а в БД для этого случая вводят спец. значение null), но ведь очевидно что этот x (который null) равен самому себе.
также очевидно что в этом примере и x+1=x+1 истинно.
хотя x мы не знаем. и это не знание по сути и выражается null-ом. можно даже пойти дальше и сказать, что x (то есть неизвестное в равенстве) это и есть null, но "tagged null"
S>Для этих примеров мы могли бы ввести "tagged null". То есть оборудовать null признаком "источника". Тогда у нас "null x" и "null y" будут различны, при этом всё ещё давая тождество при сравнении null x с null x. S>Но тогда у нас вот такие примеры будут давать контр-интуитивные результаты: S>(x + 1) = (x + 2) // оба null помечены тегом "x", так что TRUE
Такой результат будет если пытаться последовательно вычислять выражение по предложенной вами схеме, что говорит о её недостатках.
Слабое место здесь в допущении, что после операции с null новый null это тот же нул, что очевидно не так, вы сами последующим примером это и подтвердили.
S>Выражение х = х упрошается не в true, а в x is not null.
в текущих реализациях БД да, приходится так.
почему так сделали в БД принципе мне уже понятно, так как иначе возрастёт сложность реализации. то есть это компромис.
тут кстати некоторые аргументировали что закон тождества не выполняется из-за использования троичной логики (где есть 3-е значение — неизвестность) — на самом деле в троичной логике он выполняется.
Здравствуйте, MadHuman, Вы писали:
S>>Давайте так: (x + 1) = (x + 1) — видно? MH>если сделать упрощение — убрать одинаковое слагаемое с обоих частей равенства, то да, получаем опять x=x
Ок, давайте так: (x + 1) = (x + sin(0.5)*sin(0.5)+cos(0.5)*cos(0.5))
Сможете определить, что слагаемые одинаковы?
А вот так? (x + 1) = (x + sin(y)*sin(y)+cos(y)*cos(y))
S>>А так? (1 + x) = (y + 1) where x = y MH>аналогично, плюс вместо x подставляем y, получаем y=y
Ок, давайте так:
select @x = x from table1 where id = 1
select id from table1 where x = @x
Как будем подставлять x вместо @x?
А если вот так:
select @x1 = x from table1 where id = 1
set @x2 = null
select id from table1 where x = @x1
select id from table1 where x = @x2
Вот это — какие результаты должно выдавать?
MH>также можно упростить до x=x
Кратко: вам кажется, что можно.
MH>если вернутся к примеру, который приводил ранее, то видно что эти упрощения логичны и тождество соблюдается. MH>ещё раз пример — с возростом конкретного человека. допустим мы его не знаем (то есть это x, а в БД для этого случая вводят спец. значение null), но ведь очевидно что этот x (который null) равен самому себе.
Слова "очевидно" нужно избегать. Оно ведёт в ловушку. MH>также очевидно что в этом примере и x+1=x+1 истинно. S>>(x + 1) = (x + 2) // оба null помечены тегом "x", так что TRUE MH>Такой результат будет если пытаться последовательно вычислять выражение по предложенной вами схеме, что говорит о её недостатках. MH>Слабое место здесь в допущении, что после операции с null новый null это тот же нул, что очевидно не так, вы сами последующим примером это и подтвердили.
Попробуйте улучшить эту схему. Так, чтобы "одинаковые" null-ы были одинаковыми, а разные, соответственно, разными. Чтобы при этом (x + 2 + 3) давало такой же null, как и (x + 1 + 4), а (x+1) и (x+2) — разные.
S>>Выражение х = х упрошается не в true, а в x is not null. MH>в текущих реализациях БД да, приходится так.
Не в реализациях, а в three-state-logic алгебре. В принципе, интересное упражнение — вы придумайте другую алгебру так, чтобы она работала (хотя бы математически).
На всякий случай напомню, что бывают алгебраические неожиданные вещи и без null.
Например, x*expr1 = x*expr2 вовсе не эквивалентно expr1 = expr2. Потому что при x = 0 это уравнение сводится к true, и работает для любых expr1/expr2.
То, что вы наблюдаете — примерно то же самое.
MH>тут кстати некоторые аргументировали что закон тождества не выполняется из-за использования троичной логики (где есть 3-е значение — неизвестность) — на самом деле в троичной логике он выполняется.
Просто он имеет другую форму.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
MH>тут кстати некоторые аргументировали что закон тождества не выполняется из-за использования троичной логики
Сформулируй словами закон тождества. Словами, не символами.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, MadHuman, Вы писали:
MH>>тут кстати некоторые аргументировали что закон тождества не выполняется из-за использования троичной логики _AB>Сформулируй словами закон тождества. Словами, не символами.
тебя в гугле забанили?
MH>Что за хня? почему так? какая за этим логика мотивирующая такое поведение (что нарушается закон тождества и нельзя делать такие упрощения выражений фильтров)?
declare @id as int = (select id from AnyTab where 1=2) //null. а что по твоему должно быть?
select * from Tab1
where col in (select id from AnyTab where 1=2) // логично что не вернет ничего и никогда
select * from Tab1
where col = @id // опять логично - не вернет ничего. Было бы странно если бы подстановка выражений работала иначе
Здравствуйте, Sinclair, Вы писали:
MH>>если сделать упрощение — убрать одинаковое слагаемое с обоих частей равенства, то да, получаем опять x=x S>Ок, давайте так: S>(x + 1) = (x + sin(0.5)*sin(0.5)+cos(0.5)*cos(0.5)) S>Сможете определить, что слагаемые одинаковы? S>А вот так? S>(x + 1) = (x + sin(y)*sin(y)+cos(y)*cos(y))
Вы ведете к тому, что можно придумать достаточно сложное равенство которое не получится упростить, до х=х.
Бесспорно это возможно. И в случае такого равенства, действительно нельзя утверждать что части равны, поэтому логично считать что результат их сравнений null.
Не вижу тут проблемы.
MH>>ещё раз пример — с возростом конкретного человека. допустим мы его не знаем (то есть это x, а в БД для этого случая вводят спец. значение null), но ведь очевидно что этот x (который null) равен самому себе. S>Слова "очевидно" нужно избегать. Оно ведёт в ловушку.
Вы хотите сказать что видите какие-то ещё трактовки примера? что всё таки х=х не истинно?
MH>>также очевидно что в этом примере и x+1=x+1 истинно. S>>>(x + 1) = (x + 2) // оба null помечены тегом "x", так что TRUE MH>>Такой результат будет если пытаться последовательно вычислять выражение по предложенной вами схеме, что говорит о её недостатках. MH>>Слабое место здесь в допущении, что после операции с null новый null это тот же нул, что очевидно не так, вы сами последующим примером это и подтвердили. S>Попробуйте улучшить эту схему. Так, чтобы "одинаковые" null-ы были одинаковыми, а разные, соответственно, разными. Чтобы при этом (x + 2 + 3) давало такой же null, как и (x + 1 + 4), а (x+1) и (x+2) — разные.
В вырожденном случае будет "null x" +1 = "null x"+2 , то есть придется запоминать какие операции с исходным нулом были проделаны и при помощи функции типа сравнить сравнить выражения сравнивать части.
Понятно, что это перебор, но речь же не об тотальной реализации такого подхода в вычислениях СУБД, исходный вопрос был почему бы не считать тождество верным хотя бы для минимального его вида (когда х=х и х — это поле записи).
S>>>Выражение х = х упрошается не в true, а в x is not null. MH>>в текущих реализациях БД да, приходится так. S>Не в реализациях, а в three-state-logic алгебре.
как раз в трёхзначной логике закон тождества соблюдается, и неизвестность = той же самой неизвестности (х=х).
S>В принципе, интересное упражнение — вы придумайте другую алгебру так, чтобы она работала (хотя бы математически).
дак трёхзначная логика Лукасевича.
S>На всякий случай напомню, что бывают алгебраические неожиданные вещи и без null. S>Например, x*expr1 = x*expr2 вовсе не эквивалентно expr1 = expr2. Потому что при x = 0 это уравнение сводится к true, и работает для любых expr1/expr2. S>То, что вы наблюдаете — примерно то же самое.
пример интересный, но аналогии с нулом и тождеством не вижу.
подумайте ещё раз о примере с неизвестным возростом какого-либо человека (возьмём его за х). ведь х=х?
да не, это о другом, не об А=А а об получении какого то null и сравнения с каким-то другим null, в таком случае всё ок, вариантов нет — результат сравнения надо null.
R>declare @id as int = (select id from AnyTab where 1=2) //null. а что по твоему должно быть?
тут по сути, в @id присваивается результат из пустого списка, что с точки зрения строгости странно, но для удобства чтоб не падать принято соглашение что в таком случае в @id присвоить null.
и это обобщённый null, то есть null не имеющий какого-то источника.
R>select * from Tab1 R>where col in (select id from AnyTab where 1=2) // логично что не вернет ничего и никогда
ну да, результат подселекта — пустой список и в пустом списке не будет никакого из возможных значений col.
в этом примере нет сравнения null и другого null
R>а что смущает в сравнении нулов?
глубоко противится моей тонкой внутренней математической душевной организации, то что в БД нельзя критерий отбора x=x and y=1 упростить до y=1
не принимает она его и всё)
Здравствуйте, MadHuman, Вы писали:
_AB>>Сформулируй словами закон тождества. Словами, не символами. MH>тебя в гугле забанили?
Это слив такой неоригинальный? Для темы важно то, как ты этот закон понимаешь, а не как он где-то записан.
Здравствуйте, MadHuman, Вы писали:
MH>Вы хотите сказать что видите какие-то ещё трактовки примера? что всё таки х=х не истинно?
Результат сравнения x с x равен истине не для всех значений х, вот что тебе хотят сказать уже несколько человек.
Здравствуйте, MadHuman, Вы писали:
S>>(x + 1) = (x + sin(y)*sin(y)+cos(y)*cos(y)) MH>Вы ведете к тому, что можно придумать достаточно сложное равенство которое не получится упростить, до х=х.
Нет, веду к тому, что способности компилятора по упрощению равенств ограничены. MH>Вы хотите сказать что видите какие-то ещё трактовки примера? что всё таки х=х не истинно?
Конечно.
S>>Попробуйте улучшить эту схему. Так, чтобы "одинаковые" null-ы были одинаковыми, а разные, соответственно, разными. Чтобы при этом (x + 2 + 3) давало такой же null, как и (x + 1 + 4), а (x+1) и (x+2) — разные. MH>В вырожденном случае будет "null x" +1 = "null x"+2 , то есть придется запоминать какие операции с исходным нулом были проделаны и при помощи функции типа сравнить сравнить выражения сравнивать части.
Это пока что не тянет на полноценный дизайн. Доказательство эквивалентности выражений — это NP-полная задача для ограниченного случая и Проблема Останова для произвольного. MH>Понятно, что это перебор, но речь же не об тотальной реализации такого подхода в вычислениях СУБД, исходный вопрос был почему бы не считать тождество верным хотя бы для минимального его вида (когда х=х и х — это поле записи).
Очевидный ответ: "потому что такая реализация будет вести себя неконсистентно".
От отношения эквивалентности ожидают, например, транзитивности. В вашей воображаемой алгебре обеспечить транзитивность не удастся.
MH>как раз в трёхзначной логике закон тождества соблюдается, и неизвестность = той же самой неизвестности (х=х). MH>дак трёхзначная логика Лукасевича. Вы путаете логику и алгебру над nullable-типами. В SQL ровно та же логика, что у Лукасевича. В рамках чисто-логических выражений всё хорошо, т.к. нет никакой "другой неизвестности". А вот попытка натянуть ту же сову на глобус произвольных типов приведёт к неприятным парадоксам.
Проблема в том, что простой реализации, где null=null, select * from table1 where x+1 = x+2 неожиданно будет возвращать строчки с x is null. А сложную сделать вы не можете.
S>>На всякий случай напомню, что бывают алгебраические неожиданные вещи и без null. S>>Например, x*expr1 = x*expr2 вовсе не эквивалентно expr1 = expr2. Потому что при x = 0 это уравнение сводится к true, и работает для любых expr1/expr2. S>>То, что вы наблюдаете — примерно то же самое. MH>пример интересный, но аналогии с нулом и тождеством не вижу.
Ну как же. Структура выражения — строго такая же, как и (x+expr1) = (x+expr2), только по отношению не к 0, а к null.
MH>подумайте ещё раз о примере с неизвестным возростом какого-либо человека (возьмём его за х). ведь х=х?
Да, в данном конкретном примере возраст совпадает с самим собой. Но проблема в том, что мы не можем реализовать такую алгебру, где выполнялись бы нужные вам свойства. В общем случае у вас будет f1(x)=f2(x), и вам придётся доказывать эквивалентность f1 и f2 на всей области значений x, за исключением null. Тогда можно считать, что f1 и f2 дают одинаковый результат при x=null.
А если вы этого не сделаете, то пользователям будет совершенно непонятно, почему в какой-то момент теряется идентичность выражений:
select * where x=x // ok
select * where x+1=x+1 // ok? почему?
select * where x+1=1+x // ok? почему?
select * where x+1+3=2+x+2 // ok? почему?
select * where x+y=y+x // ok? почему?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, MadHuman, Вы писали: MH>глубоко противится моей тонкой внутренней математической душевной организации, то что в БД нельзя критерий отбора x=x and y=1 упростить до y=1 MH>не принимает она его и всё)
Упрощайте до (x is not null) and (y=1) — это тоже прекрасно ляжет на индекс по (y, x).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
MH>>Вы ведете к тому, что можно придумать достаточно сложное равенство которое не получится упростить, до х=х. S>Нет, веду к тому, что способности компилятора по упрощению равенств ограничены.
это очевидно. я это и не ставил под сомнение.
MH>>Вы хотите сказать что видите какие-то ещё трактовки примера? что всё таки х=х не истинно? S>Конечно.
какие?
MH>>В вырожденном случае будет "null x" +1 = "null x"+2 , то есть придется запоминать какие операции с исходным нулом были проделаны и при помощи функции типа сравнить сравнить выражения сравнивать части. S>Это пока что не тянет на полноценный дизайн. Доказательство эквивалентности выражений — это NP-полная задача для ограниченного случая и Проблема Останова для произвольного.
нет задачи придумать дизайн реализации, и да — доказательство эквивалентности выражений не всегда возможно.
из этого следует, что для некоторых равенств, которые не упрощаются до тождества, нельзя сделать вывод что они истинны, и тогда результат сравнения частей равенства — null, это вполне ок и диссонанса со здравым смыслом не вызывает.
MH>>Понятно, что это перебор, но речь же не об тотальной реализации такого подхода в вычислениях СУБД, исходный вопрос был почему бы не считать тождество верным хотя бы для минимального его вида (когда х=х и х — это поле записи). S>Очевидный ответ: "потому что такая реализация будет вести себя неконсистентно".
можно пример неконсистентности?
примеры выше были не про неконсистентность, а илюстрировали что "способности компилятора по упрощению равенств ограничены".
и когда натыкаемся на ограничение возможностей упрощения, ок пусть будет результат null.
S>От отношения эквивалентности ожидают, например, транзитивности. В вашей воображаемой алгебре обеспечить транзитивность не удастся.
пример можно?
S>В SQL ровно та же логика, что у Лукасевича. В рамках чисто-логических выражений всё хорошо, т.к. нет никакой "другой неизвестности".
то есть, если х — логическое поле, допустим выражает пол, то при его значении = неизвестно, х=х?
но ведь вы же знаете, что в sql так не будет, это выражение даст null.
S> А вот попытка натянуть ту же сову на глобус произвольных типов приведёт к неприятным парадоксам.
я не вижу кардинальной смены сути, если в нашем примере вместо возроста, мы возьмем что-то булевское, например пол (true — М, false — Ж).
при переходе от булевского признака к числу, суть примера же от этого не меняется? неизвестность будет по прежнему равна самой себе.
MH>>подумайте ещё раз о примере с неизвестным возростом какого-либо человека (возьмём его за х). ведь х=х? S>Да, в данном конкретном примере возраст совпадает с самим собой.
а есть ли какой-то другой конкретный пример, когда это не так?
S>Но проблема в том, что мы не можем реализовать такую алгебру, где выполнялись бы нужные вам свойства. В общем случае у вас будет f1(x)=f2(x), и вам придётся доказывать эквивалентность f1 и f2 на всей области значений x, за исключением null. Тогда можно считать, что f1 и f2 дают одинаковый результат при x=null.
это да.
S>А если вы этого не сделаете, то пользователям будет совершенно непонятно, почему в какой-то момент теряется идентичность выражений: S>
S>select * where x=x // ok
S>select * where x+1=x+1 // ok? почему?
S>select * where x+1=1+x // ok? почему?
S>select * where x+1+3=2+x+2 // ok? почему?
S>select * where x+y=y+x // ok? почему?
S>
то есть раз не можем сделать реализацию для общего случая, который будет сложным, то пусть и простой случай х=х будет null.
ну это собственно всё и объясняет.
ну и в случае если х=х истина, ответ на вопрос почему — потому что операция с null даёт null и оптимизатор/упроститель не может упростить до тождества. невижу тут противоречий. и пока мне это видится лучше чем х=х, дающее null при х=null.
Здравствуйте, MadHuman, Вы писали:
MH>Здравствуйте, Sinclair, Вы писали:
MH>>>Вы ведете к тому, что можно придумать достаточно сложное равенство которое не получится упростить, до х=х. S>>Нет, веду к тому, что способности компилятора по упрощению равенств ограничены. MH>это очевидно. я это и не ставил под сомнение.
MH>>>Вы хотите сказать что видите какие-то ещё трактовки примера? что всё таки х=х не истинно? S>>Конечно. MH>какие? x = x эквивалентно х is not null.
MH>нет задачи придумать дизайн реализации, и да — доказательство эквивалентности выражений не всегда возможно. MH>из этого следует, что для некоторых равенств, которые не упрощаются до тождества, нельзя сделать вывод что они истинны, и тогда результат сравнения частей равенства — null, это вполне ок и диссонанса со здравым смыслом не вызывает.
Именно поэтому и не стоит полагаться на здравый смысл. Он легко оправдывает заведомо неработоспособные вещи. Например, вам кажется, что есть такой чётко определённый класс равенств, которые "упрощаются до тождества". И можно вычесть его из класса "все сравнения", и вот этим вот остатком пренебречь. MH>примеры выше были не про неконсистентность, а илюстрировали что "способности компилятора по упрощению равенств ограничены". MH>и когда натыкаемся на ограничение возможностей упрощения, ок пусть будет результат null.
Проблема при этом, очевидно, в том, что истинность или ложность выражения теперь у нас определяется нестрого — в зависимости от того, сколько интеллекта (и времени) будет у оптимизатора, мы получим либо true либо unknown.
Кто будет полагаться на софт, который ведёт себя непредсказуемо?
S>>От отношения эквивалентности ожидают, например, транзитивности. В вашей воображаемой алгебре обеспечить транзитивность не удастся. MH>пример можно?
update table1 set y = x;
select * from table1 where y = x
MH>то есть, если х — логическое поле, допустим выражает пол, то при его значении = неизвестно, х=х?
В ANSI SQL нет "логических" полей. Предикаты возвращают специальный тип. Логики второго порядка в SQL нет. В нём нельзя написать where (x=1) = (y=1).
MH>а есть ли какой-то другой конкретный пример, когда это не так?
Дело не в конкретном примере, а в самой идее алгебры, где выражение можно вычислить "по частям" — рассчитать каждое из подвыражений, и получить результат, который не зависит от способа, которым эти подвыражения вычислялись.
А у вас получается, что (x+y) неравен (x+z), несмотря на то, что оба дают null. При этом x+1 и x+1 вполне себе равны.
В современном SQL неспособность оптимизатора доказать какие-то эквивалентности приводит к изменению производительности, но результат гарантированно остаётся прежним.
Вы предлагаете оптимизатор, который способен выдавать различные результаты в зависимости от внешних параметров.
MH>то есть раз не можем сделать реализацию для общего случая, который будет сложным, то пусть и простой случай х=х будет null. MH>ну это собственно всё и объясняет. MH>ну и в случае если х=х истина, ответ на вопрос почему — потому что операция с null даёт null и оптимизатор/упроститель не может упростить до тождества. невижу тут противоречий. и пока мне это видится лучше чем х=х, дающее null при х=null.
Ещё раз: если вы сделаете вычислитель выражений таким, чтобы он давал "TRUE" при сравнении x c x даже на null-значении, то он у вас неизбежно будет давать true и тогда, когда вы сравниваете x+1 с x+2.
Оптимизация не должна менять результат операции.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>>Нет, веду к тому, что способности компилятора по упрощению равенств ограничены. MH>>это очевидно. я это и не ставил под сомнение.
MH>>>>Вы хотите сказать что видите какие-то ещё трактовки примера? что всё таки х=х не истинно? S>>>Конечно. MH>>какие? S>x = x эквивалентно х is not null.
нет, это не трактовка примера, "х is not null" это следствие из-за принятых формальных правил вычислений в sql, которые таковы так как способности компилятора по упрощению равенств ограничены.
MH>>из этого следует, что для некоторых равенств, которые не упрощаются до тождества, нельзя сделать вывод что они истинны, и тогда результат сравнения частей равенства — null, это вполне ок и диссонанса со здравым смыслом не вызывает. S>Именно поэтому и не стоит полагаться на здравый смысл. Он легко оправдывает заведомо неработоспособные вещи.
на здравый смысл стоит полагаться. если вывод из цепочки рассуждений противоречит здравому смыслу, значит в рассуждениях ошибка.
MH>>примеры выше были не про неконсистентность, а илюстрировали что "способности компилятора по упрощению равенств ограничены". MH>>и когда натыкаемся на ограничение возможностей упрощения, ок пусть будет результат null. S>Проблема при этом, очевидно, в том, что истинность или ложность выражения теперь у нас определяется нестрого — в зависимости от того, сколько интеллекта (и времени) будет у оптимизатора, мы получим либо true либо unknown. S>Кто будет полагаться на софт, который ведёт себя непредсказуемо?
это разумный аргумент. хотя степень непредсказуемости вопрос дискуссионный.
и да, вы употребили слово "очевидно" против употребления которого выступали ранее я не против, но не давайте советы которым сами не следуете
S>>>От отношения эквивалентности ожидают, например, транзитивности. В вашей воображаемой алгебре обеспечить транзитивность не удастся. MH>>пример можно? S>
S>update table1 set y = x;
S>select * from table1 where y = x
S>
воображаемая алгебра ведёт себя в данном случае также как и sql, в sql нет транзитивности?
MH>>то есть, если х — логическое поле, допустим выражает пол, то при его значении = неизвестно, х=х? S>В ANSI SQL нет "логических" полей. Предикаты возвращают специальный тип. Логики второго порядка в SQL нет. В нём нельзя написать where (x=1) = (y=1).
а в sql 1999 есть
MH>>а есть ли какой-то другой конкретный пример, когда это не так? S>Дело не в конкретном примере, а в самой идее алгебры, где выражение можно вычислить "по частям" — рассчитать каждое из подвыражений, и получить результат, который не зависит от способа, которым эти подвыражения вычислялись.
дело как раз в примере. если нет понятного конкретного примера когда одно и тоже не равно само себе, то значит нет примера нарушения закона тождества.
Вы апелируете к принятым формальным правилам вычислений, при которых точность вычислений загрубляется. Я же говорю о самой сути, когда одна и та же неизвестность равна сама себе. х=х.
и то что при вычислениях в sql это даёт null, это из-за формальных правил этих самых вычислений.
хотя результат null в случае тождества, даже формально нельзя назвать нарушением этого тождества, тк это значит что результат неизвестен и может быть и истиной.
примерно тоже когда в случае сложно выражения мы не смогли бы его упростить и также дали бы результат null.
S>А у вас получается, что (x+y) неравен (x+z), несмотря на то, что оба дают null.
нет, результат их сравнения null. я предлагал ограничиться только кэйсом когда сравнивается сама с собой одна и таже неопределённость.
когда с неопределённостью производится любой другое действие, то возникает уже новая и её можно трактовать также как сейчас в sql и есть.
S>В современном SQL неспособность оптимизатора доказать какие-то эквивалентности приводит к изменению производительности, но результат гарантированно остаётся прежним. S>Вы предлагаете оптимизатор, который способен выдавать различные результаты в зависимости от внешних параметров.
не от внешних параметров, а от сложности выражений.
вас же не смущает, что x=x and y=1 не то же самое что y=1, хотя по здравому смыслу вроде тоже.
MH>>то есть раз не можем сделать реализацию для общего случая, который будет сложным, то пусть и простой случай х=х будет null. MH>>ну это собственно всё и объясняет. MH>>ну и в случае если х=х истина, ответ на вопрос почему — потому что операция с null даёт null и оптимизатор/упроститель не может упростить до тождества. невижу тут противоречий. и пока мне это видится лучше чем х=х, дающее null при х=null. S>Ещё раз: если вы сделаете вычислитель выражений таким, чтобы он давал "TRUE" при сравнении x c x даже на null-значении, то он у вас неизбежно будет давать true и тогда, когда вы сравниваете x+1 с x+2.
ещё раз: не между произвольными нул значениями, а для одной и той же неопределённости. при любом действии с какой-то исходной неопределённостью (с х), возникает новая, отличающаяся от исходной.
Здравствуйте, MadHuman, Вы писали: S>>Именно поэтому и не стоит полагаться на здравый смысл. Он легко оправдывает заведомо неработоспособные вещи. MH>на здравый смысл стоит полагаться. если вывод из цепочки рассуждений противоречит здравому смыслу, значит в рассуждениях ошибка.
Всё как раз наоборот. Когда мы видим "неожиданный" вывод, то всегда дополнительно проверяем цепочку рассуждений.
А вот когда мы видим что-то "очевидное", то есть искушение пропустить этам проверки. Поэтому в IT "очевидные" утверждения гораздо чаще оказываются неверными, чем "неочевидные".
MH>это разумный аргумент. хотя степень непредсказуемости вопрос дискуссионный. MH>и да, вы употребили слово "очевидно" против употребления которого выступали ранее я не против, но не давайте советы которым сами не следуете
Я употребил его не в контексте доказательства утверждения.
S>>>>От отношения эквивалентности ожидают, например, транзитивности. В вашей воображаемой алгебре обеспечить транзитивность не удастся. MH>>>пример можно? S>>
S>>update table1 set y = x;
S>>select * from table1 where y = x
S>>
MH>воображаемая алгебра ведёт себя в данном случае также как и sql, в sql нет транзитивности?
В SQL — есть. Но в SQL, в отличие от вашей алгебры, результат выражения выше гарантированно такой же, как и у
select * from table1 where x = x
SQL не вернёт строки с x = null, а ваша алгебра — вернёт.
MH>а в sql 1999 есть
Где вы там это нашли?
MH>дело как раз в примере. если нет понятного конкретного примера когда одно и тоже не равно само себе, то значит нет примера нарушения закона тождества. MH>Вы апелируете к принятым формальным правилам вычислений, при которых точность вычислений загрубляется. Я же говорю о самой сути, когда одна и та же неизвестность равна сама себе. х=х.
В алгебре никакой сути нет. Нас интересует не суть, а формальные правила вычислений.
Если в вашей прикладной задаче возраст всегда равен самому себе, даже если у объекта вовсе никакого возраста нет — никто вас не осудит.
Просто вам придётся пользоваться каким-то другим матаппаратом. Например, таким, который устраняет сравнения с "самим собой" до того, как они будут пропущены через вычислитель.
MH>примерно тоже когда в случае сложно выражения мы не смогли бы его упростить и также дали бы результат null.
Ещё раз: "формальные правила вычислений" дают согласованные друг с другом результаты.
Я всё ещё не вижу никакой альтернативы этим правилам, которые бы по-прежнему давали согласованные друг с другом результаты, но при этом (x=x) давал бы true при x is null.
S>>А у вас получается, что (x+y) неравен (x+z), несмотря на то, что оба дают null. MH>нет, результат их сравнения null. я предлагал ограничиться только кэйсом когда сравнивается сама с собой одна и таже неопределённость. MH>когда с неопределённостью производится любой другое действие, то возникает уже новая и её можно трактовать также как сейчас в sql и есть.
Ок, то есть (x+1) всё же не равен (x+1)? Это же подходит под "любое другое действие"?
MH>не от внешних параметров, а от сложности выражений. MH>вас же не смущает, что x=x and y=1 не то же самое что y=1, хотя по здравому смыслу вроде тоже.
Внешним параметром здесь выступает сложность оптимизатора. В вашем примере меня ничего не смущает — мой здравый смысл сконфигурирован по-другому.
MH>ещё раз: не между произвольными нул значениями, а для одной и той же неопределённости. при любом действии с какой-то исходной неопределённостью (с х), возникает новая, отличающаяся от исходной.
Для этого вам придётся ввести формальное понятие "одна и та же неопределённость".
Если вы собираетесь ограничиться тривиальностями типа (x=x), то непонятна мотивация — таких случаев очень мало, усложнение оптимизатора мало что даст с точки зрения эффективности.
Зато усложнит жизнь программистам — теперь эквивалентные "на первый взгляд" преобразования становятся опасными.
До этого у нас сложности были только с плавающей точкой: там никого не удивишь тем, что (x+a+b)==y, но (x+a)!=(y-b). Теперь начинаются неожиданности на ровном месте: незначительное изменение кода ломает семантику. Если раньше у нас lowercase(x)=lowercase(x) давало такой же результат, что и x=x, то теперь — другой.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Джеффри, Вы писали:
Д>Потому что с появлением NULL — это уже трехзначная логика.
Д>Можно заменить NULL на Неизвестное Значение и спросить каким должен быть результат операции "Неизвестное значение равно неизвестному значению?". Логично было бы ответить — неизвестно
В данном случае — неизвестное значение равно тому же самому неизвестному значению.
Вы путаете логику и алгебру над nullable-типами. В SQL ровно та же логика, что у Лукасевича. В рамках чисто-логических выражений всё хорошо, т.к. нет никакой "другой неизвестности". А вот попытка натянуть ту же сову на глобус произвольных типов приведёт к неприятным парадоксам. 
