Debido a las limitaciones de la lengua maya, la estrategia tiene que ser reimplementada con JS.
Desde la reimplementación de la estrategia de Ma en JS, se han encontrado muchos problemas, en el funcionamiento del disco real, se ha encontrado que en la misma línea K, debido a la volatilidad, se venden 1-2 veces de nuevo. Esto causa pérdidas.
¿Cómo está diseñado el lenguaje para evitar esto, cuál es la lógica general?
O: ¿Hay alguna manera de evitar que la misma línea K sea usada para comprar y vender dos veces con JS? ¿Quiere resolver con el tiempo de parche, encontró que no hay tiempo de parche en la orden de la transacción, el siguiente orden con JS Date.parse ((new Date))) tiempo de la orden, si se encuentra con el éxito de la orden no ordenada, o la orden de la orden no finalizada, ¿cómo se resuelve?
- ¿ Por qué?También hay un problema, con el siguiente código, que puede evitar que la misma línea K no cause pérdidas debido a un poco de fluctuación en la misma línea K. Pero también hay un nuevo problema, que es que después de que la misma línea K sea plana, si quieres hacer una mano inversa inmediatamente, está limitada, y debes esperar a que la siguiente línea K abra una posición vacía. O después de que la línea K sea plana, si quieres hacer más manos inversas en la misma línea K, también está limitada, debes esperar a que la siguiente línea K comience a abrir una posición, a menudo perdiendo el punto de compra óptimo.
El código es el siguiente: if (before_record_time!= now_records.Time) // el tiempo de la línea K anterior no es igual al error de tiempo de esta línea K.
¿Qué es esto?
// Si escribo aquí la lógica de negocio de un equilibrio, no se puede abrir el equilibrio en la misma línea K repetidamente.
¿Qué quieres decir?
Así que mi solución es esto: antes era una variable almacenada en una línea de tiempo de K. Ahora se convierte en dos variables almacenadas.
Un reloj que hace varias direcciones duo_before_record_time
Un tiempo sin dirección
Las hierbasLa factura te responde.
La calma y la buena voluntadLa línea K es el tiempo, se debe resolver con el tiempo.
- ¿ Por qué?El código es el siguiente: if (before_record_time!= now_records.Time) // el tiempo de la línea K anterior no es igual al error de tiempo de esta línea K. ¿Qué quieres decir? // Si escribo aquí la lógica de negocio de un equilibrio, no se puede abrir el equilibrio una y otra vez en la misma línea K. ¿Por qué no?
- ¿ Por qué?Se encontró una mejor solución, primero se declara una variable para almacenar el tiempo de la línea K más reciente en el momento de cada orden (no importa si se hace o no un aplazamiento, siempre y cuando la orden esté cubierta por esta variable), y luego se determina que el tiempo de aplazamiento de la última vez que se abrió no es igual al tiempo de aplazamiento de la línea K más reciente, que se puede resolver perfectamente.
- ¿ Por qué?Por cierto, con exchange.GetOrders (().length>0 se determina que no hay pedidos pendientes y se guarda el tiempo del pedido.
- ¿ Por qué?Después de un largo proceso, finalmente encontramos la solución, el código es el siguiente: si (Math.abs ((before_order_time - now_records.Time)/1000 > now_period)) y el número de segundos de la orden es el número de segundos de la orden // El tiempo de la última orden subtrae el tiempo de la línea K actual, dividido por 1000 para obtener el número de segundos, y toma el valor absoluto inferior a ambos, si es mayor que el número de segundos del ciclo, no está en la misma línea K. // necesita configurar la variable before_order_time, solo guarda el horario del orden cada vez. before_order_time = Date.parse ((new Date)))); // registra el horario actual // Número de segundos del número de periodos, es var now_period = _C ((exchange.GetPeriod); // obtiene el ciclo actual, por ejemplo, 5 minutos, 15 minutos, 1 día, y devuelve el número de segundos.
El verano no te golpea.Debería ser posible interceptar con el cronómetro dentro de los datos de la línea K. Si el cronómetro es el mismo, no se puede ordenar.