|
PureBytes Links
Trading Reference Links
|
On Fri, 14 Dec 2001, jonmac wrote:
> I have lots of trouble with the 64K size limit. My systems have many stops
> coded individually into each system, and then there are arrays etc I have
> built with help from Bob Fulks, Gary Fritz and others.
I have also received lots of help from this list.
> One problem I have is that while the arrays and other functions I have made
> help reduce the code size, when I implement the function that holds the
> array with a system using lowest or highest function I get the message:
> "Variables & Arrays cannot be passed to function Lowest".
> Does anyone have any suggestion as to what I am doing wrong, or a possible
> fix if this is a TS bug, please?
I forget off-hand, but there is an input type that must declared for a
function to receive an array. I think it is something like NumericArray.
I know you can pass in Numeric, NumericSeries, NumericSimple, etc., and I
think the array type is NumericArray. Are you using that input type?
Rereading your paragraph I think my above statement is wrong. One of the
grumps I have with Omega is the lack of integration into other standard
tools. One of the tools I would like to see integrated, or allowed for,
or recoded for, is the Unix tool lint(1). This tool is designed to check
for 'stupids' in code. To have such a tool available for EL might find
your error easily. I don't have my manuals or other resources with me,
but I would guess there is a variable or function that is similiar to
Lowest() and it is that name-space conflict that is causing your error.
> Also, when functions are made for code (even small code), is the 64K code
> size of systems reduced by the use of these functions?
I know that Omega has published that TS4 has only 64KB of code space, but
I do not remember it being stated anywhere that it is 64KB of total space,
or 64KB of space for each function/indicator/strategy/signal, or just
exactly is and is not put into that 64KB chunk. In an interpretive
system where the code is dynamically compiled to pcode and then kept
for run-time interpretation that 64KB chunk limit might apply to the
maximum quasi-compiled EL code. This implies that each function, or
indicator, or any EL component has 64KB of available space. Or if a
cheap, simple interpreted system is in place that has a pre-allocated
chunk of memory for all quasi-compiled code and there are pointers
referencing small portions of this 64KB chunk for each quasi-compiled
EL function, then there is only 64KB for all EL code in use throughout
the application.
> And in general, would it be reasonable to think that about 2x A4 pages of
> code would be about the 64K limit? (This seems to be about the amount of
> text, that produces my warning 'size' limit).
I forget the dimensions of A4, but Letter size at 8.5"x11" is roughly
80 characters by 66 lines which is 80*66=5280 (the number of feet in
a mile, how odd). Two sheets of this is 10560 characters. I guess that
the proportions of A4 would be similiar, though I know the actual
dimensions are different.
Considering my lengthy paragraph earlier about just how Omega has
interpreted the 64KB limit, the consideration of just what makes up
64KB is moot. I hope that TS is byte-compiling the code in some form
rather than parsing EL code each time at run-time. Since byte-codes
are much more dense than EL code then trying to guess just how
much EL code fits into 64MB reaches the ramifications of the number
of angles on a pin head.
Mike
|