Короче вычислять ставку НДС по суммам в регистре выручки - зашквар: после закрытия месяца распределение по партиям дает какие-то артефакты (то ли из-за пересорта в ключах аналитики, то ли еще чо-то), в итоге какой-то мизерный процент вычисленных ставок получается со ставками 11, 12, 13 и т.д. до 19 % :)

неплохая прибавка к пенсии))

Зато ты сыт одет и обут

Это вы парни авиабилеты не видели, где до 3 ставок НДС на один билет может быть)))

Я отказался от этих вычислений и таки через регистратор сделал

К вопросу об НДС: помню пришло от налоговой требование  обосновать почему компания отнесла сою к бобовым и заплатила ввозной НДС 10% вместо тогдашних 18%

упс... а везде слышу, что "словари" - наше все. В каком случае в массиве может быть выгода? В каком алгоритме?
ЗЫ: Сколько уже заменено поисков по массиву ("а есть ли элемент в массиве") на получение по ключу в соответствии. И сложность со второго порядка превращается в первый.
Или вот товарищъ сделал цикл, добавляет элемент в массив и внутри цикла проверяет не добавлен ли он поиском по массиву. Всегда элементов до сотни, но тут появилось 20000. И все...

Всем привет. Кто-нибудь видел конфу для каршеринга? С модулем проверки сданной машины, повреждения и т.д?

зачем каршерингу конфа, если это сайт и мобильное приложение?

ну как минимум массив хранит информацию о порядке элементов, то есть можно обойти коллекцию в строго том же порядке, в каком они были туда помещены, также, по идее, добавление новых элементов в соответствие должно быть более тяжелой операцией чем у массива, соответтвенно двоичный поиск не всегда может дать выигрыш учитывая потери на первоначальное пополнение коллекции. ИМХО.

ну и в третьих, не всегда же требуется хранить парное значение, если мы получаем элемент по индексу то там и скорость будет выше и нет избыточности хранения данных. короче массив нужен ))

1. то что массив отсортирован, а соответствие нет - это заложенные свойства, а не достоинства/недостатки.
2. почему добавление ключа в соответствие тяжелая операция? не уверен как внутри ведет себя 1с... хэш ключа, адрес? из какого языка пришла такая инфа?
3. про какой двоичный поиск речь? по идее у объекта должен уже быть айди/адрес, по нему получаем пару.
4. ну бред же... Какой поиск по индексу, если индекс обычно не известен и везде в коде видим Массив.Найти()?
Про какую задачу идет речь понять не могу, где массив будет выгоден? Там где не нужно соответствие - да. А если нужно? А если нужен быстрый поиск по ключу? Приведите пример алгоритма, хоть намекните или опишите решение с помощью массива моего примера задачи выше.
Еще раз сформулирую наиболее часто встречающуюся Задачу, в которую любят лепить массив:
- перебрать коллекцию 10000 элементов, что-то с ними сделать, но при этом выполнить проверку (исключить) вхождения элемента в некую другую коллекцию из N элементов.
Так вот, если вторую коллекцию запихать в массив и проверку выполнять как М.Найти(), то это фактически еще один вложенный цикл. Выполнение будет условно в N раз дольше, чем с помощью словаря-соотвествия. Куда тут индексы массива пристроить?

Где-то слышал, что с какой-то версии питона, чтобы вставки/удаления не в конец массива были веселее, в движке держат сам список + словарь индексов (или что-то вроде этого), чтобы не двигать элементы. Это так, просто в тему...

ну на счет стоимости вставки нового элемента, надо протестировать. Я говорил в теории, смотрите, если вам надо добавтиь новый элемент в массив, вам нужно просто в худшем случае выделить память по уже известному адресу (последний элемент массива), тогда как при добавлении в соответствие, вам надо сначала найти тот элемент, который будет меньше текущего, и затем уже выполнить выделение памяти (если требуется). то есть массив это просто добавление, а соотвествие это поиск+добавление. Может быть я ошибаюсь конечно и коллеги меня поправят.

- ну это мы говорим о ресурсности самих объектов языка, а не какую скорость конкретных алгоритмов они обеспечивают. Это как говорить, что лопата всегда лучше грабель, не понимая какую задачу мы решаем. Лопата проще и точка. Нужна всегда лопата. А прозвучало это именно так ((
- вставка в соотвествие? хммм... вот тут услышать бы мнение из разных языков. Реально хз как в 1С, но если бы было так - это была бы жопа и добавление N млн элементов в массив и в соотв отличалось бы пропорционально количеству элементов раз. А такого точно нет. Ключи в соотвествие добавляются то ли в в конец, то ли в свободное место, то ли в отдельный адрес... Они же не упорядочены... Зачем поиск/вставки?
- всему свое место. Например, все кэши делаются на парах К-З. Получение Значения Ключа мгновенное из любого объема, не зависит от размера словаря, и это главное. Массив тут никак не применишь.

хм, я не знаю как они точно работают. ну например, на основании документа повреждений выставить счет, отправить на ремонт и тд.

мобильное приложение не отменяет учета же

работают на связке: сайт - мобильное приложение - бортовой компьютер - внутренний интерфейс для сотрудников. 1С тут не вписывается никуда, кроме ведения бух.учета в 1С:Бухгалтерия. Счета на почту валятся из бэкэнда сразу по завершении аренды автоматом. Никто их вручную никому не выставляет

по-моему у всех в счетах даже есть маршрут на карте картинкой. также автоматом списывают деньги с карты. Надо упоротться совсем, чтобы делать это через 1С

) понятно. спасибо