Файл с текстом параграфа

[Поляков]

Скачать файл: Обработка массивов

[bonzo]

Здесь я бы еще раз упомянул, что во "взрослой" жизни файлы обычно не помещаются в память; мы делаем такое допущение, чтобы научиться работать с массивами и списками. Соответственно, там, где говорится, что для сортировки нужно иметь все в памяти, стоит поставить сноску и сказать, что есть и методы внешней сортировки, но они выходят за рамки школьной программы.

Из той же серии: по "каким-то" причинам не помещается в память не стоит писать даже в сноске, ведь нормальная ситуация -- предполагать, что это так.

"которая параметра-кортежа" (12 стр.) -- наверное, для параметра-кортежа.

"Почему операции с массивами в NumPy выполняются быстрее, чем со списками?" -- опасный вопрос, для ответа на него нужно где-то сказать про локальность данных, а это долгий разговор. Но настолько важный, что здесь я бы даже был готов поступиться принципами и без особых пояснений сказать, что очень важно, чтобы данные, с которыми работают подряд, и в памяти шли подряд.

[nikolay]

1. стр.1 "массив хранится в виде списка" -- возможно стоит сделать замечание, что этот список не имеет является классической структурой типа список? Чтобы не было путаницы.

2. Предложение "Список позволяет объединять в одной коллекции данные разных типов, например, целые и вещественные числа, строки, списки и т. д. " кажется излишнем. Возможно после слов "Объекты могут быть произвольного размера, поэтому в список легко объединяются данные разных типов" добавить "например, ....".

3. В описании кортежа: "кортеж – неизменяемый массив из трёх элементов". Чтобы не закреплять термин массив за кортежом, возможно лучше: "кортеж – неизменяемая последовательность из трёх элементов" или "…неизменяемая упорядоченная коллекция".

4. Возможно в начале еще добавить слов про массив, чтобы он уложился в голове получше как именно коллекция со своими свойствами? Что-то типа:

Обычно элементы массива нумеруются целыми числами от 0 до N−1, где N — количество элементов массива. Доступ к элементу массива по индексу выполняется за постоянное время, чтобы получить элемент с номером i, достаточно одного обращения к памяти. У любого массива есть длина (размер), то есть количество элементов, в Python длину массива, представленного списком, можно узнать с помощью функции len.

[Neket]

1. Мне не очень нравится фраза "массивом называется группа однотипных элементов, имеющих общее имя" Элементы не имеют имени, да и нельзя сказать что сам массив имеет имя, потому что массив это тип. Имя может иметь переменная типа массив. Предлагаю адаптировать определение массива из стандарта языка Си: "Массив это непустая последовательность объектов одного типа, идущих в памяти друг за другом"

Таким образом, нельзя сказать, что массив хранится в питоне в виде списка. В виде списка может храниться последовательность объектов, которая также может храниться и в виде массива в других языках. Я также не уверен в строгой корректности утверждения о том, что список это массив ссылок. Я сходу не вижу в документации требования того, чтобы ссылки на элементы списка хранились в памяти подряд.

Резюмируя, я бы до конца первого пункта вообще не использовал слово "массив" в значении слова "последовательность". Сначала можно сказать, что часто встает задача обработки последовательности чисел. Потом, что в языке питон один из способов работы с последовательностями это список. Затем, что существует второй способ -- массивы из NumPy, которые вообще-то являются основным способом работы с последовательностями однотипных данных в других языках. После, что массивы более эффективны с точки зрения скорости работы, потому что локальность данных, без упоминания накладных расходов на вычисление лишнего адреса, потому что ими как раз можно пренебречь в данном случае. Наконец, что для наших простых задач это роли никакой не играет, поэтому мы будем пользоваться списками, а слово "массив" иногда употреблять в качестве синонима слову "последовательность".

Глобальный вопрос, нас какие-то формальные требования обязывают использовать слово массив? Есть ли причины кривить душой, и называть списки массивами на протяжении всего параграфа?

2. В конце задачи 1 возможно стоит упомянуть, что создание новых списков дело не быстрое, и решение, честно итерирующееся дважды по одному списку будет эффективнее, чем создание двух дополнительных списков.

3. Чтобы не возникло путаницы, я бы уточнил, что кортежи бывают разных размеров, не обязательно из трех элементов.

4. Мне не очень нравится дословный перевод слова in-place как "на месте", не очень понятно, что это должно значить. Я бы написал развернуто "выполняет сортировку путем обмена местами элементов исходного массива". Тогда становится понятно, почему после нее исходный массив не будет доступен.

5. Мы точно хотим вводить лямбда-функции? И вообще, и в параграфе про работу с масивами (списками) в частности?

6. Про многоуровневую сортировку меня смущает размытая формулировка Убывание на втором уровне сортировки определяется знаком «минус». Что значит "определяется знаком минус"? Разве в кортеж не попадает, буквально, число -х[0]? Можно честно объяснить, что создается кортеж из противоположных по знаку чисел, поэтому порядок у них будет обратным. Мне кажется 11-классники способны это понять.

[Поляков]

Здесь я бы еще раз упомянул, что во "взрослой" жизни файлы обычно не помещаются в память; мы делаем такое допущение, чтобы научиться работать с массивами и списками. Соответственно, там, где говорится, что для сортировки нужно иметь все в памяти, стоит поставить сноску и сказать, что есть и методы внешней сортировки, но они выходят за рамки школьной программы.

Согласен, добавил.

Из той же серии: по "каким-то" причинам не помещается в память не стоит писать даже в сноске, ведь нормальная ситуация -- предполагать, что это так.

Исправил.

"которая параметра-кортежа" (12 стр.) -- наверное, для параметра-кортежа.

Исправил.

"Почему операции с массивами в NumPy выполняются быстрее, чем со списками?" -- опасный вопрос, для ответа на него нужно где-то сказать про локальность данных, а это долгий разговор. Но настолько важный, что здесь я бы даже был готов поступиться принципами и без особых пояснений сказать, что очень важно, чтобы данные, с которыми работают подряд, и в памяти шли подряд.

Я надеялся, что первый рисунок объяснит ситуацию.

[Поляков]

1. стр.1 "массив хранится в виде списка" -- возможно стоит сделать замечание, что этот список не имеет является классической структурой типа список? Чтобы не было путаницы.

Дети на базовом уровне не знают, что такое связный список. А со списками в Python они уже работали в 9 классе.

2. Предложение "Список позволяет объединять в одной коллекции данные разных типов, например, целые и вещественные числа, строки, списки и т. д. " кажется излишнем. Возможно после слов "Объекты могут быть произвольного размера, поэтому в список легко объединяются данные разных типов" добавить "например, ....".

Да, верно. Перестроил фразы, убрал лишнее.

3. В описании кортежа: "кортеж – неизменяемый массив из трёх элементов". Чтобы не закреплять термин массив за кортежом, возможно лучше: "кортеж – неизменяемая последовательность из трёх элементов" или "…неизменяемая упорядоченная коллекция".

Мне бы хотелось создать впечатление, что кортеж и массив - это почти одно и то же, и работать с ними можно одинаково. Только кортеж нельзя менять. Вряд ли правильно говорить, что это совсем разные типы объектов.

4. Возможно в начале еще добавить слов про массив, чтобы он уложился в голове получше как именно коллекция со своими свойствами? Что-то типа:
Обычно элементы массива нумеруются целыми числами от 0 до N−1, где N — количество элементов массива. Доступ к элементу массива по индексу выполняется за постоянное время, чтобы получить элемент с номером i, достаточно одного обращения к памяти. У любого массива есть длина (размер), то есть количество элементов, в Python длину массива, представленного списком, можно узнать с помощью функции len.

Добавил.

Спасибо за замечания.

[Поляков]

1. Мне не очень нравится фраза "массивом называется группа однотипных элементов, имеющих общее имя" Элементы не имеют имени, да и нельзя сказать что сам массив имеет имя, потому что массив это тип. Имя может иметь переменная типа массив. Предлагаю адаптировать определение массива из стандарта языка Си: "Массив это непустая последовательность объектов одного типа, идущих в памяти друг за другом"

Переделал.

Таким образом, нельзя сказать, что массив хранится в питоне в виде списка. В виде списка может храниться последовательность объектов, которая также может храниться и в виде массива в других языках.

Исправил.

Я также не уверен в строгой корректности утверждения о том, что список это массив ссылок. Я сходу не вижу в документации требования того, чтобы ссылки на элементы списка хранились в памяти подряд.

В CPython точно так.
Иначе как получить время доступа к элементу O(1).

Резюмируя, я бы до конца первого пункта вообще не использовал слово "массив" в значении слова "последовательность". Сначала можно сказать, что часто встает задача обработки последовательности чисел. Потом, что в языке питон один из способов работы с последовательностями это список. Затем, что существует второй способ -- массивы из NumPy, которые вообще-то являются основным способом работы с последовательностями однотипных данных в других языках. После, что массивы более эффективны с точки зрения скорости работы, потому что локальность данных, без упоминания накладных расходов на вычисление лишнего адреса, потому что ими как раз можно пренебречь в данном случае. Наконец, что для наших простых задач это роли никакой не играет, поэтому мы будем пользоваться списками, а слово "массив" иногда употреблять в качестве синонима слову "последовательность".

Думаю, что дело в том, что слово «массив» мы употребляем в разных смыслах. Когда говорят «массив данных», часто имеют в виду именно упорядоченный набор данных (последовательность!) безотносительно того, как он размещается в памяти. Я подумаю, как про это написать.

Глобальный вопрос, нас какие-то формальные требования обязывают использовать слово массив? Есть ли причины кривить душой, и называть списки массивами на протяжении всего параграфа?

ФГОС и Федеральная рабочая программа. Они предусматривают изучение любого языка программирования из набора Python, C++, C#, Java, 1C. Списки - это "фишка" Python.

2. В конце задачи 1 возможно стоит упомянуть, что создание новых списков дело не быстрое, и решение, честно итерирующееся дважды по одному списку будет эффективнее, чем создание двух дополнительных списков.

Тесты говорят, что двойной проход на Python медленнее. Потому что sum на C написана, как я понимаю.

3. Чтобы не возникло путаницы, я бы уточнил, что кортежи бывают разных размеров, не обязательно из трех элементов.

Исправил.

4. Мне не очень нравится дословный перевод слова in-place как "на месте", не очень понятно, что это должно значить. Я бы написал развернуто "выполняет сортировку путем обмена местами элементов исходного массива". Тогда становится понятно, почему после нее исходный массив не будет доступен.

Исправил.

5. Мы точно хотим вводить лямбда-функции? И вообще, и в параграфе про работу с масивами (списками) в частности?

Одна из целей учебника информатики - показать задачи ЕГЭ. А при решении задач ЕГЭ с сортировкой это очень удобный инструмент, зачастую необходимый. Почему бы и нет? Дать возможность познакомиться. Можно эти знания не проверять.

6. Про многоуровневую сортировку меня смущает размытая формулировка Убывание на втором уровне сортировки определяется знаком «минус». Что значит "определяется знаком минус"? Разве в кортеж не попадает, буквально, число -х[0]? Можно честно объяснить, что создается кортеж из противоположных по знаку чисел, поэтому порядок у них будет обратным. Мне кажется 11-классники способны это понять.

Попробовал переписать.

Спасибо за замечания.

[Neket]

Я также не уверен в строгой корректности утверждения о том, что список это массив ссылок. Я сходу не вижу в документации требования того, чтобы ссылки на элементы списка хранились в памяти подряд.

В CPython точно так.
Иначе как получить время доступа к элементу O(1).

Да, про CPython я информацию тоже нашел. Возможно в учебнике для школьников нас за такое простят, но так как я много имею дело с Си, там подобные ситуации встречаются постоянно. Если в стандарте что-то не написано, пусть даже все известные мне версии всех компиляторов делают это одним и тем же способом, обязательно найдется какая-нибудь архитектура, операционка, версия компилятора, где это происходит по-другому. И что характерно, найдется пользователь, у которого все сломается, если сделать более смелое предположение, чем позволяет стандарт.

Я бы конечно подстелил себе соломы фразой "в популярных реализациях интерпретатора языка Python"... но наверное в данном случае это не существенно.