• 1 formatNum
• 2 Включён доступ к произвольным объектам Викиданных
• 3 Отмена работы параметра кэш
• 4 Возможность называть населённый пункт по разному
• 5 Названия разные, а хэш один: есть проблема, но есть и решение
• 6 185 строчка
• 7 Интерполяция в графиках

format = {decimalMark = ",", groupMark = " ", groupMinLength = 5, groupOnlyIntegerPart = true}

format = {decimalMark = ",", groupMark = " ", groupMinLength = 5, groupOnlyIntegerPart = true}

@Туча: Да, вы правы. Игорь Темиров 07:13, 15 мая 2015 (UTC)[ответить]

@Ignatus: Отличная новость! Игорь Темиров 04:00, 24 июня 2015 (UTC)[ответить]

ча, спасибо, что напомнили. Удалил. Игорь Темиров 07:32, 6 ноября 2015 (UTC)[ответить]

Почему нужно что то удалять, если можно просто сделать работоспособным? --Туч_а 08:09, 6 ноября 2015 (UTC)[ответить]

Не видите войну правок. Объясните, для чего это нужно. Игорь Темиров 08:12, 6 ноября 2015 (UTC)[ответить]

Я лишь вернул версию до всех изменений, это полное соответствие ВП:КОНС. А намёк на войну правок, и настрой на конфронтацию - это предложение что-то обсудить на СО с не аргументированной отменой правок, без открытия этого самого обсуждения. Если параметр ввёден и введён вами!!, то, вероятно, вам не нужно объяснять зачем он нужен, например для отладки и поиска ошибок. --Туч_а 08:17, 6 ноября 2015 (UTC)[ответить]

Да, я ввел эту функцию в первоначальном варианте, так как думал использовать шаблон из других вики, но потом выяснилось, что это невозможно и расчёт хеша нужен только внутри модуля. Я поблагодарил вас (спасибо, что напомнили) и удалил. Вы не возражаете, если я удалю найденную вами неиспользуемую, ошибочную, ненужную, не содержащую программного кода функцию? Игорь Темиров 08:24, 6 ноября 2015 (UTC)[ответить]

Я починил эту функцию, я нашел эту ошибку, то есть она понадобилась. Она нужна для исследования работы модуля. --Туч_а 08:33, 6 ноября 2015 (UTC)[ответить]

Для исследований существует личное пространство. Скопируйте к себе модуль и исследуйте. Игорь Темиров 08:53, 6 ноября 2015 (UTC)[ответить]

Да модуль можно укопироватся в личное пространство до посинения, Вы же потом не дадите ничего вставить из личного пространства обратно в модуль, как показывает практика и не раз. --Туч_а 08:57, 6 ноября 2015 (UTC)[ответить]

Чем вам не угадил параметр nocat, позволяющий не включать страницу ни в какие категории, тоже непонятно. Это достаточно общая практика в википедии, о том что такой параметр иногда полезен. Вы сами ставили мне в вину, что страница замусоривает категорию, и надо сделать чтобы тестовые страницы, для которых сообщение об ошибке является нормальной работой, туда не попадали. --Туч_а 08:27, 6 ноября 2015 (UTC)[ответить]

Вы не ответили на мой вопрос. Игорь Темиров 08:31, 6 ноября 2015 (UTC)[ответить]

Вы тоже не ответили на мой вопрос, зачем вы отменили мои правки. Любое изменение модуля почему-то воспринимается в штыки, я же ничего не поломал, зачем меня было отменять? --Туч_а 08:34, 6 ноября 2015 (UTC)[ответить]

Вы просто не обратили внимания. Повторю свой ответ: Да, я ввел эту функцию в первоначальном варианте, так как думал использовать шаблон из других вики, но потом выяснилось, что это невозможно и расчёт хеша нужен только внутри модуля. Я поблагодарил вас (спасибо, что напомнили) и удалил. Если какие-то слова или фразы непонятны, это не значит, что я не ответил. Просто напишите конкретно, что не поняли, и я распишу подробнее. Игорь Темиров 08:38, 6 ноября 2015 (UTC)[ответить]

Ну а теперь поставьте себя на место другой стороны. Человек потратил время, починил эту функцию, поэтому давайте теперь её удалим, потому что вам она не нужна, потому что вы этот свой кэш считаете в off line, ну и как? Если люди вас спрашивают что это за числа, то они должны быть в праве хотя бы их получить. Вот представьте, случился апокалипсис, перестал работать бот TemirovBot, перестал заходить в википедию Игорь Темиров, люди же в праве наверно будут отойти от концепции, что кэш имеет право знать только Игорь Темиров? --Туч_а 08:54, 6 ноября 2015 (UTC)[ответить]

Только что заметил ваш комментарий к моему предыдущему вопросу. Отвечу тогда на ваш вопрос по поводу Чем вам не угадил параметр nocat?. А чем он мне не угодил? Вроде ничего против не имею. Это действительно выход. Если не получается скопировать модуль в личное пространство и экспериментировать там, то хотя бы так. Игорь Темиров 08:58, 6 ноября 2015 (UTC)[ответить]

Делаешь правку, отменяют и просят обсудить, но обсуждение не открывают. Когда задаешь прямой вопрос чем не угадила правка, то никакого ответа на самом деле нет, и даже говорится что это выход. Ну и зачем было отменять? Ничего не понимаю. Специально же делались изменения несколькими правками, что бы если есть возражения, отменялись только те изменения, по которым они есть. --Туч_а 09:36, 6 ноября 2015 (UTC)[ответить]

Согласен с вашими аргументами. Спасибо. Игорь Темиров 11:15, 6 ноября 2015 (UTC)[ответить]

Туча Да, я видел ваши правки. Сам думал о чём-то подобном. Я хотел реализовать это через таблицы на странице хешей. Сейчас и так анализируется возврат на наличие таблицы в случае коллизий. Тогда понадобится добавить анализ первого аргумента таблицы. Если он числовой, то хеш подменяется хешем из таблицы. При таком алгоритме структура страницы региона останется неизменной. Да всё руки не доходят. Как вам такой вариант? Игорь Темиров 11:28, 6 ноября 2015 (UTC)[ответить]

Этот вариант был бы очень хорош если бы хеш таблицы были отсортированы по алфавиту, а не по хешу. --Туч_а 11:49, 6 ноября 2015 (UTC)[ответить]

При чём тут алфавит? Мы имеем устаревшее название. Вычисляем, ничего не подозревая, хеш. Обращаемся к странице хешей. Получаем ответ. Спрашиваем, а не таблица ли это? Если таблица, (начинается нововвведение) спрашиваем, не число ли первый аргумент? Если нет, то это коллизия и всё идёт по старому, если да, то заменяем хеш устаревшего названия на хеш нового названия, возвращённый таблицей. Игорь Темиров 12:01, 6 ноября 2015 (UTC)[ответить]

Хэш таблица не одна, а разбита на несколько частей, старое и новое название, если сортировка по алфавиту в одной её части скорей всего с вероятностью стремящейся к единице, а если сортировка по хэшу, то они с вероятностью стремящейся к единице в разных частях. --Туч_а 12:15, 6 ноября 2015 (UTC)[ответить]

Всё равно не пойму в чём проблема. Вместо cделанной вами правки [131830654]="RYA" будет [131830654]={1627890309, "RYA"}. Плюс описанный минимальный код в модуле. Страница региона при этом не нуждается в корректировке. Игорь Темиров 12:54, 6 ноября 2015 (UTC)[ответить]

А конструкции с вложенными массивами ещё хуже. Они же память жрут. На самом деле чем меньше вложенных массивов тем меньше нужно памяти, при одном и том же количестве данных. --Туч_а 13:29, 6 ноября 2015 (UTC)[ответить]

Если бы хэши были бы отсортированы по алфавиту, то ваш вариант мог бы выглядеть как [131830654]=1627890309, [1627890309]="RYA", и не было бы ни вложенных массивов, ни необходимости хватать соседнюю часть индекса. --Туч_а 13:47, 6 ноября 2015 (UTC)[ответить]

if type(RegionPage) == "table" then RegionPage = RegionPage[PlaceName] end

1) вводится специальный "псевдорегион" STA-Multinames, которому такие хэши и должны сопоставляться;

2) если у хэша название региона указано как STA-Multinames, то производится вызов {{Население/STA-Multinames|хэш|название НП}}. Который, в свою очередь, и даст корректный регион. Так, для того же Жёлтинского вызов будет таким: {{Население/STA-Multinames|107744721|Жёлтинский}}, что даст нам правильный регион RUS-CHE. Результат — a/b.

if type(RegionPage) == "table" then RegionPage = RegionPage[PlaceName] end

if RegionPage == "STA-Multinames" then RegionPage = frame:expandTemplate{ title = ("Население/"..RegionPage), args = { PlaceHash, PlaceName } } end

@Seryo93: Да есть такая проблема {{Население|Жёлтинский|х}}:107744721,{{Население|Гришенское|х}}:107744721, но отдельный модуль тоже костыль. Скорее логичнее было бы переделать GetHashData, то есть заменить:

function GetHashData(PlaceHash) на function GetHashData(PlaceHash,PlaceName) в 68 строчке

if (HashData=="") then HashData=nil на if (HashData=="") then HashData= frame:expandTemplate{ title = templatename, args = { PlaceName } } if (HashData=="") then HashData=nil end в 75 строчке

local RegionPage = GetHashData(PlaceHash) на local RegionPage = GetHashData(PlaceHash,PlaceName) в 137 строчке

RegionPage = GetHashData(PlaceHash) на RegionPage = GetHashData(PlaceHash,PlaceName) в 142 строчке.

А if type(RegionPage) == "table" then RegionPage = RegionPage[PlaceName] end в строке 144 совсем удалить.

Source1 = RegionData['Источники'][PlaceData[NumRecord][3]][1]

Source1 = ( RegionData['Источники'] and string.format("{{%s}}",PlaceData[NumRecord][3]) ) or (RegionData['Источники'][PlaceData[NumRecord][3]] and PlaceData[NumRecord][3]) or RegionData['Источники'][PlaceData[NumRecord][3]][1]

"interpolate": {"value": "monotone"}

"interpolate": {"value": "linear"}

• Комментарий: в обсуждении графика поднимался вопрос о линейной интерполяции, конкретных возражений не было, было несколько голосов "за". Но все так нахваливали дизайн из шаблона {{Graph:Population history}}, где интерполяция по умолчанию monotone... Кроме того, был минус: я точно помню, что при резких скачках численности населения на графиках с линейной интерполяцией возникали плохо выглядящие острые углы линии. Тем не менее, сейчас я этот эффект воспроизвести не могу (или он стал незначителен). Короче, никаких фундаментальных преимуществ monotone перед linear действительно нет, а недостаток monotone действительно очевиден. Обсуждалась и возможность полного удаления линий, но однозначной поддержки не получила. Такое поведение при интерполяции monotone — несомненный баг; поскольку он пока не исправлен и, возможно, никогда не будет исправлен, я поддерживаю этот запрос. --Браунинг (обс.) 14:18, 16 августа 2018 (UTC)[ответить]
• Честно говоря, тут вообще графика не должно быть. Слишком неравномерно расположены реперные точки, слишком большой разрыв между первой и второй. Тут график не то что не даёт адекватную информацию — он вводит в заблуждение, это орисс. Надо вообще график заменить на гистограмму. GAndy (обс.) 17:54, 21 августа 2018 (UTC)[ответить]
• Причём, так проблема, по-видимому, встречается много где — может даже подумать о ботозамене. GAndy (обс.) 17:56, 21 августа 2018 (UTC)[ответить]
  • Нет. Это отдельный вопрос, по которому были широкие обсуждения -- я привёл ссылки выше. Если желаете, можно открыть новое обсуждение, если есть какие-то новые, не учтённые ранее аргументы. --Браунинг (обс.) 20:01, 21 августа 2018 (UTC)[ответить]
  • Гистограмма тоже плохо, все точки будут расположены равномерно, независимо от того сколько лет между ними прошло. Да, это там есть в обсуждении. Землеройкин (обс.) 20:52, 22 августа 2018 (UTC)[ответить]
• Я бы предпочёл вариант с исправлением интерполяции monotone, но это нужно где-то внутри Vega 2 ковыряться. Полгода назад пытался разобраться, где же проблема, но так и не нашёл. Например, в Vega-Lite всё хорошо, а в Vega 2 (код, редактор) при таких же значениях проблема. — putnik 20:49, 21 августа 2018 (UTC)[ответить]
  • Это конечно было бы здорово, но там же разобраться невозможно. Я пытался что-то понять, вроде бы кривые рисует вот эта функция? Но анекдот в том, что она их рисует правильно. Откуда берется глюк не понятно. Землеройкин (обс.) 20:56, 22 августа 2018 (UTC)[ответить]

1. Список населенных мест Дальневосточного края — 229 с.
2. Данные Всероссийской переписи населения 2002 года: таблица № 02c. Численность населения и преобладающая национальность по каждому сельскому населённому пункту. — М.: Росстат, 2004.
3. Карта-буклет Лазовский район ФГУП 2007г.
4. Лазовский район 1.01.2008
5. Приморский край. Всероссийская перепись населения 2010 года (по состоянию на 14 октября 2010 года)