S>Вероятности нахождения страниц в кэше крайне плохо поддаются предсказанию — как я уже сказал, там есть очень много факторов, которые вы так просто не учтёте.
в данном случае, необходимо предсказать другую величину, а именно отношение вероятностей нахождения в кэше страниц кластерного индекса и вероятность нахождения в кэше страниц некластерного индекса.
соответственно, можно считать, что все остальные факторы взаимоуничтожаются
DG>>так в том-то и дело, что полем при этом будет являться произвольная штука, которая обладает данными требованиями. S>Правильно. Ну так вам и твердят: объектом называется сущность, которая обладает идентичностью, поведением, и состоянием. А вы зачем-то начинаете мучить мозг и спрашивать, почему нельзя называть объектом то, что этим требованиям не удовлетворяет.
ты пропустил несколько важных моментов:
во-первых, с точки зрения математики, если чего-то не хватает, то это можно доопределить.
например, функция x2/x не является ни гладкой, ни непрерывной на всем интервале, но можно доопределить ей в точке 0 значение и производную, и она станет гладкой и непрерывной на всем интервале
во-вторых, с точки зрения математике, если, например, всё множество полем не является, то можно рассмотреть отдельные подмножества, которые являются полями, а потом на основе этого сделать вывод на основе всего множества.
отсюда и появляется, что если что-то не является объектом на на всём множестве операций, это можно рассмотреть на отдельных множествах операций когда это что-то является объектом, а потом сделать выводы и для что-то целиком.
Здравствуйте, DarkGray, Вы писали:
DG>во-первых, с точки зрения математики, если чего-то не хватает, то это можно доопределить.
Это всё понятно. Но вы хотите не "доопределить", а "недоопределить". То есть начинаете с функции y=1, а потом убираете у неё в несчётном множестве точек значение и производную, а потом удивляетесь, что её не хотят признавать гладкой и непрерывной. DG>во-вторых, с точки зрения математике, если, например, всё множество полем не является, то можно рассмотреть отдельные подмножества, которые являются полями, а потом на основе этого сделать вывод на основе всего множества.
Это интересно как? То есть мы берём, скажем, подмножество дифференцируемых интегрируемых функций, доказываем для него что-нибудь, а потом говорим "а, ну наверное всё то же приложимо и ко множеству вообще всех функций", так что ли? Весьма неожиданный ход.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Это интересно как? То есть мы берём, скажем, подмножество дифференцируемых интегрируемых функций, доказываем для него что-нибудь, а потом говорим "а, ну наверное всё то же приложимо и ко множеству вообще всех функций", так что ли? Весьма неожиданный ход.
берем множество, разбиваем его на подмножества — для каждого подмножества доказываем следствие своим способом, и в результате делаем вывод, что все множество имеет данное следствие.
из этого в частности следует, что множество не обязано быть однородным, чтобы иметь то или иное следствие.
а из этого следует, что программа может быть ООП-программой, даже если объекты в ней выделяются разными способами, и используются различные функции идентичности для различных объектов (если при этом ее можно достроить под требования ООП).
DG>>норма — это "усредненние" ожиданий членов группы, и здесь еще добавляется неопределенность от того, что можно взять разный способ "усреднения", а так же можно по разному брать группу, и соответственно норма имеет более высокую неопределенность, чем ожидание S>Ожидание члена группы — без указания конкретного индивидума еще более неопределено чем усреднение ожиданий членов группы, т.е. норма.
больше всего определенности в конкретных произошедших фактах, и соответственно самые определенные — это ожидания конкретного индивидуума в конкретной ситуации.
Здравствуйте, DarkGray, Вы писали:
DG>во-первых, с точки зрения математики, если чего-то не хватает, то это можно доопределить.
Как Хоттабыч доопределил мячей по числу футболистов?
DG>например, функция x2/x не является ни гладкой, ни непрерывной на всем интервале, но можно доопределить ей в точке 0 значение и производную, и она станет гладкой и непрерывной на всем интервале
Не понял, о какой функции идет речь. Но с точки зрения матемтики, если ты доопределил функцию, то ты получил доопределенную функцию, высказывания на счет которой не распространяются на исходную функцию в общем случае.
DG>во-вторых, с точки зрения математике, если, например, всё множество полем не является, то можно рассмотреть отдельные подмножества, которые являются полями, а потом на основе этого сделать вывод на основе всего множества.
Не понял. Множество полем не является, но существуют подмножества, являющиеся полями, причем объединение подмножеств является исходным множеством? Можно пример?
DG>отсюда и появляется, что если что-то не является объектом на на всём множестве операций, это можно рассмотреть на отдельных множествах операций когда это что-то является объектом, а потом сделать выводы и для что-то целиком.
Если что-то не обладает неким свойством на некотором множестве, то значит существуют элементы множества, на которых это что-то не обладает неким свойством. Пардон за тавтологию. Но что бы ты не рассматривал, это что-то на таких элементах обладать данным свойством не станет.
DG>>например, функция x2/x не является ни гладкой, ни непрерывной на всем интервале, но можно доопределить ей в точке 0 значение и производную, и она станет гладкой и непрерывной на всем интервале S>Не понял, о какой функции идет речь. Но с точки зрения матемтики, если ты доопределил функцию, то ты получил доопределенную функцию, высказывания на счет которой не распространяются на исходную функцию в общем случае.
так высказывания про исходную функцию при решении конкретной задаче часто никому и не нужны.
DG>>во-вторых, с точки зрения математике, если, например, всё множество полем не является, то можно рассмотреть отдельные подмножества, которые являются полями, а потом на основе этого сделать вывод на основе всего множества. S>Не понял. Множество полем не является, но существуют подмножества, являющиеся полями, причем объединение подмножеств является исходным множеством? Можно пример?
я говорил о конкретном выводе: например, что для всего множества сохраняется закон дистрибутивности.
DG>>отсюда и появляется, что если что-то не является объектом на на всём множестве операций, это можно рассмотреть на отдельных множествах операций когда это что-то является объектом, а потом сделать выводы и для что-то целиком. S>Если что-то не обладает неким свойством на некотором множестве, то значит существуют элементы множества, на которых это что-то не обладает неким свойством. Пардон за тавтологию. Но что бы ты не рассматривал, это что-то на таких элементах обладать данным свойством не станет.
ты сейчас это рассматриваешь с точки зрения логики существования, а не с точки зрения конструирования.
если нам дано сложное множество, то изначально мы не знаем существует или нет для него следствие, и это знание появится только в результате конструирования доказательства (при котором множество и разбивается на подмножества про которые известно: существует или нет следствие)
тоже самое и с программой: глядя на сложную программу мы не можем, глядя в потолок, сделать конкретный вывод: программа является или не является ООП-программой, сначала необходимо сконструировать доказательство, которое покажет, что это программа ООП или не ООП. при этом если мы не можем построить способ рассмотрения данной программы как ООП-программы, из этого не следует, что никто не может. поэтому я часто и делаю замечание Sinclair-у, что он делает слишком поспешные негативные выводы (которые неверны с точки зрения конструктивной логики).
S>Вместо этого будет достаточно эквивалентности, определённой как совпадение состояний.
как это можно использовать, например, при показе того, почему следующий код неверный?
//суммирует квадраты чисел по всей последовательности
function double SquareSum(IEnumerable<double> numbers)
{
var lazyNumbers = new List<Func<double>>();
foreach (var x in numbers)
lazyNumbers = ()=> x*x;
return lazyNumbers.Sum(lazy => lazy());
}
вызов SquareSum(new[]{1, 2}) выдает 8 (хотя должен выдавать 5)
ps
через использование идентичности и трасс можно показать, почему этот код неверный.
DG>>>например, функция x2/x не является ни гладкой, ни непрерывной на всем интервале, но можно доопределить ей в точке 0 значение и производную, и она станет гладкой и непрерывной на всем интервале S>>Не понял, о какой функции идет речь. Но с точки зрения матемтики, если ты доопределил функцию, то ты получил доопределенную функцию, высказывания на счет которой не распространяются на исходную функцию в общем случае.
DG>так высказывания про исходную функцию при решении конкретной задаче часто никому и не нужны.
Но ты их совершил. См. выделенное.
Или тут у тебя тот же фокус, что с сохранением идентичности строк при сложении?
DG>>>во-вторых, с точки зрения математике, если, например, всё множество полем не является, то можно рассмотреть отдельные подмножества, которые являются полями, а потом на основе этого сделать вывод на основе всего множества. S>>Не понял. Множество полем не является, но существуют подмножества, являющиеся полями, причем объединение подмножеств является исходным множеством? Можно пример?
DG>я говорил о конкретном выводе: например, что для всего множества сохраняется закон дистрибутивности.
согласен на конкретный пример дистрибутивного множества, не являющегося полем, но содержащим поля в качестве подмножеств. Так что дистрибутивность множества вытекает из дистрибутивности его подмножеств полей.
DG>>>отсюда и появляется, что если что-то не является объектом на на всём множестве операций, это можно рассмотреть на отдельных множествах операций когда это что-то является объектом, а потом сделать выводы и для что-то целиком. S>>Если что-то не обладает неким свойством на некотором множестве, то значит существуют элементы множества, на которых это что-то не обладает неким свойством. Пардон за тавтологию. Но что бы ты не рассматривал, это что-то на таких элементах обладать данным свойством не станет.
DG>ты сейчас это рассматриваешь с точки зрения логики существования, а не с точки зрения конструирования. DG>если нам дано сложное множество, то изначально мы не знаем существует или нет для него следствие, и это знание появится только в результате конструирования доказательства (при котором множество и разбивается на подмножества про которые известно: существует или нет следствие)
Ты же написал что что-то не является объектом на всем множестве операций. Это не вопрос. Это утверждение. Т.е. ты не исследуешь эту ситуацию, для тебя это свершившийся факт. Но путем разбиения всего множества на какие-то части ты этот факт выворачиваешь. Вот это мне странно.
DG>тоже самое и с программой: глядя на сложную программу мы не можем, глядя в потолок, сделать конкретный вывод: программа является или не является ООП-программой, сначала необходимо сконструировать доказательство, которое покажет, что это программа ООП или не ООП. при этом если мы не можем построить способ рассмотрения данной программы как ООП-программы, из этого не следует, что никто не может. поэтому я часто и делаю замечание Sinclair-у, что он делает слишком поспешные негативные выводы (которые неверны с точки зрения конструктивной логики).
Мне неизвестны формальные критерии принадлежности конкретной программы к ООП. Но известно что ты пока не смог предоставить непротиворечивую идентичность для того что бы рассматривать строки "с версионной иммутабельностью" и переменные как объекты.
DG>>я говорил о конкретном выводе: например, что для всего множества сохраняется закон дистрибутивности. S>согласен на конкретный пример дистрибутивного множества, не являющегося полем, но содержащим поля в качестве подмножеств. Так что дистрибутивность множества вытекает из дистрибутивности его подмножеств полей.
возьмем множество состоящее из множества рациональных чисел и спец. элемента inf; элемент такого множества будет называть ri
определим операцию + как:
+ для рациональных чисел такой же как + для исходного множества рациональных чисел
+ (inf, inf) = inf
+ (рац. числа, inf) и (inf, рац. числа) = inf
операцию * как:
* для рациональных чисел такой же как * для исходного множества рациональных чисел
* (inf, inf) = inf
* (рац. числа, inf) и (inf, рац. числа) = inf
докажем, что операции +/* дистрибутивны для всего множества [рац. числа; inf]:
op есть операция из множества [+,*]
следствие 1: op(ri, inf) = op(inf, ri) = inf
следствие 2: op(ri, inf) — коммутативна и ассоциативна из следствия 1
следствие 3:операции +,* коммутативны и ассоциативны для любой пары (ri, ri), т.к. пара (рац. число, рац. число) — коммутативная и ассоциативная из-за того, что рац. числа — поле, а остальные три пары представимы как (ri, inf) и коммутативны и ассоциативны на основе следствия 2
тройка (ri, ri, ri) дистрибутивна относительно операций +/-, потому что:
(рац. число, рац. число, рац. число) дистрибутивна, потому что рац. числа — поле
(inf, ri1, ri2) — дистрибутивна, потому что inf*(ri1 + ri2) = inf*(ri') = inf, а inf*ri1 + inf*ri2 = inf+inf = inf
(ri1, inf, ri2) дистрибутивна, потому что ri1*(inf + ri2) = ri1 *inf = inf, а ri1*inf + ri1*ri2 = inf + ri' = inf
(ri1, ri2, inf) дистрибутивна, потому что дистрибутивна (ri1, inf, ri2), а операция + коммутативна
дистрибутивность справа вытекает на основании следствия 3
DG>>ты сейчас это рассматриваешь с точки зрения логики существования, а не с точки зрения конструирования. DG>>если нам дано сложное множество, то изначально мы не знаем существует или нет для него следствие, и это знание появится только в результате конструирования доказательства (при котором множество и разбивается на подмножества про которые известно: существует или нет следствие) S>Ты же написал что что-то не является объектом на всем множестве операций. Это не вопрос. Это утверждение. Т.е. ты не исследуешь эту ситуацию, для тебя это свершившийся факт. Но путем разбиения всего множества на какие-то части ты этот факт выворачиваешь. Вот это мне странно.
при конструировании сложных вещей появляются куча элементов, которые почти такие же как исходные, но имеют какие-то добавочные свойства. при строгих выводах эти все добавочные элементы необходимо обозначать другими символами, но мне не хочется это делать на форуме из-за громоздкости.
DG>>тоже самое и с программой: глядя на сложную программу мы не можем, глядя в потолок, сделать конкретный вывод: программа является или не является ООП-программой, сначала необходимо сконструировать доказательство, которое покажет, что это программа ООП или не ООП. при этом если мы не можем построить способ рассмотрения данной программы как ООП-программы, из этого не следует, что никто не может. поэтому я часто и делаю замечание Sinclair-у, что он делает слишком поспешные негативные выводы (которые неверны с точки зрения конструктивной логики). S>Мне неизвестны формальные критерии принадлежности конкретной программы к ООП. Но известно что ты пока не смог предоставить непротиворечивую идентичность для того что бы рассматривать строки "с версионной иммутабельностью" и переменные как объекты.
есть множество [строки, другие объекты]:
функция идентичности для данного множества
для [строка, строка] = equals(строка, строка)
для [строка, другой объект] = false
для [другой объект, другой объект] = referenceequals(другой объект, другой объект)
S>Это всё понятно. Но вы хотите не "доопределить", а "недоопределить". То есть начинаете с функции y=1, а потом убираете у неё в несчётном множестве точек значение и производную, а потом удивляетесь, что её не хотят признавать гладкой и непрерывной.
так если в конкретной задаче эти точки не используются, то можно на этих точках функцию доопределить как угодно.
и соответственно, возникает меньшая проблема: можно ли решить конкретную задачу без использования этих точек?
если можно, то значит для данной конкретной задачи можно считать, что функция y=1 с дырками гладкая и непрерывная на всем интервале в данной задаче.
тоже самое и с идентичностью:
если в программе нигде не используется являются ли объекты x,y идентичными или нет, то нет и необходимости, чтобы функция идентичности была определена на этой паре, т.к. всегда можно для этой пары доопределить функцию идентичности как хочется, все равно это ни на что не повлияет.
DG>>>я говорил о конкретном выводе: например, что для всего множества сохраняется закон дистрибутивности. S>>согласен на конкретный пример дистрибутивного множества, не являющегося полем, но содержащим поля в качестве подмножеств. Так что дистрибутивность множества вытекает из дистрибутивности его подмножеств полей.
DG>возьмем множество состоящее из множества рациональных чисел и спец. элемента inf; элемент такого множества будет называть ri DG>определим операцию + как: DG> + для рациональных чисел такой же как + для исходного множества рациональных чисел DG> + (inf, inf) = inf DG> + (рац. числа, inf) и (inf, рац. числа) = inf DG>операцию * как: DG> * для рациональных чисел такой же как * для исходного множества рациональных чисел DG> * (inf, inf) = inf DG> * (рац. числа, inf) и (inf, рац. числа) = inf DG>докажем, что операции +/* дистрибутивны для всего множества [рац. числа; inf]: DG>op есть операция из множества [+,*] DG>следствие 1: op(ri, inf) = op(inf, ri) = inf DG>следствие 2: op(ri, inf) — коммутативна и ассоциативна из следствия 1 DG>следствие 3:операции +,* коммутативны и ассоциативны для любой пары (ri, ri), т.к. пара (рац. число, рац. число) — коммутативная и ассоциативная из-за того, что рац. числа — поле, а остальные три пары представимы как (ri, inf) и коммутативны и ассоциативны на основе следствия 2 DG>тройка (ri, ri, ri) дистрибутивна относительно операций +/-, потому что: DG>(рац. число, рац. число, рац. число) дистрибутивна, потому что рац. числа — поле DG>(inf, ri1, ri2) — дистрибутивна, потому что inf*(ri1 + ri2) = inf*(ri') = inf, а inf*ri1 + inf*ri2 = inf+inf = inf DG>(ri1, inf, ri2) дистрибутивна, потому что ri1*(inf + ri2) = ri1 *inf = inf, а ri1*inf + ri1*ri2 = inf + ri' = inf DG>(ri1, ri2, inf) дистрибутивна, потому что дистрибутивна (ri1, inf, ri2), а операция + коммутативна DG>дистрибутивность справа вытекает на основании следствия 3
Схема доказательства дистрибутивности отличается от обозначенной тобой ранее
DG>во-вторых, с точки зрения математике, если, например, всё множество полем не является, то можно рассмотреть отдельные подмножества, которые являются полями, а потом на основе этого сделать вывод на основе всего множества.
Одно подмножество поле я вижу. Назови подмножество-поле, содержащее inf.
S>>Ты же написал что что-то не является объектом на всем множестве операций. Это не вопрос. Это утверждение. Т.е. ты не исследуешь эту ситуацию, для тебя это свершившийся факт. Но путем разбиения всего множества на какие-то части ты этот факт выворачиваешь. Вот это мне странно.
DG>при конструировании сложных вещей появляются куча элементов, которые почти такие же как исходные, но имеют какие-то добавочные свойства. при строгих выводах эти все добавочные элементы необходимо обозначать другими символами, но мне не хочется это делать на форуме из-за громоздкости.
Т.е. ты под символами (да и словами) подразумеваешь что-то свое, а другие на форуме об этом должны догадаться?
S>>Мне неизвестны формальные критерии принадлежности конкретной программы к ООП. Но известно что ты пока не смог предоставить непротиворечивую идентичность для того что бы рассматривать строки "с версионной иммутабельностью" и переменные как объекты.
DG>есть множество [строки, другие объекты]: DG>функция идентичности для данного множества DG> для [строка, строка] = equals(строка, строка) DG> для [строка, другой объект] = false DG> для [другой объект, другой объект] = referenceequals(другой объект, другой объект)
Такая функция идентичности не обсуждалась в этом топике. Вместо этого были определения об идентичности равнозначных строк + строк из "одной трассы операции сложения". Как я понял, именно те определения ты выдавал за идентичность с версионной иммутабельностью.
S>Одно подмножество поле я вижу. Назови подмножество-поле, содержащее inf.
скажи сколько полей тебе нужно.
вот тебе два поля:
возмем множество пар (kind,value) где каждая пара есть (c, комплексное-число) или (r, рациональное число)
с операциями + * следующего вида (обозначим операцию как op):
(c, c-number) op (с, c-number) = (c, c-number + c-number)
(r, r-number) op (r, r-number) = (r, r-number + r-number)
(c, c-number) op (r, r-number) = (r, r-number) op (c, c-number) = (c, c-number)
докажем, что операции + * дистрибутивны для всего множества:
дистрибутивность для троек вида(c, c-number) следует из того, что комплексные числа — поле
дистрибутивность для троек вида(r, r-number) следует из того, что рациональные числа — поле
дистрибутивность для оставшихся троек доказывается аналогично, как для предыдущего множества [числа;inf]
DG>>при конструировании сложных вещей появляются куча элементов, которые почти такие же как исходные, но имеют какие-то добавочные свойства. при строгих выводах эти все добавочные элементы необходимо обозначать другими символами, но мне не хочется это делать на форуме из-за громоздкости. S>Т.е. ты под символами (да и словами) подразумеваешь что-то свое, а другие на форуме об этом должны догадаться?
я опускаю очевидные выкладки, в частности то, что после каждого шага конструирования при котором были порождены Ex', которые есть Ex+свойства, происходит переопределение символов как: Ex = Ex'
S>>>Мне неизвестны формальные критерии принадлежности конкретной программы к ООП. Но известно что ты пока не смог предоставить непротиворечивую идентичность для того что бы рассматривать строки "с версионной иммутабельностью" и переменные как объекты.
DG>>есть множество [строки, другие объекты]: DG>>функция идентичности для данного множества DG>> для [строка, строка] = equals(строка, строка) DG>> для [строка, другой объект] = false DG>> для [другой объект, другой объект] = referenceequals(другой объект, другой объект)
S>Такая функция идентичности не обсуждалась в этом топике.
S>Схема доказательства дистрибутивности отличается от обозначенной тобой ранее
схема всё та же. при доказательстве рассматривается множество троек, а не просто множество исходных элементов.
соответственно из этого множества троек выделяются подмножества, которые дистрибутивны из-за того, что в них используются элементы из одного поля, а дальше остается рассмотреть только спец. тройки и доказать дистрибутивность для них каким-либо способом.
Здравствуйте, DarkGray, Вы писали:
S>>Одно подмножество поле я вижу. Назови подмножество-поле, содержащее inf.
DG>скажи сколько полей тебе нужно. DG>вот тебе два поля: DG>возмем множество пар (kind,value) где каждая пара есть (c, комплексное-число) или (r, рациональное число) DG>с операциями + * следующего вида (обозначим операцию как op):
вопрос снят, зачет.
DG>>>при конструировании сложных вещей появляются куча элементов, которые почти такие же как исходные, но имеют какие-то добавочные свойства. при строгих выводах эти все добавочные элементы необходимо обозначать другими символами, но мне не хочется это делать на форуме из-за громоздкости. S>>Т.е. ты под символами (да и словами) подразумеваешь что-то свое, а другие на форуме об этом должны догадаться?
DG>я опускаю очевидные выкладки, в частности то, что после каждого шага конструирования при котором были порождены Ex', которые есть Ex+свойства, происходит переопределение символов как: Ex = Ex'
И все выглядит так, будто ты что-то утверждаешь относительно исходного Ex. Подмена сивмолов не очевидная выкладка.
DG>>>есть множество [строки, другие объекты]: DG>>>функция идентичности для данного множества DG>>> для [строка, строка] = equals(строка, строка) DG>>> для [строка, другой объект] = false DG>>> для [другой объект, другой объект] = referenceequals(другой объект, другой объект)
S>>Такая функция идентичности не обсуждалась в этом топике.
DG>так такая функция тебя устраивает?
Такую я сам предлагал не далее чем осенью в этом форуме. Но я не делал сильных утверждений что только такой идентичностью можно достичь чего-то, что она имеет практический смысл.
S> Но я не делал сильных утверждений что только такой идентичностью можно достичь чего-то, что она имеет практический смысл.
такая формулировка означает, что есть какое-то смутное доп. требование к функции идентичности, выполнение которого необходимо для того, что функция идентичности имела смысл.
S>> Но известно что ты пока не смог предоставить непротиворечивую идентичность для того что бы рассматривать строки "с версионной иммутабельностью" и переменные как объекты.
есть множество [строки, другие объекты]:
функция идентичности для данного множества
для [строка, другой объект] = false
для [другой объект, другой объект] = referenceequals(другой объект, другой объект)
для [строка, строка] =
программа разбивается на отдельные кодовые операции, из кодовых операции выделяются подмножество кодовых типизированные операции вида строка op(строка, ..), для которых специфицировано, что op не меняет identity. для данных случаев считается, что строка на входе и строка на выходе это один и тот же объект (true). последовательность таких операций назовем трассой.
если два объекта не входят в одну трассу, то они считаются разными(false).
Здравствуйте, gandjustas, Вы писали:
V>>Тем не менее, для коммутативных операций это так. G>Тоже неверно. Представим коммутативную операцию a ~ b = b ~ a = 1. То есть всегда возвращающую одно значение. Для нее требуется вычислять аргументы? Вообще-то нет.
А как мы ее представим в SQL или РА?
G>Представим другую, некоммутативную операцию, a | b = not a. Для вычисления требуется вычислять аргументы? Тоже нет.
Ну.. сочинять несуществующие алгебры можно хоть до посинения. В любом случае, коль семантика операции известна (ты же настаиваешь, что вычислять аргументы не надо, т.е. мы знаем об этом), кто мешает привести ее к правой (канонической) части, и затем отбросить все эти рассуждения за ненадобностью?
G>Вообще если принять нормальный порядок вычислений, а не аппликативный, то порядок вычислений с порядком композиции почти никак не зависят друг от друга.
Это для независимых аргументов так. Дык, случай независимых аргументов априори не может вызвать разногласий, тут спорить нечего.
G>Так как нормальный порядок вычислений всегда дает результат если это возможно, то его можно принять за умолчание в любой выичслительной теории если явно не указано обратное. G>И в РА кажись не предполагается энергичный порядок.
Если у нас идут в выражении постоянные проекции и переименования, то даже для ленивого порядка вычислений необходимо будет сделать всю "линкову" всех проекций атрибутов и их переименований ДО начала вычислений, причем именно таким образом, как если бы эти значения распространялись в случае энергичного вычисления. Но и это не важно. Ленивость по природе своей не влияет на порядок вычислений атрибутов внутри кортежа, а влияет только на порядок получения всех кортежей относительно промежуточных результатов. Т.е. даже если кортежи вычисляются не все сразу, а по 1-му, всё равно ленивый порядок вычисления каждого атрибута кортежа будет соответствовать исходной формуле.
Здравствуйте, Sinclair, Вы писали:
V>>Уже показал на примере Cross production selection, где аналитический вид ф-ии ограничения считается известным, поэтому всё преобразование свелось к декомпозиции самой ф-ии ограничения и применения разных ее частей на разных этапах. Так вот, РА не занимается исследованием декомпозиций аналитических ф-ий, поэтому, хоть и показаны преобразования формул РА, это происходит не на уровне РА, а над ним. S>Ну то есть мы начинаем постепенно понимать, что оптимизатор запросов в СУБД работает не на уровне РА. Это хорошо.
Опять спор с самим собой. Речь была о том, применим ли аппарат РА на уровне таблицы, когда мы выбираем какой индекс можно использовать. Я утверждал, что применим, если рассматривать индексы как декомпозицию (а их так и рассматривают). Т.е. можно составить варианты исполнения в терминах РА и уже на этом уровне оценить затраты.
V>>Это как раз случай явной выразимости одних операций через другие, т.е. таких, где не требуется знание аналитического вида формул. S>Каких одних через какие другие?
Например, вариант 2 в твоей ссылке: последовательность операций ограничений можно выразить через одну операцию ограничения, соединив по AND критерии.
Вообще, спор насчет порядка операций — это малость в бок. Это невладение проблематикой. Я так нутром чую, что ты имел нечто вроде примера Selection and cross product, где если рассматривать формулу слева направо, то вроде как какие-то оптимизации есть... Однако возьми составлять некую формулу РА по заданному критерию результата, и у тебя сразу будет получаться формула в правой части. Потому что это естественно — применить предварительно ограничения к тому отношению, которое владеет требуемыми атрибутами, а уже к самой продукции применить лишь те ограничения, которые зависят одновременно от атрибутов исходных отношений.
Ноги нашего спора растут из-за различного понимания проблематики составления алгоритмов исполнения запросов. Уровень РА — это алгоритмический уровень, именно так запросы раскладывают на примитивные операции (я помню про твое добавления про 2 уровня планирования в MS SQL, по мне хоть 10, это итерации получения конечного решения). Ес-но, само РА — некий абстрактный уровень, бо вид конкретных контейнеров и способ реализации операций не оговаривается. Но сам аппарат предоставляет терминологию примитивных операций и даже кое-какие преобразования по ним. Почему я настаиваю, что РА как раз применим на уровне таблица->индексы. Потому что в классике проблематика стоит так: есть некий критерий результата, т.е. формула в терминах РИ, описывающая результат выборки из некоей схемы. Мы, зная ВСЮ декомпозицию схемы, составляем всевозможные варианты в терминах РА, которые удовлетворяют этому запросу. Вот на что натаскивают студентов по этим предметам. Однако, в реальных СУБД автоматически это невозможно, т.к. если у нас есть специальная избыточность и прикладные зависимости м/у атрибутами — то СУБД об этом никак не в курсе, она понятия не имеет о соотношении исходной прикладной схемы и декомпозированной — в виде реальных таблиц. В этом смысле ей сложновато составить действительно все варианты, удовлетворяющие прикладному запросу, поэтому в SQL мы явно указываем таблицы, из которых происходит выборка. И единственный уровень, который ей доступен — это декомпозиция таблиц и их индексов. Вот здесь уже можно составить ВСЕ варианты в терминах РА (или расширенной РА) вокруг одной таблицы и её индексов, провести оптимизацию (коль используются не внешние ф-ии, а ограничения, заданные в аналитическом виде в запросе) и затем применить оценку сложности каждого из вариантов, исходя из вида доступа, физического размера данных, статистики по индексам и т.д.
Выражения реляционной алгебры строятся на основе алгебраических операций (высокого уровня), и подобно тому, как интерпретируются арифметические и логические выражения, выражение реляционной алгебры также имеет процедурную интерпретацию. Другими словами, запрос, представленный на языке реляционной алгебры, может быть вычислен на основе вычисления элементарных алгебраических операций с учетом их старшинства и возможного наличия скобок. Для формулы реляционного исчисления однозначная интерпретация, вообще говоря, отсутствует. Формула только устанавливает условия, которым должны удовлетворять кортежи результирующего отношения. Поэтому языки реляционного исчисления являются более непроцедурными или декларативными.
V>>К тому же, про этот случай сказал в предыдущем сообщении, и его физический смыл был раскрыт в следующих строчках по твоей же ссылке: V>> V>>Операция AND в условиях выборки коммутативна, поэтому да. Даи это было лишнее для аргументации. Ведь часть операций РА, которые являются теоретико-множественными, коммутативны сами по себе, поэтому можно было просто привести вот так еще в самом начале: V>>A AND (B AND C) = (A AND B) AND C. V>>A OR (B OR C) = (A OR B) OR C. V>>Где A,B,C — совместимые отношения. Сразу бы и отделили коммутативные от некоммутативных, чтобы не обобщать огульно. S>Вы путаете коммутативность с ассоциативностью.
Коль речь была про порядок вычислений, то и то и другое неплохой пример.
A AND (B AND C) = (B AND C) AND A
И вообще, мне сложно вспомнить операцию, которая коммутативна и не ассоциативна при этом, всегда считал, что из одного следует другое. Обратное явно неверно.
V>>Нет, не поэтому, а исключительно из-за коммутативности. Аналогично вычислениям над обычными числами даже в императивной программе, часть вычислений можно проводить в произвольном порядке, если речь идет о коммутативных равноприоритетных операцих. S>Вы ошибаетесь. Возьмём, к примеру, коммутативную операцию над обычными числами: S>
S>int i = GetA()*GetB();
S>
S>Если у GetA() или GetB() есть побочный эффект, то перестановка порядка вычислений запрещена. Несмотря на коммутативность умножения.
Я не ошибаюсь. В С/С++ компилятор имеет право сгенерить произвольный порядок вычисления твоей формулы, а за побочными эффектами пусть следит программист. Порядок вычисления аргументов задан только для операций: || , &&. Любопытно, C# гарантирует порядок вычисления аргументов операций и методов? Вроде тоже нет.
V>>РА не занимается семантикой, это делается на уровне РИ и реляционной модели. Т.е., чтобы провести все те преобразования формул РА, помимо заведомо коммутативных преобразований (т.е. безусловным образом выразимых через друг друга), S>Алиса, никогда не употребляй слова только за то, что они длинные и красивые. Погуглите определение термина "коммутативность".
Хм, уже потерял нить беседы? Сорри, оперативно отвечать не имею возможности...
Это было на твой же пример:
Он верен из-за коммутативности операции AND:
V>>Возможно, хотя может сделать его процедурным, если мы не используем первоклассные ф-ии, не? S>Не, не может.
Т.е. в отсутствии первоклассных ф-ий всё равно функциональный подход? Хорошо себя чувствуешь?
V>>А процедурный подход относится к императивному или нет? Мне таки интересно твое развернутое мнение. Таки машина Тьюринга описана как автомат с ленточной памятью. S>А частично рекурсивные функции — нет. Дальше что?
А уже можно составить SQL-выражение, эквивалентное частично-рекурсивной ф-ии?
Давай определимся с твоим высказыванием сначала, что мой пример не делает функциональный подход императивным. Я предупреждал, что тема иммутабельности — скользкая. Мне любопытны аргументы.
V>>Ну коль для кластерного индекса строится точно такое же дерево на уровне неличтовых страниц, то чем он отличается от некластерного, когда на странице будет всего одна запись? S>Тем, что для некластерного таки будет создана отдельная страница. Вы не стесняйтесь, читайте литературу.
Когда на странице одна запись, то вроде не важно. Кластерный индекс всегда будет указывать не на диапазон, а на одну запись, как и некластерный.
V>>Насчет порядка: если некая соединительная операция из 3-х (грубо) составляющий выполняется в 4 раза быстрее, что каждая в среднем стала выполняться быстрее в корень 3-й степени из 4. S>Простите, но зачем вы продолжаете это делать? Времена выполнения операции Join очень косвенно связаны с произведением кардинальностей аргументов. S>Например, merge join вообще выполняется как O(N+M).
Ну это если одна таблица хранится сортированной под внешнему ключу, а другая по первичному. А если это не так и обе сильно не влазят в память, то формула будет малость посложнее. А если происходит join по какой-либо формуле, которой нет в виде индекса, то ближе к O(N*M). (Интересно, умеет ли MS SQL решать уравнения, чтобы привести join по формуле к O(log(N) + log(M) + N + M)?)
V>>Для удобства в MS Access после проверки этого выражения проверь вот это: V>>SELECT (TRUE AND (5 > NULL)) IS NULL S>Ок, я понял. Ваш опыт, которым вы так гордитесь, получен в основном на настольной СУБД.
Ух, лихо. Т.е. движок базы данных и офисное приложение — это уже одно и то же?
Как ответный реверанс — я вижу ограниченность/замкнутость на MS SQL. А у себя не помню ни одного проекта, где бы делали только под MS SQL. Мимимум под 3 базы обычно, где MS SQL — одна из них. Наиболее весело, когда одновременно под MS SQL и под Oracle.
V>>Это я про то, что порядок и вид выражений РА вовсе не обязан соответствовать "естественному" порядку исходного SQL. И еще про то, что SQL крайне избыточен, позволяя задавать одни и те же запросы очень многими способами. Так вот, из приведения всех вариантов запросов к одному (для данного случая) варианту в терминах РА следует, что вид операций РА слабо связан с видом выражения в SQL. S>Ок, хорошо, разница между РА и SQL становится всё более явной.
Дык, что разница есть — это говорилось. Так же как и то, что местами разницы нет. Например здесь: select * from X where X.x1 = 42. Для этого выражения есть только одно отображение в РА, поэтому и говорят, что в SQL присутствуют элементы РА, коль некоторые выражения будут взаимно-однозначны. Например на уровне РИ нет * from X, т.к. конкретная декомпозиция схемы не важна. Так же присутствуют элементы РИ, т.к. вид многих выражений задает не столько алгоритм запроса, сколько характеристики результата.
основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных БД: язык называется реляционным, если он обладает не меньшей выразительностью и мощностью, чем реляционная алгебра или реляционное исчисление.
Не меньшей! А тебя смущает, что SQL обладает бОльшей выразительностью. Дык, пусть себе...
Конкретный язык манипулирования реляционными БД называется реляционно полным, если любой запрос, выражаемый с помощью одного выражения реляционной алгебры или одной формулы реляционного исчисления, может быть выражен с помощью одного оператора этого языка.
SQL реляционно-полон, разумеется. Любое выражение РА можно выразить через один оператор select (верхнего уровня).
V>>До сегодняшнего дня да, коль (x-y)==-(y-x). V>>Но у тебя ошибка в коде, нет учета переполнения. S>Воот. Эта ошибка связана с тем, что код предполагает такую же математику в компьютере, как и в учебнике. В учебнике у всех целых чисел есть их "антипод", -x = -1*x. S>А в компьютере — не у всех, разрядность ограничена. S>И можно действовать двумя способами: S>а) привести задачу к "условиям теории", чтобы можно было использовать весь теоретический аппарат S>б) привести решение к "специфике реализации", чтобы использовать тот аппарат, который есть на практике. S>В первом варианте мы начинаем требовать от компьютера поддержки целых чисел произвольной разрядности; во втором — подпиливаем код так, чтобы он корректно работал с учётом ограничений, несмотря на то, что он выглядит не как "теоретическое" решение. S>Вы пошли по второму варианту. S>Но для реляционной модели и SQL вы продолжаете настаивать на первом варианте.
Я понял рассуждения, но это рассуждения по аналогии. Например std::set прекрасно может обслужить задачи алгебры множеств в кач-ве контейнера, коль мн-ва будут заведомо конечны и влезут в память (пусть виртуальную). Т.е. я бы хотел таки услышать аргумент конкретно по РА. Бо в реальности мы тоже работаем с конечными мн-вами, и обратное не предполагается даже теорией РА, поэтому аналогия с конечностью разрядов малость хромает. Тем более, что все преобразования РА (по моему ИМХО) остаются валидны даже для повторяющихся записей, т.е. даже в случае некоторого выхода за реляционную модель.
ИМХО, уникальность записей нужна для уровня реляционного исчисления, которое оперирует отношениями и зависимостями м/у атрибутами, из-за этого дубликаты кортежей не имеют никакого физического смысла. Но уровень РА — это просто уровень операций над множествами, и на этом уровне физический смысл элементов этих множеств уже глубоко до фени. К тому же, сложно придумать такое представление кортежей в программе, чтобы экземпляры этих кортежей были неразличимы в адресации. А для использования наработок теории мн-в достаточно св-ва различимости элементов.
S>Мускул, простите, не показатель. В нём вообще много чего ещё нет. А встраиваемые и настольные базы данных я предлагаю не рассматривать — они не для промышленного применения, поэтому в них все новшества появляются с большим опозданием.
Когда речь идет о сценариях фактически read-only (крайне редкое обновление), и сами данные вменяемых размеров, то встраиваемые движки идут для "промышленного применения" аж бегом. Бо они резвые и эффективные в плане ресурсов. Это примерно как с микропроцессорами: на каждый центральный процессор компьютера есть около десятка суммарно в системнике и всей периферии, и еще больше в окружающих гаджетах... Сама MS использует движок Jet в нескольких приложениях для хранения реляционных данных (хотя файлы зачастую имеют другое расширение, не MDB), а в некоторых других использует MS SQL CE для тех же целей. Именно поэтому мы и делали задачи под разные СУБД, дабы давать возможность масштабирования. И плюс есть такая фишка — не все клиенты согласны на Windows + MS SQL, поэтому приходилось делать и под Oracle, и под остальное юниховое.
V>>Считается, что вокруг реляционных баз таки теория, а не просто инженерия. S>Да это-то я понимаю. Мне было интересно, что именно вы под этим словом понимаете. Потому что вы имеете трогательную привычку использовать термины неожиданным образом.
А при чем тут конкретно "теория реляционных субд"? Разве будет ошибкой относить сюда любые теоретические наработки вокруг СУБД? Характерно, что к ней относят даже языки РИ (коих несколько), которые, вообще-то, могут быть сугубо прикладными, если построить СУБД, удовлетворяющую правилам Кодда.
V>>Первично реализация требований. S>Ну вот видите. А теоретические модели — они появляются потом, когда мы анализируем решения, удовлетворяющие требованиям.
Дык, вся эта теория разрабатывалась в IBM для их DB, и была затем применена при разработке DB-2. Столько денег угрохать на исследования и не применять наработки? Я в это не поверю с т.з. здравого смысла. Да и какой смысл, изучая предмет реляционных СУБД отводить SQL пару последний занятий, зато мучить год реляционным исчислением и алгеброй?
S>>>И с дьявольской предусмотрительностью сделали основой модели SQL мультимножества для того, чтобы сразу же колбасить на SQL-совместимых СУБД постреляционные приложения и дать в полный рост развернуться системам ORM. V>>Для хранения объектов вообще реляционные субд не айс. Просто пользуют из-за надежной реализации транзакций... ИМХО, сугубо исторически. S>Конечно исторически. Просто кроме RDBMS на рынке ничего промышленно-надёжного так и не появилось. Успели выдавить в своё время.
Это я про то, что тема ORM в связке с реляционными СУБД теоретически неинтересна. Объектам не нужны ключи, две коллекции объектов одного типа не означают два разных прикладных отношения и т.д. до бесконечности. Про наследование вообще молчу, каждый извращается в меру своей распущенности. Надо смотреть на пост-реляционные. Попробуйте Postgre. Можно задавать пользовательские составные типы данных, хранить массивы в ячейках таблиц, есть непосредственный доступ к журналу, и прочие плюшки. Считается достаточно надежной, примерно в 10 раз надежней кода BSD.
V>>Неправильно, ты потерял контекст. S>Тогда напишите, как правильно. Когда именно лучше обыгрывать неуникальный ключ дополнительным отношением, вместо банального создания индекса? S>Первоначальная суть индексов — в уменьшении количества обращений к диску. S>Ограничение объёма данных — это один из способов добиться этого уменьшения, причём не самый эффективный.
V>>Есть еще фишка: по таблице кластерный индекс может быть только один, а такие "искусственные" индексы в виде отдельного отношения для прикладных сценариев могут иметь каждый свой кластерный индекс. S>Вы рассматривайте всю картину в целом. Сравните накладные расходы на неуникальный индекс и на "отдельное отношение" — даже если в этом отдельном отношении есть кластерный индекс.
Если неуникальный индекс некластерный, то все-равно в общем случае каждая запись будет доставаться из разных страниц. Сценарий уже был дан: это потребность в полях, помимо входящих в индекс. Тут рассматривать нечего: если записей этого "искусственного" индекса будет больше на каждой странице, то уже выигрыш на чтении есть. Вопрос, конечно, в том, насколько именно, тут зависит от физического размера искуственного индекса по отношению к размеру строки исходной таблицы и от кол-ва самих данных. Тут правильно делали замечание, что кеширование страниц со счетов сбрасывать не стоит, оно влияет оч. сильно на конечный результат. Ну и относительная частота записи-чтения играет роль, т.к. любой лишний индекс, даже искусственный — это лишняя нагрузка при обновлении.
