Using parametric types

[femtotrader]

MarketObservables.jl/src/orderbook/base.jl

Lines 7 to 8 in 392499d

	function price(ob::AbstractOrderBook, volume::Volume; raise=false)
	if volume == Volume(0)

doesn't use parametric type but it should because volume can be integer or float

see #3 (comment)

[roshii]

Why not using Real instead?

volume::Real
volume == zero(Real)

[roshii]

On an higher level, I'd proposed to using the following structure, keeping in mind that it would be used as something like Observable{MarketObservable}

MarketObservable
    |_ AbstractOrderBook
        |_ FiniteDepthOrderBook
        ...
    |_ Ticker
    |_ Trades

[femtotrader]

To my understanding, it's generally a bad idea to use abstract types

https://docs.julialang.org/en/v1/manual/performance-tips/index.html

Moreover type for volume can be different depending of the assets

Volume for shares is for example integer
Volume for forex lots is decimal ...

[roshii]

I indeed suspected a performance implication... Parametric type it is then to cover both Float and Integer cases

[femtotrader]

I think we absolutely need to support volume of several types

see https://en.wikibooks.org/wiki/Introducing_Julia/Types

same for price so we don't have to be explicit about type to use here

It can be Float64, Int64 but also Decimal (to avoid rounding issue)

[femtotrader]

I personally don't use them... but some people may also want to use Unums!

[femtotrader]

I had a types.jl with the following content

const Price = Float64 #Nullable{Float64}
const Volume = Float64 #Nullable{Float64}
const Ticket = Integer #Nullable{Integer}
const Magic = Integer #Nullable{Integer}
const Slippage = Integer #Nullable{Integer}

null_price = NaN #Price()
null_volume = NaN #Volume()
null_datetime = DateTime(0)
null_ticket = -1 #Ticket()
null_magic = -1 #Magic()
null_slippage = -1 #Slippage()

function isnullprice(price::Price)
    isnan(price)
end

function isnullvolume(volume::Volume)
    isnan(volume)
end

function isnulldatetime(dt::DateTime)
    dt == null_datetime
end

function isnullmagic(magic::Magic)
    magic == null_magic
end

function isnullslippage(slippage::Slippage)
    slippage == null_slippage
end

but

const Price = Float64 #Nullable{Float64}
const Volume = Float64 #Nullable{Float64}

is definitely not the correct way of doing...

(that's why I'm not adding this to this repository)

[femtotrader]

I also had

abstract type AbstractPriceData{Tprice,Tvol} end

struct TickData{Tprice,Tvol} <: AbstractPriceData{Tprice,Tvol}
    ask::Tprice
    bid::Tprice
    volume::Tvol
end

struct BarData{Tprice,Tvol} <: AbstractPriceData{Tprice,Tvol}
    open::Tprice
    high::Tprice
    low::Tprice
    close::Tprice
    volume::Tvol
    adj_close::Tprice
    
    function BarData(open::Tprice, high::Tprice, low::Tprice, close::Tprice, volume::Tvol) where {Tprice, Tvol}
        new{Tprice,Tvol}(open, high, low, close, volume, close)
    end

    function BarData(open::Tprice, high::Tprice, low::Tprice, close::Tprice, volume::Tvol, adj_close::Tprice) where {Tprice, Tvol}
        new{Tprice,Tvol}(open, high, low, close, volume, adj_close)
    end
end

struct PriceTimedData
    time::DateTime
    data::AbstractPriceData
end

I have just add currently

abstract type AbstractPriceData{Tprice,Tvol} end

in this repository (types.jl) as it's required to compile

[roshii]

It can be Float64, Int64 but also Decimal (to avoid rounding issue)

I like the Decimal approach instead of Float.
Exchanges do have decimal parameters in their API and so it will make setup easier while as you said, avoid rounding issues.

[femtotrader]

I think we should absolutely avoid to decide this now! and we should have our structs / functions able to manage any Number for Volume or Price

[roshii]

I personally don't use them... but some people may also want to use Unums!

I don't either, let's park it for now, we may still explore in the future

I think we should absolutely avoid to decide this now!

Agreed, nothing is set in stone, just brainstorming :)

[femtotrader]

Working with Decimal brings precision but it is sometimes at the expense of performance... if we can use Decimal or Float (or Integer) given context I think it's better

[femtotrader]

Similar code improvement than #10 should probably be done in

• MarketObservables.jl/src/orderbook/base.jl

  Line 7 in 9b81e47

  function price(ob::AbstractOrderBook, volume::Volume; raise=false)

• MarketObservables.jl/src/orderbook/base.jl

  Lines 20 to 21 in 9b81e47

  	function bid(ob::AbstractOrderBook)
  	bid(ob, Volume(0))

• MarketObservables.jl/src/orderbook/base.jl

  Lines 24 to 25 in 9b81e47

  	function ask(ob::AbstractOrderBook)
  	ask(ob, Volume(0))

• MarketObservables.jl/src/orderbook/base.jl

  Lines 28 to 29 in 9b81e47

  	function spread(ob::AbstractOrderBook)
  	spread(ob, Volume(0))

• MarketObservables.jl/src/orderbook/base.jl

  Line 32 in 9b81e47

  function spread(ob::AbstractOrderBook, volume::Volume; raise=false)

• MarketObservables.jl/src/orderbook/depth_finite.jl

  Lines 56 to 57 in 9b81e47

  	function bid(ob::FiniteDepthOrderBook, volume::Volume; raise=false)
  	if volume == Volume(0)

• MarketObservables.jl/src/orderbook/depth_finite.jl

  Lines 64 to 65 in 9b81e47

  	function ask(ob::FiniteDepthOrderBook, volume::Volume; raise=false)
  	if volume == Volume(0)

• MarketObservables.jl/src/orderbook/depth_infinite.jl

  Lines 22 to 23 in 9b81e47

  	function bid(ob::InfiniteDepthOrderBook, volume::Volume; raise=false)
  	ob.highest_bid, Volume(0)

• MarketObservables.jl/src/orderbook/depth_infinite.jl

  Lines 26 to 27 in 9b81e47

  	function ask(ob::InfiniteDepthOrderBook, volume::Volume; raise=false)
  	ob.lowest_ask, Volume(0)

Unfortunately I can't spend more time on this this week... I let you @roshii have a look at this