Здравствуйте, 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? почему?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
null — это абстрактное значение, введённое для того, чтобы его не путали с числами, строками, булевыми значениями и т.п. В ряде случаев null означает, что "значение не определено". Но далеко не во всех случаях.
Д>Можно заменить NULL на Неизвестное Значение и спросить каким должен быть результат операции "Неизвестное значение равно неизвестному значению?". Логично было бы ответить — неизвестно
это зависит. если за x взять возрост конкретного человека, и он неизвестен (то есть представлен null-ом), то очевидно что в этом случае x=x истинно. как возрост человека не может быть равен его же возросту (даже если мы его не знаем)?
Д>Ну, или представить, что в обычной двухзначной логике выражение X = Y можно представить как !(X < Y) && !(X > Y). И если X и Н — это NULL (неизвестные значения), задать вопрос неизвестное значение меньше неизвестного значения? Очевидно, что неизвестно. Тоже и для оператора больше. Поэтому второе выражение должно иметь результат — неизвестно. И первое получается — тоже.
в случае "неизвестное значение меньше неизвестного значения?" результат — неизвестно — да, это очевидно. так как если нет никакой дополнительной информации о происхождении неизвестности мы действительно ничего не можем утверждать (больше значение или меньше), поэтому результат — неизвестно, вполне логичен.
Д>Даже, если представить, что NULL — это некое специальное значение, которое эквивалентно себе, но никогда неравно другим значениям (этого можно добиться, например, с помощью SET ANSI_NULLS OFF), то все равно комбинации операции сравнение не будут давать тот же результат, что и операция равно. Т.е. будут противоречия.
это не то. два разных null-а о происхождении которых мы не знаем, действительно мы не можем утверждать что это равные значения.
но когда это неизвестность из одного источника, то x=x можно и логично считать истинным.
Здравствуйте, 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>Что за хня? почему так? какая за этим логика мотивирующая такое поведение (что нарушается закон тождества и нельзя делать такие упрощения выражений фильтров)?
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 // опять логично - не вернет ничего. Было бы странно если бы подстановка выражений работала иначе
Здравствуйте, 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.
Оптимизация не должна менять результат операции.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Есть закон тождества, гласящий, что x=x. Что очевидно и интуитивно и по другому быть не может.
И выражение x=x and y=1 можно смело сократить до y=1
Это вроде всё очевидно и интуитивно понятно.
Однако если это критерий для выборки из таблицы БД, то нет.
Так как если x=null, то по правилам операций в БД всё выражение становится null, что уже как-то очень странно.
Как же тогда тождество? И если null по сути — значение не известно, то сравнения с тем же самым "не известным" логично бы чтоб было true (в этом случае закон тождества не нарушается).
Если мы точно знаем что источник неизвестности один и тот же, то вполне ок считать что эти значения равны.
Вот если мы этого не знаем, тогда да, логично что результат выражения будет null.
Что за хня? почему так? какая за этим логика мотивирующая такое поведение (что нарушается закон тождества и нельзя делать такие упрощения выражений фильтров)?
MH>Что за хня? почему так? какая за этим логика мотивирующая такое поведение (что нарушается закон тождества и нельзя делать такие упрощения выражений фильтров)?
select
case a
when 1 then '111'
when 2 then '222'
when 3 then null-- 3else null-- 4end
from t
Здравствуйте, MadHuman, Вы писали:
MH>Что за хня? почему так? какая за этим логика мотивирующая такое поведение (что нарушается закон тождества и нельзя делать такие упрощения выражений фильтров)?
Потому что с появлением NULL — это уже трехзначная логика.
Можно заменить NULL на Неизвестное Значение и спросить каким должен быть результат операции "Неизвестное значение равно неизвестному значению?". Логично было бы ответить — неизвестно
Ну, или представить, что в обычной двухзначной логике выражение X = Y можно представить как !(X < Y) && !(X > Y). И если X и Н — это NULL (неизвестные значения), задать вопрос неизвестное значение меньше неизвестного значения? Очевидно, что неизвестно. Тоже и для оператора больше. Поэтому второе выражение должно иметь результат — неизвестно. И первое получается — тоже.
Даже, если представить, что NULL — это некое специальное значение, которое эквивалентно себе, но никогда неравно другим значениям (этого можно добиться, например, с помощью SET ANSI_NULLS OFF), то все равно комбинации операции сравнение не будут давать тот же результат, что и операция равно. Т.е. будут противоречия.
Здравствуйте, L.K., Вы писали:
MH>>И если null по сути — значение не известно
LK>null — это абстрактное значение, введённое для того, чтобы его не путали с числами, строками, булевыми значениями и т.п. В ряде случаев null означает, что "значение не определено". Но далеко не во всех случаях.
это понятно.
непонятно как может закон тождества нарушаться. даже если вместо X мы подставляем это специальное абстрактное значение. в случае тождества это одно и тоже.
Здравствуйте, MadHuman, Вы писали:
MH>это зависит. если за x взять возрост конкретного человека, и он неизвестен (то есть представлен null-ом), то очевидно что в этом случае x=x истинно. как возрост человека не может быть равен его же возросту (даже если мы его не знаем)? MH>но когда это неизвестность из одного источника, то x=x можно и логично считать истинным.
А каким образом описать, что данные из одного источника? Нет, я понимаю, что в программировании можно перезагрузить оператор сравнения и сделать так, чтобы он проверял, например, равенство указателей, а не только значений. Но это уже за пределами математической логики... Можно, конечно, сказать, что если x — NULL, то x = x, тоже должно быть NULL. а вот если x = NULL и y = NULL, то x = y должно быть NULL. Но зачем так усложнять и что, например, делать с выражениями вроде x = x + 0.
Опять же SQL оперирует кортежами сущностей. Т.е. таблица людей и в ней есть атрибут возраст. В общем случае запросы будут выглядеть — выбрать людей с одинаковым возрастом или выбрать людей, у которых возраст равен заданному.
Д>А каким образом описать, что данные из одного источника?
В случае тождества x=x, это видно.
Д>Нет, я понимаю, что в программировании можно перезагрузить оператор сравнения и сделать так, чтобы он проверял, например, равенство указателей, а не только значений. Но это уже за пределами математической логики... Можно, конечно, сказать, что если x — NULL, то x = x, тоже должно быть NULL. а вот если x = NULL и y = NULL, то x = y должно быть NULL. Но зачем так усложнять и что, например, делать с выражениями вроде x = x + 0.
Вообщем-то я не говорю о том что надо всё усложнять и тотально отслеживать источник NULL-а (хотя может и есть в этом смысл, это отдельный и непростой вопрос), я говорю о том что в условиях отбора тождество можно сокращать и тем самым упрощать выражение условия отбора.
Д>Опять же SQL оперирует кортежами сущностей. Т.е. таблица людей и в ней есть атрибут возраст. В общем случае запросы будут выглядеть — выбрать людей с одинаковым возрастом или выбрать людей, у которых возраст равен заданному.
Да, и что? в любом случае если сравнивается атрибут возрост конкретного человека со своим же возрастом, то по здравому смыслу очевидно что они равны и тождество соблюдено, даже если этот атрибут у этого конкретного человека null.
И конечно при выборке людей с заданным возрастом, очевидно что мы не можем включать в выборку людей у которых возрост не задан (=null).
Я понимаю что такое null в БД и зачем. Я не понимаю почему в условиях отбора x=x нельзя отбросить и такая добавка реально влияет на выборку (записи где x равен null не выбираются).
Здравствуйте, MadHuman, Вы писали:
MH>Что за хня? почему так?
Потому что в противном случае... нарушается закон тождества.
Закон тождества гласит, что каждое понятие должно сохранять своё однозначное значение на протяжении всего рассуждения. (А вовсе не что x=x).
Понятие "сравнение null с любым значением даёт результат null" по закону тождества не должно иметь исключения в виде "но если null выражен через переменную, то сравнение переменной самой с собой должно давать результат true".
Здравствуйте, _ABC_, Вы писали:
_AB>Потому что в противном случае... нарушается закон тождества. _AB>Закон тождества гласит, что каждое понятие должно сохранять своё однозначное значение на протяжении всего рассуждения. (А вовсе не что x=x).
И в чем тут нарушение? если за Х принять например твой возрост, я его не знаю (придам значение null), и согласно "понятие должно сохранять своё однозначное значение" это понятие должно быть одинаково во всем рассуждении, а следовательно равно самому себе.
Здравствуйте, MadHuman, Вы писали:
MH>Я не понимаю почему в условиях отбора x=x нельзя отбросить и такая добавка реально влияет на выборку (записи где x равен null не выбираются).
Навесь на поле x ограничение not null и можно будет отбросить (и продвинутая СУБД будет отбрасывать). Доволен?
Здравствуйте, MadHuman, Вы писали:
MH>И в чем тут нарушение?
Ты читать умеешь?
Понятие "сравнение null с любым значением даёт результат null" по закону тождества не должно иметь исключения в виде "но если null выражен через переменную, то сравнение переменной самой с собой должно давать результат true".
MH>если за Х принять например твой возрост,
Возраст. Пожалуйста, проявляй уважение к собеседникам и их кровоточащам глазам.
MH>я его не знаю (придам значение null), и согласно "понятие должно сохранять своё однозначное значение" это понятие должно быть одинаково во всем рассуждении, а следовательно равно самому себе.
Ты очень многое путаешь.
1. Возраст — это не понятие. Это признак объекта или его характеристика. А null применительно к возрасту — это параметр, конкретное значение из списка возможных этого признака или характеристики.
2. Понятие — это мысль, которая категоризирует или выделяет какие-либо объекты по каким-либо характеристикам в определенное множество, в класс, так сказать.
Вообще, мне стоило употребить слово "высказывание"/"суждение", а не "понятие", но давно я уже не освежал знания по формальной логике.
3. Суждение или высказывание — мысль, содержащая наличие или отсутствие связи между объектами и признаками.
Поэтому правильнее будет сформулировать так:
Суждение "сравнение null с любым значением даёт результат null" по закону тождества не должно иметь исключения в виде "но если null выражен через переменную, то сравнение переменной самой с собой должно давать результат true".
W>Навесь на поле x ограничение not null и можно будет отбросить (и продвинутая СУБД будет отбрасывать). Доволен?
нет. ты говориш очевидную вещь. вопрос не об этом.
Здравствуйте, MadHuman, Вы писали:
MH> Если мы точно знаем что источник неизвестности один и тот же, то вполне ок считать что эти значения равны. MH> Вот если мы этого не знаем, тогда да, логично что результат выражения будет null.
По-моему более понятно становится если null считать не неизвестностью, а отсутствием значения.
Тогда оно хорошо согласуется с тем, что left/right join даёт null в колонках при отсутствии записи в заджойненной таблице.
Тогда обычные булевы операции типа = <> становятся неприменимы, ибо нечего сравнивать — результат сравнения тоже отсутствует.
И никаких "источников неизвестности" не надо. Просто источник пуст.
Монада Maybe.
Д>>А каким образом описать, что данные из одного источника? MH>В случае тождества x=x, это видно.
Погоди, а какой смысл сравнивать х и х? Ну, кроме как отбросить null, хотя для этого есть способ и получше.
Здравствуйте, Muxa, Вы писали:
M>Погоди, а какой смысл сравнивать х и х? Ну, кроме как отбросить null, хотя для этого есть способ и получше.
Есть определённый "упроститель" критериев отбора определяемых юзерами фильтров, он упрощает критерий прежде чем сгенерить sql для запроса в БД.
И возникла дилемма что делать с x=x
Конечно практического смысла руками осмысленно писать такой критерий в sql нет. Но он (x=x) может появиться после ряда упрощений исходного более сложного фильтра, либо в его части.
Здравствуйте, MadHuman, Вы писали: MH>Есть закон тождества, гласящий, что x=x. Что очевидно и интуитивно и по другому быть не может. MH>И выражение x=x and y=1 можно смело сократить до y=1 MH>Это вроде всё очевидно и интуитивно понятно.
Ну, из меня подобную дурь выбили на втором курсе универа, в процессе изучения дифур. В общем говоря — так делать нельзя, ты теряешь область значений функции. А тождество работает только там.
MH>Что за хня? почему так? какая за этим логика мотивирующая такое поведение (что нарушается закон тождества и нельзя делать такие упрощения выражений фильтров)?
Это нормально. Ничего не нарушается.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, Ромашка, Вы писали:
MH>>Что за хня? почему так? какая за этим логика мотивирующая такое поведение (что нарушается закон тождества и нельзя делать такие упрощения выражений фильтров)?
Р>Это нормально. Ничего не нарушается.
ну ок, допустим такое поведение ничего не нарушает. тогда допустим, что если поведение интуитивно (когда тождество x=x всегда истинно), то что нарушится?
Здравствуйте, 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-е значение — неизвестность) — на самом деле в троичной логике он выполняется.
MH>тут кстати некоторые аргументировали что закон тождества не выполняется из-за использования троичной логики
Сформулируй словами закон тождества. Словами, не символами.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, MadHuman, Вы писали:
MH>>тут кстати некоторые аргументировали что закон тождества не выполняется из-за использования троичной логики _AB>Сформулируй словами закон тождества. Словами, не символами.
тебя в гугле забанили?
Здравствуйте, 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, Вы писали: 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.
Здравствуйте, 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 на Неизвестное Значение и спросить каким должен быть результат операции "Неизвестное значение равно неизвестному значению?". Логично было бы ответить — неизвестно
В данном случае — неизвестное значение равно тому же самому неизвестному значению.
Здравствуйте, 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 не припомню случаев где бы здравый смысл подводил.
Да постоянно. Классический пример:
"Здравый смысл", унаследованный из 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>в целом соглашусь, что на текущий момент, текущие формальные правила вычислений с нул (с учетом сложностей реализации более продвинутых) для практических нужд кажутся оптимальны.
Пока что речь не столько о сложностях, сколько о невозможности реализации "более продвинутых".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Вы путаете логику и алгебру над nullable-типами. В SQL ровно та же логика, что у Лукасевича. В рамках чисто-логических выражений всё хорошо, т.к. нет никакой "другой неизвестности". А вот попытка натянуть ту же сову на глобус произвольных типов приведёт к неприятным парадоксам. 
