Budżet: 7500 UAH Termin: 1 dzień
Zrobię to w ciągu jednego dnia, używając Clion. Wszystko wyjaśnię i wyjaśnię. W razie potrzeby szczegółowo opisuję pracę programu. Napisz do wiadomości osobistych
Нужно реализовать B+ дерево на c++. Лабораторная работа 1 курса. У самого не получается.
Понимаю идею, но возникли сложности с языком, не могу реализовать даже операцию вставки. Запутался в выделении памяти.
Задача: написать ОСНОВНЫЕ методы: вставка, удаление, и необходимые для них. Убедится, что проходят тесты на эти методы. + я хочу понимать весь код, поэтому нужна zoom встреча, на который вы бы могли объяснить как что написано(~1 час). После этого, я бы написал остальное: итераторы, операторы... ии вслучае проблем, снова бы обратился к вам за помощью.
Прилагаю readme файл, как что должно быть написано.
НЕ НАДО копировать код с интернета, т.к. код должен быть уникальным.
Кто готов, отпишитесь, более подробно объясню, потом уже скину начальный проект, тесты...
Желательно работать в Clion.
Дедлайн: как можно быстрей, хочется чтобы через 4 дня уже были insert+erase+основные тесты.
По цене, договоримся.
Текст задачи в readme.
# B+ дерево
## Потребность в блочных структурах данных
Организация памяти в вычислительных системах сложна и иерархична, с существенным ростом стоимости доступа к каждому следующему уровню.
Поэтому выгодными оказываются блочные схемы обращения к памяти - когда за раз читается относительно большой непрерывный блок данных, даже если это повлечёт
за собой дополнительный вычислительные затраты на его обработку.
Особенно актуальна блочная организация для хранения данных на HDD - скорость случайного доступа у дисков очень низка и выгода от чтения больших блоков
весьма существенна.
Пример:
* Процессор с частотой 1 Гц
* Скорость доступа к кешу процессора - примерно 10 тактов = 10 нс
* Скорость доступа к ОЗУ - примерно 100 тактов = 100 нс
* Скорость доступа к HDD (время перемещения головки) - примерно 10 мс - медленнее ОЗУ в 10^5 раз
## Идея
B+ дерево - это дерево с более высокой степенью ветвления (порядком), нежели двоичное. Внутренние узлы дерева порядка N могут иметь от ceil(N/2) до N потомков.
Порядок дерева - не меньше 3.
Корень дерева может иметь от 2 до N потомков.
Внутренние узлы дерева хранят только ключи и ссылки на потомков.
Листья дерева содержат ключи и значения, каждый лист может содержать от N/2 до N пар ключ-значение. Листья связаны в односвязный список, что позволяет эффективно
реализовывать поиск интервалов.
Подробнее можно ознакомиться с идеей B+ дерева в [статье википедии](https://en.wikipedia.org/wiki/B%2B_tree).
Другое описание см. [здесь](http://www.cburch.com/cs/340/reading/btree/index.html).
Основных отличия от двоичных деревьев несколько:
* узлы гораздо большего размера, хранят много ключей
* внутренние узлы хранят только ключи и ссылки на потомков, любой поиск сопряжён со спуском до листа
* листья связаны в односвязный список, что позволяет эффективно получать интервалы
Обычно размер узла делают достаточно существенным, чтобы читать данные большими блоками. Например, если на хранение ключа и ссылки на потомка требуется 32 байта,
размер узла - 4096 байт, то порядок дерева = 128. Если требуется хранить в таком дереве 10^7 элементов, то высота его будет варьироваться от 4 до 5 - то есть,
любой поиск будет сопряжён максимум с 5 чтениями. Сравните с бинарным деревом - у идеально сбалансированного дерева на 10^7 элементов высота будет равна 23.
## Постановка задачи
Требуется реализовать шаблонный ассоциативный массив с интерфейсом, во многом подобным `std::map`.
Предполагается, что все хранимые ключи уникальны (как и с `std::map`).
Нужно реализовать основные функции типичной коллекции:
* проверка размера и очистка
* провера наличия ключа
* поиск элемента по ключу
* прямой доступ к элементу по ключу
* добавление и удаление элементов
* поддержка задания произвольного компаратора
В основе реализации должно лежать B+ дерево. Его порядок не фиксирован и выбирается исходя из размера хранимых типов так, чтобы обеспечить фиксированный
размер блока, задаваемый шаблонным параметром класса дерева, значение по умолчанию - 4096 байт.
Предельная заполненной блока должна быть максимально возможной, например, если для обслуживания 1 ключа во внутреннем блоке
требуется 100 байт, то порядок дерева будет равен 40.
Допускается во внутренних узлах иметь дополнительные накладные расходы в виде размер ключа + размер указателя (т.е. при эффективной вместимости узла в `K` ключей,
отводить место под `K+1`), это может упростить реализацию.
Помимо этого предполагается, что внутренние узлы имеют место для хранения `K` ключей и `K+1` указателей, а также хранят количество присутствующих ключей.
Таким образом, `K` можно определить как `(BlockSize - sizeof(std::size_t) - sizeof(void *)) / (sizeof(Key) + sizeof(void *))`.
Листья имеют тот же размер, который используют для хранения пар ключ-значение, количества присутствующих пар и указателя на следующий лист.
Возможность задания произвольных типов ключей и значений нарушает идею "блочной" структуры данных: к примеру, `std::string` выделяет память под своё значение
самостоятельно и на это сложно повлиять. Тем не менее, по сравнению с `std::map`, такое B+ дерево всё-таки будет "блочным" - доступ к одному узлу даст множество
ключей, а не один.
Итераторы коллекции должны иметь категорию forward.
Допустимы следующие упрощения:
* можно игнорировать служебные расходы на организацию классов (например, для поддержки виртуальных функций); достаточно, если в заданный размер блока укладывается
всё явно определённое содержимое узла
* можно игнорировать то, что некоторые классы ключей или значений могут самостоятельно выделять память; достаточно упаковать в заданный размер блока сами объекты
ключей и значений (и иные вспомогательные поля классов узлов)
* разное количество ключей во внутренних узлах и листьях: размер блока распространяется на оба типа узлов, но если внутренние узлы помимо ключей содержат ссылки на
потомков, то листья содержат помимо ключей - объекты значений, размер которых может отличаться от затрат на представление ссылок
## Требуемый интерфейс
```c++
template <class Key, class Value, std::size_t BlockSize, class Less = std::less<Key>>
class BPTree
{
public:
using key_type = Key;
using mapped_type = Value;
using value_type = std::pair<Key, Value>; // NB: a digression from std::map
using reference = value_type &;
using const_reference = const value_type &;
using pointer = value_type *;
using const_pointer = const value_type *;
using size_type = std::size_t;
using iterator = ...;
using const_iterator = ...;
BPTree(std::initializer_list<std::pair<Key, Value>>);
BPTree(const BPTree &);
BPTree(BPTree &&);
iterator begin();
const_iterator cbegin() const;
const_iterator begin() const;
iterator end();
const_iterator cend() const;
const_iterator end() const;
bool empty() const;
size_type size() const;
void clear();
size_type count(const Key &) const;
bool contains(const Key &) const;
std::pair<iterator, iterator> equal_range(const Key &);
std::pair<const_iterator, const_iterator> equal_range(const Key &) const;
iterator lower_bound(const Key &);
const_iterator lower_bound(const Key &) const;
iterator upper_bound(const Key &);
const_iterator upper_bound(const Key &) const;
iterator find(const Key & key);
const_iterator find(const Key & key) const;
// 'at' method throws std::out_of_range if there is no such key
Value & at(const Key &);
const Value & at(const Key &) const;
// '[]' operator inserts a new element if there is no such key
Value & operator[] (const Key &);
std::pair<iterator, bool> insert(const Key &, const Value &); // NB: a digression from std::map
std::pair<iterator, bool> insert(const Key &, Value &&); // NB: a digression from std::map
template <class ForwardIt>
void insert(ForwardIt begin, ForwardIt end);
void insert(std::initializer_list<value_type>);
iterator erase(const_iterator);
iterator erase(const_iterator, const_iterator);
size_type erase(const Key &);
};
```
## Рекомендации
Данная структура данных весьма проста идейно, но её реализация оказывается довольно сложной. Причём эта сложность не алгоритмическая, а во многом связана с организацией
структуры на конкретном языке. Самая сложная операция - удаления. Попробуйте для начала отключить тесты, требующие операций удаления и реализовать только вставку.
У некоторых авторов возникает желание добавить горизонтальные связи между внутренними узлами дерева - лучше от этого воздержаться, т.к. только операция удаления может
получить от этого какой-то выигрыш, но для удаления вам всё равно понадобятся сложные вертикальные манипуляции и соседа можно получить через родителя.
Если допустить возможность временного переполнения внутренних узлов при вставке (см. выше про допустимые накладные расходы), то операцию вставки во внутренний узел
можно сильно упростить выделив две раздельные стадии - вставку и расщепление.
Говорят, что на викиконспектах ИТМО в описании операций над B+ деревом есть ошибки или неточности.
При возникновении проблем, попробуйте воспроизвести каждую из них по отдельности, написав минимальный юнит-тест (за хорошие тесты вы можете получить дополнительные баллы).
Budżet: 7500 UAH Termin: 1 dzień
Zrobię to w ciągu jednego dnia, używając Clion. Wszystko wyjaśnię i wyjaśnię. W razie potrzeby szczegółowo opisuję pracę programu. Napisz do wiadomości osobistych
Budżet: 1500 UAH Termin: 5 dni
Dzień dobry .
Mam doświadczenie w tworzeniu programów z różnymi strukturami danych.
Jesteśmy gotowi porozmawiać z Tobą o warunkach współpracy.
Dziękuję za uwagę.
Budżet: 1000 UAH Termin: 2 dni
Pozdrawiam, mam doświadczenie w wykonywaniu takich zadań, zrobię to w ciągu 2 dni
Wymagana jest разработка łatki do sterownika karty graficznej, rozszerzającej możliwości zarządzania adapterem graficznym poprzez dodanie dodatkowych ustawień użytkownika. Łatka powinna integrować się z istniejącą architekturą sterownika bez naruszania jego podstawowej funkcjonalności i zapewniać zgodność z obsługiwanymi wersjami systemu operacyjnego. Głównym celem jest zapewnienie bardziej elastycznego dostępu do parametrów, które są niedostępne w standardowej panelu sterowania, z możliwością ich zmiany przez interfejs użytkownika lub programowe API. Łatka powinna przewidywać modułową strukturę, umożliwiającą w przyszłości dodawanie nowych parametrów bez istotnej przeróbki kodu. Należy zapewnić poprawne przetwarzanie błędów, rejestrowanie zmian, możliwość przywrócenia ustawień do wartości domyślnych, a także zachowanie zgodności z przyszłymi aktualizacjami sterownika, o ile to możliwe. Rozwiązanie powinno być dostarczone z dokumentacją techniczną opisującą architekturę, zrealizowane możliwości, ograniczenia oraz zalecenia dotyczące testowania.
Jesteśmy dużą firmą logistyczną, która ma własny eksport. Dysponujemy dużym parkiem samochodowym i nieustannie wysyłamy nasze pojazdy na eksport do krajów Europy.Opis Strona: https://echerha.gov.ua/ Na tej stronie umieszczamy nasze samochody w elektronicznej kolejce do przekroczenia granicy państwowej. Podczas rejestracji należy wprowadzić następujące dane: imię i nazwisko kierowcy; numer paszportu zagranicznego; adres e-mail; numer telefonu logisty do otrzymywania powiadomień; typ pojazdu (ciężarowy); nazwa producenta samochodu; numer rejestracyjny ciągnika; numer rejestracyjny przyczepy; numer deklaracji celnej. Dla każdego samochodu z góry określono konkretny dzień i godzinę przekroczenia granicy. Na przykład, samochód musi przejść przez punkt kontrolny „Rawa-Ruska” w poniedziałek o 10:00.Nasz problem - Kolejka na stronie https://echerha.gov.ua/ porusza się nieprzewidywalnie. - Na przykład, dzisiaj jest piątek, a samochód musi przekroczyć granicę w poniedziałek o 10:00. - Nie wiemy, kiedy dokładnie kolejka zacznie się posuwać. Może to nastąpić w piątek wieczorem, w dowolnym momencie w sobotę lub niedzielę, wcześnie rano, w ciągu dnia lub późno wieczorem. - Kiedy kolejka zaczyna się poruszać, jest to od razu widoczne na stronie. Czasami w ciągu zaledwie kilku minut może przesunąć się z piątku na poniedziałek lub nawet na wtorek. - Z tego powodu logistycy muszą nieustannie kontrolować aplikację mobilną lub stronę internetową, aby nie przegapić momentu, gdy kolejka dojdzie do potrzebnej daty i godziny. Jeśli ten moment zostanie utracony, fizycznie nie zdążamy umieścić samochodu w kolejce na odpowiedni slot czasowy.Zadanie - Po wprowadzeniu danych o samochodzie (na przykład do tabeli lub innego interfejsu, w zależności od realizacji programisty) system powinien automatycznie śledzić ruch kolejki. - Kiedy kolejka dojdzie do wcześniej określonej daty i godziny, system powinien automatycznie wypełnić wymagane dane i umieścić samochód w kolejce bez udziału logisty.
Szukam doświadczonego programisty TrinityCore 3.3.5a, który dobrze zna się na strukturze jądra, systemie Battleground, C++, SQL i kliencie WoW 3.3.5. W projekcie zintegrowano już niestandardowy Battleground „Dolina Niewolnictwa” (Slavery Valley), przeniesiony z AzerothCore na TrinityCore. Główna część pracy została już wykonana, jednak wymaga doprowadzenia do poziomu Blizzard.Co już zrobiono TrinityCore 3.3.5a + Eluna. Serwer w pełni skonfigurowany. Battleground zintegrowany z jądrem. Działa wejście do BG. Działa interfejs klienta (częściowo). Przeniesiono większość SQL i DBC. Buduje się bez błędów.Co należy zrobić Naprawić pozostałe błędy Battleground. Doprowadzić mechanikę do poziomu oficjalnych Battleground Blizzard. Naprawić fazę startową meczu. Wdrożyć poprawne bramy startowe/ściany ognia. Naprawić mechanikę przejmowania punktów. Naprawić zakończenie meczu. Sprawdzić przyznawanie punktów i działanie WorldState. Naprawić pozostałe problemy C++ i SQL. Przeprowadzić pełne testy gry.Wymagania Obowiązkowe doświadczenie: TrinityCore 3.3.5a; C++; SQL (MariaDB/MySQL); DBC; MPQ; Visual Studio; CMake; Git. Dużym plusem będzie: AzerothCore; Eluna; doświadczenie w tworzeniu Battleground; znajomość części klienckiej WoW 3.3.5a.Format pracy Praca etapowa. Po każdym etapie obowiązkowe testowanie. Każdy etap akceptowany tylko po weryfikacji w grze. Potrzebne są zrozumiałe raporty dotyczące zmian.W przyszłości To długoterminowy projekt. Po zakończeniu Battleground planowane jest: przeniesienie nowych Battleground; przeniesienie nowych aren; nowe rasy; nowe klasy; nowe systemy gry; dalszy rozwój własnego serwera World of Warcraft 3.3.5a. Szukam programisty, który już pracował z TrinityCore i będzie w stanie nie tylko pisać kod, ale doprowadzić system do w pełni działającego stanu.nie serwer z 0 jak chcę Jeśli szukasz programisty nie tylko na jeden Battleground, ale na stworzenie serwera od podstaw, to ogłoszenie powinno wyglądać mniej więcej tak.Nazwa projektu Rozwój serwera World of Warcraft 3.3.5a od podstaw (TrinityCore / C++ / SQL / Eluna)Opis projektu Szukam doświadczonego programisty TrinityCore 3.3.5a do długoterminowej współpracy. Potrzebuję osoby, która będzie w stanie od podstaw stworzyć w pełni gotowy serwer gry World of Warcraft 3.3.5a na bazie TrinityCore z dalszym rozwojem projektu. Projekt jest duży i przewidziany na kilka miesięcy rozwoju.Podstawa projektu TrinityCore 3.3.5a. Jak najbardziej stabilna i zbliżona do Blizzard baza. Eluna Lua Engine. MariaDB. Visual Studio + CMake. Git.Co planuje się zrealizować W pełni działający serwer 3.3.5a. Naprawa błędów jądra. Rozwój nowych systemów gry. Integracja niestandardowych Battleground. Integracja nowych aren. Przeniesienie użytecznych modułów z AzerothCore na TrinityCore. Rozwój własnych modułów. Nowe systemy PvP i PvE. Nowe wydarzenia w grze. Balansowanie klas. Dodatkowe systemy progresji. Poprawa wydajności serwera.W przyszłości Po zakończeniu podstawowej części planowane jest: nowe rasy; nowe klasy; nowe strefy; nowe lochy; nowe rajdy; nowe Battleground; nowe profesje; nowe mechaniki gry; integracja nowoczesnych systemów w kliencie 3.3.5a.Wymagania dla programisty Obowiązkowe: Doskonała znajomość TrinityCore 3.3.5a. Pewna znajomość C++. SQL (MariaDB/MySQL). Git. Visual Studio. CMake. Znajomość architektury TrinityCore. Doświadczenie w pracy z Battleground, PvP i mechanikami gry. Dużym plusem będzie: Doświadczenie w pracy z AzerothCore. Eluna Lua Engine. Praca z DBC i MPQ. Doświadczenie w tworzeniu własnych systemów gry.Format pracy Praca etapowa. Każde zadanie jest dokumentowane jako osobne zadanie techniczne. Po każdym etapie przeprowadzane są obowiązkowe testy. Praca akceptowana tylko po weryfikacji bezpośrednio w grze. Potrzebny jest programista, który potrafi doprowadzić funkcjonalność do w pełni działającego stanu, a nie tylko pisać kod.
Stworzyć kompatybilność między naziemną stacją zarządzania, systemem automatycznego startu (SAS), radarem a samolotem.