Структура должна уметь хранить массив бесконечной мерность(1D,2D,6D, и т.д), алгоритм должен уметь создавать структуру и вывести конечные точки(1D массив, конечное измерение) в очередь
А можешь написать пример на псевдо-языке, как ты будешь работать с такими много-мерными массивами?
:
Тут надо побольше ограничений придумать. Чем больше ограничений тем проще будет реализация.
mkone112, ты же понимаешь, что когда мы говорим о недостатке, то мы имеем в виду
сравнительную категорию.
Нельзя говорить о недостатке в вакууме. Тоесть было некое эталонное приложение.
Например benchmark. И оно считает допустим модель IntelCore-i3 за 100%.
И дальше оно меряет скорость вычислений твоего ноута в мегафлопах на 1 ядре. Потом как-то перемножает
на количество ядер например (с логарифмом) потом как-то хитро добавляет скорость
операций с памятью и в конце выводит тебе что твой ноут соотвествует к
примеру 120%.
Вот. И у тебя появляется какая-то метрика. Дальше с этой метрикой уже можно что-то делать.
zeaovede, посмотри в отладчике браузера какой rest-запрос тормозит. Возмоно там идет работа с более сложным стеком чем PHP. Например идет обращение в базу. А база имеет свои лаги, которые живут своей жизнью.
Всякие там вакуумы, джобы и прочее.
Catmengi, как только массив примитивов покидает границы платформы (x86, Itanium, ARM)
у тебя появляется вопрос "endiannes", тоесть в каком порядке байты хранятся в машинном слове.
Стандарт С обходит этот вопрос стороной. Он - как-бы отдает это на откуп нижнему уровню
и ты должен заранее гарантировать что клиент и сервер будут не просто написаны на "C" но
и также будут иметь одинаковую архитектуру железа и порядка байтов в машинном слове.
вы - ошибаетесь. Банки, например его все еще используют. Более
того они его не спешат заменять на REST протоколы, потому что им
важно поддерживать механизмы описания спецификаций. И SOAP
все еще предоставляет такие механизмы.
Тут либо PHP плох, либо сам писатель. Следствием этой боли должен быть какой-то
SOAP клиент который решает задачу. Потому что со стороны это выглядит как
безсилие языка перед технологией.
Ну. Тема топика не про это. У вас может быть качественный JPEG и очень плохое,
прошедшее 100 преобразований PNG изображение. И тут недостаточно будет
мерять свойства конейнера изображения. Ну .. если-б я был автором вопроса
то меня как раз интересовало бы само изображение.
Для JPEG мы знаем эти артефакты. Есть размеры JPEG-фрейма (типа 8х8) и по этой границе
можно предполагать появление резких изменений уровня сигнала. И зная этот период
и частототу мы можем ее эффективно давить полосовым фильтром. И даже более
того, мы точно знаем фазу этого сигнала.
А можешь написать пример на псевдо-языке, как ты будешь работать с такими много-мерными массивами?
:
Тут надо побольше ограничений придумать. Чем больше ограничений тем проще будет реализация.