Здравствуйте, ·, Вы писали:
S>>·>Я претензии предъявлял к словам "термин имеет совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten".
S>>Я что-то не понял чего ты с чем сравниваешь и зачем. Заметь: flatten != flatmap. А flatten что в ruby, что в scala, что в питоне делает одно и то же.
S>>Именно поэтому вы вставили фразу про то, что flatten в Ruby и в Scala делает одно и тоже. Между тем, обратного я и не говорил, но вы зачем-то выделенное жирным написали.
·>И что?
И все.
·>Каким фактам оно противоречит?
Тому факту, что я никак не сравнивал flatten в Ruby с flatten в Scala.
·>И как это меняет мою претензию к корректности твоих слов?
Кардинально.
S>>·>Про нормальность я ничего _не доказывал_. Цитату в студию или признавайся
S>>Мои слова (в прямом негативном контексте):
S>>Интересно, как много людей в мире Java страдают от оксюморона ArrayList?
·>А почему это оксюморон-то?
Подумайте, здесь информации было высказано предостаточно.
·>Я всё прямо и однозначно стараюсь говорить.
И у вас получается, что "=" как обозначение операции "сравнение на равенство" -- это совершенно другое, чем "flat_map" как обозначение операции "трансформация с собиранием результата в плоский контейнер".
Херня редкая и не дружит с логикой, но зато прямо и однозначно.
S>>·>Я _объяснял_, что java List соответствует общепринятому ADT List.
S>>Только вот он не соответствует.
·>Каким местом не соответствует?
Тем, что в Java List дает доступ к элементу по индексу.
·>Во-вторых, вот нашел тут: "user can access"
Тут вот какое дело: если "user can", значит контейнер дает такую возможность. Не просто "container can provide", а именно "user can" -- возможность предоставлена, значит юзверь может воспользоваться или не воспользоваться. Но контейнером такая возможность предоставлена.
·>В чём принципиальная разница в контексте обсуждения *List? Ок, давай забудем "индекс", будем говорить только "позиция". В нашем разговоре это рояли не играет.
А вот фигушки. Наличие индекса как ключа для доступа к элементу в List и есть то, вокруг чего завертелся весь сыр-бор.
И как тут не вспомнить то, что уже случалось чуть ранее:
Может я не так распарсил твоё высказывание, но это неважно.
Так вот -- это не просто важно, это архиважно.
·>Мы можем посчитать нечто, не спорю, но вот только это не будет ни индексом элемента в Set, ни позицией.
Это будет таким же номером элемента при итерации, как и номер элемента в List-е, который мы можем получить только точно такой же итерацией.
S>>>>Так вот, интерфейс List, который дает доступ по индексу, но стоимость этого доступа может варьироваться от O(1) до O(N)
S>>·>Ты так говоришь, как будто это что-то плохое.
S>>Я так говорю, потому что это не просто плохое, это откровенное говно.
·>Это твоя эмоциональная оценка, никаким фактам не соответствует, поэтому идёт в топку.
Факт неявной смены сложности операции с O(1) на O(N) пациентом отвергается как незначительный. Что характерно, до этого пациент неоднократно утверждал, что его интересуют только факты.
s>>>>>> handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
S>>>>·>Нет, не имеем. Мы имеем порядковый номер в итераторе.
S>>>>Нет, здесь нет никаких номеров в итераторах. Более того, если мы возьмем реализации абстрактных типов List и Set в их C++ном виде, то там и физически никаких номеров в итераторах не будет (как, полагаю, и в Rust-е).
S>>·>Физические номера в итераторе ты сам придумал, и сам обиделся.
S>>Т.е. "Мы имеем порядковый номер в итераторе." -- это ваши слова,
·>Это перепевка ваших слов "порядковый номер во множестве".
Только вот в моих примерах не было никаких номеров в итераторах. Был отдельно итератор, отдельно счетчик номеров. И ключевой момент в том, что нам приходится вести этот счетчик номеров именно что отдельно и от контейнера, и от итератора.
S>>а про физические номера в итераторе -- это я сам придумал?
·>Да, конечно. Либо давай в студию мою цитату про физические номера.
Лехко:
Мы имеем порядковый номер в итераторе.
Но, можно предположить, что предлог "в" -- это еще одно "это другое".
Здравствуйте, so5team, Вы писали:
S>·>Каким фактам оно противоречит?
S>Тому факту, что я никак не сравнивал flatten в Ruby с flatten в Scala.
Это твои мысли и слова, а не факты.
S>·>И как это меняет мою претензию к корректности твоих слов?
S>Кардинально.
Ок, о чём конкретно твои слова о "совсем другой смысл" и каким фактам они соответствуют?
S>>>Интересно, как много людей в мире Java страдают от оксюморона ArrayList?
S>·>А почему это оксюморон-то?
S>Подумайте, здесь информации было высказано предостаточно.
Ага-ага.
S>·>Я всё прямо и однозначно стараюсь говорить.
S>И у вас получается, что "=" как обозначение операции "сравнение на равенство" -- это совершенно другое, чем "flat_map" как обозначение операции "трансформация с собиранием результата в плоский контейнер".
Ещё раз. Flat Map это не обо
значение, а понятие из CS. А вот "=" — это
значок. Даже в scala нет значка "flat_map", а есть другой значок "flatMap", и чё?..
S>>>Только вот он не соответствует.
S>·>Каким местом не соответствует?
S>Тем, что в Java List дает доступ к элементу по индексу.
И? Это ровно то, что написано в
https://en.wikipedia.org/wiki/List_(abstract_data_type) "access an item by index".
S>·>Во-вторых, вот нашел тут: "user can access"
S>Тут вот какое дело: если "user can", значит контейнер дает такую возможность. Не просто "container can provide", а именно "user can" -- возможность предоставлена, значит юзверь может воспользоваться или не воспользоваться. Но контейнером такая возможность предоставлена.
И? Можно было предоставить, вот и предоставили. Могли и не предоставлять.
S>·>В чём принципиальная разница в контексте обсуждения *List? Ок, давай забудем "индекс", будем говорить только "позиция". В нашем разговоре это рояли не играет.
S>А вот фигушки. Наличие индекса как ключа для доступа к элементу в List и есть то,
Я кажется стал догадываться в чём твой затык. Ты не различаешь List
Abstract Data Type и Linked List
Data Structure. Ознакомься, прежде продолжать гнуть свою линию:
https://en.wikipedia.org/wiki/List_(abstract_data_type)
https://en.wikipedia.org/wiki/Linked_list
S>вокруг чего завертелся весь сыр-бор.
Вначале я вообще написал "номер", потом уже перевёл как позиция-индекс, базируясь на цитатах из доков. Согласен, в контексте "оксюморон ArrayList" лучше всего подходит термин "позиция".
S>·>Мы можем посчитать нечто, не спорю, но вот только это не будет ни индексом элемента в Set, ни позицией.
S>Это будет таким же номером элемента при итерации, как и номер элемента в List-е, который мы можем получить только точно такой же итерацией.
Почему будет? Ты можешь свои фантазии подкрепить фактами?
S>>>·>Ты так говоришь, как будто это что-то плохое.
S>>>Я так говорю, потому что это не просто плохое, это откровенное говно.
S>·>Это твоя эмоциональная оценка, никаким фактам не соответствует, поэтому идёт в топку.
S>Факт неявной смены сложности операции с O(1) на O(N) пациентом отвергается как незначительный.
Опять врёшь и фантазируешь. И ведь цитаты-то не будет, как всегда.
S>>>>>Нет, здесь нет никаких номеров в итераторах. Более того, если мы возьмем реализации абстрактных типов List и Set в их C++ном виде, то там и физически никаких номеров в итераторах не будет (как, полагаю, и в Rust-е).
S>>>·>Физические номера в итераторе ты сам придумал, и сам обиделся.
S>>>Т.е. "Мы имеем порядковый номер в итераторе." -- это ваши слова,
S>·>Это перепевка ваших слов "порядковый номер во множестве".
S>Только вот в моих примерах не было никаких номеров в итераторах. Был отдельно итератор, отдельно счетчик номеров. И ключевой момент в том, что нам приходится вести этот счетчик номеров именно что отдельно и от контейнера, и от итератора.
В моих примерах тоже не было. Прекращай спорить с голосами в голове.
S>>>а про физические номера в итераторе -- это я сам придумал?
S>·>Да, конечно. Либо давай в студию мою цитату про физические номера.
S>Лехко: Мы имеем порядковый номер в итераторе.
S>Но, можно предположить, что предлог "в" -- это еще одно "это другое".
У меня проблемы со зрением... Сделай в этой цитате слово "физический" жирным, а то никак не вижу.
