LabVIEW
Help design a new OpenG VI, Average 1D Array
Update: After an initial round of comments and discussion, the cadidate contributor (Christopher Relf) and sponsor (Justin Goeres) have revised the functional spec. Here's what the VI currently looks like:
This opens up another Public Comment period for you to provide your valuable feedback. We appreciate any thoughts you might have. Please, take a look at the functional spec and let the OpenG developers know what you think, before this VI shows up in your palette
This opens up another Public Comment period for you to provide your valuable feedback. We appreciate any thoughts you might have. Please, take a look at the functional spec and let the OpenG developers know what you think, before this VI shows up in your palette
Hi All,
The Arithmetic Mean Candidate Functional Spec is now complete, and it has entered its Final Review Period. Comments on the Functional Spec are still welcome, but any issues should be brought up sooner rather than later.
The Initial Review Period for the Arithmetic Mean Candidate Technical Spec has now begun. Anyone who's interested is invited to look at the Technical Spec page and offer comments here. This is the time to bring up any issues or concerns you have with the actual implementation of the function.
There is currently one major Open Issue with the technical spec that needs to be settled:
The current implementation uses the top option in the figure. How important is it to avoid this copy? Note that one of the Key Technical Requirements is high performance.
Please join in on the discussion, here:
http://forums.openg.org/index.php?showtopic=820&st=60
The Arithmetic Mean Candidate Functional Spec is now complete, and it has entered its Final Review Period. Comments on the Functional Spec are still welcome, but any issues should be brought up sooner rather than later.
The Initial Review Period for the Arithmetic Mean Candidate Technical Spec has now begun. Anyone who's interested is invited to look at the Technical Spec page and offer comments here. This is the time to bring up any issues or concerns you have with the actual implementation of the function.
There is currently one major Open Issue with the technical spec that needs to be settled:
The current implementation uses the top option in the figure. How important is it to avoid this copy? Note that one of the Key Technical Requirements is high performance.
Please join in on the discussion, here:
http://forums.openg.org/index.php?showtopic=820&st=60
What's the reasoning for going to EXT and back. Seems silly. 🙂
If you are really worried about overflowing (and I don't think this is really an issue), you could divide the array first, then sum the elements. I don't think carrying that extra baggage of EXT is worth it. (The extra memory footprint for EXT in the loop version is not very significant, but allocation an entirely new array of EXT as in the no-loop version is expensive for large arrays.)
In order to overflow, all array elements need to be (on the average) within 2^31 of the upper DBL limit in the absolute worst case. A highly unlikely scenario.
I'll do some benchmarks for a better picture 😉
LabVIEW user groep 
10 min. edit limit:
And a better way (preventing the boolean array):
No benchmarks done.
Ton
Message Edited by TonP on 04-26-2008 07:17 PM
And a better way (preventing the boolean array):
No benchmarks done.
Ton
Message Edited by TonP on 04-26-2008 07:17 PM
There has been a lot of discussion that the 'add array' elements will result in an 'inf' result.
This was prevented by the adding insitde the for loop (as proposed by Jim), but it is too slow.
My proposal does it fast the first time without relocating a new array. If this results in an Inf while the input array has no Inf's I propose an add ext array. This will result in a bigger second array but is still considerable faster than the loop method.
Ton
(who likes to sing and dance)
This was prevented by the adding insitde the for loop (as proposed by Jim), but it is too slow.
My proposal does it fast the first time without relocating a new array. If this results in an Inf while the input array has no Inf's I propose an add ext array. This will result in a bigger second array but is still considerable faster than the loop method.
Ton
(who likes to sing and dance)
TonP wrote:
(who likes to sing and dance)
😄 I was mostly puzzled by the SGL instead of DBL for the final output, but I also seriously doubt that EXT is really needed, it just doubles the cost.
Do you have a link to the discussions with Inf results for pathological inputs of Σ. Does the LabVIEW "mean" work correctly for these?
The SGL is just easier to 'inf' than a double.
@altenbach wrote:I was mostly puzzled by the SGL instead of DBL for the final output, but I also seriously doubt that EXT is really needed, it just doubles the cost.Do you have a link to the discussions with Inf results for pathological inputs of Σ. Does the LabVIEW "mean" work correctly for these?
The start is here, or Jim is just looking for nails on low tide (a Dutch saying), meaning he is looking for a non-existing problem?
I don't know about the LabVIEW mean.
I'm quite sure the point-by-point mean will fail.
Ton
Message Edited by TonP on 04-26-2008 11:31 PM
