No, you are mistaken. NULLs mean "don't know" or "having no value at all". NULL is AFL is NOT zero. It is different than in languages like C where NULL is just a zero.
In AFL Null is NOT numeric value. NULL in AFL is special and follows null semantics (propagates through statments), so for example NULL plus any number is still NULL. This is because NULL means "having NO VALUE AT ALL". It's a black hole. Nothing.
NULLs are ONLY accepted at the beginning of the array. Once first non-NULL values is present in the array there must be NO null values anymore.
If entire array is filled with NULLs it means that "you don't know what period is" and result should be NULL (no answer) all the way.
My question was mainly about the different results for Dist2/Dist3 and H2/H3. I would expect the ARRAY NULL and the SINGLE VALUE NULL to have the same effect as the PERIOD part of the AFL function.
HHVBars and some other functions (that get variable period) are polymorphic. This means 2 different code paths for scalar input and array input. This is done because it gives more speed for scalar input by leveraging the fact that period does not change. Frankly, you should be getting an error message when you pass NULL (scalar) input as period. Period should be >= 1 and majority of functions already issue the error if you attempt to pass wrong period. I will check and error message will be added.
But why not expand the error mesage to arrays too? If an array is used a PERIOD and some element of the array is NULL, ideally I would like an error message, indicating the barindex() of the NULL PERIOD element.
Everything has its costs. Doing IF (conditional jump) on CPU is costly (it actually costs more than dozens of multiplications because pipeline is invalidated). If you do one "if" per function call (scalar input) it is not a problem, but if you do that for every array element and you have say one million array elements it is HUGE cost.
"Normal" people have no idea how todays CPUs work and "common sense" does not work in computers. I have 30 years of low level hardware experience with CPUs starting from TTL logic, then Z-80 and ending with todays x86/x64 and ARM architectures and I know what I am doing when I write programs.
AmiBroker would not be as fast as it is if it was written by average senior programmer (when I say "average" I mean someone with 20+ years experience).
So every solution in AmiBroker is well thought and for good reason. But I really don't have the time and the need to explain each and everyone as to why because I would not have any time for anything if I did.
AmiBroker was designed with principle to be fast and assumption that the end user has at least some idea what she/he is doing. Therefore when it would cost too much of performance it won't warn you that the "hot tea is hot".
If you don't know what you put in your own code, then you can do the checks yourself. There is even special function that counts nulls in the array: NullCount():
if( NullCount( period, 0 ) > 0 )
{
Error("Jeez I've got NULL(s) in period array");
}