What is "scale fix"?
Are you still trying to measure "angles" on the chart instead of simply using slopes? Your life could be so much easier and you wouldn't have to worry about things that cannot be clearly defined or have no definition at all.
Now, if your defining Slope as simply the distance between 2 points in terms of pips, I wouldn't call that slope. I'd call it more like velocity.
How ARE you calcuatling slope then?
How ARE you calcuatling slope then?
Personally, I'm with 7bit on this one. Angles on charts are arbitrary unless you have a reason for attaching significance to the spacing of values on each axis.
On a related note, I've often seen angles used as a spurious reason for not taking trades when looking back at a historic chart - e.g. "I wouldn't have taken that trade because the angle of indicator X was flat". Whereas, in very many cases, indicator X only gets drawn as flat on a historic chart because of a very large move in the market after the time in question.
If you want a slightly more elegant slope calculation, have a look at linear regression. For example, Excel's SLOPE() function (e.g. http://phoenix.phys.clemson.edu/tutorials/excel/regression.html) still gives you a value whose units are price-change-per-bar, but it's generally more useful than simply looking at the price movement between the first bar and the last bar.
Personally, I'm with 7bit on this one. Angles on charts are arbitrary unless you have a reason for attaching significance to the spacing of values on each axis.
On a related note, I've often seen angles used as a spurious reason for not taking trades when looking back at a historic chart - e.g. "I wouldn't have taken that trade because the angle of indicator X was flat". Whereas, in very many cases, indicator X only gets drawn as flat on a historic chart because of a very large move in the market after the time in question.
If you want a slightly more elegant slope calculation, have a look at linear regression. For example, Excel's SLOPE() function (e.g. http://phoenix.phys.clemson.edu/tutorials/excel/regression.html) still gives you a value whose units are price-change-per-bar, but it's generally more useful than simply looking at the price movement between the first bar and the last bar.
Correct?
Well the x axis will be in whole values then (eg, 1, 2, 3, etc.) depending on how far you go back. Now, if we're doing like that, then I can see the usefulness.
Linear regression isn't suddenly radically more useful than the sort of slope measurement you've already discussed with 7bit. It's still measuring a price change per bar, e.g. a rise of 0.00073 per bar. A linear regression calculation just takes into account more information: the intermediate bars as well as the first and last ones.
/** * slope in raw price per second */ double getSlopeRaw(datetime t1, double p1, datetime t2, double p2){ return((p2 - p1) / (t2 - t1)); } /** * slope in Points per hour */ double getSlope(datetime t1, double p1, datetime t2, double p2){ return(getSlopeRaw(t1, p1, t2, p2) * 3600 / Point); } /** * slope of a line, ignoring weekend gaps */ double getSlopeOfLine(string name){ datetime t1 = ObjectGet(name, OBJPROP_TIME1); datetime t2 = ObjectGet(name, OBJPROP_TIME2); double p1 = ObjectGet(name, OBJPROP_PRICE1); double p2 = ObjectGet(name, OBJPROP_PRICE2); // now calculate bar numbers and multiply with // Period instead of using the times directly // to get the time in seconds *without* weekend gaps int dt = (iBarShift(NULL, 0, t1) - iBarShift(NULL, 0, t2)) * Period(); return(getSlope(0, p1, dt, p2)); }nondisclosure wrote >>
Now, if your defining Slope as simply the distance between 2 points in terms of pips, I wouldn't call that slope. I'd call it more like velocity.
How ARE you calcuatling slope then?
not the same units is perfectly allowable here. think about things like consumption of x liters gasoline per 100km or weight loss of x kg per day or the rise of the sea level of x centimeters per year. All these calculations involve different units and the result is of the dimension [unit1]/[unit2]. Sometimes (if you live in the part of the world where the metric ISO units are used) these are even new units that can be directly used standalone without any further conversion,
for example Energy (Joule) per time (Second) is measured in the Power (Watt) or simply E/t = P. 1 Joule per Second is 1 Watt.
In our case we simply measure the rise per time and call it growth and it can be measured (for example) in pips per hour.
see above for an example
not the same units is perfectly allowable here. think about things like consumption of x liters gasoline per 100km or weight loss of x kg per day or the rise of the sea level of x centimeters per year. All these calculations involve different units and the result is of the dimension [unit1]/[unit2]. Sometimes (if you live in the part of the world where the metric ISO units are used) these are even new units that can be directly used standalone without any further conversion,
for example Energy (Joule) per time (Second) is measured in the Power (Watt) or simply E/t = P. 1 Joule per Second is 1 Watt.
In our case we simply measure the rise per time and call it growth and it can be measured (for example) in pips per hour.
You could, if you wanted "points per time frame", you could do the following
double getSlopeRaw(int t1, double p1, int t2, double p2){ return((p2 - p1) / (t2 - t1)); }Just pass bar numbers instead of datetime and you get the movement of your line per time frame on your chart. Correct?
Sorry for the dumb question, I don't normally drink and I had a 'pint' about 15 minutes ago. :P
On the common tab of the property's for a chart there is an option of "Scale fix One to One". One what to one what?
I went through this issue rather intensively some time ago as well. Instead I just ended up using the difference in pip values, which is really all that is relevant. However if you want to utilize the information that you seek, just use 'Delta' Pips/'Delta' time and always use the same units on the time scale. Utilizing this method makes the representation on the chart a moot point and will 'standardize' your data info and calculations so that they are truly meaningful. For EAs and data analysis it is the actual data that is relevant, NOT the charts! So just use that data directly and forget about the chart for usage in your EAs etc. The EA does NOT take the info 'from the charts.' It takes it from the various data sets from dedicated and custom arrays etc as does the chart. The charts are only visual representations for us non digital beings to assist us and are indicative of the relative dynamic (mathematical) relationships going on with currency pairs so that we can understand the actual data.
If you want and need to make 'human' decisions based on the info on the charts and have it always be consistent and meaningful to YOU, then you need to lock all of your charts to this 'fixed' relationship. This makes them much more cumbersome and visually less effective as the charts normally change dynamically to present the data in the charts in the most effective layout.
VERY good points (and examples on power too!). NOW I get what you've been saying about slope.
As I already promised: You will eventually understand what I say, maybe I'm just not good at teaching things, so it always takes a while until I find the words to explain it in the most descriptive way.
Correct. You could just use bar numbers for time if you never switch timeframes. For true timeframe independence multiply the bar number with Period() and you always have the time in Minutes, Period() returns the duration of a bar in minutes. (I think i just have discovered an error in the above example, i should not have used Period() but Period() * 60 instead to get the seconds in the last function).
On the common tab of the property's for a chart there is an option of "Scale fix One to One". One what to one what?
If you are trying to avoid opening trades when the market is stagnant: 'consolidated' and trading sideways. There is an example of code in the library for doing so. If you want and need this and can't find it, let me know and I'll track it down for you. Personally I just set a external integer 'iMinimumPips' value for the chart/trading interval I am using. If it is lower than this, it won't open a trade. This method makes changing the value more directly indicative and understandable: you don't have to try and figure out all of the other variables involved with the slope value or angle and then calculate it .It also makes optimizing easier and more effective regardless if you are doing it yourself or with the strategy tester.
People keep talking about 'just using 'slope' and not the value of the 'angle' as figured out with trigonometry. 'Slope' IS a trig function with a different name!
I've started using the convention from a tip that CloudBreaker recommended by always preceding my (defined custom) variables with a single lower case letter that tells you what type of variable it is. Examples:
Integer = iWholeNumbers;
Double = dComplexNumbers;
Bool = bIsThisTrue;
String = sLiteralCharacters;
I've also added a second lower case letter for variables that have been 'normalized'. Examples:
Normalized Integers = inProperIntegerRepresentation;
Normalized doubles = dnCorrectAmountOfDecimalPlacesForTheTradeServer;
It's a small thing but is a very effective one that makes programming just a little bit easier as one instantly always knows what type of variable they are dealing with.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
On the common tab of the property's for a chart there is an option of "Scale fix One to One". One what to one what?