На счет обновления не помню точно, возможно сам xmind проверяет новые версии. А если вручную, загружаете deb-пакет и запускаете его установку. У самого нативная Убунта, не знаю какое в минте менеджер пакетов используется, если убунтовский software-manager, он сам определит версию deb и предложит обновить или переустановить.
Удалять как и любое другое ПО, через любой удобный менеджер пакетов: apt, synaptic, software-manager…
В таком случае вариантов не очень много, я бы даже сказал нет совсем. В xml разве что ЦБ отдает курсы валют, но это не Forex. Таблицы котировок можно найти в более-менее пригодном для парсинга виде на сайтах различных форексных контор или информ агентств: например, МФД.
С видел этот класс, но сходу так и не разобрался как его использовать — какие методы и с какими параметрами. Я не большой знаток C#. В любом случае проблема была не в это. Но, в любом случае, спасибо за ответ!
как минимум — писать некому. Я реалист, понятное дело, что выбрав движок хранилища мне придется смириться с его недостатками (у любого варианта будут свои плюсы и минусы), но все же не придется базовый функционал изобретать.
NoSQL подкупает объектами. Например, если взять локальные экстремумы, их было бы достаточно найти один раз, после чего добавить к соответствующему объекту ряда данных метку или параметр. В принципе и в SQL можно объект запихнуть, но вот работать потом с ними придется на уровне приложения.
Я не против SQL, как такового, да и не говорю, что в данной задаче он не применим… В задачах, которые я уже с его помощью решал, приходилось много работы перекладывать на приложение, т. к. быстрых SQL-решений найти не удалось. Исходя из этого и появилась идея о том, что возможно есть другие движки хранилищ данных, которые бы лучше справились с задачами.
Самое сложное условие я даже предположить не могу ;) т. к. фактически мне требуется разработать набор базовых функций поиска по условию, а в дальнейшем данные функции могут комбинироваться в произвольные конструкции. Из чего следует, что базовые функции должны быть максимально быстрыми, а так же поддерживать оптимизацию в сочетаниях друг с другом, так чтобы итоговый алгоритм выполнялся в ограниченное время. Тем более, что показанный в топике числовой ряд будет далеко не единственным.
Да, это биржевые котировки, только у нас собственные алгоритмы и матстат не требуется. Собственно наши фильтры будут строится на взаимных отношениях котировок в зависимости от их положения во времени. Т. е. скорее потребуются всевозможные варианты поиска по условиям и перебор вариантов, но хотелось бы часть работы, видимо поиск, переложить на движок БД.
Да, с подзапросами, найти локальный максимум достаточно просто (особенно если индексы, как в условии идут последовательно и соседние отличаются на единицу, хотя в реале это будет далеко не так), но желательно обойтись без них, т. к. я упомянул в топике, что это первое что пришло на ум и условия могут быть и будут значительно сложнее.
Найти элемент, который больше предыдущего и следующего. Да, сейчас заметил, что в топике неправильное условие записал. Правильно так: Xi+1 < Xi > Xi-1.
А не подскажете, есть ли примеры реализации чего-нибудь подобного на Монге? Из key=>value, я, если честно, только memcached знаю, в смысле работал с ним, и если брать именно его, получается вся выборка будет происходить в приложении, а хотелось бы переложить эту задачу на движок базы. Или я отстал от жизни? ;)
Не вопрос, просто не знаю на что смотреть. Первое, что приходит на ум — Монга, но т. к. я с ней не работал, не уверен, что в ней можно это реализовать и насколько это будет удобно, потому и появился данный топик.
Грамотное умение составлять — всегда рулит, но, имхо, SQL, как раз и не подходит. Не представляю каким образом, скажем в мускуле, найти ближайшее максимальное значение, относительно текущего, индексы которого меньше индекса текущего… Извернуться, конечно, можно, но уж больно нетривиально будет.