Там ошибка у всех этих средств измерения мама не горюй, чтобы можно было без GNSS
Да, баз периодической коррекции по GNSS эти ошибки накапливаются.
Совместное использование GNSS и инерциальной навигации ощутимо повышает точность позиционирования (например, данные инерциальной навигации могут использоваться в фазе предсказания в фильтре Калмана), но только инерциальная навигация без GNSS не работает.
В вертикальной ориентации все еще хуже - там эта хтонь занимает 3/4 экрана. И ее постоянно надо смахивать.
Оптимально - вообще убрать. Нужен поиск, маршрут, навигатор. Причем, это не должно болтаться на экране, а появляться по нажатию на кнопку. И убираться.
По технической части все уже сказано неоднократно.
Ошибки округления (см. рекуррентное соотношение Мюллера) при множественных операциях с плавающей точкой (вычисление процентов, в т.ч. "сложных процентов" и процентов на проценты, конвертация валют и т.п.).
Ошибки переполнения.
Производительность при высоких нагрузках и больших объемах данных (сотни миллионов банковских операций в сутки, сотни миллионов операций, в т.ч. связанных с начислением процентов, при закрытии банковского дня)
Причем финансовыми вычислениями на основе float математики занимаются почти все, например я видел вагон реализаций корзины интернет магазина, и ни одна из них не делала вычисления базой (а это единственный способ имея php+js использовать честный numeric)
Финансовые вычисления это прежде всего банки, страховые, налоговые.
Не только. Кроме всякой подсветки синтаксиса, автодополнений и прочего есть еще, например, окошко outline
где показывается структура модуля с которым работаешь.
Есть работа с удаленным сервером. Я вот пишу под IBM i - там без возможности работать с удаленным сервером очень скучно - не все используемые объекты есть на локале, какие-то инклуды могут быть на удаленном сервере (и тот же VSCode + IBM i Development Pack позволяет их посмотреть без загрузки на локал).
Бывает что нужно работать с экранными формами которые пишутся на DDS (Data Defenition Specifications)
И для них есть preview (что тоже очень удобно)
Есть работа с гитом, например, get line history - история изменений конкретной строки кода
Есть git graph
Если работаешь с документацией в adoc, опять же, есть режим preview
Т.е. на 99% все можно делать внутри одного IDE. Просто установкой нужного набора плагинов.
Сколько времени уйдет на то, чтобы хоть как-то приблизить VIM к такому набору возможностей?
Тогда надо сразу предупреждать крупными буквами что вычисления приблизительные, не соответствуют банковским правилам. Только оценка.
За ссылки на COBOL спасибо)
Да не за что :-)
Если интересно, есть еще. Уже мое (почти 9 лет в этом кручусь, правда, моя тема комплаенс, клиентские данные всякие террористы-экстремисты, санкции, риски и т.п., счета-платежи практически не бывает в работе, этим другие команды занимаются).
Экзотика, но ы РФ на этом работали (на уровне центральных серверов и ядра АБС) Райф, Росбанк, Альфа (и Альфа-Страхование), Ак-Барс. Мы (Альфа) пока еще на ней продолжаем, про остальных не в курсе.
Какое-то время назад таки машины были еще в ПФР и РЖД. Сейчас не в курсе что там, скорее всего нет уже.
А что это в вашем случае? Рисователь каких-то цифирек? А потом пользователь будет удивляться почему ваш калькулятор показывает одно, а банк "немножко другое"?
Если бы беретесь за какие-то финансовые расчеты - делайте это по правилам, принятым для финансовых расчетов. Или не делайте вообще.
По поводу математики - все суммы в банковских БД обычно хранятся в миноритарных единицах. Формат полей - типы с фиксированной точкой (обычно - decimal, есть еще numeric, но там внутренне представление другое, decimal компактнее).
В подавляющем большинстве случаев хватает decimal(15, 0), в исключительных - decimal(23, 0).
В языках, разработанных специально для коммерческих вычислений (COBOL, RPG...) эти типы нативно поддерживаются самим языком (безо всяких костылей типа BigDecimal). В RPG decimal -> packed, numeric -> zoned. Естественно, что там же поддерживается и вся арифметика, включая операции с бухгалтерским округлением (в RPG просто пишем eval(h) a = b / c вместо a = b / c)
Также следует обратить внимание на возможность переполнений. В системах, ориентированных именно на коммерческие вычисления переполнение вызывает системное исключение (как деление на ноль). Вам же придется за этим следить руками. Обычно объявляется временная переменная с максимально поддерживаемой размерностью, результат заносится туда, потом проверяется, не превышает ли он размерности целевой переменной и только в случае положительного ответа уже переносится в целевую.
Производители этой одноразовой продукции нынче локомотив нашей экономики, т.к. для них государство денег не жалеет, включая денег на зп. Платят там даже рядовому персоналу так хорошо что квартиры с машинами хватает покупать.
Это срабатывает кратковременно, для удовлетворения отложенного спроса. А когда квартиры-машины заканчиваются, а новых не завозят - не строят т.к. остальные отрасли в глубокой дупе...
И те деньги, которых "не жалеет государство" фактически перестают работать. Они вроде и есть, но купить на них становится нечего. А дефицит только подстегивает инфляцию.
Высокая ключевая ставка, высокие налоги, производство, мягко говоря не того, что дает прибыль ("одноразовая" продукция которая сразу же "сжигается" понятно где)... Тут много чего можно перечислять, но в основном вот это.
А банки... Они заложники регулятора (ЦБ). Один из основных источников дохода банка - привлекать деньги на депозиты у одних и давать их в кредит другим. Проценты по кредиту немного выше процентов по депозиту, но и то и другое достаточно жестко привязано к ключевой ставке.
Когда ключевая ставка высокая, проценты по кредиту высокие, объемы выдачи падают. Но объемы привлечения депозитов растут. Для банка это не выгодно т.к. денег вроде бы и много, но они лежат мертвым грузом и не дают прибыли.
Дочка Инженер-Теплотехник по диплому. Плюс сама уже кучу всяких допусков получила (по электрике и еще чему-то там). И в проектных конторах работала и в УК (главный инженер). Работы дофига, работать некому (говорит что много приходится самой делать что по должности должны делать подчиненные которых не хватает), а денег так себе платят...
«Цивилизация статуса» (1960) — научно-фантастический роман Роберта Шекли, описывающий планету-тюрьму Омега, куда ссылают преступников с Земли. Это жестокое общество, построенное на строгой иерархии (статусе), где каждый вынужден бороться за выживание, а власть удерживается за счет неравенства и невежества
Да, баз периодической коррекции по GNSS эти ошибки накапливаются.
Совместное использование GNSS и инерциальной навигации ощутимо повышает точность позиционирования (например, данные инерциальной навигации могут использоваться в фазе предсказания в фильтре Калмана), но только инерциальная навигация без GNSS не работает.
Поддержу на 146%
В вертикальной ориентации все еще хуже - там эта хтонь занимает 3/4 экрана. И ее постоянно надо смахивать.
Оптимально - вообще убрать. Нужен поиск, маршрут, навигатор. Причем, это не должно болтаться на экране, а появляться по нажатию на кнопку. И убираться.
По технической части все уже сказано неоднократно.
Ошибки округления (см. рекуррентное соотношение Мюллера) при множественных операциях с плавающей точкой (вычисление процентов, в т.ч. "сложных процентов" и процентов на проценты, конвертация валют и т.п.).
Ошибки переполнения.
Производительность при высоких нагрузках и больших объемах данных (сотни миллионов банковских операций в сутки, сотни миллионов операций, в т.ч. связанных с начислением процентов, при закрытии банковского дня)
Ссылок тут уже было предостатчоно.
Ну я как-бы немного в курсе как оно там работает. Причем, на уровне центральных серверов. Ядра АБС.
И что там? Каждый день пересчитываются проценты (кредиты/депозиты)? Есть мультивалютные проводки (в курсе как они организованы) ?
В курсе что в банке баланс сводится каждый день (закрытие банковского дня)? И он должен сойтись.
Все это сильно сложнее чем просто просуммировать товары в корзине.
Кривая реализация на костылях не означает нормальность. Нормально - использовать наиболее подходящий для решения задачи инструмент.
Финансовые вычисления это прежде всего банки, страховые, налоговые.
И реализуются они точно не на "php+js".
Не только. Кроме всякой подсветки синтаксиса, автодополнений и прочего есть еще, например, окошко outline
где показывается структура модуля с которым работаешь.
Есть работа с удаленным сервером. Я вот пишу под IBM i - там без возможности работать с удаленным сервером очень скучно - не все используемые объекты есть на локале, какие-то инклуды могут быть на удаленном сервере (и тот же VSCode + IBM i Development Pack позволяет их посмотреть без загрузки на локал).
Бывает что нужно работать с экранными формами которые пишутся на DDS (Data Defenition Specifications)
И для них есть preview (что тоже очень удобно)
Есть работа с гитом, например, get line history - история изменений конкретной строки кода
Есть git graph
Если работаешь с документацией в adoc, опять же, есть режим preview
Т.е. на 99% все можно делать внутри одного IDE. Просто установкой нужного набора плагинов.
Сколько времени уйдет на то, чтобы хоть как-то приблизить VIM к такому набору возможностей?
Тогда надо сразу предупреждать крупными буквами что вычисления приблизительные, не соответствуют банковским правилам. Только оценка.
Да не за что :-)
Если интересно, есть еще. Уже мое (почти 9 лет в этом кручусь, правда, моя тема комплаенс, клиентские данные всякие террористы-экстремисты, санкции, риски и т.п., счета-платежи практически не бывает в работе, этим другие команды занимаются).
Современный RPG — что может и зачем нужен
Способы работы с БД DB2 в языке RPG на платформе IBM i
Экзотика, но ы РФ на этом работали (на уровне центральных серверов и ядра АБС) Райф, Росбанк, Альфа (и Альфа-Страхование), Ак-Барс. Мы (Альфа) пока еще на ней продолжаем, про остальных не в курсе.
Какое-то время назад таки машины были еще в ПФР и РЖД. Сейчас не в курсе что там, скорее всего нет уже.
А что это в вашем случае? Рисователь каких-то цифирек? А потом пользователь будет удивляться почему ваш калькулятор показывает одно, а банк "немножко другое"?
Если бы беретесь за какие-то финансовые расчеты - делайте это по правилам, принятым для финансовых расчетов. Или не делайте вообще.
По поводу математики - все суммы в банковских БД обычно хранятся в миноритарных единицах. Формат полей - типы с фиксированной точкой (обычно - decimal, есть еще numeric, но там внутренне представление другое, decimal компактнее).
В подавляющем большинстве случаев хватает decimal(15, 0), в исключительных - decimal(23, 0).
В языках, разработанных специально для коммерческих вычислений (COBOL, RPG...) эти типы нативно поддерживаются самим языком (безо всяких костылей типа BigDecimal). В RPG decimal -> packed, numeric -> zoned. Естественно, что там же поддерживается и вся арифметика, включая операции с бухгалтерским округлением (в RPG просто пишем eval(h) a = b / c вместо a = b / c)
Работа с float/double, а еще итеративная, может преподнести забавные сюрпризы (см. рекуррентное соотношение Мюллера).
Вообще, про коммерческие вычисления было уже
Заложники COBOL и математика. Часть 1
Заложники COBOL и математика. Часть 2
Также следует обратить внимание на возможность переполнений. В системах, ориентированных именно на коммерческие вычисления переполнение вызывает системное исключение (как деление на ноль). Вам же придется за этим следить руками. Обычно объявляется временная переменная с максимально поддерживаемой размерностью, результат заносится туда, потом проверяется, не превышает ли он размерности целевой переменной и только в случае положительного ответа уже переносится в целевую.
Это если все делать правильно.
Тут речь не про редактирование текстовых файлов, но про написание кода. А это поболе чем просто редактировать текст.
Экономические законы давно уже не работают в чистом виде. На первое место вышла политика и личные амбиции тех кто ей рулит.
Там тоже все проседает...
Это срабатывает кратковременно, для удовлетворения отложенного спроса. А когда квартиры-машины заканчиваются, а новых не завозят - не строят т.к. остальные отрасли в глубокой дупе...
И те деньги, которых "не жалеет государство" фактически перестают работать. Они вроде и есть, но купить на них становится нечего. А дефицит только подстегивает инфляцию.
Ну я бы так сказал - нет проблем, характерных для промышленности и сферы услуг. Но свои проблемы тоже есть.
Да, нужно смотреть сколько остается после всех регулярных платежей. Т.е. приводить к уровню цен и покупательной способности.
В этом смысле полностью согласен. Тут классическая формула" Отрицание - Гнев - Торг - Депрессия - Принятие
Высокая ключевая ставка, высокие налоги, производство, мягко говоря не того, что дает прибыль ("одноразовая" продукция которая сразу же "сжигается" понятно где)... Тут много чего можно перечислять, но в основном вот это.
А банки... Они заложники регулятора (ЦБ). Один из основных источников дохода банка - привлекать деньги на депозиты у одних и давать их в кредит другим. Проценты по кредиту немного выше процентов по депозиту, но и то и другое достаточно жестко привязано к ключевой ставке.
Когда ключевая ставка высокая, проценты по кредиту высокие, объемы выдачи падают. Но объемы привлечения депозитов растут. Для банка это не выгодно т.к. денег вроде бы и много, но они лежат мертвым грузом и не дают прибыли.
Дочка Инженер-Теплотехник по диплому. Плюс сама уже кучу всяких допусков получила (по электрике и еще чему-то там). И в проектных конторах работала и в УК (главный инженер). Работы дофига, работать некому (говорит что много приходится самой делать что по должности должны делать подчиненные которых не хватает), а денег так себе платят...
Хоть бы что новое придумали...
Да, в случае наличия семьи нужен некоторый гарантированный доход. А это точно не про личные проекты.