Plot class Max and Min value?

[FireFly]

I noticed that although Plot uses doubles, it crashes when I set a plot to double.MaxValue or double.MinValue. I experimented a bit and found that setting it to 7E+28 is still OK but 8E+28 makes it crash.

What exactly is the limitation? Is that a fixed number?

Of course I can easily prevent the plot from being set to a number higher than 7E+28 but is it then guaranteed not to crash? My point is that if I don't understand under which conditions it will crash I cannot build in checks to prevent that from happening. Could there be cases in which lower numbers will crash it?

[NinjaTrader_Lance]

While we have system indicators that override the Plot() we do not support doing so and as such I cannot give you a definitive answer.

Consider posting your question here: http://ninjatrader.com/support/forum...ad.php?t=22435

Let me know if I can be of further assistance.

[FireFly]

While we have system indicators that override the Plot() we do not support doing so and as such I cannot give you a definitive answer.

Consider posting your question here: http://ninjatrader.com/support/forum...ad.php?t=22435

Let me know if I can be of further assistance.

I do not intend to override Plot(). I just like to understand this limitation to make sure I use Plot() within it's limits.

It's a simple question: in Plot0.Set(x), what is the highest and the lowest value of x that I can use?

[NinjaTrader_Lance]

The only limitation with doubles is going to be C# related and not NinjaTrader related

These bounds can be found here: http://msdn.microsoft.com/en-us/libr...(v=vs.71).aspx

Are you saying you're placing a number within these bounds and getting a crash?

Plot0.Set() is setting the data series named Plot0 at the current bar index

http://www.ninjatrader.com/support/helpGuides/nt7/index.html?dataseries_class.htm

[FireFly]

The only limitation with doubles is going to be C# related and not NinjaTrader related

These bounds can be found here: http://msdn.microsoft.com/en-us/libr...(v=vs.71).aspx

Are you saying you're placing a number within these bounds and getting a crash?

Yes that is what I'm saying. In the Control Center I get the message "Error on setting indicator plot for indicator 'Test2'. Value outside of valid range".

This happens when setting the plot to 8E28. At 7E28 or below it is OK.

Although these numbers are huge, they are well below the maximum value a double can handle (±5.0E−324 to ±1.7E308 as per the msdn link that you posted).

As I said before, it is not a big deal because do a check before setting the Plot. But it would be nice to understand WHY I get the error and what the "official" range is that the Plot class can manage.

[NinjaTrader_Lance]

Unfortunately I'm not able to give an exact number but after discussing this further with my colleagues I am able to give you a little more information.

Our chart system has limitations to the values that can be plotted. When you're setting the value of the dataseries Plot0 it will take a double but that double will have to be within these bounds of the chartable area.

[FireFly]

Unfortunately I'm not able to give an exact number but after discussing this further with my colleagues I am able to give you a little more information.

Our chart system has limitations to the values that can be plotted. When you're setting the value of the dataseries Plot0 it will take a double but that double will have to be within these bounds of the chartable area.

OK. So the chartable boundary is around 7E28? (apparently)

I was just wondering if the boundary is always the same or that it depends on anything else..

See, I'm plotting something that sometimes divides by zero. To prevent that I checked if the denominator is zero and made the value double.MaxValue to prevent it from crashing. But when plotting it still crashes because the number is too large to plot. So now I assign 7E28 to it because that appears to be "small" enough not to crash the plot:

		private double Divide( double x, double y )
		{
			if ( y == 0 )
			{
				if ( x > 0 )
				{
					return 7E28;
				}
				else if ( x < 0 )
				{
					return -7E28; 
				}
				else
				{
					return 0;
				}
			}
			else
			{
				return x/y;
			}
		}

Anyway, if it is unclear what the exact limit is then I'll just have to see how this holds up in the coming time. Thanks for your advice!