antonvongolub / code Goto Github PK

In code.java, the for loops starting at 867 and again at 935 attempt to iterate through the entire List of prices, but if the take profit conditions are met, the List of prices is modified, leading to an incomplete iteration over the loop.

``https://github.com/AntonVonGolub/Code/blob/c361282e0d5317690b87d8c93ea9e45e2f7ab4fb/code.java#L867-L879

This implies that the current position decreasing logic does not behave as intended.

Please see this discussion for how to achieve removal safely.

Hi,

First I want to say that I appreciate your effort to make such examples.

And second...
I'm confused with some text inside the code.java example and differences with the LimitOrder example. Would you mind explain more about their differences. Because it seems to me that the only differences between these two examples are a few TODO's which have been implemented in the LimitOrder and putting Limit order type instead of instant market order type.

Are there any other differences which make code.java 'not supporting trading model' as you mentions in readme section?

Regards,
Dave

There are no restrictions to how large the position gets, and it will hold forever until the position is profitable.

Also Java indexing is zero based.

This would mean the first open position never closes throughout the entire simulation.

Hello,

In code.java there's a bunch of imports from ch.olsen.products and routes. Is it possible for me to get access to those libraries?

Thanks

Hi!

I am porting you code to Python and was able to get most of it done.
One trouble I seem to have is with the Liquidity class. It looks like it is not used anywhere. Only the LocalLiquidity is used. Is that right and the Liquidity class can be safely removed or am I missing something?

I assume that Runner is actually intrinsic events detector, while run(price) method updates the detector's state and returns the event detected, if any.

For return value, it seems that 0 stands for No event, 1 = Direction changed up, 2 = Overshoot up, -1 and -2 is the same only for down events.

If so, why in line 660, in LocalLiquidity does it return 2, which is according to the above Overshoot up, when the closure it's in handles a type == -1 (direction down)?

Hi
Recently I downloaded a code from following URL
(https://github.com/AntonVonGolub/Code/blob/master/code.java) to run for research purpose.

I deleted several imports "ch.olsen~~~" unused imports
and joined with other library imports, by pressing "ctrl + shift + o" and selected the library related with
'olsen'.

but i still have difficulties to run the code.
To illustrate, Main code is blank(empty) ,and also it seemed like some class definition codes are also missing.
(AtomInput,Atomabstr and so on). I assume this is the part of the project's code or some of the class definitions are included in ch.olsen library. Should I have to find external library file(ch.olsen~~) and import to the project to run this code?

Could you please tell how to proceed to run the code?
Thank you .

Hi @jbglattfelder,

I read the paper and looked into the both sample codes, but couldn't see many differences with a grid system which opens a contrarian position after an overshoot(which is called a gap or level in grid system) and averages down/up when position is in loss.

For calculating the lot in case of averaging down/up the agent uses liquidity indicator (which is called lot multiplier in averaging system).

I'm afraid I've overlooked something important in this concept that makes this better than a grid system. But I don't know what!
I will really appreciate it if you point me to the differences or advantages of this concept compared to a grid system with averaging the losses.

with regards,
Armin

Hello,

Many thanks for your paper and sharing your work on github ;-)
I really like your ideas.
I'm testing it, trying to make it work with my own backtesting framework, with minimal changes.

So far, I'm launching only one CoastlineTrader with delta = 0.0005 for long positions.

My assumptions and understanding of your implementation is that

• You have at the same time opposite positions on the same market but coming from different agents / deltas.
• The position.s (limit order impl.) of one agent is closed when a given profit is reached by making a market order of volume of all disbalanced orders
• When a agent in buying mode (for example) decascades, a sell limit order is made in order to close some of the previous buy (eventually taking a loss)

Is that correct or does the sell limit order force the position in the opposite direction so that an agent in buy mode could also open positions in both directions ? The methods makeBuyFilled and makeSellFilled take the profit and remove the orders from the disbalanced orders so I don't think a same agent manages positions in opposite directions but I just wanted to be 100% sure.

My question is: how do you ensure that you won't close the positions managed by another agent?
Maybe my question is naive and linked to my broker... But I don't have the possibility to make the matching of the position myself. Either I close one particular position, or I close many by compensating existing positions but my brocker maximizes the profit when I do so and picks the positions opened at a lower price if closing long and the opposite for short.

In real-world, do you use the "compensatedOrders" list to make sure you close the proper positions?

Thank you in advance,

First - thank you for publishing your work on scaling laws and trading models - it is quite amazing. I have two questions for you on the java code:
(i) LocalLiquidity uses parameters alpha and alpha weight that don't appear in equations (2) - (6) in the alpha engine paper. Could you please explain what alpha and alpha weight represent?
(ii) In calculating the surprise values and subsequent liquidity values in LocalLiquidity I can't see how the probability of K state transitions for a price trajectory in a time interval [0,T] is explicitly considered. Can you please clarify?

Hi,

I couldn't find the reason behind having multiple agents with different threshold for the same type of orders. Suppose that after some kind of research we find out that the certain threshold applies best to a currency like "AUD_CAD". Let's assume that 0.02 has been profitable for Buy and 0.03 for Sell based on historical research on this currency. Wouldn't be logical to have only one coastlinetrader for buy and one coaslinetrader for sell with these thresholds?

I see that the source code example uses multiple coastlinetraders with different thresholds. Is there a reason for that?

Regards,
Dave

I have run the algorithm on the USD INR data and all the positions are not closed by the end of the day.
Is it supposed to be like this ? If not, is there anything special that needs to be done while transitioning between days. Or can we just treat the first point of the next day as the next point in the time series.

Hi

I have recently tried to use your Code.java but due to the imports I have difficult time to use this code.

There seems several Import/Annotation issue in current code and seems like you did not uploaded the cleaned code which is not using legacies.

For example, when I tried to use this code in Eclipse system with Windows OS, there are many "red lines".

It seems several classes for example Atom , AtomInput or PriceFeedData and else are not implemented in this code.

I think it would be better if you implement all the requirements for this code in here(Code.java) or write some suggestions how to compile this code in Eclipse system or directly in Termianl(or command line prompt for Windows).

Or is there any chance that I can obtain those packages callsed "ch.olsen" ??

Lists are below ( directly copied and pased from your Code.java )

import ch.olsen.products.util.configuration.Configuration;
import ch.olsen.products.util.configuration.DoubleProperty;
import ch.olsen.products.util.configuration.EnumProperty;
import ch.olsen.products.util.configuration.StringProperty;
import ch.olsen.routes.atom.Atom;
import ch.olsen.routes.atom.AtomAbstr;
import ch.olsen.routes.atom.AtomException;
import ch.olsen.routes.atom.AtomInput;
import ch.olsen.routes.atom.AtomInputAbstr;
import ch.olsen.routes.atom.AtomOutput;
import ch.olsen.routes.atom.AtomOutputAbstr;
import ch.olsen.routes.atom.RoutesStep;
import ch.olsen.routes.cell.library.LibraryAutoDeploy;
import ch.olsen.routes.data.ArrayDataElement;
import ch.olsen.routes.data.DataElement;
import ch.olsen.routes.data.DataType;
import ch.olsen.routes.data.DoubleDataElement;
import ch.olsen.routes.data.NullDataElement;
import ch.olsen.routes.framework.RoutesFramework;

Hi,

I tried running the above code on the USD-INR(indian rupee) data and the response rate is very low. I mean to say that it shows a couple of trades on some days and on some days, it shows no trades. So how frequently did the model show trades when you ran on other currencies.

Also, I am feeding the data day wise. At once I just send one day's tbt data and then in the next iteration , I send the next day's data but there is no connection between the previuos day's data to the next day's data. Is that how it is supposed to be. Or should I combine the data odf several days and then run the code.

Thanks.

I open this issue only to announce I ported the Alpha Engine to Node.js: https://github.com/albertosantini/argo-trading-plugin-dc.

Thank you a lot for your efforts based on IE.

In CoastlineTrader, when tP > 30, events will be taken from runnerG[0][1], which was initialised as following -

runnerG[0][1] = new Runner(0.50*deltaUp, 2.00*deltaDown, price, fxRate, 0.50*deltaUp, 0.50*deltaUp);

But notice that 50% of the threshold means that it will increase position sooner, since threshold is lower.

What is the logic in increasing the position faster when position is already large (>30)?

To my logic it should be the opposite - in order to reduce risk, threshold should be higher the bigger our position is.

In line 107, Runner calculates a Math.log(price.elems.bid/extreme) when price is a PriceFeedData object, while at line 164, the it's the same method except that it receives a price of type double and it performs a linear calculation of delta price - extreme instead the previous logarithmic calculation.

Why for an object price Runner uses a logarithmic calculation and for a double it performs a linear calculation of delta?

Thank you for your work. I have tested your theory on forex pairs and had success similar to those mentioned in Figure 1 of the article (eg NZDJPY being a profitable pair). I have also tested this on gold starting 2007 to 2017. XAUUSD failed tests as compared to forex pairs. Had you done any testing on XAUUSD or could you try and let the community know your findings? Thank you.