Для Excel нашли полезное применение — девушка запилила в нём фильм
(Подсмотрено в ТГ "Дизайнерские мемчики" - клуб творческих людей!)
P.S. любителям котов и кошек - легендарная котыща!
(Подсмотрено в ТГ "Дизайнерские мемчики" - клуб творческих людей!)
P.S. любителям котов и кошек - легендарная котыща!
Таблицы в Excel — штука мощная, но с телефона на ходу вбивать сделки и проверять котировки — то ещё удовольствие. Тоже долго сидел на табличках, а потом психанул и запилил бесплатный Telegram Mini App — skarnum @Investapp_tracker_bot За секунду открывается прямо в телеге, сам подтягивает актуальные цены по акциям США, ETF, крипте и золоту, считает общий P&L, плюс встроил туда калькулятор усреднения (DCA) и AI-оценку структуры портфеля. Кому надоело чинить слетевшие формулы в таблицах — забирайте, пользуйтесь
Microsoft не исправляет существующую десятилетия ошибку в Excel, связанную с несуществующей датой, из-за риска нарушить работу таблиц, сообщает немецкий журнал Computer Bild.
Ситуация состоит в том, что программа Excel считает 1900 год високосным, признавая существование 29 февраля. Так как каждому дню присваивается порядковый номер (например, 1 января 1900 года следует под номером 1, 2 января — под номером 2), из-за наличия номера 60, которое получило 29 февраля 1900 года, дальнейшие даты оказались сбиты на одну позицию.
«Microsoft поясняет: “Хотя технически возможно исправить это поведение, чтобы текущие версии Microsoft Excel не считали 1900 год високосным, недостатки такого подхода перевешивают преимущества”. Причина: если бы компания устранила ошибку, пришлось бы изменить всю нумерацию последующих дат. 1 марта 1900 года получило бы номер 60 вместо порядкового номера 61. Это сдвинуло бы все последующие даты на один день и могло бы привести к значительным проблемам, особенно в старых файлах Excel. Формулы, работающие с датами, в частности, могли бы давать некорректные результаты. Поэтому некорректная обработка високосных дней остается особенностью Excel», — пишет Computer Bild.
Уточняется, что, по данным Microsoft, проблема затрагивает только 1900 год, а все остальные високосные годы Excel обрабатывает корректно.
В PostgreSQL есть одна особенность, на которой легко ошибиться даже при написании простых SQL-запросов: деление целых чисел не всегда возвращает дробный результат.
Разберём целочисленное деление, работу с остатком и особенности дробных чисел.
В моем канале Аналитика FM выпуски про бизнесовые метрики в разных бизнесах, про особенности SQL запросов и работы аналитика.
Канал я веду с нуля подписчиков, рассказываю про аналитику и разбираю различные кейсы на реальных примерах.
Подписывайся, если интересно как устроен мир аналитика!
Представим, что мы делим выручку на количество заказов и хотим получить средний чек.
SELECT 10 / 3;
Какой результат ожидаем?
3.33?
А PostgreSQL вернёт:
3
Почему? Потому что оба числа - целочисленные (integer), а значит, PostgreSQL выполняет целочисленное деление.
При таком делении дробная часть отбрасывается, а не округляется.
Посмотрим на несколько примеров:
SELECT 10 / 3 AS integer_division
, 10.0 / 3 AS decimal_division
, 10::numeric / 3 AS numeric_division;
Результат:
| integer_division | decimal_division | numeric_division |
|:-------------------------:|:---------------------------:|:---------------------------:|
| 3 | 3.333333... | 3.333333... |
В чём разница?
10 / 3 - оба операнда целые числа, поэтому результат целочисленный.
10.0 / 3 - число 10.0 имеет тип numeric, поэтому результат дробный.
10::numeric / 3 - мы явно преобразовали число в numeric.
💡 Важно: если привести результат к numeric уже после деления, дробная часть не вернётся!
SELECT (10 / 3)::numeric;
Результат:
3
Потому что сначала произошло целочисленное деление, и только потом преобразование типа.
Правильно:
SELECT 10::numeric / 3;
Например:
SELECT 10 / 3 AS result_1,
11 / 3 AS result_2,
8 / 3 AS result_3;
Результат:
result_1 | result_2 | result_3
-------------+--------------+---------
3 | 3 | 2
PostgreSQL просто отбрасывает дробную часть.
Если нам нужно именно округление, используем ROUND():
SELECT ROUND(10::numeric / 3, 2);
Результат:
3.33
А теперь интереснее.
В PostgreSQL есть оператор %, который возвращает остаток от деления.
Например:
SELECT 10 / 3 AS division,
10 % 3 AS remainder;
Результат:
division | remainder
-------------+----------
3 | 1
Потому что:
10 = 3 * 3 + 1
То есть:
/ - целая часть результата деления для целочисленных операндов;
% - остаток от деления.
Оператор % работает не только с целыми числами, но и с numeric.
Например:
SELECT 10.5 % 3;
Результат:
1.5
Например, нам нужно определить, является ли число чётным.
Для этого достаточно проверить остаток от деления на 2:
SELECT number,
CASE WHEN number % 2 = 0 THEN 'Чётное'
ELSE 'Нечётное' END AS number_type
FROM numbers;
Или распределить пользователей по группам:
SELECT user_id, user_id % 3 AS group_number
FROM users;
Остаток позволяет распределять записи по группам, проверять кратность чисел и решать другие задачи.
Целочисленное деление в PostgreSQL отбрасывает дробную часть в сторону нуля.
SELECT -10 / 3 AS division,
-10 % 3 AS remainder;
Результат:
division | remainder
-------------+----------
-3 | -1
Проверка:
-10 = (-3) * 3 + (-1)
Обратите внимание: остаток в этом случае отрицательный.
Если оба операнда целочисленные, PostgreSQL выполняет целочисленное деление.
Дробная часть отбрасывается, а не округляется.
Чтобы получить дробный результат, преобразуйте хотя бы один операнд в numeric или тип с плавающей точкой до деления.
ROUND() используется для округления результата.
Оператор % возвращает остаток от деления.
При работе с отрицательными числами целая часть отбрасывается в сторону нуля.
И главное: всегда обращайте внимание на типы данных при делении. Иначе можно получить вполне корректный с точки зрения PostgreSQL, но совершенно неожиданный с точки зрения бизнес-аналитики результат.
Ну а в моем канале Аналитика FM уже есть серия постов про AI-агентов.
Присоединяйся, если интересно разбираться в аналитике данных.
Большинство «Excel тормозит, всё долго и всё ломается» лечится не курсами, а парой привычек. Собрал то, чем реально пользуюсь каждый день в рабочих таблицах — учёт, заказы, выработка, деньги. Сохраняйте, пригодится.
Горячие клавиши (Windows, русский Excel)
Перемещение и выделение
Ctrl + стрелка — прыжок в конец данных вместо прокрутки колёсиком.
Ctrl + Shift + стрелка — выделить всё до конца столбца или строки.
Ctrl + Пробел — выделить весь столбец, Shift + Пробел — всю строку.
Ctrl + Page Up / Page Down — переключать листы.
Ctrl + Home — вернуться в ячейку A1.
Ввод и правка
F2 — править ячейку, не трогая мышь.
Alt + Enter — перенос строки внутри ячейки.
Ctrl + ; — сегодняшняя дата, Ctrl + Shift + ; — текущее время.
Ctrl + D — скопировать ячейку сверху вниз на всё выделение.
Ctrl + Enter — ввести одно значение сразу во все выделенные ячейки.
Ctrl + E — мгновенное заполнение: напишите пример (например, только фамилию из ФИО) — Excel сам продолжит по образцу.
Ctrl + «+» / Ctrl + «−» — вставить или удалить строки/столбцы.
Формулы
Alt + = — автосумма.
F4 — внутри формулы ставит $: A1 → $A$1 → A$1 → $A1. Вне формулы — повторяет последнее действие.
Ctrl + ё — показать все формулы вместо значений (удобно искать числа, вбитые руками «на время»).
Таблицы и вид
Ctrl + T — «умная таблица»: формулы сами протягиваются на весь столбец, новые строки сразу попадают в отчёты.
Ctrl + Shift + L — включить/выключить фильтр.
Ctrl + 1 — формат ячеек.
Alt + F1 — диаграмма по выделенным данным за одну секунду.
Запись макроса — когда одно и то же делаете каждый день
Если каждое утро вы открываете выгрузку и руками удаляете лишние столбцы, ставите формат, фильтр и сортировку — это работа для макроса. Программировать не нужно, Excel просто запомнит ваши действия.
1. Вид → Макросы → Запись макроса (или вкладка «Разработчик», если она включена).
2. Дайте имя без пробелов, например «Выгрузка», и назначьте сочетание, например Ctrl + Shift + В.
3. «Сохранить в»: выберите «Личная книга макросов» — тогда макрос будет работать в любом файле, а не только в этом.
4. Сделайте всё, что делаете руками: удалили столбцы, поставили формат, включили фильтр, отсортировали.
5. Вид → Макросы → Остановить запись.
Всё. Завтра открываете новую выгрузку, жмёте Ctrl + Shift + В — и 10 минут рутины превращаются в секунду.
Три грабли, на которые наступают все:
— Если выгрузка каждый раз разной длины, перед записью включите «Относительные ссылки» (там же, в меню макросов), иначе макрос будет работать только с теми ячейками, что были при записи.
— Файл с макросом сохраняйте как .xlsm, в обычном .xlsx макрос пропадёт.
— Макросы Excel не работают в Google Таблицах (там своя запись: Расширения → Макросы) и могут не работать или работать иначе в Р7-Офис и МойОфис — проверьте до того, как на них завязать отчёт.
И главное правило, которое важнее любых клавиш: данные вводятся в одну таблицу, один раз, построчно. Отчёты — отдельно и только формулами. Как только в отчёте появляется число, вбитое руками, через месяц никто не помнит, какая цифра правда.
А какое сочетание вы узнали поздно и пожалели, что не знали раньше?
В комментарии к моему посту написали "в Excel подогнал полиномом через ЛИНЕЙН — и номограмма превращается в обычную формулу". Да, такой вариант есть. Более того - лет семь назад мы с него и начинали. В видео я хотел показать несколько основных проблем при оцифровке (получения уравнения) с помощью встроенной функции ЛИНЕЙН.
Из основных я бы выделил сразу:
Далеко не всегда (скорее редко когда в реальных задачах) можно выполнить интерполяцию исходных данных полиномом.
Необходимо обязательно контролировать результат оцифровки путём построения. Никаких "да там и так видно". Поверьте - видно вам и видно МНК это два разных видно.
Если уравнение берётся с графика как уравнение линии тренда, то необходимы обязательно действия по корректировке форматов чисел.
Коэффициенты ЛИНЕЙН не всегда совпадают с коэффициентами выданными в уравнении линии тренда. Об этом рассказывал в ролике https://rutube.ru/video/df25be5500146314172cbcd1989ea8bc/
Вот так вот.. И даже если вы автоматизировали получение уравнения и использования коэффициентов (в видео показал), то результат расчёта по этому уравнению (через ЛИНЕЙН) может выдавать неверный результат. И без построения вы об этом не узнаете.
Экстраполяция при полиномиальной обработке это ЗЛО. Кто сталкивался - знает, остальные просто поверьте.
Стоит ли отказываться от получения уравнения и всё заменить на кусочную интерполяцию? Я уверен что нет. Массовая обработка типовых графиков - несомненно без полиномиальной интерполяции/аппроксимации, только кусочная интерполяция. Где и когда стоит смотреть в сторону создания формулы:
Когда график простой вида "прямая", и то это не точно (особенно если попытаться интерполировать данные с прямой линии с помощью полинома высокой степени).
Когда у вас много времени. По опыту - объём оцифровки что я сейчас за раб.день в самом начале делали 4 человека два месяца... Ну мы тогда ещё учились :)
Когда есть цель иметь красивую формулу а не UDF.
Когда график редкий/специфичный и кусочная интерполяция не работает.
Примером такого специфичного графика (надо формулу обязательно) для меня за последний год (т.е. одной из несколько тысяч) была вот такая номограмма в логарифмических осях:
Получилось обработать уравнениями вида
с использованием всё той же ЛИНЕЙН. Но, повторюсь: разовая работа, много времени потрачено, было нужно именно уравнение, причём единое для всей номограммы.
За сим всё. Если есть какая то номограмма, которую не смогли оцифровать с помощью "Быстрофункции на минималках" , то присылайте, посмотрим.