|
PureBytes Links
Trading Reference Links
|
----- Original Message -----
From: "Gary Fritz" <fritz@xxxxxxxx>
To: <omega-list@xxxxxxxxxx>
Sent: Saturday, February 28, 2004 3:45 PM
Subject: Re: Re[2]: QuantStudio
> > > Many times your system will not give
> > > the results you expect because of the difference between
> > > an indicator on the chart making it look like you should have a
> > > signal, but in fact your system shows different values then the
> > > indicator when you look at them. Indicators will, if setup to,
> > > automatically compute the number of bars to calculate on.
> >
> > AHA! This may be it, since I am looking at an indicator that is set
> > up EXACTLY the way the code expects it, but perhaps the iternal logic
> > for indicators is different for systems. In either case though, that
> > would be a bug. However, I will look at this more closely - this is
> > the first suggestion that actually makes sense.
>
> That's the definition of how TS works. Indicators can optionally
> auto-compute the minimum allowable MaxBarsBack value (and do by
> default), but you must specify it explicitly for systems. Maybe
> you don't like the definition, but that doesn't make it a bug.
> It's just something that anybody with any experience with TS
> should be aware of.
Wait, that is not what I was saying. What I am saying is that it may be that
the indicator is giving a signal, where as the code does not. The Max Bar
setting is the first thing I check when doing these things. I assuer you,
that is not the problem.
> The fact that 1) you weren't aware of it, and 2) you think you
> may have code that is sensitive to the MBB setting, makes me
> seriously suspect the problem is in your code (or the way you've
> set up your charts & studies) and not in TS.
I am fully aware of it. See above.
> Indicators don't have to auto-compute the MBB value. Set it
> explicitly (Format indicator -> Properties tab -> User specified)
> to the same value you set for your system, and then see if the
> indicator and the system match. If they do, then the problem
> lies in your code, not in TS. You need to write code that is
> stable regardless of how much leading data is present in the
> chart -- or at least be aware that your code (*not* TS) is
> sensitive to the amount of leading data and make sure you set up
> your indicators and systems with the same conditions.
>
> To continue with your BNF/compiler/etc example: it's possible
> for the same source code to produce different results if you
> compile it in ANSI C or C++. That doesn't mean the compilers are
> wrong. It means your assumptions are wrong if you expected the
> two languages to have the same behavior in that case. I think
> you have some wrong assumptions about your TS setup.
I do not have two ANSI compilers giving different answers here. I have one
program giving differnt results on the same computer on the same compilter.
The result you give above on C and C++ compilers are on subtle issues when
the laguage description changes, or the code generated is left to the
compiler writers. The difference in that case is that it is made known to
the community by stating as so. But this analogy is pointless, these errors
occur on 1 computer, on 1 and the same compiler.
> > I guarantee you, the machines are more than ample for the task. The
> > OS is windows 2000 Server. I have SP5 2000i Platinum. It started as I
> > added more and more systems, and more and more charts.
>
> Exactly the description of an under-configured system. TS2k
> absolutely has stability problems on too-small systems (not
> enough RAM, etc) but in most cases I've heard of, they go away if
> the PC has enough RAM. So yes, it is TS's fault, but you can do
> something about the problem.
WHAAAAAAAAAAT! So a computer running on dual Xeon processors, with 6 GB of
RAM, runngin windows 2003 Server Standard Edition is not enough hardware for
the task. Surely you jest!
> > > Well what we have here is a failure to communicate.
> > Where was the "failure" to communicate? I have bugs that are
> > unresovable in TS.
>
> Obviously I can't prove it without a lot more information, but I
> strongly suspect the bugs are NOT unresolvable in TS, but (in at
> least some cases) result from your lack of understanding how the
> system is SUPPOSED to work.
Well, I would love it to be resolvable in TS. If that happens, then this
waste of time back and forth will not have been pointless to me.
Ivan
> To Jimmy you said:
> > I am not an EL "pro" whatever that means. I have been programming
> > professionally for 15 years in C/C++/C#, in and out of the trading
> > industry. I will leave it to you to decide if that makes me an
> > "expert."
> > My guess is you know very little about the way languages and
> > computers really work.
>
> For what it's worth, I've been programming for twice that long,
> professionally for a good part of it, and I understand quite well
> how languages and computers really work.
>
> Gary
>
|