Сколько я помню вычислительные методы, то берут некоторую величину допустимой погрешности и начинают последовательно "улучшать" модель и при этом считать разность результатов между шагами. Когда разность абсолютно опустится ниже выбранной погрешности, то считаем, что посчитали достаточно и процесс останавливается. Под улучшением может быть выбор коэффициентов с корректировкой, дробление разбиения полигонами, увеличение степени многочлена и т.п.
Тут есть такое?
Кстати такой подход работает если есть обоснование, что процесс сходится. А то ведь и расходящийся ряд так можно посчитать. Или машинное округление привнесет сюрприз из-за неустойчивости процесса.
Можно посмотреть на это так. Мы вводим понятие комплексных чисел и говорим, что i это корень уравнения x^2+1
При этом мы прекрасно понимаем, что корней у него два. Так какой из корней все таки мы обозначили за i? Неважно. Какой бы не обозначили - получим поле комплексных чисел. Правда они будут зеркально симметричные эти два поля.
Ни откуда не следует, что пока вы "стираете" нули справа у вас не "вырастают" единицы слева быстрее, пусть и не постоянно, но в глобальном смысле - быстрее. В конце концов при начальном 27 мы достигаем в пике 9232 и совершенно неясно, что обязательно рост прекратится. Думаю тут без количественных оценок нельзя обойтись будет.
И да, бесконечный рост необязателен - единственность цикла 1-4-2 непонятна
Мы говорили не про функциональные типы даже. А про то, что декларативный подход все таки удобнее - он компактнее и выразительнее, спасибо, что ты это это признал
И вот в бухгалтерскую базу приходит документ. Бухгалтер считает, что он отражен не совсем корректно с его точки зрения. Что-то меняет в нём. После этого в управленческой базе его перепроводят (даже не затрагивая данные важные для бухгалтерии). И документ снова выгружается в бухгалтерскую базу в первоначальном виде, затирая все что сделал бухгалтер. Бухгалтер недоволен.
Потому что надо было не документ менять, а его настройки. Но изменив настройки, надо все равно перевыгрузить документ
Так это и есть тренд. Всюду (Java, python, JavaScript, kotlin, .net) для работы с коллекциями используют методы с передачей в них функциональных типов. А в 1с кстати этого нет до сих пор
А вот это уже очень серьезно. Насколько мало мы знаем в алгебраической геометрии. Насколько велико многообразие таких преобразований?
Так там нет связи один-к-одному. Разным дифференцируемым отображениям R^n->R^n может соответствовать один определитель как функция R^n->R
Что такое "односвязность определителя и функции"?
инициатор маркировки - правительство РФ, там под сотню НПА, изучай )))
У клиента какая-то древняя конфигурация? Посмотрите как сделано в современных релизах. Сам список доступен на том же сайте ИТС
Браться за работу, не вдаваясь в предметную область, и ожидать хорошего результата - разве это не безумие?
Сколько я помню вычислительные методы, то берут некоторую величину допустимой погрешности и начинают последовательно "улучшать" модель и при этом считать разность результатов между шагами. Когда разность абсолютно опустится ниже выбранной погрешности, то считаем, что посчитали достаточно и процесс останавливается. Под улучшением может быть выбор коэффициентов с корректировкой, дробление разбиения полигонами, увеличение степени многочлена и т.п.
Тут есть такое?
Кстати такой подход работает если есть обоснование, что процесс сходится. А то ведь и расходящийся ряд так можно посчитать. Или машинное округление привнесет сюрприз из-за неустойчивости процесса.
Подстановка корней это и есть проверка того, что значение удовлетворяет соотношению.
Кстати многочлен x, конечно отличается в разных точках, но очень странно описывать i через само себя.
Можно посмотреть на это так. Мы вводим понятие комплексных чисел и говорим, что i это корень уравнения x^2+1
При этом мы прекрасно понимаем, что корней у него два. Так какой из корней все таки мы обозначили за i? Неважно. Какой бы не обозначили - получим поле комплексных чисел. Правда они будут зеркально симметричные эти два поля.
Попытка поменять проц самостоятельно это делегирование? Ты противоречешь сам себе
асинх же есть?
https://wonderland.v8.1c.ru/blog/uluchsheniya-v-sintaksise-yazyka-1s-dlya-raboty-s-asinkhronnymi-funktsiyami/
Ни откуда не следует, что пока вы "стираете" нули справа у вас не "вырастают" единицы слева быстрее, пусть и не постоянно, но в глобальном смысле - быстрее. В конце концов при начальном 27 мы достигаем в пике 9232 и совершенно неясно, что обязательно рост прекратится. Думаю тут без количественных оценок нельзя обойтись будет.
И да, бесконечный рост необязателен - единственность цикла 1-4-2 непонятна
Мы говорили не про функциональные типы даже. А про то, что декларативный подход все таки удобнее - он компактнее и выразительнее, спасибо, что ты это это признал
То есть надо сказать бухгалтерии, что до момента Х не стоит лезть в выгруженные данные. Все верно?
Это хороший вопрос. Но раз вы сказали, что бухучет будет вестись в бухгалтерской базе - значит в ней меняет документ.
И вот в бухгалтерскую базу приходит документ. Бухгалтер считает, что он отражен не совсем корректно с его точки зрения. Что-то меняет в нём. После этого в управленческой базе его перепроводят (даже не затрагивая данные важные для бухгалтерии). И документ снова выгружается в бухгалтерскую базу в первоначальном виде, затирая все что сделал бухгалтер. Бухгалтер недоволен.
Потому что надо было не документ менять, а его настройки. Но изменив настройки, надо все равно перевыгрузить документ
Не принципиально?
Если внимательно посмотреть, то большинство кода 1с это всевозможные манипуляции с коллекциями. И каждый раз пишутся циклы, вложенные циклы.
А какая декларативность "та"?
А есть ли эти мелочи в 1с? Из-за этого в 1с как раз кода надо писать больше
Напиши в 1С функцию, которая по данной коллекции создает новую с отбором по полю "Сумма>0"
Вот декларативно в шарпе:
Опять, кто эти мы? Что такое нормальность?
Кто эти Мы?
Так это и есть тренд. Всюду (Java, python, JavaScript, kotlin, .net) для работы с коллекциями используют методы с передачей в них функциональных типов. А в 1с кстати этого нет до сих пор