Могу привести очень много примеров, Но это тема прямо для отдельной статьи.
Конкретно в вашем запросе суть в том, что выражение "эффективность бизнеса" по-разному понимается в классическом западном бизнес-подходе и в российском кабанчиковом менталитете. Западный подход трактует эффективность как соблюдение стратегии и ключевых метрик эффективности, российский же принцип заключается в подходах типа "бери больше - кидай дальше, "я начальник - ты дурак“ и "не нaeбёшь - не проживёшь". Каждый российский отдел закупок - это маленькое озерцо коррупции, в котором начальник мутит какой-то свой мутный бизнес со своими собственными поставщиками - а на просьбу раскрыть информацию об этом он начинает реветь белугой, что если не дай бог что-нибудь нарушится в его процессах, то весь бизнес тут же рухнет. И генеральный директор на это обычно реагирует словами "воу воу, ладно работай дальше, трогать тебя не будем". Попытка загнать таких чуваков в условную Арибу заканчивается корпоративным конфликтом и, как минимум, саботажем всей системы. Реальная система состоит из тысяч каких-то мутных excel файлов, записных книжек конкретных продавцов, директоров, и каких-то приближённых товарищей, каких-то договорённостей на словах с поставщиками и коррумпированными чиновниками и прочей ерундой. И попытка свести это всё во что-то единое, что требуют системы типа SAP, опять же заканчиваются уверениями акционера в том, что всё тут же разрушится, потому что они нарушат устоявшуюся систему. Русские кабанчики любят стабильность, а не какую-то там мифическую эффективность. Для них стабильность есть эффективность. Если всё крутится и лавэха мутится, несмотря даже на отрицательную маржинальность, то это считается эффективным бизнесом.
Всё просто. Любой SAP и прочие системы предлагают свой фреймворк, под который нужно перестраивать бизнес. А русские бизнесмены, у которых нет бизнес-образования - зато есть огромное чувство собственной важности, считают что их бизнес абсолютно уникальный, и перестраивать его нельзя. А 1с наоборот, вписывается в любой, самый корявый бизнес и самый корявый документооборот в нём. Именно поэтому 1С на западный рынок так и не вышел, хотя очень пытался.
Вы сова? Встаете поздно? Это чёткий тайминг циркадной активации у сов - когда поднимается кортизол внутри дня. Это может вызывать скачок давления и соматическую мигренозную реацию. Это никакими приборами и неврологами не измерить, только опытным путем подбирать лечение.
Если боль не сильная - то она снимается большой дозой ибупрофена (800-1200 за раз) - это основная первая линия лечения, помогает даже заядлым мигренозоникам, если пить прям в момент начала боли.
Если не поможет - надо тестировать препараты. Попробуйте купить спрей Эксенза от мигрени и брызгать его СТРОГО ДО НАЧАЛА боли - раз она у вас по графику. Спрей действует лучше и быстрее - но только до начала приступа.
Если жалко денег на спрей - примите таблетки от мигрени (наверняка вам дали какие-то триптаны, типа суматриптана или золмитриптана) тоже ДО НАЧАЛА боли и посмотрите на эффект.
Купите тонометр и измеряйте давление каждый час ДО и ПОСЛЕ начала боли. Только такие измерения помогут что-то найти, поскольку проблема плавающая, то в кабинете невролога её не поймать.
И да, исключите скачок сахара. Вполне возможно, что каждый второй день в 15:00 вы едите тажелую пищу на обеде в офисе и в голову вам бъет скачок инсулина, что также часто бывает у людей 30+.
Хотите секрет? Реальные люди не пишут буллет-поинтами и короткими ёмкими абзацами. Так делают только нейросети. В следующий раз, когда будете копипастить статью из ChatGPT, то попросите его переписать его более человечно, он это тоже умеет.
А если по-сути - то вы вообще не понимаете разнцу между задачами отдельного человека и проектного офиса. Потому что все описанные вашей нейросетью методы в равной мере подходят и не подходят обоим. Потому что они и про время, и про задачи, и про приоритеты и вообще про всё. Вы сравнили тёплоё с мягким, просто поленившись даже попросить нейросеть задать вам пару вопросов.
Не делайте так, это неуважение и к хабру и к самим себе. Вы же продвигаете что-то там типа проектного управления - а такими статьями показываете, что сами в нём ничего не понимаете.
Если уж реально писать такую статью не на отъeбиcь, то надо было бы сначала сравнить задачи и ворклоады отдельных людей и группы людей, команды, компании и т.п. - смотря на каком уровне вы представляете себе проектный офис. И уже исходя из этого смотреть на плюсы и минусы методологий и сравнивать их в связке, поскольку многие из них друг друга дополняют.
Основное динамическое уравнение ЕТИ формулируется как минимизация функционала информационного действия:
Принцип Наименьшего Информационного Действия определяет состояние минимальной информационной избыточности - аналог динамического равновесия физического мира.
Но это неправильно, динамические дифф.уры так не работают. Нулевой ПНИД не даст минимум избыточности, это всего лишь один из локальных минимумов. А реальный минимум дифф.ура надо искать через градиентный спуск (в нейросетях это везде используется).
При этом вам нужен градиент А-типа, т.к. остальные будут давать вырожденные корни. И естессно с комплексным множителем, дифференцированным по dy. В итоге получится всё равно приближение, т.к. этот диффур неразрешим в частных производных - но это всё равно лучше, чем промах на локальный минимум.
Итого, получится следующее: Градиент Наименьшего Информационного Действия (А-типа):
Нет, не теоретизирую. Я эти интервью в гугле провожу. Я знаю, как они, по крайней мере, дложны работать. Нет, код никуда в падавляющем большинстве случаев не копируют и не прогоняют. Он в 60% случаев вообще не скомпилировался бы по моим ощущениям, но кандидаты интервью проходят
Вы в Гугле работаете? Получали согласование с руководством на такие комментарии?
Надеюсь вы понимаете, что из этого комментария легко написать статью "СОТРУДНИК ГУГЛ ПРИЗНАЛСЯ, ЧТО НАНИМАЕТ НА РАБОТУ ЛЮДЕЙ, НЕ УМЕЮЩИХ ПРОГРАММИРОВАТЬ" - и опровергать это придется на сильно высоком уровне.
Чота там подраспустил вас нынче ваш комплаенс, в наши времена за такие комменты по шапкам прилетало сразу.
Раз он так красиво всё связал в своей гениальной теории, то пусть объяснит проблему конфайнмента, например. Или любую другую, необьясненную, коих полно в современных теориях. Да хотя бы пусть темную материю опишет - и как её детектировать - куча учёных будет очень благодарна! Разумеется, построив модель её распределения с начала большого взрыва, которая бы совпадала с реальными наблюдениями - иначе не считается!
Это вы откуда взяли такой постулат?😁 Вы матаном владеете?
И в КМ и в ОТО пространство, время и поля - более чем строгие математические объекты. Наоборот, это чаще приводит к обратным философским проблемам - например, что времени и пространства вообще не существует - и никакая философская демагогия неспособна доказать обратное.
Вся психологическая безопасность разобьётся о картинку, с которой начинается ваша статья.
Потому что, в первую очередь, люди неидеальны. Один забыл отчёт вовремя послать, другой забыл цифру проверить, третий устал и заболел, четвертый слишком долго кодил и вовремя не сдал релиз т.п. И показывая пальцем на соседа они все будут правы. Потому что в их узком кругозоре (который они имеют право иметь по своей должности) проблема реально в соседе и том, как он плохо работает.
А меж тем проблема в некорректном планировании проекта и неправильной оценке сроков исходя из реальных компетенций команды в целом - и это видно только с уровня руководителя, который видит всю команду в целом и решает задачи и проблемы уровнем выше тех, которые понимают члены команды.
Поэтому психологический комфорт надо выстраивать один на один руководителю с каждым сотрудником. Чтобы не при всех все друг друга поносили - а наедине ему одному честно всё рассказывали, а он уже принимал справедливое решение от своего имени.
Вот где-то 300 и было. 10 лет работали как попало, от проекта до проекта, сплошные кассовые разрывы, долги и переработки.
Потом собрались с мыслями и сделали стратегию и долго её реализовывали, структурируя бизнес. И одним из первых шагов как раз был переход к строгой проектной методологии со строгим прайс-листом и детальной оценкой различных профилей сотрудников - что позволило ставить задачи не просто от балды "куда-то в разработку" - а на четкого спеца с четким набором компетенций и с уровнем ответственности, подходящим под конкретный проект - да, это странно звучит, но не на каждого клиента надо ставить супер-ответственного, супер-придирчивого, супер-умного - а значит - и супер-дорогого человечка. Это крайне важный вопрос оптимизации костов, который в разработке может очень круто сыграть в плюс. Или в минус, если неправильно сделать 😁
Спасибо, очень ценная практическая статья, плюсанул вам в карму.
Мы на основании похожие методологии в компании на 300+ разработчиков сделали детальную градацию, которая позволила экономить миллионы рублей на правильной локации ресурсов на сложные проекты и, соответственно, снижение штрафов за простой и ошибки. Эта штука реально работает, если её правильно применять И поддерживать в актуальном состоянии.
Божечки, Дракон... Я уж думал, никогда уже не услышу этого названия... 😲
Там ведь ещё эти были... шампур-схемы!!!! 😁😁😁
Я в аспирантуре учился в начале двухтысячных и уже владел неплохо всякими новыми штуками, типа UML и XML, начитавшись про них книжек в оригинале, ибо на нашем языке их ещё не выпускали. И когда мне научник принес книжку о дружелюбном драконе и его шампур-схемах со словами: "Вот наши тайные советские разработки, обязательно из используй!" - то я смотрел на это и не знал, плакать мне или смеяться.
Ну я смеялся, конечно, в основном - потому что в книжке описывались кейсы использования Дракона на программах, которые мы в восьмом классе на информатике решали. А плакал я потому что понимал, что меня могут заставить засовывать в эти шампуры сложные программные архитектуры, которые я тогда проектировал (многопоточности и синхронизации, например, в Драконе я не видел).
Но сейчас я готов задать осмысленный вопрос - а почему Дракон? Почему не UML или там BPML например? Или не обычные какие-нибудь mind maps?
Какую проблему вы пытаетесь решить, склеивая дракон с ллм ? Ведь вдоль и поперек уже известно, что визуальные системы программирования и проектирования крайне сильно ограничены в реальном мире - чуть более сложный чем hello world алгоритм в них будет выглядеть чудовищно сложно и отлаживать его и искать ошибки будет в разы сложнее, чем в коде.
А какие-то простые и понятные последовательности рисовать можно просто в виде презентаций со стрелочками - так они и понятнее, и приятнее.
Разгоревшийся выше спор про размерности, наверное, можно разрешить таким образом - размерность можно трактовать как дополнительную... эм... размерность??? 😬... ну, типа размерность в понятии измерений, как доп.координату, как ортогональный базис к самому значению.
Ну то есть математику важно, чтобы все числа были в одном множестве - R × R → R. Здесь у чисел нет дополнительной координаты РАЗМЕРНОСТИ, что позволяет такие операции производить.
Но если мы вводим размерности, то это как-бы добавляет к каждому числу новую координату - как i у комплексных чисел - и, соответственно, сводит числа с одинановой размерностью в нормальные замкнутые кольца , а числам с разной размерностью вообще не позволяет существовать в одном кольце, т.к. у них не совпадает доп.координата.
Т.е. можно сложить метры и метры - т.к. это одно кольцо, а метры и килограммы сложить нельзя - т.к. это разные кольца, хотя числовая компонента у них одинаковая. Ну или можно сложить эти числовые компоненты (без размерностей) - но физический смысл этой суммы будет непонятен, т.к. именно размерность определяет физический смысл
Но какого-то готового сценария я не дам, т.к. они очень плохо воспроизводятся в ИИ. Может вылезти какой-то странный косяк - то ИИ скажет, что у него отключены библиотеки для работы с изображениями, то будет стабильно генерировать документ, заполненный черными квадратами, то будет создавать pdf из одной одинаковой страницы и на просьбу наполнить их инфой будет всё равно выдавать тот же кривой пдф 😬
Общая схема такая - берете одну типичную страницу документа и на ней тестируете разные подходы - превратить в текст, в doc, в латекс, в pdf, нарезать картинками и вставить в html или сразу сделать готовый html и т.п.
Лучше всего работает вывод текстом непосредственно в сообщение чата - в нем ИИ меньше всего накосячит - с дальнейшей обработкой этого текста следующими запросами и перенос вручную в docx-файл с нужным вам форматированием
Позволяют. Ещё и оформят красиво в любом формате и картинки нарисуют прям по тексту. Я так запихиваю в нейросети старые fb2шки Лукьяненко и получаю на выходе pdf рендер идеального размера под любой экран, с любимым шрифтом и завораживающими иллюстрациями
То же самое и с BI, например. Красивая диаграмма нужна, чтобы быстро очертить проблему. А изучать её можно только по полотнам экселевских табличек - и никакой серьезный стратег или аналитик никогда не будет испытывать дискомфорта, глядя на лист А2, заполненный цифирками 9 шрифтом - для них они гораздо информативнее любой инфографики.
Проблема обучающихся не в том, что они не программируют во время туториалов - а в том, что их проблемы и ошибки очень часто находятся не просто за пределами туториала, а вообще за пределами их текущей предметной области.
Условно говоря, если ты перепутал = и == в условном C++, то ты получишь такой жуткий набор ошибок, для понимания которых тебе потребуются знания всего - от низкоуровневой архитектуры распределения памяти до системы обработки исключений на уровне ядра. Плюс глубокое понимание логики работы компилятора, которое позволит таки понять, что злобный С++ не пытается взорвать твой комп - а всего лишь реагирует на неправильный символ в неправильном месте.
И если ты кодер неопытный, то основная часть гимора связана с неглубоким пониманием того, что работает сложнее, чем кажется на поверхностный взгляд. И туториалами это не решить - потому что твоя задача всегда немножко отличается от туториала, и это немножко, как правило, оказывается настолько критичным, что требует отдельного туториала - а ученик, как правило, даже и не понимает, в чём проблема!
И программировать больше - это тоже не поможет, если ты тупо нажимаешь кнопочки вслед за говорящей головой. Потому что завтра на работе тебе надо будет нажать ещё одну кнопочку, про которую не говорила говорящая голова - и эта одна кнопочка положит всё твое обучение набок.
Поэтому лучшим способом обучения пока что остаётся обучение на реальных проектах с реальным учителем, который сможет давать быстрые ответы на внезапные вопросы. Если это сможет делать нейронка - то тоже хорошо, но пока что опыт показывает, что они могут ещё больше запутаться сами и запутать обучающего.
Могу привести очень много примеров, Но это тема прямо для отдельной статьи.
Конкретно в вашем запросе суть в том, что выражение "эффективность бизнеса" по-разному понимается в классическом западном бизнес-подходе и в российском кабанчиковом менталитете. Западный подход трактует эффективность как соблюдение стратегии и ключевых метрик эффективности, российский же принцип заключается в подходах типа "бери больше - кидай дальше, "я начальник - ты дурак“ и "не нaeбёшь - не проживёшь". Каждый российский отдел закупок - это маленькое озерцо коррупции, в котором начальник мутит какой-то свой мутный бизнес со своими собственными поставщиками - а на просьбу раскрыть информацию об этом он начинает реветь белугой, что если не дай бог что-нибудь нарушится в его процессах, то весь бизнес тут же рухнет. И генеральный директор на это обычно реагирует словами "воу воу, ладно работай дальше, трогать тебя не будем". Попытка загнать таких чуваков в условную Арибу заканчивается корпоративным конфликтом и, как минимум, саботажем всей системы. Реальная система состоит из тысяч каких-то мутных excel файлов, записных книжек конкретных продавцов, директоров, и каких-то приближённых товарищей, каких-то договорённостей на словах с поставщиками и коррумпированными чиновниками и прочей ерундой. И попытка свести это всё во что-то единое, что требуют системы типа SAP, опять же заканчиваются уверениями акционера в том, что всё тут же разрушится, потому что они нарушат устоявшуюся систему. Русские кабанчики любят стабильность, а не какую-то там мифическую эффективность. Для них стабильность есть эффективность. Если всё крутится и лавэха мутится, несмотря даже на отрицательную маржинальность, то это считается эффективным бизнесом.
Всё просто. Любой SAP и прочие системы предлагают свой фреймворк, под который нужно перестраивать бизнес. А русские бизнесмены, у которых нет бизнес-образования - зато есть огромное чувство собственной важности, считают что их бизнес абсолютно уникальный, и перестраивать его нельзя. А 1с наоборот, вписывается в любой, самый корявый бизнес и самый корявый документооборот в нём. Именно поэтому 1С на западный рынок так и не вышел, хотя очень пытался.
Вы сова? Встаете поздно? Это чёткий тайминг циркадной активации у сов - когда поднимается кортизол внутри дня. Это может вызывать скачок давления и соматическую мигренозную реацию. Это никакими приборами и неврологами не измерить, только опытным путем подбирать лечение.
Если боль не сильная - то она снимается большой дозой ибупрофена (800-1200 за раз) - это основная первая линия лечения, помогает даже заядлым мигренозоникам, если пить прям в момент начала боли.
Если не поможет - надо тестировать препараты.
Попробуйте купить спрей Эксенза от мигрени и брызгать его СТРОГО ДО НАЧАЛА боли - раз она у вас по графику. Спрей действует лучше и быстрее - но только до начала приступа.
Если жалко денег на спрей - примите таблетки от мигрени (наверняка вам дали какие-то триптаны, типа суматриптана или золмитриптана) тоже ДО НАЧАЛА боли и посмотрите на эффект.
Купите тонометр и измеряйте давление каждый час ДО и ПОСЛЕ начала боли. Только такие измерения помогут что-то найти, поскольку проблема плавающая, то в кабинете невролога её не поймать.
И да, исключите скачок сахара. Вполне возможно, что каждый второй день в 15:00 вы едите тажелую пищу на обеде в офисе и в голову вам бъет скачок инсулина, что также часто бывает у людей 30+.
Хотите секрет? Реальные люди не пишут буллет-поинтами и короткими ёмкими абзацами. Так делают только нейросети. В следующий раз, когда будете копипастить статью из ChatGPT, то попросите его переписать его более человечно, он это тоже умеет.
А если по-сути - то вы вообще не понимаете разнцу между задачами отдельного человека и проектного офиса. Потому что все описанные вашей нейросетью методы в равной мере подходят и не подходят обоим. Потому что они и про время, и про задачи, и про приоритеты и вообще про всё. Вы сравнили тёплоё с мягким, просто поленившись даже попросить нейросеть задать вам пару вопросов.
Не делайте так, это неуважение и к хабру и к самим себе. Вы же продвигаете что-то там типа проектного управления - а такими статьями показываете, что сами в нём ничего не понимаете.
Если уж реально писать такую статью не на отъeбиcь, то надо было бы сначала сравнить задачи и ворклоады отдельных людей и группы людей, команды, компании и т.п. - смотря на каком уровне вы представляете себе проектный офис. И уже исходя из этого смотреть на плюсы и минусы методологий и сравнивать их в связке, поскольку многие из них друг друга дополняют.
Вы пишете что
Но это неправильно, динамические дифф.уры так не работают. Нулевой ПНИД не даст минимум избыточности, это всего лишь один из локальных минимумов. А реальный минимум дифф.ура надо искать через градиентный спуск (в нейросетях это везде используется).
При этом вам нужен градиент А-типа, т.к. остальные будут давать вырожденные корни. И естессно с комплексным множителем, дифференцированным по dy. В итоге получится всё равно приближение, т.к. этот диффур неразрешим в частных производных - но это всё равно лучше, чем промах на локальный минимум.
Итого, получится следующее: Градиент Наименьшего Информационного Действия (А-типа):
ГНИД(А) ≈ ЕТИ·Тb-℮∨o(℉ℼℹℤ)dy
Вы в Гугле работаете? Получали согласование с руководством на такие комментарии?
Надеюсь вы понимаете, что из этого комментария легко написать статью "СОТРУДНИК ГУГЛ ПРИЗНАЛСЯ, ЧТО НАНИМАЕТ НА РАБОТУ ЛЮДЕЙ, НЕ УМЕЮЩИХ ПРОГРАММИРОВАТЬ" - и опровергать это придется на сильно высоком уровне.
Чота там подраспустил вас нынче ваш комплаенс, в наши времена за такие комменты по шапкам прилетало сразу.
Именно так. А зачем ещё делаются новые теории?
Раз он так красиво всё связал в своей гениальной теории, то пусть объяснит проблему конфайнмента, например. Или любую другую, необьясненную, коих полно в современных теориях. Да хотя бы пусть темную материю опишет - и как её детектировать - куча учёных будет очень благодарна! Разумеется, построив модель её распределения с начала большого взрыва, которая бы совпадала с реальными наблюдениями - иначе не считается!
Это вы откуда взяли такой постулат?😁 Вы матаном владеете?
И в КМ и в ОТО пространство, время и поля - более чем строгие математические объекты. Наоборот, это чаще приводит к обратным философским проблемам - например, что времени и пространства вообще не существует - и никакая философская демагогия неспособна доказать обратное.
Вся психологическая безопасность разобьётся о картинку, с которой начинается ваша статья.
Потому что, в первую очередь, люди неидеальны. Один забыл отчёт вовремя послать, другой забыл цифру проверить, третий устал и заболел, четвертый слишком долго кодил и вовремя не сдал релиз т.п. И показывая пальцем на соседа они все будут правы. Потому что в их узком кругозоре (который они имеют право иметь по своей должности) проблема реально в соседе и том, как он плохо работает.
А меж тем проблема в некорректном планировании проекта и неправильной оценке сроков исходя из реальных компетенций команды в целом - и это видно только с уровня руководителя, который видит всю команду в целом и решает задачи и проблемы уровнем выше тех, которые понимают члены команды.
Поэтому психологический комфорт надо выстраивать один на один руководителю с каждым сотрудником. Чтобы не при всех все друг друга поносили - а наедине ему одному честно всё рассказывали, а он уже принимал справедливое решение от своего имени.
Вот где-то 300 и было. 10 лет работали как попало, от проекта до проекта, сплошные кассовые разрывы, долги и переработки.
Потом собрались с мыслями и сделали стратегию и долго её реализовывали, структурируя бизнес. И одним из первых шагов как раз был переход к строгой проектной методологии со строгим прайс-листом и детальной оценкой различных профилей сотрудников - что позволило ставить задачи не просто от балды "куда-то в разработку" - а на четкого спеца с четким набором компетенций и с уровнем ответственности, подходящим под конкретный проект - да, это странно звучит, но не на каждого клиента надо ставить супер-ответственного, супер-придирчивого, супер-умного - а значит - и супер-дорогого человечка. Это крайне важный вопрос оптимизации костов, который в разработке может очень круто сыграть в плюс. Или в минус, если неправильно сделать 😁
Статья выглядит как дословная цитата книги Стивена Кови от 1989 года
Спасибо, очень ценная практическая статья, плюсанул вам в карму.
Мы на основании похожие методологии в компании на 300+ разработчиков сделали детальную градацию, которая позволила экономить миллионы рублей на правильной локации ресурсов на сложные проекты и, соответственно, снижение штрафов за простой и ошибки. Эта штука реально работает, если её правильно применять И поддерживать в актуальном состоянии.
Божечки, Дракон... Я уж думал, никогда уже не услышу этого названия... 😲
Там ведь ещё эти были... шампур-схемы!!!! 😁😁😁
Я в аспирантуре учился в начале двухтысячных и уже владел неплохо всякими новыми штуками, типа UML и XML, начитавшись про них книжек в оригинале, ибо на нашем языке их ещё не выпускали. И когда мне научник принес книжку о дружелюбном драконе и его шампур-схемах со словами: "Вот наши тайные советские разработки, обязательно из используй!" - то я смотрел на это и не знал, плакать мне или смеяться.
Ну я смеялся, конечно, в основном - потому что в книжке описывались кейсы использования Дракона на программах, которые мы в восьмом классе на информатике решали. А плакал я потому что понимал, что меня могут заставить засовывать в эти шампуры сложные программные архитектуры, которые я тогда проектировал (многопоточности и синхронизации, например, в Драконе я не видел).
Но сейчас я готов задать осмысленный вопрос - а почему Дракон? Почему не UML или там BPML например? Или не обычные какие-нибудь mind maps?
Какую проблему вы пытаетесь решить, склеивая дракон с ллм ? Ведь вдоль и поперек уже известно, что визуальные системы программирования и проектирования крайне сильно ограничены в реальном мире - чуть более сложный чем hello world алгоритм в них будет выглядеть чудовищно сложно и отлаживать его и искать ошибки будет в разы сложнее, чем в коде.
А какие-то простые и понятные последовательности рисовать можно просто в виде презентаций со стрелочками - так они и понятнее, и приятнее.
Зачем Дракон-то ?
Разгоревшийся выше спор про размерности, наверное, можно разрешить таким образом - размерность можно трактовать как дополнительную... эм... размерность??? 😬... ну, типа размерность в понятии измерений, как доп.координату, как ортогональный базис к самому значению.
Ну то есть математику важно, чтобы все числа были в одном множестве - R × R → R. Здесь у чисел нет дополнительной координаты РАЗМЕРНОСТИ, что позволяет такие операции производить.
Но если мы вводим размерности, то это как-бы добавляет к каждому числу новую координату - как i у комплексных чисел - и, соответственно, сводит числа с одинановой размерностью в нормальные замкнутые кольца , а числам с разной размерностью вообще не позволяет существовать в одном кольце, т.к. у них не совпадает доп.координата.
Т.е. можно сложить метры и метры - т.к. это одно кольцо, а метры и килограммы сложить нельзя - т.к. это разные кольца, хотя числовая компонента у них одинаковая. Ну или можно сложить эти числовые компоненты (без размерностей) - но физический смысл этой суммы будет непонятен, т.к. именно размерность определяет физический смысл
Ого! Это откуда у вас много старых словарей?😲
Подпишусь на вас на всякий случай, наверняка же об этом будете писать - а мне такое жутко интересно 😎
Просто ChatGPT по подписке за $20.
Но какого-то готового сценария я не дам, т.к. они очень плохо воспроизводятся в ИИ. Может вылезти какой-то странный косяк - то ИИ скажет, что у него отключены библиотеки для работы с изображениями, то будет стабильно генерировать документ, заполненный черными квадратами, то будет создавать pdf из одной одинаковой страницы и на просьбу наполнить их инфой будет всё равно выдавать тот же кривой пдф 😬
Общая схема такая - берете одну типичную страницу документа и на ней тестируете разные подходы - превратить в текст, в doc, в латекс, в pdf, нарезать картинками и вставить в html или сразу сделать готовый html и т.п.
Лучше всего работает вывод текстом непосредственно в сообщение чата - в нем ИИ меньше всего накосячит - с дальнейшей обработкой этого текста следующими запросами и перенос вручную в docx-файл с нужным вам форматированием
Позволяют. Ещё и оформят красиво в любом формате и картинки нарисуют прям по тексту. Я так запихиваю в нейросети старые fb2шки Лукьяненко и получаю на выходе pdf рендер идеального размера под любой экран, с любимым шрифтом и завораживающими иллюстрациями
То же самое и с BI, например. Красивая диаграмма нужна, чтобы быстро очертить проблему. А изучать её можно только по полотнам экселевских табличек - и никакой серьезный стратег или аналитик никогда не будет испытывать дискомфорта, глядя на лист А2, заполненный цифирками 9 шрифтом - для них они гораздо информативнее любой инфографики.
Не страшно вам там работать, после уголовки на Мацоцкого? А то завтра окажется, что архитекторы спроектировали слишком дорогую архитектуру для ФНС.
Проблема обучающихся не в том, что они не программируют во время туториалов - а в том, что их проблемы и ошибки очень часто находятся не просто за пределами туториала, а вообще за пределами их текущей предметной области.
Условно говоря, если ты перепутал = и == в условном C++, то ты получишь такой жуткий набор ошибок, для понимания которых тебе потребуются знания всего - от низкоуровневой архитектуры распределения памяти до системы обработки исключений на уровне ядра. Плюс глубокое понимание логики работы компилятора, которое позволит таки понять, что злобный С++ не пытается взорвать твой комп - а всего лишь реагирует на неправильный символ в неправильном месте.
И если ты кодер неопытный, то основная часть гимора связана с неглубоким пониманием того, что работает сложнее, чем кажется на поверхностный взгляд. И туториалами это не решить - потому что твоя задача всегда немножко отличается от туториала, и это немножко, как правило, оказывается настолько критичным, что требует отдельного туториала - а ученик, как правило, даже и не понимает, в чём проблема!
И программировать больше - это тоже не поможет, если ты тупо нажимаешь кнопочки вслед за говорящей головой. Потому что завтра на работе тебе надо будет нажать ещё одну кнопочку, про которую не говорила говорящая голова - и эта одна кнопочка положит всё твое обучение набок.
Поэтому лучшим способом обучения пока что остаётся обучение на реальных проектах с реальным учителем, который сможет давать быстрые ответы на внезапные вопросы. Если это сможет делать нейронка - то тоже хорошо, но пока что опыт показывает, что они могут ещё больше запутаться сами и запутать обучающего.