1 |
On Wed, Jan 26, 2011 at 10:47 AM, Michael Orlitzky <michael@××××××××.com> wrote: |
2 |
> On 01/26/2011 12:56 PM, Mark Knecht wrote: |
3 |
>> Michael, |
4 |
>> Thanks for the inputs. It gives me more to think about. |
5 |
>> |
6 |
>> In this case the input language is interpreted, not compiled. The |
7 |
>> trading platform interprets the program and internally turns it into |
8 |
>> buy & sell operations. (Not the piece of code I supplied - that was |
9 |
>> just a small function.) Unfortunately, as the language is proprietary |
10 |
>> to the trading platform there isn't a way to go to any common |
11 |
>> low-level language. |
12 |
>> |
13 |
>> The 'battery of tests' would be, I think, the trading program being |
14 |
>> executed on a certain market, producing a certainly list of buy & sell |
15 |
>> operations and a specific gain or loss. It would be quite easy to |
16 |
>> compare the outcome because it's nothing more than a list of trades. |
17 |
>> If the translated code generates the same list then it works. If not, |
18 |
>> I dig into why. This part of the task seems relatively straight |
19 |
>> forward to me. |
20 |
>> |
21 |
>> I was mainly hoping to find a tool that might generate _reasonable_ |
22 |
>> C code, even if it's not perfect. If the C code compiles and runs then |
23 |
>> I could determine what works, what doesn't, and start fixing things. |
24 |
>> I'm not a C programmer and haven't touched that language in at least |
25 |
>> 15 years so anything that moves me forward would be helpful. |
26 |
>> |
27 |
>> Again, I do appreciate your inputs. If this extra info gives you |
28 |
>> any new ideas please let me know. |
29 |
> |
30 |
> If you don't even have a common low-level language, what you're |
31 |
> essentially doing is creating a compiler for EasyLanguage. Take a small |
32 |
> example, adding two integers in E.L. I won't pretend to know the syntax, |
33 |
> but let's just assume that you have two integers (or numbers or |
34 |
> whatever) 'a' and 'b' declared. |
35 |
> |
36 |
> How do you translate "a+b" to C code? You can declare two ints 'a' and |
37 |
> 'b' in C, of course. But these are 32- or 64-bit integers. So if 'a' and |
38 |
> 'b' are large, "a+b" will overflow. Do EasyLanguage integers work that |
39 |
> way? Probably not... |
40 |
> |
41 |
> How about "a/b"? Does EasyLanguage do integer division, or does it treat |
42 |
> them like floats? If it does treat them like floats, do the rounding and |
43 |
> precision agree with C floats? Probably not, so floats are out too. |
44 |
> |
45 |
> If you try to fix all of these problems, what you'll end up with is |
46 |
> something like a struct EasyLanguageInteger {...} with associated |
47 |
> functions add_easylanguage_integers, divide_easylanguage_integers, etc. |
48 |
> Then, you can translate "a+b" into add_easylanguage_integers(a, b) where |
49 |
> 'a' and 'b' are now structs instead of just ints or floats. |
50 |
> |
51 |
> Then, you'll have to write a parser that understands the rules of |
52 |
> precedence, looping constructs, functions, and everything else so that |
53 |
> they can be converted into the appropriate structs and function calls. |
54 |
> At the end, if it works, you'll have an EasyLanguage compiler. |
55 |
> |
56 |
> Without a spec (the language is proprietary?), you'd have to guess at |
57 |
> most of that stuff anyway, so the chances you'd get it all right are |
58 |
> about zero. |
59 |
> |
60 |
> Your best bet[1] is to create a ton of test data, and feed it to the |
61 |
> E.L. program. Make sure the test data triggers any edge cases. Then you |
62 |
> can attempt to rewrite the code in C, and compare the output. You as a |
63 |
> human who understands what the code does can take a lot of shortcuts |
64 |
> that a translator couldn't. |
65 |
> |
66 |
> |
67 |
> [1] I'm assuming you want to do this for a relatively small number of |
68 |
> programs, and that writing a compiler would not actually be less |
69 |
> time-consuming. |
70 |
> |
71 |
> |
72 |
|
73 |
OK - this is probably WAY too off topic for this list. If folks |
74 |
strongly want me to stop the thread I will but I appreciate the |
75 |
technical adeptness of folks on this list quite a lot and the eventual |
76 |
outcome would be the use of this thing on Gentoo, so I hope folks |
77 |
won't mind too much if we continue a little further. |
78 |
|
79 |
|
80 |
REALLY great points about the math issues. Thanks. |
81 |
|
82 |
As for testing it _may_ be a slight bit easier than having to get to |
83 |
that level. There is a library in portage called ta-lib which |
84 |
implements lots of standard technical analysis constructs. After it's |
85 |
installed I don't seem to have the C code for the actual functions |
86 |
anymore. What I have is a compiled library as well as some header |
87 |
files to look at. I suspect I can install the library again using |
88 |
portage bt not getting rid of the functions which I could then use as |
89 |
an example for my coding. |
90 |
|
91 |
I have not used this library myself, but I've read enough on the web |
92 |
to be reasonably sure it's results are very consistent with what |
93 |
TradeStation functions of the same type do. |
94 |
|
95 |
For a simple function call like a moving average EasyLanguage would write: |
96 |
|
97 |
Inputs: |
98 |
Price(Close), |
99 |
Length(10) |
100 |
; |
101 |
variable: |
102 |
MA1(0) |
103 |
; |
104 |
|
105 |
MA1 = Average(Price,Length); |
106 |
|
107 |
Here is what I see for a similar moving average function from ta-lib: |
108 |
|
109 |
/* |
110 |
* TA_MA - Moving average |
111 |
* |
112 |
* Input = double |
113 |
* Output = double |
114 |
* |
115 |
* Optional Parameters |
116 |
* ------------------- |
117 |
* optInTimePeriod:(From 1 to 100000) |
118 |
* Number of period |
119 |
* |
120 |
* optInMAType: |
121 |
* Type of Moving Average |
122 |
* |
123 |
* |
124 |
*/ |
125 |
TA_RetCode TA_MA( int startIdx, |
126 |
int endIdx, |
127 |
const double inReal[], |
128 |
int optInTimePeriod, /* From 1 to 100000 */ |
129 |
TA_MAType optInMAType, |
130 |
int *outBegIdx, |
131 |
int *outNBElement, |
132 |
double outReal[] ); |
133 |
|
134 |
TA_RetCode TA_S_MA( int startIdx, |
135 |
int endIdx, |
136 |
const float inReal[], |
137 |
int optInTimePeriod, /* From 1 to 100000 */ |
138 |
TA_MAType optInMAType, |
139 |
int *outBegIdx, |
140 |
int *outNBElement, |
141 |
double outReal[] ); |
142 |
|
143 |
int TA_MA_Lookback( int optInTimePeriod, /* From 1 to 100000 */ |
144 |
TA_MAType optInMAType ); |
145 |
|
146 |
|
147 |
Maybe I could use the definitions of these functions as a basis for |
148 |
understanding what might be a reasonable set of guesses? From my point |
149 |
of view, a good start at translation would be to use whatever is |
150 |
available in ta-lib whenever possible and only have to deal with other |
151 |
stuff like If/Else, Switch, etc. |
152 |
|
153 |
Just thinking. |
154 |
|
155 |
Thanks, |
156 |
Mark |