The ReST autonumbering problem
In .rst files, item lists can be created with a syntax that allows for autonumbering.
Handy, but it's exactly that convenience that makes referring to other items in the list a fraught undertaking. If a list item is referenced by number, it's all too easy for someone to later update the list, causing a renumbering, and neglect to update the item-reference. (Assuming it's even close enough to be noticed.) For example:
Item Franchise
==============
#. *Item*
#. Prequel: *Birth of Item*
#. *Son of Item*
#. *Item III: The Enumerating*
#. *Item Jr.*\ , a Remake of *Son of Item* (see item 2, above)
Obviously, the last entry should be referencing "item 3, above", but the author forgot about Birth of Item (or it was subsequently added to the list).
How do I know that's a concern? Well, besides the fact that it's obvious (for many of the same reasons that manual page-number references are a headache), I just opened a PR against the Python documentation, correcting exactly such an error that's gone unnoticed for the past three years.
Is there a better way?
I'll be very surprised if the answer to this is "yes", but is there any way to define item references in ReST so that it'll maintain them automatically, changing the referenced target-item number whenever the list ordering changes? Or perhaps someone's come up with a Sphinx extension along those lines?
If not, I'd certainly be interested in any clever suggestions for better ways to refer both to and between items in an ordered list. (Assume a situation more like the Python doc error, not my example where the "titles" are incredibly obvious crossref opportunities.)
Related
I just had a assessment about data structures and algorithms. And my teacher said that it is impossible to add a new node before the header. I have checked everywhere (on the internet and books) and it all said that is was possible.
So now my question is, who is right here?
EDIT: Here is a picture of the situation, add the red arrow I need to insert a new node.
You can add a first element easily (in one step) even either to the usual linked list or double-linked one. You are right.
The new element will get the pointer to the old first element.
For double-linked list also the old first element gets back reference to the new element.
The new element becomes the first one and is addressed as the list.
But be very soft and careful telling the teacher about his/her mistake. Maybe: "you meant inserting the last element in one step for the non-circular doubly linked list really, didn't you?" :-) I hope, you teacher is not the kind of person that gets easily offended hearing complex sentences.
As for the circular doubly linked list, you can insert both last or first element in one step. For the insert at head:
A new element gets reference to the old first and the back reference to the last ( from the old head back reference)
Old first changes its back reference to the new first
Last changes its reference to the new first.
Head (if you have one as a special something that has not data and is not a node) changes the reference to the new first. Edit According to your picture, you have not such thing.
You can also insert any element into any list, but it could take many steps moving from one element to another, for to reach the place.
Edit
Maybe, your teacher really meant that special reference that references the circular list from outside and has not its own data. It can exist for some special need. The very question of putting something into the list before the header has not sense at all - for the header does not belong to that part of the structure where the word before is defined. The element that is before the first element, is not outside the list, but it is the last element of the list.
That header, of course, can have something referencing it. The header is merely a reference, and it can have another "header of the header" and so on.
Big fleas have little fleas,
Upon their backs to bite 'em,
And little fleas have lesser fleas,
and so, ad infinitum.
And only an act of human will or some technical or religious limitation can forbide the possibility to reference a reference.
So, if the question (how to put something before the header) has sense, the word "before" for header must be interpreted as "referencing to", and we can put something before it. If "before" is defined for list nodes only, the question itself is senseless.
Linked Lists are dynamic meaning that there is no restriction on the size of it , and you can enter a node anywhere you desire, this is one of the many advantage of linked list. Your teacher might not have been talking about linked list may be circular queue otherwise she is wrong.
I am building a system that uses Elasticsearch to store and retrieve library catalogue data. One thing I've been asked for is a browse interface.
Here's a definition of what this is:
The user does a search, for example "Author starts with" and they
supply "Smith"
The system puts them into the middle of a list of authors, at or near
the position of the first one that starts with "Smith", so they might
see:
Smart, Murray
Smart, Murray J.
Smeaton, Duncan
Smieliauskas, Wally
Smillie, John
Smith Milway, Katie <-- this being the first actual search result
Smith, A. M. C.
Smith, Andrew
Smith, Andrew M. C.
etc.
The one with the marker is the one actually searched for, but you can see the ones around it according to the sort order, including ones that don't actually match the query.
These will be paged, so having ~20 or so results per page. If the user pages back, they head towards the start of the alphabet, if they page forwards they will go onward.
Each result shown will have a count beside it showing how many results (i.e. catalogue items) are associated with that author.
Clicking on a result takes you to everything by that author (this and everything beyond it is fairly easy and mostly implemented already.)
I'm wondering if anyone has any good ideas on how to approach this. At this stage, I don't care too much about handling searches that aren't "field starts with" searches, as exactly how that will be done is currently up in the air and I'll deal with it when the time comes.
Here's what I'm thinking, but there are serious issues with it:
All the fields that are going to be browsed are faceted
I get a list of all the facets for that field, search through it to find the starting point, and handle the paging manually in code.
This has the big problem that I might be fetching hundreds of thousands of terms and processing them, which won't be quick.
In retrospect, it's no different to loading all the values into its own index and fetching all them in sorted order.
I'm open to any options here, whether I can somehow jump into the middle of a large set of facets like the query "from" field, or if I should instead put everything into another index specifically for this purpose (though I don't know how I'd structure and query it), or something else.
From what I can see, my ideal solution would be that I can specify the facet field, tell ES that I want to start at the one that starts with "Smith", and it displays from around there, then I have the ability to say "go 20 back", but I'm not sure that this is possible.
You can see an example of the sort of thing I'm talking about in action here: http://hollisclassic.harvard.edu/ - put in Smith as "Author (last name first)", and it gives you a (terribly ugly looking) browse list.
Any thoughts?
On:
The one with the marker is the one actually searched for, but you can
see the ones around it according to the sort order, including ones
that don't actually match the query.
I had a similar requirement: "Show the user how many records we would have found if the search-conditions were more relaxed".
I solved this by doing two searches (one exact, one more relaxed), as the performance of ES is so good that doing one or two searches does not matter. The time gets eaten up in the displaying (in my case) and not in the search.
Still you would need to merge these two results in you application to generate one list to display.
I need to find which link among turtle links is the oldest or newest , now I am using a property called , link-order which stores this value for each link and I find it using min-of my-out-links [link-order]
Is there any better way to do this? Without the need to have link-order attribute for all the links?
The only alternative I can think of would be to have a global list of all links, and whenever a link is created, stick it on the end (and remove any nobody entries that have accumulated because of links dying). Then the oldest link is always the first item in the list.
Your original idea seems fine to me too though — neither approach seems obviously superior to the other. I'd probably pick your idea just because it seems a little simpler and less error-prone to code.
Are there guidelines or best practice for formatting first and last names displayed in gridviews? Is it better to display the first name first or the last name first?
There is no universally accepted convention; the ordering of parts of personal names depends on the culture.
You can read more about this here: http://www.w3.org/International/questions/qa-personal-names
Then again, from a user-interface perspective, if the user is more likely to sort by the last name it should come before the first name.
In general, I've always found it better to show the surname first, followed by given name. Perhaps it's possible for you to have two separate columns if sorting on either one could be useful.
Bear in mind, if this is appropriate to your task, that the first/last names are not always the given name/surname in certain cultures so it's better to refer to them as given/surnames.
First of all, I finally made this a wiki, but I believe a "simple," straightforward answer is highly desirable, especially since the result would define a unified IDE behavior for everyone. More on the simple later.
In the past, I've blogged about what it means to have a well-behaved member selection drop down. If you haven't read it, do so now. :)
Visual Studio 2010 adds new features to the IntelliSense selection process that makes things ... not so easy. I believe there's great power we can harness from these features, but without a clean set of governing rules it's going to be very difficult.
Before you answer, remember this: The rules should allow someone "in tune" with the system to take advantage of the IntelliSense power with fewer keystrokes and less time than other solutions provide. This is not just about what you're used to - If you use a system as long and frequently as I do, relearning the patterns is trivial next to the time it saves to have a great algorithm behind it.
Here are the controllable axes:
Filtering: A "full" list contains every identifier or keyword allowed at the current location, without regard for the partially typed text the cursor is within.
Sorting: We (at least Visual Studio users) are used to the member selection drop down being sorted in alphabetical order. Other possibilities are partial sorting by some notion "relevance," etc.
Selection: Based on the currently typed text, we have the ability to select one item as the "best match." Selection states are:
No item selected
Passive selection: one item outlined, but pressing ., <space> or similar won't fill it in without using an arrow key to make it:
Active selection: one item selected, and unless Esc or an arrow key is pressed, a . or <space>, etc will auto-complete the item.
My previous set of rules restricted the manipulation to the selection axis. They took into account:
Characters typed as matched against list items with a StartsWith operation (prefix matching), with variants for whether the match was case-sensitive.
Previous completions that started with the same set of characters.
The following are additionally available and potentially useful, but not all have to be used:
CamelCase matches or underscore_separation ("us"): Long, expressive identifiers? Not a problem.
Substring matches: long prefixes hindering your selection speed? Not a problem.
Information available in the summary text, where available: I lean against this but I must admit it's come in handy in the Firefox address bar, so you never know.
The rules you write should address the axes (in bold above) in order. In my previous posts on the subject, the rules were very simple, but the additional considerations will likely make this a bit more complicated.
Filtering
Sorting
Selection
Just one addition or remark ...
IntelliSense should adapt to the context. In the case of Visual Studio, places where only subtypes of a specific type or interface may be used, the dropdown list should filter by these.
IList list = new (Drop down all the types implementing IList) - not all possible types!