DG>>>при этом ты утверждаешь, что оператор == для value-типов в .net сравнивает побитово? S>>хм, для predefined — да.
DG>нет, же. конечно. DG>вот тебе два контрпримера. в одном случае битовое представление одинаковое, но == возвращает false. DG>в другом случае — обратное. битовое представление различное, но сравнение одинаковое.
Да, ты прав. (==) не сравнивает побитово. Но с выводами из этого согласиться не могу.
DG>>>а мы здесь чем занимаемся? S>>Путаем объекты с переменными и пытаемся понять, почему это не хорошо.
DG>в ООП нет переменных, поэтому не понятно что с чем путаем
Вот мне тоже не понятно, но есть ощущение, что ты называешь объектом не объект, а то ли переменную, то ли ссылку на объект. С чего у тебя += для строк якобы изменяет объект?
DG>>>и в рамках какой модели это происходит? S>>В рамках указанного бинарного отношения эквивалентности на множестве значений ключа.
DG>а модель где? DG>hint: в модели должны вводится какие-то понятия, допущения, делаться какие-то следствия и выводы.
Я не понимаю, о чем речь. Какие допущения и следствия нужны для работы словаря, кроме свойств отношения эквивалентности, ну и GetHashCode(), соответственно?
DG>>а модель где? DG>>hint: в модели должны вводится какие-то понятия, допущения, делаться какие-то следствия и выводы. S>Я не понимаю, о чем речь. Какие допущения и следствия нужны для работы словаря, кроме свойств отношения эквивалентности, ну и GetHashCode(), соответственно?
тогда попробуй сначала ответить на вопрос:
как мы видели даже у predefined-типов изменен оператор == как минимум для типов:
double, decimal и string — он возвращает не тоже самое, что описано в Ecma Identity.
зачем это было сделано?
Здравствуйте, DarkGray, Вы писали:
DG>>>а модель где? DG>>>hint: в модели должны вводится какие-то понятия, допущения, делаться какие-то следствия и выводы. S>>Я не понимаю, о чем речь. Какие допущения и следствия нужны для работы словаря, кроме свойств отношения эквивалентности, ну и GetHashCode(), соответственно?
DG>тогда попробуй сначала ответить на вопрос: DG>как мы видели даже у predefined-типов изменен оператор == как минимум для типов: DG>double, decimal и string — он возвращает не тоже самое, что описано в Ecma Identity. DG>зачем это было сделано?
Вообще говоря, никто не настаивал на том что оператор (==) должен возвращать то, что описано в Ecma Identity. Оператор (==) определяет эквивалентность, а не идентичность.
DG>>в ООП нет переменных, поэтому не понятно что с чем путаем S>Вот мне тоже не понятно, но есть ощущение, что ты называешь объектом не объект, а то ли переменную, то ли ссылку на объект. С чего у тебя += для строк якобы изменяет объект?
потому что с точки зрения ООП для выдвижение тех или иных утверждений я должен пользоваться только внешним контрактом, и только теми понятиями, которые есть в ООП.
в ООП есть понятие объект, косвенно упоминается понятие ссылка, понятия переменной там нет.
соответственно, когда я вижу код:
x += "1";
и для описания использую вышепревиденные понятия, то у меня получается следующее:
x — это ссылка, потому что обладает ссылочным контрактом (объект, конечно, тоже — потому что в ООП: всё есть объект)
+= dx — это полиморфная операция обладающая контрактом: изменение объекта на величину dx (и этим она отличается от операции +, у которой в контракте зафиксировано, что она создает новый объект)
используя оба эти утверждения, я получаю, что после применения этого кода я получаю через x тот же самый объект, но измененный на величину dx
при этом с помощью функции referenceequals я могу сравнить ссылки на этот объект с чем-нибудь, а с помощью equals(или ==) сравнить состояние этого объекта с чем-нибудь.
вы же утверждаете, что всё это не так, при этом ссылаясь на детали реализации, хотя ООП утверждает, что как раз детали реализации могут быть любыми — важен лишь контракт.
S>Вообще говоря, никто не настаивал на том что оператор (==) должен возвращать то, что описано в Ecma Identity. Оператор (==) определяет эквивалентность, а не идентичность.
на секунду допустим этого.
тогда вопрос: при этом equality может ли быть различным, если идентичность одна и та же?
DG>>>в ООП нет переменных, поэтому не понятно что с чем путаем S>>Вот мне тоже не понятно, но есть ощущение, что ты называешь объектом не объект, а то ли переменную, то ли ссылку на объект. С чего у тебя += для строк якобы изменяет объект?
DG>потому что с точки зрения ООП для выдвижение тех или иных утверждений я должен пользоваться только внешним контрактом, и только теми понятиями, которые есть в ООП. DG>в ООП есть понятие объект, косвенно упоминается понятие ссылка, понятия переменной там нет.
DG>соответственно, когда я вижу код: DG>x += "1"; DG>и для описания использую вышепревиденные понятия, то у меня получается следующее: DG>x — это ссылка, потому что обладает ссылочным контрактом (объект, конечно, тоже — потому что в ООП: всё есть объект)
Все есть объект — это не про понятия ЯВУ. Это про моделирование.
DG>+= dx — это полиморфная операция обладающая контрактом: изменение объекта на величину dx
А откуда ты взял что это изменение объекта? DG>(и этим она отличается от операции +, у которой в контракте зафиксировано, что она создает новый объект)
В C# += это сахар для + с последующим присваиванием.
DG>используя оба эти утверждения, я получаю, что после применения этого кода я получаю через x тот же самый объект, но измененный на величину dx
Вот по поводу того же самого — явно не так.
DG>при этом с помощью функции referenceequals я могу сравнить ссылки на этот объект с чем-нибудь, а с помощью equals(или ==) сравнить состояние этого объекта с чем-нибудь.
Вот сравни ссылки, и пойми, что ты получил не изменение объекта, а новый объект.
DG>вы же утверждаете, что всё это не так, при этом ссылаясь на детали реализации, хотя ООП утверждает, что как раз детали реализации могут быть любыми — важен лишь контракт.
контракт в данном случае следующий
x = operator(+)(x, dx)
S>>Вообще говоря, никто не настаивал на том что оператор (==) должен возвращать то, что описано в Ecma Identity. Оператор (==) определяет эквивалентность, а не идентичность.
DG>на секунду допустим этого. DG>тогда вопрос: при этом equality может ли быть различным, если идентичность одна и та же?
Такая реализация возможна, но надо понимать, что она не будет удовлетворять требованиям отношения эквивалентности. Не будет выполняться рефлексивность.
DG>>соответственно, когда я вижу код: DG>>x += "1"; DG>>и для описания использую вышепревиденные понятия, то у меня получается следующее: DG>>x — это ссылка, потому что обладает ссылочным контрактом (объект, конечно, тоже — потому что в ООП: всё есть объект) S>Все есть объект — это не про понятия ЯВУ. Это про моделирование.
бездоказательно.
DG>>+= dx — это полиморфная операция обладающая контрактом: изменение объекта на величину dx S>А откуда ты взял что это изменение объекта? DG>>(и этим она отличается от операции +, у которой в контракте зафиксировано, что она создает новый объект) S>В C# += это сахар для + с последующим присваиванием.
согласен. был не прав, использовал контракт для += из C++.
DG>>при этом с помощью функции referenceequals я могу сравнить ссылки на этот объект с чем-нибудь, а с помощью equals(или ==) сравнить состояние этого объекта с чем-нибудь. S>Вот сравни ссылки, и пойми, что ты получил не изменение объекта, а новый объект.
я уже давал ссылку на определение, в котором явно сказано, что разницы ссылок не следует, что объект не тот же самый
Здравствуйте, DarkGray, Вы писали:
S>>Она является функцией идентичности по ECMA для ссылочных типов.
DG>если ReferenceEquals есть та самая Единая функция для проверки идентичности объектов, то почему тогда, например, Dictionary (и Hashtable) ее не использует для проверки объектов на равенство, а использует другую функцию?
Потому что для Dictionary (и Hashtable) нужна не идентичность, а эквивалентность. Идентичность является одним из вариантов эквивалентности, только вот идентичность по разному определяется для ref и value типов.
Вообще-то в Ecma-335 вполне точно описано что есть идентичность, чем она отличается от эквивалентности и для чего они нужны.
Здравствуйте, DarkGray, Вы писали:
DG>я уже давал ссылку на определение, в котором явно сказано, что разницы ссылок не следует, что объект не тот же самый
В общем случае да, но для CLR идентичность и есть равенство ссылок.
S>>Вообще говоря, никто не настаивал на том что оператор (==) должен возвращать то, что описано в Ecma Identity. Оператор (==) определяет эквивалентность, а не идентичность.
DG>на секунду допустим этого. DG>тогда вопрос: при этом equality может ли быть различным, если идентичность одна и та же?
Вполне. Читай ecma-335, там черным по английскому написано математическое определение equality: бинарное отношение обладающее свойствами рефлексивности, симметричности, транзитивности.
identity частный случай отношения equality и в ООП требуется чтобы объект был идентичен только сам себе и это отношение не зависело от состояния и поведения. В ecma-335 identity определен как ReferenceEquals и состоявшиеся дебаты на форуме показали что другой реализации identity в рамках ecma нету.
DG>>>твое "ну, понял" справедливо только при следующих утверждениях: DG>>>1) y1 и y (а также z1 и z) — это один и тот же объект G>>Присваивание ссылок очевидно сохраняет identity.
DG>как только появляется слово "очевидно", то это означает, что человек не может объяснить происходящее.
Ты не понимаешь почему присваивангие ссылок не меняет identity? Тогда вопрос как мы работаем с объектами в программе? Что мы используем чтобы обратиться к объекту? Видимо ссылку.
Так вот с точки зрения ООП есть функция identity, которая принимает две ссылки и говорит true если они обе ссылаются на один объект и false в противном случае.
DG>откуда известно, что в данном месте происходит присвоение ссылок, а не что-то другое?
Из ecma-335, так как для ref-типов оператор "=" — присвоение ссылок. Мы ведь в рамках ecma-335 находимся, не так ли?
G>>Я сделал это на основании того что строки в .NET это reference типы, других соображений не нужно.
DG>правильно я понял, что ты утверждаешь, что всегда когда в коде на c# мы видим операцию = и тип переменной reference, то всегда происходит лишь присваивание ссылки?
Именно так.
G>>Хотя сведения о том что += не изменяет строку есть в MSDN, только инкапсуляцию это никак не нарушает.
DG>является ли операция += полиморфной в C#? и если она такой является, то каким контрактом она при этом обладает?
a+=b является "сахаром" для a=a+b, это уже по ecma-334.
DG>>правильно я понял, что ты утверждаешь, что всегда когда в коде на c# мы видим операцию = и тип переменной reference, то всегда происходит лишь присваивание ссылки? G>Именно так.
а вот samius смог вовремя распознать подвох.
поэтому я еще раз повторю, что как только человек говорит "очевидно", это означает что человек не понимает то, о чем говорит.
DG>>откуда известно, что в данном месте происходит присвоение ссылок, а не что-то другое? G>Из ecma-335, так как для ref-типов оператор "=" — присвоение ссылок. Мы ведь в рамках ecma-335 находимся, не так ли?
DG>правильно я понял, что ты утверждаешь, что всегда когда в коде на c# мы видим операцию = и тип переменной reference, то всегда происходит лишь присваивание ссылки?
Именно так.
[занудно]
из того, что для ref-типов оператор '=' используется для присвоение ссылок не следует, что каждое использование оператор '=' для ref-типов является лишь присвоением ссылок.
DG>>если ReferenceEquals есть та самая Единая функция для проверки идентичности объектов, то почему тогда, например, Dictionary (и Hashtable) ее не использует для проверки объектов на равенство, а использует другую функцию? S>Потому что эти классы работают на более общем отношении эквивалентности, чем идентичность.
я правильно понимаю, что фактически под идентичностью вы понимаете возможность определения, что объект является сам собой же?
для каких алгоритмов (ситуаций, задач и т.д.) это знание вообще требуется?
Здравствуйте, vdimas, Вы писали:
V>Да, но не заданы свыше. Это принципиально.
А про "свыше" никто и не говорит. Вот сели разработчики дотнета, и безо всякой подсказки свыше разделили слои C#, СLR и так далее.
V>Ну таки при некотором навыке экономит невообразимую массу времени во время разработки. И во время поиска узких мест у коллег тоже. Там не rocket-science вовсе... ты же обратил внимание, что мне сам факт обсуждения подобных вещей кажется странным?
Обратил. Это как раз признак догматического мышления
V>Скажу так, что ПЕРЕД началом оптимизаций, программу необходимо переписать.
Хм. Я-то ожидал 100% предсказания результатов профайлера. Ну уж если не прямо процентовки времени вызовов, то хотя бы порядок, в котором в выходе профайлера будут идти функции. Ну да ладно, замнём. Мне важно было понять, что вы считаете заменой профайлеру.
V>Это можно в тестах выяснить, зачем что читать? Как раз тонкости реализаций не всегда описаны. Берем 2 независимые от вызовов операции, одинаковые по стоимости в случае одного потока. Затем прогоняем их на многопроцессорной машине из многих потоков, строим график и видим, какая операция масштабируется фактически линейно, а какая нет.
Ну, тут многое может зависеть от деталей организации теста. Ок, при случае проверю ваши предположения.
Но, тут важно вот что: не слеплять в голове понятия "мьютекс" и "делегат" в одно понятие. Потому, что когда в версии фреймворка N+1 реализацию изменят, ваши интуитивные представления о том, что медленно, а что быстро, окажутся неверными.
V>А ты понял значение этих терминов? Bookmark Lookup — это восстановление соответствия м/у выделенным индексом и индексируемыми строками.
Я-то понял. Вы лучше откройте-ка учебник по реляционной алгебре, и попробуйте найти в нём операцию "восстановление соответствия м/у выделенным индексом и индексируемыми строками." V>Откуда берутся индексы — уже говорил выше. Clustered Index Seek — это есть операция "выборка" по проекции или "ограничение".
"Clustered" — это подробность хранения индекса, идет из раздела реляционных баз данных. Я уже упоминал, что реляционные базы, реляционная модель, реляционное исчисление и реляционная алгебра связаны друг с другом. Матаппарат делиться на разделы, ок, ну разделы и разделы себе... Но использовать одно без другого бессмысленно, ведь реляционная модель была придумана для реляционных баз, а реляционное исчисление и реляционная алгебра были введены как инструмент над реляционной моделью. А вовсе не "сами по себе".
Они, конечно же, не сами по себе. Тем не менее, в РА нет и не может быть никаких индексов. Потому что индексы определяются в терминах подробностей хранения данных, а их в РА нету.
V>Таки настаиваю. Понимаешь, индекс можно построить даже по данным, которые не поддерживают операцию сравнения, хоть этого нельзя конкретно в MS SQL, но это лишь подробности MS SQL. Принципиально в таком индексе будет то, что объем данных проекции может быть гораздо меньше объема всех данных, поэтому операция выборки/ограничения по индексу может быть выполнена многократно эффективнее, чем по всем исходным данным. Вот так может приниматься решение — делать индекс кластерным или некластерным.
Вы напрасно спорите с очевидным. Если мы рассуждаем исключительно в терминах РА, то нет никакого смысла в "сохранении" результата какой-то операции, т.к. там нет понятия "эффективности". Если мы рассуждаем в терминах RDBMS, то операции "проекция" недостаточно, по двум причинам:
1. Индекс, помимо "публичных" данных, которые можно получить в результате проекции, хранит обратные ссылки на "строки таблицы". В РА невозможно сослаться на конкретную строку.
2. Индекс, помимо "содержания" данных, обладает особенностями их размещения, которые позволяют некоторые операции выполнять быстрее. В частности, поиск значения ключа в индексе традиционно выполняется за O(log(N)) либо O(N/M), с достаточно большими основаниями логарифма или M для того, чтобы в практических случаях это сводилось к O(1). Некоторые виды индексов также позволяют делать c подобной асимптотикой операции диапазонного поиска.
Кстати, индекс для данных, не поддерживающих операции сравнения, не имеет никакого смысла.
V>Еще раз большими буквами — любой некластерный индекс — это и есть проекция. В классике индексы некластерные изначально. Просто в MS SQL ввиду особенностей хранения блобов кластерные индексы оч популярны.
Вы продолжаете писать бессмысленный набор слов. Популярность кластерных индексов в MS SQL никак не связана с особенностями хранения блобов, да и вообще с блобами не связана. Я написал определение некластерного индекса — попробуйте соорудить проекцию(т.е. таблицу), которая будет эквивалентна ему по производительности.
V>Я тебе скажу так, в достаточно большой системе, с многими миллионами записей движений и сотнеями справочников, одно лишь только изменение суррогатных ключей с типа int на shortint в справочниках и оформление индексов как некластерных у справочников, где записи достаточно большие (много полей) подняло производительность более чем в четверо. Вот зачем нужна проекция при построении индекса — это снижение объема перелопачиваемых данных при операциях над таблицами, проводимыми по этому индексу/ключу (фактически все операции из РА).
Я вас разочарую: снижение объема перелопачиваемых данных в индексах выполняется не за счёт операций проекции, а за счёт организации данных.
V>Наверно не понимаешь, что есть реляционное исчисление, а что есть реляционная алгебра, так? Это совсем не одно и то же.
И тем не менее, SQL не оперирует понятиями реляционной модели.
V>Я не знаю, что есть логическое, а что есть физическое в твоем понимании?
Это я вижу. Поясняю: При рассмотрении анатомии оптимизаторов запросов в СУБД, выделяют два вида "планов запроса":
1. Логический план. Выражается в терминах операций расширенной РА; является результатом синтаксического разбора SQL запроса и некоторой предварительной оптимизации. Предварительные оптимизации на этом этапе имеют целью упрощение плана для дальнейшего анализа и устранение заведомых неоптимальностей.
2. Физический план. Выражается в терминах императивных операций, работающих над конкретными объектами реляционной базы. Это совсем другие операции. Скажем, там, где в логическом плане была пара операций π и σ, в физическом плане будет одна операция table scan. Или одна операция index seek. Или операция index scan и операция bookmark lookup.
V>Использование разного порядка сканирования индексов — это физическое отличие или логическое?
Конечно же это отличие физического плана. В логическом плане никаких индексов нет. V>А ведь разные вещи, хотя с т.з. реляционного исчисления — это не имеет значения, но с т.з. реляционной алгебры — это разная последовательность императивных операций над разными таблицами-индексами.
В реляционной алгебре нет никаких императивных операций. RTFM.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
