Сообщение Re: tuple vs record от 08.02.2020 21:42
Изменено 08.02.2020 21:44 vdimas
Re: tuple vs record
Здравствуйте, MadHuman, Вы писали:
MH>Есть тупль, ну например t1=(x,y). Есть ещё один t2=(y,x).
MH>Они равны? нет, так как тупли равны когда равны все элементы на одинаковых позициях.
А что сравниваем-то?
Например, в первом тупле (кг, м/с) во втором (Гц, Вт), что тогда?
А низлежащие типы данных совпадают...
В общем, при любом сравнении важна семантика, т.е. даже не всегда важно представление данных.
Например, можно сравнивать float с double, с int, с long и т.д. с некоторой заданной точностью.
MH>вводим возможность именования позиций (например a b для нашего случая). То есть элемент теперь можно получать
MH>не только по индексу позиции, но и по идентификатору, например tuple.a
1. tuple.a — оксюморон.
2. Именование тоже не принципиально, бо любое именование — лишь некий алиас числа сугубо для глупца-человека.
Взять ту же БД, в одной таблице {Id, SubId, ..}, в другой { ParentSubId, ParentId, .. }.
Не смотря на разные названия и разное положение полей в таблице, тут должно быть понятно, что с чем можно сравнивать при построении join-запросов.
Т.е., опять важна лишь семантика, а хорошо подобранные идентификаторы помогут человеку сориентироваться в ней.
MH>Дак становится ли тупль рекордом когда его мемберы сделали инменованными?
В математике упорядоченный набор данных называют кортежом (tuple), в программировании записью (record).
Де-факто это одно и то же.
Исторически в математике принято ссылаться на элементы кортежа по индексу, а в программировании принято ссылаться на элементы записи по символьному идентификатору.
"Раскручиваем" нынешнее положение вещей:
* Идентификатор переменной в ЯП — это отсылка к некоему адресу (если это идентификатор поля структуры, то адрес от начала структуры).
* Адрес — это индекс значения.
Круг замкнулся. ))
MH>Вроде как нет, ведь добавив "для удобства" именования позициям мы ведь вроде как не изменили структуру данных.
Так и есть.
MH>Но опять же, а почему собственно нет? ведь все признаки (структура) рекорда налицо... почему это не рекорд?
ИМХО, это накопленная ошибка процесса развития практик в IT. ))
Изначально в некоторых языках ФП было замечено, что порой лаконичности (т.е. удобства) добавляют ср-ва позиционного оперирования полями записи, а в этих операциях важен индекс поля (как в математике), поэтому и назвали структуру, над которой можно производить позиционные операции, tuple.
Забавно, однако, что для указания смены позиций (индексов) в тупле всё-равно используют идентификаторы, а не числа.
Например, swap значений переменных в C#:
И обратно — позиционное оперирование именованными полями (инициализация типов-агрегатов в C/C++ и обратная их декомпозиция):
Т.е., вводить новомодные tuple в языки программирования было не обязательно, достаточно было дать операции позиционного манипулирования над структурами-агрегатами.
Сейчас-то это уже понятно...
Но туплы уже "протекли" в программистский обиход, лишний раз напоминая людям о их (людях) несовершенстве. ))
MH>Также вспомним select из sql, он что возвращает? кортеж с возможностью доступа по именам или рекорд?...
С т.з. зрения программиста — запись.
С т.з. движка СУБД — кортеж, бо по индексу адресация более эффективная.
MH>как верно идеалогически?
А как правильней: "древесина" или "материал из дерева"? ))
MH>Есть тупль, ну например t1=(x,y). Есть ещё один t2=(y,x).
MH>Они равны? нет, так как тупли равны когда равны все элементы на одинаковых позициях.
А что сравниваем-то?
Например, в первом тупле (кг, м/с) во втором (Гц, Вт), что тогда?
А низлежащие типы данных совпадают...
В общем, при любом сравнении важна семантика, т.е. даже не всегда важно представление данных.
Например, можно сравнивать float с double, с int, с long и т.д. с некоторой заданной точностью.
MH>вводим возможность именования позиций (например a b для нашего случая). То есть элемент теперь можно получать
MH>не только по индексу позиции, но и по идентификатору, например tuple.a
1. tuple.a — оксюморон.
2. Именование тоже не принципиально, бо любое именование — лишь некий алиас числа сугубо для глупца-человека.
Взять ту же БД, в одной таблице {Id, SubId, ..}, в другой { ParentSubId, ParentId, .. }.
Не смотря на разные названия и разное положение полей в таблице, тут должно быть понятно, что с чем можно сравнивать при построении join-запросов.
Т.е., опять важна лишь семантика, а хорошо подобранные идентификаторы помогут человеку сориентироваться в ней.
MH>Дак становится ли тупль рекордом когда его мемберы сделали инменованными?
В математике упорядоченный набор данных называют кортежом (tuple), в программировании записью (record).
Де-факто это одно и то же.
Исторически в математике принято ссылаться на элементы кортежа по индексу, а в программировании принято ссылаться на элементы записи по символьному идентификатору.
"Раскручиваем" нынешнее положение вещей:
* Идентификатор переменной в ЯП — это отсылка к некоему адресу (если это идентификатор поля структуры, то адрес от начала структуры).
* Адрес — это индекс значения.
Круг замкнулся. ))
MH>Вроде как нет, ведь добавив "для удобства" именования позициям мы ведь вроде как не изменили структуру данных.
Так и есть.
MH>Но опять же, а почему собственно нет? ведь все признаки (структура) рекорда налицо... почему это не рекорд?
ИМХО, это накопленная ошибка процесса развития практик в IT. ))
Изначально в некоторых языках ФП было замечено, что порой лаконичности (т.е. удобства) добавляют ср-ва позиционного оперирования полями записи, а в этих операциях важен индекс поля (как в математике), поэтому и назвали структуру, над которой можно производить позиционные операции, tuple.
Забавно, однако, что для указания смены позиций (индексов) в тупле всё-равно используют идентификаторы, а не числа.
Например, swap значений переменных в C#:
// C#
int a = 1, b = 2;
(a, b) = (b, a);И обратно — позиционное оперирование именованными полями (инициализация типов-агрегатов в C/C++ и обратная их декомпозиция):
struct {int x, y;} s = {1, 2};
auto [a, b] = s;Т.е., вводить новомодные tuple в языки программирования было не обязательно, достаточно было дать операции позиционного манипулирования над структурами-агрегатами.
Сейчас-то это уже понятно...
Но туплы уже "протекли" в программистский обиход, лишний раз напоминая людям о их (людях) несовершенстве. ))
MH>Также вспомним select из sql, он что возвращает? кортеж с возможностью доступа по именам или рекорд?...
С т.з. зрения программиста — запись.
С т.з. движка СУБД — кортеж, бо по индексу адресация более эффективная.
MH>как верно идеалогически?
А как правильней: "древесина" или "материал из дерева"? ))
Re: tuple vs record
Здравствуйте, MadHuman, Вы писали:
MH>Есть тупль, ну например t1=(x,y). Есть ещё один t2=(y,x).
MH>Они равны? нет, так как тупли равны когда равны все элементы на одинаковых позициях.
А что сравниваем-то?
Например, в первом тупле (кг, м/с) во втором (Гц, Вт), что тогда?
А низлежащие типы данных совпадают...
В общем, при любом сравнении важна семантика, т.е. даже не всегда важно представление данных.
Например, можно сравнивать float с double, с int, с long и т.д. с некоторой заданной точностью.
MH>вводим возможность именования позиций (например a b для нашего случая). То есть элемент теперь можно получать
MH>не только по индексу позиции, но и по идентификатору, например tuple.a
1. tuple.a — оксюморон.
2. Именование тоже не принципиально, бо любое именование — лишь некий алиас числа сугубо для глупца-человека.
Взять ту же БД, в одной таблице {Id, SubId, ..}, в другой { ParentSubId, ParentId, .. }.
Не смотря на разные названия и разное положение полей в таблице, тут должно быть понятно, что с чем можно сравнивать при построении join-запросов.
Т.е., опять важна лишь семантика, а хорошо подобранные идентификаторы помогут человеку сориентироваться в ней.
MH>Дак становится ли тупль рекордом когда его мемберы сделали инменованными?
В математике упорядоченный набор данных называют кортежом (tuple), в программировании записью (record).
Де-факто это одно и то же.
Исторически в математике принято ссылаться на элементы кортежа по индексу, а в программировании принято ссылаться на элементы записи по символьному идентификатору.
"Раскручиваем" нынешнее положение вещей:
* Идентификатор переменной в ЯП — это отсылка к некоему адресу (если это идентификатор поля структуры, то адрес от начала структуры).
* Адрес — это индекс первой ячейки памяти значения.
Круг замкнулся. ))
(почти)
MH>Вроде как нет, ведь добавив "для удобства" именования позициям мы ведь вроде как не изменили структуру данных.
Так и есть.
MH>Но опять же, а почему собственно нет? ведь все признаки (структура) рекорда налицо... почему это не рекорд?
ИМХО, это накопленная ошибка процесса развития практик в IT. ))
Изначально в некоторых языках ФП было замечено, что порой лаконичности (т.е. удобства) добавляют ср-ва позиционного оперирования полями записи, а в этих операциях важен индекс поля (как в математике), поэтому и назвали структуру, над которой можно производить позиционные операции, tuple.
Забавно, однако, что для указания смены позиций (индексов) в тупле всё-равно используют идентификаторы, а не числа.
Например, swap значений переменных в C#:
И обратно — позиционное оперирование именованными полями (инициализация типов-агрегатов в C/C++ и обратная их декомпозиция):
Т.е., вводить новомодные tuple в языки программирования было не обязательно, достаточно было дать операции позиционного манипулирования над структурами-агрегатами.
Сейчас-то это уже понятно...
Но туплы уже "протекли" в программистский обиход, лишний раз напоминая людям о их (людях) несовершенстве. ))
MH>Также вспомним select из sql, он что возвращает? кортеж с возможностью доступа по именам или рекорд?...
С т.з. зрения программиста — запись.
С т.з. движка СУБД — кортеж, бо по индексу адресация более эффективная.
MH>как верно идеалогически?
А как правильней: "древесина" или "материал из дерева"? ))
MH>Есть тупль, ну например t1=(x,y). Есть ещё один t2=(y,x).
MH>Они равны? нет, так как тупли равны когда равны все элементы на одинаковых позициях.
А что сравниваем-то?
Например, в первом тупле (кг, м/с) во втором (Гц, Вт), что тогда?
А низлежащие типы данных совпадают...
В общем, при любом сравнении важна семантика, т.е. даже не всегда важно представление данных.
Например, можно сравнивать float с double, с int, с long и т.д. с некоторой заданной точностью.
MH>вводим возможность именования позиций (например a b для нашего случая). То есть элемент теперь можно получать
MH>не только по индексу позиции, но и по идентификатору, например tuple.a
1. tuple.a — оксюморон.
2. Именование тоже не принципиально, бо любое именование — лишь некий алиас числа сугубо для глупца-человека.
Взять ту же БД, в одной таблице {Id, SubId, ..}, в другой { ParentSubId, ParentId, .. }.
Не смотря на разные названия и разное положение полей в таблице, тут должно быть понятно, что с чем можно сравнивать при построении join-запросов.
Т.е., опять важна лишь семантика, а хорошо подобранные идентификаторы помогут человеку сориентироваться в ней.
MH>Дак становится ли тупль рекордом когда его мемберы сделали инменованными?
В математике упорядоченный набор данных называют кортежом (tuple), в программировании записью (record).
Де-факто это одно и то же.
Исторически в математике принято ссылаться на элементы кортежа по индексу, а в программировании принято ссылаться на элементы записи по символьному идентификатору.
"Раскручиваем" нынешнее положение вещей:
* Идентификатор переменной в ЯП — это отсылка к некоему адресу (если это идентификатор поля структуры, то адрес от начала структуры).
* Адрес — это индекс первой ячейки памяти значения.
Круг замкнулся. ))
(почти)
MH>Вроде как нет, ведь добавив "для удобства" именования позициям мы ведь вроде как не изменили структуру данных.
Так и есть.
MH>Но опять же, а почему собственно нет? ведь все признаки (структура) рекорда налицо... почему это не рекорд?
ИМХО, это накопленная ошибка процесса развития практик в IT. ))
Изначально в некоторых языках ФП было замечено, что порой лаконичности (т.е. удобства) добавляют ср-ва позиционного оперирования полями записи, а в этих операциях важен индекс поля (как в математике), поэтому и назвали структуру, над которой можно производить позиционные операции, tuple.
Забавно, однако, что для указания смены позиций (индексов) в тупле всё-равно используют идентификаторы, а не числа.
Например, swap значений переменных в C#:
// C#
int a = 1, b = 2;
(a, b) = (b, a);И обратно — позиционное оперирование именованными полями (инициализация типов-агрегатов в C/C++ и обратная их декомпозиция):
struct {int x, y;} s = {1, 2};
auto [a, b] = s;Т.е., вводить новомодные tuple в языки программирования было не обязательно, достаточно было дать операции позиционного манипулирования над структурами-агрегатами.
Сейчас-то это уже понятно...
Но туплы уже "протекли" в программистский обиход, лишний раз напоминая людям о их (людях) несовершенстве. ))
MH>Также вспомним select из sql, он что возвращает? кортеж с возможностью доступа по именам или рекорд?...
С т.з. зрения программиста — запись.
С т.з. движка СУБД — кортеж, бо по индексу адресация более эффективная.
MH>как верно идеалогически?
А как правильней: "древесина" или "материал из дерева"? ))