I'm reading the well known book "The C programming Language, 2nd edition" and there is one exercise that I'm stuck with. I can't figure out what exactly needs to be done, so I would like for someone to explain it to me.
It's Exercise 5-17:
Add a field-searching capability, so sorting may be done on fields within lines, each field sorted according to an independent set of options.
What does the input program expect from the command line; what does it mean by "independent set of options"?
Study the POSIX sort utility, ignoring the legacy options. Or study the GNU sort program; it has even more options than POSIX sort does.
You need to decide between fixed-width fields as suggested by Neil Butterworth in his answer and variable-width fields. You need to decide on what character separates variable-width fields. You need to decide on which sorting modes to support for each field (string, case-folded string, phone-book string, integer, floating point, date, etc) as well as sort direction (forward/reverse or ascending/descending).
The 'independent options' means that you can have different sort criteria for different fields. That is, you can arrange for field 1 to be sorted in ascending string order, field 3 to be sorted in descending integer order, and field 9 to be sorted in ascending date order.
Note that when sorting, the primary criterion is the first key field specified. When two rows are compared, if there is a difference between the first key field in the two rows, then the subsequent key fields are never considered. When two rows are the same in the first key field, then the criterion for the second key field determines the relative order; then, if the second key fields are the same, the third key field is consulted, and so on. If there are no more key fields specified, then the usual default sort criterion is "the whole line of input in ascending string order". A stable sort preserves the relative order of two rows in the original data that are the same when compared using the key field criteria (instead of using the default, whole-line comparison).
It's referring to the ability to specify subfields in each row to sort by. For example:
sort -f1:4a -f20:28d somefile.txt
would sort the field beginning at character position 1 and extending to position4 ascending and within that sort the field beginning at position 20 and extending to 28 descending.
Of course, there are lots of other ways to specify fields, sort order etc. Designing the command line switches is one of the points of the exercise, IMHO.
Related
Good afternoon, the standard sorting in comerstools supports sorting alphabetically. The sorting principle is special characters first, then numbers, then letters. I need records to be returned
A-Z
numbers
specsymbols
and if the record starts with a space, then this space is not taken.
"A"
" B"
"9"
"("
Is it possible to do this with the standard tools of comerstools? The documentation says only about sorting in ascending and descending order. I need to set a different sorting principle.
I'm trying to use the queries described in the documentation
products-search#sorting
Currently, the sort feature cannot be customized as you describe.
As mentioned in the documentation, if multiple sort expressions are specified via multiple sort parameters, they are combined into a composed sort where the results are first sorted by the first expression, followed by equal values being sorted according to the second expression, and so on. This could be helpful to your use case.
https://docs.commercetools.com/api/general-concepts#sorting
Best regards,
Michael
I have an Azure Search Index that I'm hitting from an AngularJS app and I've run into a bit of a problem. One of my tables has a property that defines a "Sort Order" for the rows in the table, which is going to be used in the app to determine what order to display the items in the table to the user. Sort Order is an integer, and the goal here is when an admin user defines the "Sort Order" as 1, that item will appear first, 2 will appear second, etc.
My preferred solution would be to just sort the results from my query by ascending and spit that out to the user, but I've run into a problem with my null values, since Sort Order isn't a required field. All my models are written in C#, so null entries are being set to 0, and thus the entries without a sort order defined would be displayed first if ordered by ascending, which is the exact opposite of what I want.
There's a lot of different ways I could deal with this, but the easiest would be if I could just set the SortOrder property as a nullable int. The only problem with this is I'm not sure how Azure Search treats null values with its OrderBy statement. My initial thought was, if sorted by ascending, it would list all the numerical values in ascending order first, then kick the null values down to the end. If that's the case, then that's perfect, but I'm just looking to find out if that is indeed the case.
So, in short, my question is: Would Azure Search treat null values as greater than or less than a defined integer value? Put another way, if I OrderBy ascending integers, would the null values appear at the top or the bottom?
Azure search will place those documents whose $orderby column happens to be null towards the end of the results. This is true regardless of if you choose to order by "descending" or "ascending".
If there are multiple documents where the $orderby column is null, rest assured that all of them would be placed near the end, but you should ideally treat the ordering amongst the "null-valued" documents as undefined.
I find the above answer wrong, as per my experience, If there are null values in the field, null values appear first if the sort is asc and last if the sort is desc.
You can refer the Azure documentation below for same search-query-odata-orderby
Consider a 2D array "Array" that contains values : {1,2,3,4,5,6,7,8,9}. My major issue with the understanding of both orders is that if Row Major Order is to be represented as Array[i,j] (while i is row and j is column),
[i0,j0][i0,j1][i0,j2]
[i1,j0][i1,j1][i1,j2]
[i2,j0][i2,j1][i2,j2]
So that if you are asked with a question such as "find the address of element Array[1,2] in Array[2][2]", you'd know that the number of rows come before the number of columns and it would be easy to put them in the formula:
Base(Address) + w(dataSize){N(i - Row_lowerBound)+(j - Col_lowerBound)}
While 'N' is the number of columns
does it mean that the column order can be represented as Array[j,i] which would mean that the Column number appears earlier than the row number. So there is no way of knowing where the i,j,Row_lowerbound and Col_lowerbound values of Array[j][i] (e.g Array[3][4]) are to be put in the formula.
for e.g if the question appears as: "Find the address of Array[1][2] in the array Array[3][4]" How would you know if 3 is the number of colmns or 4? How would you know whether the 'i' is 3 or 4?
You can't know. There is no relation between how the computer represents the data and how you interpret it. Since you are "free" to interpret it the way you like, then it's your responsability to know which index is for rows and which one for columns.
Usually you can, write the specification in comments in the code itself or write documentation for functions using the structure. Also, you could write functions to access the array that enforce the order of indexes. But then, it's still not immediately unambiguous but has the benefit that you can check for out of bound access.
I read over the docs for PostgreSQL v 9.3 arrays (http://www.postgresql.org/docs/9.3/static/arrays.html), but I don't see the question of ordering covered. Can someone confirm that Postgres preserves the insertion order/original order of an array when it's inserted into an array column? This seems to be the case but I would like absolute confirmation.
Thank you.
The documentation is entirely clear that arrays are useful in scenarios where order is important, inasmuch as it explicitly documents querying against specific positions within an array. If those positions were not reliable, these queries would have no meaning. (Using the word "array" is also clear on this point, being as it is a term of the art: An array is an ordered datatype by its nature; an unordered collection allowed to contain duplicates would be a bag, not an array, just as an unordered collection in which duplicates were not allowed would be a set).
See the examples given in section 8.1.4.3, of "pay by quarter", with index position within the array indicating which quarter is being queried against.
Cannot find in documentation, but I'm pretty sure. Yes, order is preserved. And [2,4,5] is different from [5,2,4].
In case I'm wrong, indexes cannot work.
I have a set of data which has a name, some sub values and then a associative numeric value. For example:
James Value1 Value2 "1.232323/1.232334"
Jim Value1 Value2 "1.245454/1.232999"
Dave Value1 Value2 "1.267623/1.277777"
There will be around 100,000 entries like this stored in either a file or database. I would like to know, what is the quickest way of being able to return the results which match a search, along with their associated numeric value.
For example, a query of "J" would return both James and Jim results which the numeric values in the last column.
I've heard people mention binary tree searching, dictionary searching, indexed searching. I have no idea which is a good route to peruse.
This is a poorly characterized problem. As with many optimization problems, there are trade-offs in resources. If you truly want the fastest response possible, then a likely approach is to compile all possible searches into a table of prepared results, so that, given a search key, you can look the search key up in the table and return the result.
Assuming your character set is limited to A-Z and a-z, a table with an entry for each search key from 0 to 4 characters will use a modest amount of memory by today’s standards. Each table entry merely needs to have two values in it: The start and end positions in a list of the numeric values. (Compile the list in this way: Sort the records by the name field. Extract just the numeric values from the records, maintaining the order, putting them in a list. Any search key must return a sublist of contiguous records from that list. This is because the search is for a prefix string of the name field, so any records that match the search key are adjacent, when sorted by the name field.)
Thus, to create a table to look up any key of 0 to 4 characters, you need fewer than 534 entries in a table of pairs, where each member of the pair contains a record number (32 bits or fewer). So 8•534 = 60.2 MiB suffices. (53 is because you have 52 characters plus one sentinel character to mark the end of the key. Alternate encodings could reduce this some.)
To support keys of more than 4 characters, you need to extend this. With typical data, 4 characters will have narrowed down the search greatly, so you can take the set of records indicated by the first 4 characters and prune it to get the final results. If the data has pathological cases where 4 characters does not reduce the search much, you can embellish this technique.
So, is that really what you want to do, make the speed as fast as possible, regardless of other resources (including engineering time) consumed? If not, what are your actual goals?