Account Performance feature on NT 8 ??

[jjanguda]

Hi,

Attached image is from NT 7 account performance tab.
I can easily modify date range to show how I did and how much I made or lost.
But I can't find account performance tab on NT 8 control center.

Is there even this particular feature available in NT 8?

Thanks for your help.


__________________________

Update


Sorry. I found out trader performance under New. Thanks

[usdivers]

sort of same problem

I am with Tradervue.....when I was with NT7 I could get the performance and save as CS file and then upload performace to TraderVue.

However...on NT8...I can't find this feature....I need the data in CS file so I can save and upload to TraderVue.

[sledge]

I am with Tradervue.....when I was with NT7 I could get the performance and save as CS file and then upload performace to TraderVue.

However...on NT8...I can't find this feature....I need the data in CS file so I can save and upload to TraderVue.

What is a CS file?

According to bing..

CS file extension
A CS file is a source code file written in C# (pronounced C Sharp"), an object-oriented programming language created by Microsoft for use with the .NET Framework. It used for developing a range of applications, from simple desktop programs to applications for distributed environments.

Did you mean a CSV?

[NinjaTrader_Jim]

Hello usdivers,

Thanks for your question.

Data grids in the NinjaTrader platform can be exported as .CSV or .XLSX by right clicking on the data grid and selecting Export.

Working with Data grids - https://ninjatrader.com/support/help...data_grids.htm

Please let us know if we can be of further assistance.

[fastpalo]

Go To "New" and then "Trade Performance"

Go To "New" and then "Trade Performance"

I know jjanguda updated his post with this info but i missed it the first time I looked though this. So i posted this info in a reply so it is easier for people to find.

[Johnny]

I hope I can add a "Performance Report" question here.

How is the Profit Per Month statistic/metric calculated?

I'm viewing one day only for one account with one daily trade at a loss of $250. Yet, the monthly profit is at $-6100.

I don't understand how this can be (no other live trades during this period).

[NinjaTrader_Jim]

Hello Johnny,

The statistic can be referenced here: https://ninjatrader.com/support/help...ProfitPerMonth

I agree this figure does not look right. I've reported the issue further and I will write back as this develops.

[Johnny]

Hello Johnny,

The statistic can be referenced here: https://ninjatrader.com/support/help...ProfitPerMonth

I agree this figure does not look right. I've reported the issue further and I will write back as this develops.

It seems to be more of a 'fantasy' calculation and potentially misleading. If anything, I guess it would be nice to have the option of not displaying it.

But thank you for clarifying. At least now I know the logic of it.

[NinjaTrader_Jim]

Hello Johnny,

QA has shared that this is expected based on the math used to calculate the statistic. Basically the PnL is being divided by 1/30.5 and is multiplying the statistic. The help guide will be improved to better reflect what the statistic represents, and we have created a feature request for being able to hide the Profit Per Month statistic.

The ticket ID is SFT-3218. As with other feature requests, we cannot present an ETA as they are fulfilled based on the development team's schedule and priorities. Upon implementation the ticket ID can be found publicly on the Release Notes page of the help guide. I'll provide a link below.

Release Notes: https://ninjatrader.com/support/help...ease_notes.htm

If there is anything else we can do to assist, please let us know.

[brucerobinson]

Please add my vote.
"QA has shared that this is expected based on the math used to calculate the statistic. Basically the PnL is being divided by 1/30.5 and is multiplying the statistic."
'Basically' this is total horse both as a reply and what is going on.
For "expected based on the math used to calculate the statistic" read "the math used is wrong, fundamentally flawed incorrect muddled thinking - 30.5 is used because there are average 30.5 days in a month. But there aren't 30.5 trading days that are going to generate the profit calculated in a month, there are 20. So unless you are a half-wit you're not going to expect to generate 30.5 days of profit and therefore unless you are a half-wit you're not going to use that as the math and try to say it is correct with some bunch of weasel-word gobbledegook non-reply.
It has been like this since 7 and possibly 6 before it, and has not been addressed in 8 so don't hold your breath. Or in Ninjaspeak "we have created a feature request for being able to hide the Profit Per Month statistic". - if it calculated correctly Profit per Month correctly on 20 days you wouldn't need a 'feature' to hide it. Unreal. "The ticket ID is SFT-3218. As with other feature requests, we cannot present an ETA as they are fulfilled based on the development team's schedule and priorities." Gobbledeweaselspeak for the software is wrong and we haven't fixed this in 10 years so don't get your hopes up that we're going to fix this any time soon.
Doesn't bother me in the slightest because I'm not interested in it, and because I figured out the ludicrous schoolboy error years ago - if wanted just take 2/3 of the number. But really............. "QA has shared that this is expected based on the math". Grow up with your answers.
Kind regards,

[NinjaTrader_Brett]

Bruce,

We track suggestion and feedback and review them in aggregate to see if we would want to take any action.

In this case this is a request to change it from what we originally intended which is that profit per month is a calendar year stat, allow me to demonstrate using round numbers.

You run a backtest and make $100 dollars every month for a total period of 4 months from January 2018 to April 2018. What do you expect profit per month to be?

I expect to see, profit per month of around $100 and we see this number in NinjaTrader since the actual calendar days between the first execution on Jan 1st and last execution on April 30th is 120 actual calendar days . 120 / 30.5 = 3.93 averaged months. $400 profit / 3.93 months = $101.78 profit per month. Its not exactly $100 because this is where the 30.5 approximation comes in on number of days in a calendar month since not all months have the same number of days.

If we try to instead 2/3 the number by using a 'trading days' concept. Then the profit per month value would be impacted as such: 120 actual days / 21 trading days in a month = 5.71 trading months, $400 profit / 5.71 months = 70.05 profit per month. Which does not match my expected profit per month value.

Its possible your expected profit per month might be be a measure of time of trading days vs calendar months but right now we keep it at calendar months unless we see enough feedback there to change it. As an alternative we open sources performance metrics in NT8 and any performance metric can be custom added simply, since there is no one size fits all metrics.

[brucerobinson]

Brett,
I understand what is happening, having experienced it myself and previously reverse engineered the behaviour reported by Jonny that I responded to.

The problem Jonny encountered results from the use of a calendar days approach applied as a multiplier to a single trading day or period when trading and calendar days are not of a 5:7 ratio. Per Jonny - "I'm viewing one day only for one account with one daily trade"

In that situation Trade Performance multiplies a single trading day's performance and extrapolates and reports it as a Profit per month using 30.5 calendar days in the month. In that situation, doing so is flawed because there are not 30.5 trading days in the month from which the Profit per month figure can be generated

Allow me to demonstrate using round numbers.
I trade for one day and make $100 profit. The expected Profit per month displayed by Trade Performance is $3,050 ($100 x 30.5). That is quite simply wrong. There are not 30.5 days on which the Profit from a single day that is being multiplied can be generated. There are around 20-23, so Profit per month would be expected to be $2,000 ($100 x 20). To use Jonny's words "more of a 'fantasy' calculation and potentially misleading". This is the situation Jonny raised, and the reason it is happening was not explained.

With regard to your response/example of using trading days:
"If we try to instead 2/3 the number by using a 'trading days' concept. Then the profit per month value would be impacted as such: 120 actual days / 21 trading days in a month = 5.71 trading months, $400 profit / 5.71 months = 70.05 profit per month. Which does not match my expected profit per month value. "
It seems you may have misunderstood what I wrote/wasn't clear, and confused or combined a 'trading days' concept and '2/3 the number', The approach you have used here makes no sense to me.

The correct approach, such that it would be, for a 'trading days' concept would be to apply 2/3 to the 120 calendar days
Allow me to demonstrate in your example using round numbers:
“If we try to instead 2/3 the number by using a 'trading days' concept. Then the profit per month value would be impacted as such: 120 elapsed days x 2/3 actual trading days / 21 trading days in a month = 3.8 trading months, $400 profit / 3.8 months = $105 profit per month. Which does match my expected profit per month value.”
Both the elapsed days period under analysis and the number of trading days generating the profit in a month are of the same unit - trading days, apples with apples. Your approach doesn't make any sense, but it doesn't serve to demonstrate why a trading days concept could not be used.

However this was not in fact what I was suggesting nor advocating although it has merit for the situation brought to your attention.

What I intended was as a workaround to the issue raised, Jonny or others might simply multiply whatever fantastical Profit per month figure Trade Performance produces under the circumstances described by 2/3 to correct for NT multiplying by an unavailable 30.5 trading days in the month when there are in fact only around 20. (20-23 trading days /30.5 calendar = 2/3 approx, multiply the spurious $3,050 Trade Performance figure by 2/3 and you'll get $2,000 and back to reality)

The example you choose to use for illustration - back-testing over a (in comparison) long period mutes the problematic effect associated with use of calendar days over a short period, which is what Jonny reported and I experienced.

However, the Trade Performance functionality and Profit per month is not a tool used only for back-testing. Indeed in the example shown in the Help section a one week period is shown selected. This effect of use of calendar days is not limited to single day extrapolation. If you choose a shorter time period including holidays, this will have a skewed effect on the Profit per month.

I'm not advocating a change or a feature request, although I feel the behaviour is undesirable.

I am advocating that when issues such as this are brought to Support's attention, a full transparent explanation is provided which may in turn help others in future.

The frustration evident in my earlier tone stems from a lack of this.

Kind regards

Bruce

[NinjaTrader_Brett]

Thanks for the replay and understand.

Just to make sure I understand the use case. Your using the profit per month as a forcast with incomplete data vs using it as a breakdown of what already has happened. Do I understand that correctly?

[brucerobinson]

Brett,
I already told you "Doesn't bother me in the slightest because I'm not interested in it". I'm not using it for anything. I have observed the same behaviour as reported, I'm responding to incorrect information being generated by the platform, and the explanations given for it, wherever such may apply or the use case.

Kind regards
Bruce

[NinjaTrader_Brett]

Fair enough, was just thinking about possible introducing a better forecasting metric for that use case that would just work differently and might work better for the use case. Thanks again.