Gentoo Archives: gentoo-user

From: Mark Knecht <markknecht@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] [OT] - Code translation tools?
Date: Wed, 26 Jan 2011 19:42:22
Message-Id: AANLkTinF8h475j1E8Cd6ZE4cK-ggKTim63EyDENVF-g9@mail.gmail.com
In Reply to: Re: [gentoo-user] [OT] - Code translation tools? by Michael Orlitzky
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

Replies

Subject Author
Re: [gentoo-user] [OT] - Code translation tools? Michael Orlitzky <michael@××××××××.com>