how to manual test and a few questions

[sg-qwt]

Hi Alberto,

Thanks for this library. I'm new to algorithmic trading and find the library quiet interesting.

I noticed there's a comment block in testing says:

(comment
  ; manual test, with portal and Tradingview
  (tap> (update-vals indicators-vals (fn [i] (into (sorted-map) i))))
  (tap> (into (sorted-map) (::ma indicators-vals))))

I know I can tap values into Portal for view, but I'm curious how do you incorporate Tradingview into this workflow? Do you somehow created a custom Tradingview viewer wired up with Portal this case? I'm researching easy ways of charting and visualizing market data native to clojure.

Also, I like the minimum design of this library, but how does it compares to ta4j per say in terms of performance or other aspects?

There's an active fork of trateg https://github.com/clojure-quant/trateg that seems quiet interesting that it connects that with the new stack of data libraries (dtype-next, tech.ml.dataset, tablecloth) in the clojure world. I'm not sure if you follow those libraries in the data science world, but if so, with those new libraries in mind, would that change your approach of doing things in this library?

Appreciate your inputs and thoughts, thanks!

Best

[bortexz]

Hi @sg-qwt, thanks for the interest in the library and the Q's!

I know I can tap values into Portal for view, but I'm curious how do you incorporate Tradingview into this workflow? Do you somehow created a custom Tradingview viewer wired up with Portal this case? I'm researching easy ways of charting and visualizing market data native to clojure.

It is more rudimentary than that, I just open tradingview on the browser, open the chart for which I have the data, and just look over the values to see if they are the same. No portal viewer involved or anything similar. The 'portal' comment only refers to printing the sorted-map in portal to navigate it a bit better than in repl output.

Also, I like the minimum design of this library, but how does it compares to ta4j per say in terms of performance or other aspects?

Main differences I'd say are that tacos uses immutable sorted-maps (allows late arriving events, can index per timestamp). Haven't tested performance against ta4j, but ta4j is probably faster.

Another difference is that graphcom allows to create custom processors (or the default parallel processor) to allow parallelism.

There's an active fork of trateg https://github.com/clojure-quant/trateg that seems quiet interesting that it connects that with the new stack of data libraries (dtype-next, tech.ml.dataset, tablecloth) in the clojure world. I'm not sure if you follow those libraries in the data science world, but if so, with those new libraries in mind, would that change your approach of doing things in this library?

So one of the things that I don't like about the original design of this library is sorted-maps. They have logn complexity for many operations, and end up being quite slow, even if I tried to optimize a few ops needed for tails and things like that. I have been experimenting with using another data structure that is similar to a ring-buffer that has constant complexity for most needed operations, but looses the time indexing and late-arriving events capability, but I think for realtime trading it's a reasonable trade-off to favor constant complexity. I also think that to go even faster, at some point you also need to drop immutability to use a double array for backing the ring buffer mentioned above. Something like hummingbot trailing indicators (https://github.com/hummingbot/hummingbot/tree/master/hummingbot/strategy/__utils__/trailing_indicators).

For the investigative side of things, I am also leaning towards the broader data science ecosystem leveraging the tech.ml stack, although I am quite new to it and I'm just getting to know the landscape.

One of the open questions I currently have is about using the datasets for realtime trading, as they seem more focused on interactive investigation and fast batch processing than realtime (e.g incremental updates) but I think there might be a place to combine the incremental approach with more 'batch' oriented approach of datasets (i.e not recalculating whole dataset on every new tick, only when substantial data is changed, etc).

I am also moving away from graphcom as well, I have been experimenting developing a library similar to https://github.com/janestreet/incremental that offers a different kind of API for incremental computations, but it's WIP yet, and is aimed at the realtime trading side of things, not so much the interactive investigation / visualization.

Hope this answers your questions, let me know if you have more 🙏🏼

[sg-qwt]

I don't have any more questions for now. That's really interesting and insightful! Thanks for sharing your thoughts on this. Look forward to seeing what's coming after graphcom if you decide to open source it some day.

All the best 🙏🏼