pi314

Тип зависит от типа используемых транспондеров, а возможности зависят от используемого софта (и, при стандартном раскладе - от знания или незнания пароля). Так что, просто так от балды скопировать чё-попало вряд ли выйдет ))

Андрей Пронин, Да, это проще простого - их делает MySQL Workbench по результатам EXPLAIN.

nklyuchnikovspb, Ну, я не разбирался конкретно с этой dlib, сейчас некогда. Но если речь о приведенном псевдопримере, то принцип предельно прост. Переменную my_object нужно вынести из тела метода в члены класса и сделать ленивую инициализацию. Иначе она действительно освобождается, как только поток покидает метод, и ее приходится всякий раз пересоздавать. Если экземпляр класса не уничтожается, то и созданный объект будет жить между вызовами.
Но, во-первых, если такое использование действительно возможно (повторяю, я не смотрел, что это за предиктор и т.д.) то разработчики библиотеки (а она, на первый взгляд, выглядит довольно ванильненько) наверняка позаботились о том, чтоб сделать соотв. метод в API, который это делает сам. А если не сделали, это может означать, что предиктор таки НУЖНО создавать всякий раз заново... словом, это уже все - спекуляции. Нужно разбираться с самой библиотекой.
А по второму варианту, как хранить "снаружи" (хотя это и очень странно, и антипаттерн и т.д.) - метод должен принимать параметром CustomClass, а результат возвращать не как bool, а как какую-нибудь обертку, в которой содержится и результат, и созданный (или просто заюзанный, от чего он, возможно, изменил внутренние состояния) объект CustomClass. Но, повторюсь - так никогда не делайте. За такое разработчиков API подкарауливают в темных переулках и проводят с ними воспитательную беседу на тему SOLID :)

Это похоже на какой-то отвратительный костыль (( Что за dlb, у нее есть внятная дока или исходники? Если эта dlb по странной причуде сама не хранит созданный предиктор, должен, по крайней мере, быть доступ к этому объекту, и перегруженные функции, принимающие такой объект (чтоб его можно было между вызовами хранить "снаружи")... Но это все выглядит невероятно странно и указывает на одно из двух: либо эта dlb говнокодовый примерчик, не пригодный для использования в данном юзкейсе, либо ее нужно таки правильно готовить ))

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

Наверное, все же "кАрдинально", хотя и тогда не совсем понятно, что такое "другая природа и структура". А достоверный критерий всегда один единственный: если может быть найдена, или можно доказать, что МОЖЕТ СУЩЕСТВОВАТЬ функция, выполняющая обратное преобразование, или же алгоритм, выполняющий это преобразование за конечное время.

Захар Шайков, Скажу, что вы пытаетесь переизобрести свечной анализ, придуманный японскими торговцами рисом еще в XVII веке )) И, что было бы невероятно полезно, прежде, чем пытаться придумывать "новые" алгоритмы, почитать о том, что люди уже напридумывали на эту тему. Пролистайте любой вводный курс по теханализу, и наверняка найдете там огромное количество вдохновения и гораздо более обоснованных мнений о том или ином подходе, чем те, которые могут быть высказаны на Тостере. Только, никому не доверяйте полностью, особенно, торговым площадкам ;)

Griboks, Да, верно, мы с вами говорим о разных вещах, причем, не протеворечащих друг дружке. Я просто пытался оставаться в рамках сформулированного вопроса: "Можно ли с точки зрения эффективности полученных знаний рассматривать участок графика как систему?" и истолковал "эффективность", как эффективность подхода для предсказания будущего, ибо, что же еще может быть интересно при анализе курсов, ну никак же не многообразие корреляций, наблюдавшихся в прошлом )) А при такой постановке вопроса мы, рано или поздно, неизбежно упремся в жесточайшую несправедливость окружающего нас мира, заключающуюся в том, что корреляция не тождественна причинно-следственной связи. Она может быть ее прямым следствием (как в случае с маятником), а может быть (как в случае с курсами) в диаппазоне от вообще мимо кассы и вплоть до того, что, с учетом обратной связи в системе, сама выступать фактором, влияющим на процесс. Типа, в прошлый раз финансовые прогнозы опубликовали в пасмурный день, и курс просел, сегодня погода так себе, новостей еще нет, но я, на всякий случай, начну продавать прямо сейчас, чтоб не опоздать. (А на меня посмотрят другие, и пошло-поехало...) Для анализа (с целью предсказания) таких процессов, по моему скромному мнению, гораздо эффективнее "вейвлеты" -> фракталы, волны Эллиотта и пр. "эзотерика", а Фурье пригоден лишь для выявления паттернов ))

Захар Шайков, Для анализа т.н. хаотических процессов, с которыми мы имеем дело при анализе курсов, подход совершенно оправдан и дает гораздо лучшие результаты, чем интуитивно очевидная (но неверная!) идея прямой экстраполяции прошлого на будущее. В качестве очень упрощенной аналогии возьмем банальный амплитудно модулированный сигнал радиостанции, где диктор читает новости. Исторические данные могут быть полезны, чтоб выявить сам факт и уточнить функцию модуляции, но никак не помогут нам предсказать поведение сигнала в будущем, т.к. оно, в основном, зависит от того, какое будет следующе слово в тексте сегодняшних новостей. Однако, это не значит, что мы совсем ничего не можем предсказать )) Если мы знаем язык, мы можем восстановить семантический->лексический->фонетический контекст (для этого нам понадобится гораздо более короткая история сигнала, чем "бесконечное прошлое") и с вероятностью гораздо выше "пальцем в небо" предсказать поведение сигнала в будущем.

Идеально было бы смотреть в прошлое бесконечно много

Очень смелое утверждение, если не уточнять, какой именно класс процессов мы хотим анализировать )) К сожалению, оно справедливо только для монотонно протекающих процессов, обусловленных конечным и константным(!) множеством влияющих на них факторов. В качестве примера, для которого это не работает, возьмем хотя бы колебания идеального маятника... для предсказания будущего нет никакой пользы от знания бесконечного прошлого - достаточно одного единственного полного периода. Что же касается курса одного актива к другому, утверждение неверно, т.к. множество влияющих на процесс факторов само по себе есть функция от времени. Грубо говоря, знание о том, что актив взлетел на х пунктов пять лет назад, ровно никак не поможет нам предсказать, что произойдет с ним в следующие 5 минут ))

Вопрос не тупой, но совершенно непонятный. Что значит "считать", считать откуда: с клавиатуры, из памяти, из com-порта?.. И в какой среде это нужно выполнить: на голом контроллере, с каким-нибудь BIOS или под какой-нибудь OC?.. Короче, миллион вариантов, что это может означать и, соответственно, как это сделать ))

Виктор, К слову: точность практически будет еще сильно зависеть от потребителя . Если лампа накаливания, то будет близка к рассчетной, а если импульсный блок питания, то будет ближе к "средней температуре пациентов по больнице" ))))

Какая именно технология RFID - КВ/УКВ? Это принципиально важно указать, чтоб можно было фантазировать дальше. Судя по описанному сценарию, похоже на пассивные УКВ метки (UPC-GEN2). Если так, то поздравляю: проблема может быть в чем угодно, от самих меток (разброс параметров в серии), материала "груза" и способа/места прикрепления к нему меток, пространственной ориентации меток по отношению к антеннам в момент прохождения, и вплоть до источников помех вокруг.
Большинство проблем решаются отладкой процессов (какие метки, как и куда крепят, как проносят/провозят груз). Если дело в самих метках, то либо сменить поставщика, либо проводить входной контроль качества. Для этого понадобится измерительное оборудование. Не знаю, о каких порядках цифр идет речь, но на всякий случай - нормальное оборудование позволяет контроллировать качество около 400-500 транспондеров в секунду (на ленте), и стоит от 15-20 к€.

UNy, Всегда пожалуйста. И еще совет, вдогонку - не чтитайте всякую лабуду, где про А и Б, сидевших на трубе. Читайте, где внятные и интуитивно понятные примеры из реального мира. ООП придумали для того, чтоб просто и логично моделировать объекты реального мира, и в нем все просто и естественно. Если кажется, что это не так, значит, автор учебника наводит тень на плетень и нужно читать другой ))

UNy, Все верно. Поэтому, так делают не просто от балды, а только в случаях, когда именно это и нужно. В примере, конечно же, приведен упрощенный вариант, чтоб показать суть самой возможности. Реально никто не станет создавать экземпляр В, если прямо тут нужен А, и есть возможность и необходимость его создать. Но это далеко не всегда так. Класс А может быть, например, абстрактным. Или, у него нет публичного пустого конструктора, а только конструктор с параметрами, нужных значений для которых у нас в этом месте просто нет, т.к. код, который мы тут пишем, не отвечает за создание экземпляра, а просто должен им воспользоваться... например, нам в метод передали ссылку на где-то-там-почему-то-созданный экземпляр типа В, а нам от него нужно всего-то поведение базового класса А. Короче, есть варианты.
И, потом, что конкретно значит "теряем"?.. Теряем мы слева от приведения типа, т.е. в переменной типа А, которой присваивается значение. В правой части (там где new B() ) мы ничего не потеряли. Если нам нужно и то, и другое, можно было бы написать так:

B b = new B(); //создали экземпляр наследника и сохранили ссылку в переменной
A a = (A) b;      //привели его к базовому классу и сохранили в другой переменной

b.sum(); //тут пользуемся функционалом наследника
a.sum(); //тут пользуемся функционалом базового класса

...или, если нужно просто единоразово, не плодя переменные, можно так:

B b = new B();
//...тут делаем что-то там с b...

//... а потом вдруг
((A)b).sum(); //пользуемся ей, как А

//...и дальше, как ни в чем не бывало, пользуемся b

странный вопрос... почему бы просто не спросить у заказчика или дизайнера, делавшего макет, и, в случае чего, скорректировать фикседпрайс? ))

UNy, Снаружи никто не знает, какие урезаются и урезаются ли вообще. И не должен знать, ибо инкапсуляция. Принадлежность объекта к какому-то классу - это "гарантия" только того, что у экземпляра есть некие методы, но не того, как именно они реализованы внутри. Да, есть, конечно, принцип подстановки Лисков, но о нем не все знают, а из тех, кто знает, не все используют :) Вот весь этот пример как раз и есть на тему полиморфизма: вызвали метод sum() наследника (класса В), получили разность, вызвали этот же метод предка (класса А), получили сумму. Объект один и тот же, метод тот же самый, а результаты разные. Приведение типа для того и используется, чтоб, грубо говоря, взять объект/экземпляр/переменную тиа В, но "воспользоваться" ей, как если бы она была типа А.

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

rosis, Да не, если нужно придумать - это запросто... Но я так понял, что нужно починить. А раз так, диагноз один единственный: нести в ремонт.
Все остальное будет дороже, муторней и закончится печальнее )))

Нести в ремонт.