Allow me some comments on the last posts
1) About C (Nitro post)
Using C and considering the way you explained certainly suits yourself perfectly, but it is an extreme approach not accessible to everyone and also in general people tend to be either good in C or good in trading.
Instead of coding everything in a fast but difficult programming language it is possible to build just the critical blocks. An example of this are option pricing functions that we have in QuoteLink. These functions can be invoked through a COM or .NET interface and are coded to be simple and the fastest possible (they are also available in Excel as worksheet functions). Everything that is not critical should be written in a âglueâ language like VB, C#, Python. For trader programmers to build the fastest blocks I recommend C# because it is fast and you can use it to get real time data (using QuoteLink or APIs from other vendors). For the glue code I would recommend VB, Python or even c# depending on the degree of flexibility needed . The use of a interpreted language like VB or Python as glue language is far more flexible with a minimal impact on performance.
2) About âUsing Excel as real time toolâ and âthe conceptual idea around Excelâ (Nitro and Cash posts):
As Nitro said Excel is a front end tool and as such I believe it should be always plugged to the brain of the trader not to the feeds. Excel follows a spreadsheet paradigm related to functional programming that makes it appealing to non-programmer traders. This gives those traders an edge, because through Excel they can express themselves in way that would not be possible for them otherwise. To allow Excel to be used in real time scenarios and to avoid frustration, extreme care must be taking to not affect it and keep Excel strictly as a front-end tool that respects its original paradigm. This implies that data collection or anything depending on the rhythm of the feed, like any synchronous calculations, must be done without using those spreadsheet paradigms. In other words do it in other threads using some classic procedural approach and pass the results using RTD.
In practice this is achieved using Excel as the final tool where the trader has is âhands onâ, complemented with modules written in a faster language. These modules can come from a vendor or written by the trader himself as above.
Antonio Leite
p.s.
About my posts in general I would like to say that my objective is to participate in the discussions when it concerns subjects related to QuoteIN and QuoteLink with two fundamental objectives, first to state my opinions equilibrating the discussions and second to read other opinions so that I can finalize and improve QuoteLink. I would give back any customers that eventually came through ET if that would avoid any incident, it looks thus pathetic to me that someone may expect me to be grateful because of any post. Specially for posts that obviously I consider wrong .
1) About C (Nitro post)
Using C and considering the way you explained certainly suits yourself perfectly, but it is an extreme approach not accessible to everyone and also in general people tend to be either good in C or good in trading.
Instead of coding everything in a fast but difficult programming language it is possible to build just the critical blocks. An example of this are option pricing functions that we have in QuoteLink. These functions can be invoked through a COM or .NET interface and are coded to be simple and the fastest possible (they are also available in Excel as worksheet functions). Everything that is not critical should be written in a âglueâ language like VB, C#, Python. For trader programmers to build the fastest blocks I recommend C# because it is fast and you can use it to get real time data (using QuoteLink or APIs from other vendors). For the glue code I would recommend VB, Python or even c# depending on the degree of flexibility needed . The use of a interpreted language like VB or Python as glue language is far more flexible with a minimal impact on performance.
2) About âUsing Excel as real time toolâ and âthe conceptual idea around Excelâ (Nitro and Cash posts):
As Nitro said Excel is a front end tool and as such I believe it should be always plugged to the brain of the trader not to the feeds. Excel follows a spreadsheet paradigm related to functional programming that makes it appealing to non-programmer traders. This gives those traders an edge, because through Excel they can express themselves in way that would not be possible for them otherwise. To allow Excel to be used in real time scenarios and to avoid frustration, extreme care must be taking to not affect it and keep Excel strictly as a front-end tool that respects its original paradigm. This implies that data collection or anything depending on the rhythm of the feed, like any synchronous calculations, must be done without using those spreadsheet paradigms. In other words do it in other threads using some classic procedural approach and pass the results using RTD.
In practice this is achieved using Excel as the final tool where the trader has is âhands onâ, complemented with modules written in a faster language. These modules can come from a vendor or written by the trader himself as above.
Antonio Leite
p.s.
About my posts in general I would like to say that my objective is to participate in the discussions when it concerns subjects related to QuoteIN and QuoteLink with two fundamental objectives, first to state my opinions equilibrating the discussions and second to read other opinions so that I can finalize and improve QuoteLink. I would give back any customers that eventually came through ET if that would avoid any incident, it looks thus pathetic to me that someone may expect me to be grateful because of any post. Specially for posts that obviously I consider wrong .
