topic Re : Sorting list problems in 2013 in LabWindows/CVI

Sorting list problems in 2013

just4u78 — Tue, 22 Jul 2014 04:15:35 GMT

I'm programming by CVI.

However, I encounter a critical problem - the list sort built-in library does not work.

In both of console and real-time application, the sort result is wrong.

How can I solve this problem.

=================================================================

int main (int argc, char *argv[])
{
double value1 = 3.0;
double value2 = 4.0;
double value3 = 1.0;
double value4 = 2.0;

double test;

int i;

ListType newList;

// if (argc < 2 || argc > 3)
// usage (argv[0]);

printf("This is built-in List type test program!\n");

newList = ListCreate(sizeof(double));

if (newList == VI_NULL)
{
return -1;
}

ListInsertItem(newList, &value1, END_OF_LIST);
ListInsertItem(newList, &value2, END_OF_LIST);
ListInsertItem(newList, &value3, END_OF_LIST);
ListInsertItem(newList, &value4, END_OF_LIST);

printf(">>>>> The original list\n");
for (i=0; i<ListNumItems(newList); i++)
{
ListGetItem(newList, &test, i);
printf("[%d] %f\n", i, test);
}

ListInsertionSort(newList, DoubleCompare);

printf(">>>>> The sorted list\n");
for (i=0; i<ListNumItems(newList); i++)
{
ListGetItem(newList, &test, i);
printf("[%d] %f\n", i, test);
}

if (newList)
{
ListDispose(newList);
}

return 0;
}

=================================================================

This is built-in List type test program!
>>>>> The original list
[0] 2.000000
[1] 3.000000
[2] 4.000000
[3] 1.000000
>>>>> The sorted list
[0] 4.000000
[1] 1.000000
[2] 2.000000
[3] 3.000000

RE: Sorting list problems in 2013

just4u78 — Tue, 22 Jul 2014 06:08:17 GMT

ListInsertItem function is not correctly working, too.

Who's duty about modification of this wrong library?

Rif.: Sorting list problems in 2013

RobertoBozzolo — Tue, 22 Jul 2014 06:31:58 GMT

There is nothing wrong in those function, it's really that you haven't read the help for ListGetItem, which clearly states that positionOfItemToGet parameter must vary from 1 to the number of items in the list. With your for loops starting at 0, you are really reading the last element in the list first (END_OF_LIST has the value of 0), next all other elements except the last one.

Rif.: Sorting list problems in 2013

just4u78 — Tue, 22 Jul 2014 06:54:20 GMT

Thanks for your attention.

I just know about the index.

Re : Sorting list problems in 2013

jm73 — Thu, 24 Jul 2014 12:19:41 GMT

Hello,

I met the same problem with ListFindItem:

ListFindItem with StartingPosition out of range

You are not alone

Most CVI functions returned error codes except the List functions, most CVI functions are 0 based except the List functions. The List functions don't respect the CVI "rules", unfortunatly for us !

Best regards.

Re : Sorting list problems in 2013

RobertoBozzolo — Thu, 24 Jul 2014 14:46:39 GMT

Well, as Daniel and Luis explained in the thread you linked, this is not actually a bug, even though I agree that it's not obvious.

Neither it's true that list functions are the only 1-based ones: just as an example, when you work with tables, row and column indexes are 1-based, working with a database the first record is 1 and there may be other cases.

The true fact is that when you use a function that requires an index you must double-check whether it is 1-based or 0-based.

Re : Sorting list problems in 2013

jm73 — Fri, 25 Jul 2014 08:23:23 GMT

Hello Roberto,

I agree with you, it's not a bug and we must be careful when using index.

1°) I think the documentation is "ambiguous". The parameter startingPosition for ListFindItem function is defined like this:

The position of the item in the list to start the search from. The position may be a number from 1 to the number of items in the list.
To start searching from the first item in a list, the constant FRONT_OF_LIST may be passed.

When you read " The position may be a number from 1 to the number of items in the list" you mind automatically eliminates values <1 (you never remember that FRONT_OF_LIST = -1 ! ) and END_OF_LIST is not mentionned.

If you write the help like below with the possible values, perhaps there will be less confusion:

The position of the item in the list to start the search from. The possible values are:

-1 (FRONT_OF_LIST) to start searching from the first item in a list.
0 (END_OF_LIST) to start searching from the last item in a list.
a number between 1 and the number of items in the list.

2°) I think it's was a bad idea to define END_OF_LIST = 0 because 0 is a "special" value.

END_OF_LIST = -2 would have been a better choice. So ListGetXXX would return NULL with an index = 0 and the index mistake would be easier to detect .

Bye.

Re : Sorting list problems in 2013

RobertoBozzolo — Fri, 25 Jul 2014 08:48:15 GMT

Yes, you're right, that choice of constant value is odd and may lead to confusion, even more if you consider for example that VAL_TO_EDGE (the constant used to set Rect structures up to the end of valid range in tables) is defined as -1!

That note of passing FRONT_OF_LIST to start searching from the beginning is too weak compared to END_OF_LIST being set as 0, so I agree that an improvement in the function help may be needed.

I have as a golden rule to carefully read the help and use system-defined constant whenever possible: this example encourages me to continue this way!