OpenG Slice 1D Array Issue

[eisenwr]

I was using the Slice 1D Array (DBL)__ogtk.vi and noticed it seem to always be missing the one end point. The VI documentation points to this. For -4:-2, it should return 3 elements, not just two as listed. This issue appears to be a missing increment for the Default case (see attached screenshot). How do I help to get this fixed an deployed into OpenG Array package?

[eisenwr]

Is the OpenG toolkit basically under no maintenance?

[hooovahh]

Well it's been about 7 years since any update was made to the Array package that did much, and the last fix was 5 years ago.  I can't say it is under no maintenance but if it is being supported I would say don't expect to see changes happen quickly.  

I'm sure it can be frustrating but there are plenty of people who don't monitor these boards daily.  JGCode last posed on the forums in February and he seemed responsible for that fix 5 years ago.  Volunteers like him have a work life, and a home life.  If you want to discuss OpenG issues, this is the place to do it.  If you want to see OpenG releases, please be patient.

Personally I would love to see especially the array package revisited.  There are plenty of optimizations like inlining, and conditional terminals that could make array operations much more efficient than they were for this code that was originally written in the 5.x era.

[GregSands]

Also, most of the Array functions could be rewritten as .vim macros, which solves both the issues of polymorphism and inlining.

[hooovahh]

Just now, GregSands said:

Also, most of the Array functions could be rewritten as .vim macros, which solves both the issues of polymorphism and inlining.

I would love that however VIMs (as you know) aren't really a supported and documented part of LabVIEW.  OpenG has generally been seen as stable, and well tested.  If you start adding unofficial technologies in it I would be very concerned that the stability can't be guaranteed.  But yeah this is something I think I'll do for fun some day, just re-write and update the OpenG Array tools as VIMs.  Especially with the new structure Jeff mentioned which would allow for one VI to handle the scalar and array permutations.

[drjdpowell]

My two thoughts on this were:

1) is this actually a bug?  Having the top end of a range be exclusive is not unusual, I think (if unintuitive at first).

and

2) who uses this function?  I can’t think of a use case.

[Jordan Kuehn]

1 hour ago, drjdpowell said:

My two thoughts on this were:

1) is this actually a bug?  Having the top end of a range be exclusive is not unusual, I think (if unintuitive at first).

and

2) who uses this function?  I can’t think of a use case.

If you consider this as similar to Matlab array indexing, then I believe it should be inclusive.  And there's an answer to #2.

 

http://www.mathworks.com/help/matlab/learn_matlab/array-indexing.html?requestedDomain=www.mathworks.com

Edited July 28, 2016 by Jordan Kuehn
source link

[hooovahh]

Yeah I have a hard time trying to figure out how to use this function and never have, nor have I known anyone to use it.  So I can't say if it is a bug or intended.

[ensegre]

If python-like indexing is implied, the OP is probably wrong.

$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a=[7,6,5,4,3,2,1]
>>> a[2:]
[5, 4, 3, 2, 1]
>>> a[:3]
[7, 6, 5]
>>> a[-1]
1
>>> a[4]
3
>>> a[-4:-2]
[4, 3]

https://docs.python.org/3/tutorial/introduction.html#lists

https://docs.python.org/3/tutorial/introduction.html#strings

[eisenwr]

Currently it does not like actually having the brackets included in the string. I could see a version that uses the () to be exclusive and [] to be inclusive per typically range syntax.

Following ensegre's example above 

[-4:-2) would give 4,3
[-4:-2] would give 4,3,2
(-4:-2) would give 3

Opinions? 

 

[Jordan Kuehn]

1 minute ago, eisenwr said:

Currently it does not like actually having the brackets included in the string. I could see a version that uses the () to be exclusive and [] to be inclusive per typically range syntax.

Following ensegre's example above 

[-4:-2) would give 4,3
[-4:-2] would give 4,3,2
(-4:-2) would give 3

Opinions? 

 

If it retained the current functionality and added the ability to parse those additional parameters I think it would be a useful addition.

[eisenwr]

On 7/28/2016 at 2:21 PM, hooovahh said:

Well it's been about 7 years since any update was made to the Array package that did much, and the last fix was 5 years ago.  I can't say it is under no maintenance but if it is being supported I would say don't expect to see changes happen quickly.  

I'm sure it can be frustrating but there are plenty of people who don't monitor these boards daily.  JGCode last posed on the forums in February and he seemed responsible for that fix 5 years ago.  Volunteers like him have a work life, and a home life.  If you want to discuss OpenG issues, this is the place to do it.  If you want to see OpenG releases, please be patient.

Personally I would love to see especially the array package revisited.  There are plenty of optimizations like inlining, and conditional terminals that could make array operations much more efficient than they were for this code that was originally written in the 5.x era.

My follow up to this, is I would be willing to get the work done on this VI at least. But how would I go about getting out for everyone to benefit from it?

EDIT: Started thread on this- 

 

Edited August 9, 2016 by eisenwr
Added new thread link

[eisenwr]

1 minute ago, Jordan Kuehn said:

If it retained the current functionality and added the ability to parse those additional parameters I think it would be a useful addition.

The original functionality be its current not inclusiveness of the last element?

[eisenwr]

On 7/29/2016 at 7:16 AM, hooovahh said:

Yeah I have a hard time trying to figure out how to use this function and never have, nor have I known anyone to use it.  So I can't say if it is a bug or intended.

I work in audio and the was testing filer passband flatness, but the AP box would only give me all the data and I had to start before and after my passband to get clean data. I used this to chop the data to just my passband and get max & min from the resulting array.

[Jordan Kuehn]

2 minutes ago, eisenwr said:

The original functionality be its current not inclusiveness of the last element?

In my opinion, yes.  Otherwise you risk breaking compatibility with existing implementations.

[eisenwr]

Just now, Jordan Kuehn said:

In my opinion, yes.  Otherwise you risk breaking compatibility with existing implementations.

That is what I was thinking.