Boundary Condition. Starting a counter at Bar 1

[sbhyde]

This is quite simple, I thought .. but this one is making be think this is VB6 all over again.

I am running a counter starting at bar 1. I don't always increment it but for this example I am. This is an isolated and simplifier example.
It did not include in the images, but the close price is different for each bar. You can look at the bars and see that. This should be easy to reproduce,

# MDLN  < use this symbol to easily get to bar #1

def pC = if BarNumber() == 1 then 1 else if (close == close[1]) then pC[1] else pC[1] + 1;

AddChartBubble(yes, high, BarNumber() + "  " + pC + "  " + isNAN(pC), Color.WHITE);

Despite the line assigning the counter the value of 1 when the Barnumber is 1 (BarNumber() == 1 then 1), the value in the counter is 0. The value is not NaN.
Attached is an image showing the code and the result.
Troubleshooting isolated the problem to (close == close[1]). If I replaced that expression with (1 == 2), I get the expected result.
Apparently even though the first condition of the if statement is true, it still evaluates close[1] which does not exist. But it does not produce an error.

I tried using CompoundValue like this

# MDLN  < use this symbol to easily get to bar #1

def pC = CompoundValue(1, pC[1] + 1, 1);

AddChartBubble(yes, high, BarNumber() + "  " + pC + "  " + isNAN(pC), Color.WHITE);

The counter initialized properly on bar 1, but it did not increment on bar 2. Proper incrementing started on bar 3. See images
Any thoughts would be appreciated

 

[Joshua]

The issue is that you're introducing a constant-driven offset [1] to a primary fundamental (OHLC, etc.) at the explicit beginning of the chart, where no data exists prior. I can explain it in greater detail if need be.

def pc =
    if barnumber() == 1 then 1
    else pc[1] + !(close == getvalue(close,1));

AddChartBubble(yes, high,
    BarNumber() + "  " + pC + "  " + isNAN(pC)
,Color.WHITE);

 

[sbhyde]

The issue is that you're introducing a constant-driven offset [1] to a primary fundamental (OHLC, etc.) at the explicit beginning of the chart, where no data exists prior. I can explain it in greater detail if need be.

def pc =
    if barnumber() == 1 then 1
    else pc[1] + !(close == getvalue(close,1));

AddChartBubble(yes, high,
    BarNumber() + "  " + pC + "  " + isNAN(pC)
,Color.WHITE);

Joshua. I wanted to thank you for the reply and to create a record for others who might come across this problem.

I understand what you are saying. I am not having a problem on bar 1, when [1] has nothing to reference. I encountered the problem on bar 2, when [1] referenced the value in bar 1 which printed on the screen as 1. (just like VB6 - don't make no sence!)

CompoundValue(1, pC[1] + 1, 1) is supposed to use 1 for bar 1 and not evaluate pc[1] until the bar number is greater that 1. I thought this was the entire reason for the existence of CompoundValue, to protect the code from the starting boundary issues!

As a non-member my post was held for a week plus and I eventually went to ToS support. After an hour of discussion, they admitted this was a bug that only occured when evaluating the day after the first issue date and they placed it on the bug fix list. Fix date unknown.

I tried other approaches, trying to find a way around what appeared to be erroneous behavior.
I tried this
def pc = if BarNumber() == 1 then 1 else CompoundValue(1, pC[1] + 1, 1);
Didn't work. Neither did a few other things. At the time I didn't realize this was a bug deep in the CompoundValue function.

Your code works!
It would seem the solution is to stay away from the CompoundValue function.

Thank you....

 

[Joshua]

A chart has two beginnings. One is when you've chosen to limit the span of visible data in your time frame settings by preference. The other is first issuance, this is the absolute beginning of the data.

Offsets introduce pre-fetch, this generates virtual bar numbers 0 through -N, incrementing leftward from the chart's first bar. The length of which is driven by maximum length offset present in the script. This allows calculations that involve a length of bars to display immediately.

Pre-fetch effects the entire script. One variable can begin calculating prematurely due to unintended pre-fetch from another variable. That's what compound value is for, primarily.

The same can be accomplished and surpassed free-hand though. Nobody really uses compound value. It's usually a sign of ai-spam, or more fittingly, of experienced programmers from other languages trying to be overly official with the syntax while first learning thinkscript.

However, the data must exist, such as beyond the span limit. Things behave strangely when pre-fetch overruns first issuance. The result isn't simply NaN as would be expected, it can be, but pre-fetch overrun posts a number of different return values based on context.

For example. Constants resolve to Self. Fundamental data, which is anything with a green identifier in the editor, resolves to NaN. Purely user defined variables resolve to zero. However, there seems to be an additional check involving recursion.

A entire variable definition can not include 1) an expression containing an offset fundamental reference, and 2) a recursive expression, both anywhere in the entire definition, while [n] overruns first issuance.

If that is the case, the entire definition resolves to zero. This rather unique check completely ignores the exclusivity of logical branches, individual expressions, and so forth.

I believe this is because of the fact that any expression involving NaN will always resolve to NaN itself outside of isNaN(). Therefore, otherwise, a recursive fundamental offset at first issuance would cascade NaN all the way down the entire chart.

So it sort of error-dumps it to zero.

def pC = if BarNumber() == 1 then 1 else if (close == close[1]) then pC[1] else pC[1] + 1;

Due to Close[1], and ... = pC[1], this entire definition resolves to zero while [1] overruns first issuance. The check for if BarNumber() == is not even considered until [n] overrun is exhausted.

Where as, in your (1 == 2) example, those are both constants, which resolve to self. There's no potential to recursively cascade NaN all the way down the chart, so it works.

The solution is to use GetValue() instead of offsets, unless you need intentional pre-fetch, or to simply delay all calculations until beyond max-offset length.