Какие логарифмы?! Мы ничего не ищем, мы проходим все элементы. Проходить массив (в ABAP это внутренняя таблица) можно только за O(n). Проход двумерного массива будет (на ABAP вложенные таблицы) равен, если быть педантом, O(n*(1+m)), трехмерного - O(n*(1+(m*(1+k)))).
Пусть m=n=k=10, тогда классический массив будет O(1000), а на внутренних таблицах - O(1110). То есть разница в производительности 11%. Пусть теперь m=n=k=100, тогда кл. массив будет O(1000000), а на вн. таблицах - O(1010100). То есть разница уже всего лишь в 1%. То есть чем больше общее кол-во элементов в массиве, тем меньше будет разница в производительности между классическим массивом и ABAP-овским эквивалентом. Так что не надо лохматить бабушку!

Ну и создавайте структуру динамически, кто мешает то. Будет вам internal table с динамическими полями, в чем, собственно, проблема-то ?

Про смех в налоговой - это на небезызвестный форум бухгалтеров. Там вам как расскажут - сами обхохочетесь.

Выкладка для массива абсолютно правильная. Только массив <> внутренней таблице и гложут меня сомнения, что SAP получает значение {n;m} за О(1). Чтобы это утверждать нужно знать способ представления внутренней таблицы в памяти и способ чтения из нее. Так что я склонен думать, что это похоже на O(n*(1+m)*k). Где k будет О() для алгоритма чтения из структуры данных. Если k <> log^n, то я не буду настаивать. Но в линейность функции О(k) мне верится с трудом.

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

Я что-то не сразу понял логику реализации murmur в его коде. Да, там нет ограничений по осям. Только ваши nested internal table там тоже отсутствуют. У него просто таблица, где по ключу из двух полей находится значение. Что у него куда вложено?

Ну решите свою задачку. Пусть тогда будет неизвестными будет или количество товаров или их цена. Ставки НДС 0, 10, 18. В любом другом случае сумма налога будет считаться по моей формуле или по ее производной.

Ну хорошо, заплатили поставщику, поставщик заплатил НДС. Как это связано с "Ну вот есть счет, его оплачивали частями. В счете был НДС. Надо отражать в отчетности тот самый ндс пришедшийся на частичные оплаты."?

Кодер, с вами очень тяжело вести диалог. Если вам просто лень, приводить вменяемою аргументацию ваших заявлений, то зачем вообще делать эти заявления?

Судя по вашим сообщениям, для вас это - нормально. Пожалуй даже "не сразу" там лишнее

повторю его код

Каждая завпись lt_array - это внутренняя таблица.
При необходимости увеличить размерность дальше - по индукции.


Я свою задачу отлично давно решил. Ваша формула и ее модификации под нее не подходят. Там используется деление. Задача типовая при расчетах различных сумм НДС.


Оплата счета поставщика может производится частями в различных налоговых периодах. Исполненные платежи следует учитывать для расчета уплаты\возмещения ндс. Т.е. найти сколько вот в этом именно платеже было НДС. Исходный НДС был в самом счете. Ну и т.д. в самых разных вариациях.

Глядя на ваш пример со статистической задачей, я вижу что вы не внимательно читали тему для розжига. Речь шла не о математических, а о финансовых задачах (те самые задачи "с точностью до копейки"). Понятно, что второе - подвид первого. Но со своими тонкостями. Поэтому решать дифуры в абап - да, извращение. Для этого есть что-то свое (привет многофункциональным инструментам, но, кажется, с дифурами лучше справится матлаб, мапл и т.д.)

Не понял, что хотел доказать жулик вот этим, но справится с ABAP у него явно не получилось
[quote="жулик"]Я сознательно не стал предлагать использовать массив произвольных типов данных для сравнения возможностей, где в строка может быть определена множеством произвольных типов, включая другие массивы.[/url]
То есть вложенные массивы в ABAP не погуглили

Что-то вы слишком нервно реагируете. Замете, что я, вопреки моим ограниченным способностям, на личности не переходил.

Я про первый пример написал. Как этот (второй) решает задачу я так до сих пор и не понял. Может я конечно туплю, я уже несколько лет не писал на АВАРе, но в чем логика? Мы объявили список интов и назвали его TRow. Потом переназвали его TArray. Какую структуру данных мне будет возвращать код. Мне кажется, что это будет одиночное поле типа инт. Я ошибаюсь?

Блестящая аргументация!

Так я в первом посте и написал, что деление только в задачах распределений.

Пример был из линейной алгебры. Дифуры, вроде бы, в мат.анализе. А от решения проблем с округлениями можно уйти ведя учет на целочисленных типах. Через целые типы большинство банков работает.

Только суть даже не в уравнениях, а в том, что оптимизационные задачи решаются более сложными средствами, чем те, что может предложить АВАР. Есть целый ряд задач оптимизации и прогнозирования за которые в АВАР среде лучше просто не браться.

Object[] anyData = new Object[n];

Это пример линейного массива на Java, который позволяет хранить: строки как строки, числа как числа, файлы как файлы и т.п.
Напомню, что все объекты и примитивные типы (переменные) являются наследниками Object. Т.е. я могу делать так:


Как мне такое сделать в АВАР?

Никаких переходов на личности. Исключительно мнение о ваших сообщениях в треде.

Да, ошибаетесь. В примере murmur - действительно а-ля 2-мерный массив получается. При необходимости можно продолжить вложенность и получить большую размерность (я же говорю - по индукции). Объявить тип TCube который является внутренней таблицей, у которой каждый элемент это TArray. При необходимости - повторить дальше.

Атож! Вы думали я буду полностью вам расписывать задачу? Не, не буду. Если вы сами не работали с отчетностью НДС, то я не вижу смысла вам это расписывать


Это ведь ваши слова в сообщении Ср фев 17, 2016 11:03 am ? Налоговая отчетность - не редкость, это одна из центральных тем учета. В ней деление используется постоянно. Опровергать будете?


Дифуры я привел как гиперболизированный до крайности пример мат.расчетов.
Целочисленные типы не спасут. Спасает именно реализация внутри правил округления.
Вы не поверите, задачи оптимизации вполне себе решаются на абапе. Да, он живет исключительно в erp sap. И да, на нем внутри реализована оптимизация(балансировка) в модуле производства и проч. аналогичные процессы оптимизации. В части стат. задач: на нем же реализован расчет IRR, например.



Использовать тип reference to data.

Как правильно заметил Кодер, это всего лишь массив ссылок

Значит ошибаюсь. Если бы я не ошибался, то сидел бы в казино, а не на форуме.

С НДС работал, но не как консультант. Самое разумное правило для меня было считать оплату НДС поставщика после оплаты товара. Так мне было проще потом подавать на возмещение. Тем более, что в срок не уложиться сложно. А оспаривать отказ в возмещении гораздо сложнее и программирование тут ни при чем.

Буду:


Спасут. Представьте, что вы ведете учет в копейках. Тогда у вас будет:
5/2 =2 -> целая часть
5%2 = 1 -> хвост, который докидывается в одну из половин.
Если брать отношения между клиентом и банком, то копейка достается банку. Если между счетами клиента, то первому по порядку счету.
Именно по этому сказки про хакеров, которые поимели копеечки с округлений - бред.

Оооо!... РР и оптимизация - мои любимые темы, а обсуждать линейную регрессию в SAP APO для функции f(x)=sin(x) мое любимое занятие. Можем завтра всем форумом вспомнить формулу наименьших квадратов и рассчитать O(n) в этой функции.

Я этого не знаю. Если это действительно работает, то я соберу узелок и уйду по росе на другой форум. В scala тоже не все хорошо с массивами.

@Удав:
Какое значение примет ls_data-ref в отладке? 5?

т.е. если после этого кода у меня будет строка кода:
Я после этого смогу сделать:
и вернуть все значения?

(смотрит мутным взглядом): 1(одна) копейка%118. Куда хвост относить будем?


А может вы сперва с поиском в гугле, пользованием хелпа и пониманием термина "по индукции" разберетесь? Думаю после этого вопросов у вас станет гораааздо меньше!

2 Удав: проводить ликбез по абапу в ветке про работу - харам. Так что я пожалуй - пас. И так день нажористый получился. Так и попкорн скоро кончится