Вот кроме реальной экономики, а особенно скальперы ориентируются на графические модели (и т.д.) и волновую разметку Нейронную сеть потенциально можно натаскать на графике делать правильный вывод, её цель угадать 6 раз из 10.
Несоветую, есть у нас есть граф 20-20, тут конечное число вариантов, если у нас 33 буквы и есть прмиерно конечное число вариантов написания. комбинаторика. Тот тут, одна компания покупает другую, вторая банкротится, третья невыходит на прибыль, четвертая выпускает плохую продукцию. Дядя решил купить себе дом и вывел 100 000 долларов. санкции херанции инфлции девальвации платежеспособность денежная масса безработица строительство чистая прибыль экономический календарь http://www.alpari.ru/ru/analytics/calendar_fxstreet/
На каком языке нейронную сеть писал? Neuroph Java кстати неплохая для этого среда - персептроны, распознавания, обучение. И главное все графически, что очень удобно и красиво. У тебя тоже была графическая среда или визуал студия какая нибудь? Добавлено спустя 1 минуту 30 секунд: Еще раз повторю свою идею. Тебе не кажется что покерный(blackJack) бот содержит в себе намного меньше переменных и обучить сеть проще при сохранении профита?
Ну есть киты, тот же индекс Dow Jones состоит из 30 крупнейших компаний США которые торгуются более-менее в трендах. Хотя в целом, конечно, грааля не существует.
Несовсем понимаю, пользовался какой то библиотекой на java, загонял туда данные за 10 лет. В сети должно быть очень много вариантов, достаточно данных для принятия решения. Суть в том что просто цифр недостаточно. А что бы принять верное решение нужно знать решения людей до того как они их приняли. это не тоже самое что распознать набор из 33 символов поразному написаных Добавлено спустя 6 минут 54 секунды: не жалко, что байты и пиксели жалеть Это было несколько лет назад я уже несколько компов сменил. На youtube есть видео, на хабре полно материалов + форумы трейдеров. По этой причине я завел себе яндекс диск и блог, что бы данные не терялись. По мере решения задач выкладываю.
33 символа поразному написанных)) Хотя действительно интересная алгоритмическая задача, завязанная на определении кодировках, чистках от шума, персептроны тут в конце идут.
Технических фигур меньше, чем букв алфавита. Нужно брать снимок графика за некоторый период и идентифицировать фигуру тех. анализа. Потом определить её силу (сколько условий соблюдено, насколько точно), сравнить с какими-то индикаторами и типа всё. Сила технического анализа в том, что на него и ориентируются мириады спекулянтов. Так что когда вымпел сходится, у игроков мысли тоже сходятся. Если вдруг не случится чего. Се-ля-ви!
В формате грабить корованы - набросок: --- Добавлено --- Как думаете иммет ли смысл шифровать пакеты например: * Формат пакета клиента: [time,user_id/session_id,controller_id,skill9-target] * Формат пакета клиента: [time,user_id/session_id,controller_id,barter-target] * Формат пакета сервера: [time,кому,['object1','move' => 'xyz'],['object1' => 'object2','effect32']] --- Добавлено --- Всмысле сжимать или шифровать
Если интенсивность и содержание обмена такого что сжимание даст профит клиенту и серверу с позиции перфоманса, то почему бы и не пожать. Во всех остальных случаях лишено смысла.
В общем подумав понял, что мне понадобится что то на подобии фреймворка: аналог yii на сокетах. В yii каждый раз создается экземпляр приложения - мне же нужно держать достаточно большу часть приложения в памяти. Начал писать - захаблю. Что там будет: MVC Демонизация (старт стоп и прочие "плюшки") Конечно сокеты Очереди сообщений ОРМ Сессия реплики шифрование Конфиг Игровой сервер будет написан поверх - а фреймворк станет open source проектом вдруг кому то пригодится
Логика такая: 1) Создается экземпляр приложения - демонизируется и превращается в сервис c помощью rc и start stop restart скрипта 2) Создается сокет 3) Создается бесконечный цикл в котором принимаются входящие соединения 4) В этом цикле для каждого соединения создается поток 5) Чтение сообщения от юзера 6) Разбор 7) Роутинг 8) Вызов контроллера и метода или модуля контроллера и метода 9) Внутри контроллера работаем с экземплярами модели которые наследуются от классов ORM (Dao/ActiveRecorrd) 10) Формируем ответ и отправляем обратно на сокет в виде зашифрованного xml,json или чего то еще а дальше клиент может быть любой
Интересная статья Working with Datagram Sockets For some programs (such as a program that needs current date/time information or a network-based game that notifies all players when someone joins the game or leaves the game), the overhead incurred by using stream sockets is unacceptable. After all, it takes a certain amount of time for a client program to establish a connection with a server program. To reduce the overhead, the Network API supplies a second kind of socket: the datagram socket. A datagram socket uses UDP to send a datagram (a short message) from a client program to a server program, or from a server program to a client program. Unlike multi-IP packet messages that can be sent via stream sockets, a datagram must fit inside a single datagram packet. Furthermore, the datagram packet must fit inside a single IP packet. That limits the maximum length of a datagram to around 60,000 bytes. "Java Tip 40: Object Transport via Datagram Packets". Multicasting and the MulticastSocket Class Previous examples showed a server program thread sending a single message (via stream or datagram sockets) to one and only one client program. That activity is known as unicasting. Some situations are not appropriate to unicasting. For example, imagine that a rock musician holds a benefit concert that will be transmitted over the World Wide Web. Depending on the quality of the video and audio feed (and its length), a server program might need to transmit around a gigabyte (a billion bytes) to a client program. Using unicasting, each client program requires its own copy of the data. For example, if 10,000 individuals want to view the concert over the World Wide Web, the server program must transmit approximately 10,000GB of data across the Internet. That excess network traffic has the potential to slow down much Internet traffic. For situations in which the same message needs to be transmitted to many client programs, server and client programs can take advantage of multicasting (the capability of a server program to send one copy of a message to multiple client programs). To multicast, a server program sends a sequence of datagram packets to a special IP address—a multicast group address—and a specific port (as indicated by a port number). Client programs that want to receive those datagram packets create a multicast socket using that port number. The IP address is registered with the multicast socket via a join group operation. At that point, the client program can receive datagram packets that are sent to the group. (The client program can also send datagram packets to the group.) Once the client program has read all the datagram packets that it needs to read, it removes itself from the group by applying a leave group operation against the multicast socket. NOTE IP addresses 224.0.0.1 to 239.255.255.255 (inclusive) are reserved for use as multicast group addresses. The Network API supports multicasting via class MulticastSocket, along with InetAddress and some minor classes (such as NetworkInterface). When a client program needs to join a multicast group, it creates an object from MulticastSocket. The MulticastSocket(int port)constructor allows the client program to specify the number of the port (via the port argument) over which it will receive datagram packets. That port number must match the server program's port number. To join a group, the client program calls one of two joinGroup() methods. To leave the group, the client program calls one of two leaveGroup() methods. Because MulticastSocket extends DatagramSocket, a MulticastSocket object has access toDatagramSocket methods. The only new methods that you will probably need to work with are the previously mentioned joinGroup() and leaveGroup() methods. Listing 6's MCClient source code presents an example of a client program joining a multicast group. Listing 6: MCClient.java // MCClient.java import java.io.*; import java.net.*; class MCClient { public static void main (String [] args) throws IOException { // Create a MulticastSocket bound to local port 10000. All // multicast packets from the server program are received // on that port. MulticastSocket s = new MulticastSocket (10000); // Obtain an InetAddress object that contains the multicast // group address 231.0.0.1. The InetAddress object is used by // DatagramPacket. InetAddress group = InetAddress.getByName ("231.0.0.1"); // Join the multicast group so that datagram packets can be // received. s.joinGroup (group); // Read several datagram packets from the server program. for (int i = 0; i < 10; i++) { // No line will exceed 256 bytes. byte [] buffer = new byte [256]; // The DatagramPacket object needs no addressing // information because the socket contains the address. DatagramPacket dgp = new DatagramPacket (buffer, buffer.length); // Receive a datagram packet. s.receive (dgp); // Create a second byte array with a length that matches // the length of the sent data. byte [] buffer2 = new byte [dgp.getLength ()]; // Copy the sent data to the second byte array. System.arraycopy (dgp.getData (), 0, buffer2, 0, dgp.getLength ()); // Print the contents of the second byte array. (Try // printing the contents of buffer. You will soon see why // buffer2 is used.) System.out.println (new String (buffer2)); } // Leave the multicast group. s.leaveGroup (group); // Close the socket. s.close (); } } MCClient creates a MulticastSocket that's bound to port 10,000. It next obtains an InetAddresssubclass object containing multicast group IP address 231.0.0.1. That object is used to join the group via joinGroup(InetAddress addr). MCClient next receives 10 datagram packets, prints their contents, and leaves the group via leaveGroup(InetAddress addr). Finally, the socket is closed. You might be curious about the need for two byte arrays, buffer and buffer2. When a datagram packet is received, the getData() method returns a reference to its datagram. The length of that datagram is exactly 256 bytes, as specified by the server program (which you will shortly investigate). If you try to print all those bytes, you will see a lot of empty spaces after the actual data. You can eliminate those spaces by creating a smaller byte array—buffer2—that has the exact length of the actual data. To get that length, call DatagramPacket's getLength() method. For a fast way to copy the firstgetLength() bytes from buffer to buffer2, call System.arraycopy(). It's time to investigate the server program. Listing 7's MCServer source code shows how that server program works. Listing 7: MCServer.java // MCServer.java import java.io.*; import java.net.*; class MCServer { public static void main (String[] args) throws IOException { System.out.println ("Server starting...\n"); // Create a MulticastSocket not bound to any port. MulticastSocket s = new MulticastSocket (); // Because MulticastSocket subclasses DatagramSocket, it is // legal to replace MulticastSocket s = new MulticastSocket (); // with the following line. // DatagramSocket s = new DatagramSocket (); // Obtain an InetAddress object that contains the multicast // group address 231.0.0.1. The InetAddress object is used by // DatagramPacket. InetAddress group = InetAddress.getByName ("231.0.0.1"); // Create a DatagramPacket object that encapsulates a reference // to a byte array (later) and destination address // information. The destination address consists of the // multicast group address (as stored in the InetAddress object) // and port number 10000 -- the port to which multicast datagram // packets are sent. (Note: The dummy array is used to prevent a // NullPointerException object being thrown from the // DatagramPacket constructor.) byte [] dummy = new byte [0]; DatagramPacket dgp = new DatagramPacket (dummy, 0, group, 10000); // Send 30000 Strings to the port. for (int i = 0; i < 30000; i++) { // Create an array of bytes from a String. The platform's // default character set is used to convert from Unicode // characters to bytes. byte [] buffer = ("Video line " + i).getBytes (); // Establish the byte array as the datagram packet's // buffer. dgp.setData (buffer); // Establish the byte array's length as the length of the // datagram packet's buffer. dgp.setLength (buffer.length); // Send the datagram to all members of the multicast group // that listen on port 10000. s.send (dgp); } // Close the socket. s.close (); } } MCServer creates a MulticastSocket object. No port number needs to bind to the multicast socket because it is specified as part of a DatagramPacket object, along with the multicast group's IP address (231.0.0.1). Once the DatagramPacket object has been created, MCServer enters a loop that sends 30,000 lines of text. For each line of text, a byte array is created, and its reference is stored inside the previously created DatagramPacket object. The datagram packet is sent to all group members via send(). After compiling the MCServer and MCClient source code, log onto the Internet. Start MCServer by typing java MCServer. Finally, run one or more copies of MCClient by typing java MCClient.
Padaboo Если используешь Java -мне кажется что лучше NIO для сокетов ещё ничего не придумали(скорость, загрузка процессоpa). Обычный ServerSocket убивает систему чуть только начинают запросы на него падать. Какого жанра в итоге игра будет? На что похожа? Шутер, РПГ, гонки?
Там видно будет - через пару часов подпишу все слои и уровни. выложу. Пишу что nio лучше. поищу примеры спасибо.
У NIO недостаток только один -если ты напишешь что то типа while(does not Socket.AllDataRead){ Give Me more Data... Thread.sleep(1000); } И там нужно именно с точки зрения алгоритма прописать АСИНХРОННОЕ взаимодействие с сервером, активно используя аттачменты. Иначе никакого профита. Как уже сказал - делал socks5 реализацию через которую можно в 100 потоков торренты качать, и ещё с запасом ресурсы остались --- Добавлено --- А вот ServerSocket у меня сразу на первом же сайте не смог нагрузку выдержать(ставил свойство прокси у браузера). Убивал напрочь систему и не мог простейший сайт открыть. Кстати браузер любит долбить прокси запросами, очень, чуть сделай задержку на 50 миллисекунд на обработку того же input http header'a
Я писал парсинг на java в 50 поток, потом с помощь selenium webdriver node js, тот же парсинг пулами по 5-10 потоков. Тут немного другая история.
асинхронные алгоритмы сложны для понимания. Намного проще написать блокирующее соединение, но тогда как уже сказал -джава томозит. Ситуация та же, не парсинг а обмен с клиентом, прокси, и веб сайтами
Проблема в языке и виртуальной машине? Что тогда посоветуете. Это не совсем простой фреймворк. Например. Онлайн игра,монстр нападает на игрока У нас есть виртуальная карта игры [64][64] Есть сложный объект монстра. Монстр нападает на игрока и посылает ему пакеты. С точки зрение программирования 1) объект монстра висящий в памяти 2)объект игрока висящий в памяти 3) AI монстра - поток который по таймауту проверяет различные условия и совершает действия. AI проверяет если ли в радиусе игрок, если есть: создается единица работы - которая: 1) Вызывает у объекта монстра метод move() в направлении игрока - создается единица работы которая ставит сообщение в очередь 2) Если расстояние достаточно для удара или применения скила - применяется случайный скилл - создается пакет игрок монстра убивает 1)объект монстра уничтожается, уничтожается поток AI, создается пакет для клиента в котором монстр умирает 2)Создается отложная единица работы c таймаутом через 5 минут. которая ставит монстра по его респауну и добавляет AI поток для него Второй пример: игрок1 вешает баф (улучшение статов на 15минут) на игрок2. Проходит 10 минут игрок 2 выходит из игры. Его объект нужно выкинуть из памяти и сбросить в базу. вместе со всеми его шмотками и надетыми пушками. Игрок 2 заходит в игру. на следующий день. тот же баф должен на нем остаться. Третий пример: сервер со всеми этими бафами монстрами пвп и квестами и потоками просто выключается - этлектричество кончилось. Что вижу лично я: 1) Единицы работы 2)Потоки 3)Таймеры 4) Общие ресурсы 5) логику пользовательского приложения со стороны сервера 6) Работу с бд 7) Работу с памятью 8) сокеты 9) сообщения Все это нужно по максимуму автоматизировать,систематизировать, добавить генератор кода. Так как например в lineage 500 монстров добрая пара сотня шмоток + квесты.
Решается средствами NIO довольно легко 1.Команда первыми 1-2 байтами сообщает свое имя и тип, по которым можно определить её длину. 2. Далее идёт чтение, пока не достигнут конец команды 3. Выполнение команды. Насчёт потоков. Если не знаком, то при создании в джаве большого количества new ThreadAlpha().start() - это конец системе. Поэтому используй FixedThreadPool, либо cached, но учти, что несмотря на на рандомное количество потоков он тормозит в случае если поток быстро не завершается. Разделяемые ресурсы Думаю будет достаточно public static объектов, либо synchronized функций, которые с ними работают