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.
Related
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.)
I added a linked fact using:
context.InsertLinked(longOrderKey, longOrder);
At some point later, I want to remove this fact. It's easy for me to construct the key without having the record:
var longOrderKey = (managedAccount.AccountId, PositionType.Long, fungible.FungibleId);
So why do I need the record when removing a linked fact using the method:
context.RetractLinked(longOrderKey, longOrder);
Why can't this method just use the longOrderKey? What if I don't have the 'longOrder' record. Do I really need to look it up before I can remove it?
Linked facts are tied to an activation that created them. The purpose of the key is to be able to identify the specific fact if the activation produced more than one linked fact. If you are inserting just one linked fact in the RHS of a rule, you can really set the key to anything, e.g. "1"; if you were to insert two facts, you could set keys to "1" and "2", and so on. In essence, the key is to identify the linked fact within the activation. The fact itself is needed, so that the engine can find the corresponding entries in the working memory. Much like ISession.Retract requires the fact object, so that it can find it in the working memory.
Another point is that in most scenarios you should not need to retract the linked facts as they would get retracted automatically, once the activation gets deleted (i.e. the conditions that created the activation become false).
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.
I'm trying to make an algorithm that easily simplifies and groups synonyms (with mismatches, capitals, acronims, etc) into only one. I supose there should exist a standard way to build such a structure that, looking for a string with possible mismatches, if the string exists in the structure, it returns a normalized string key. In short, sometimes the same concept could be written in several ways, but I only want to keep the concept.
For instance: Supose I want to normalize or simplify the appearances of
"General Director", "General Manager", "G, Dtor", "Gen Dir", ...
into
"GEN_DIR"
and keep only this result for further reference.
By the way, I suppose that building a Hash with key/value pairs like
hash["General Director"]="GEN_DIR"
hash["General Manager"]="GEN_DIR"
hash["G, Dtor"]="GEN_DIR"
hash["G, Dir"]="GEN_DIR"
could be a solution, but I suspect that there are more elegant or adequate solutions to that.
I would also need the way to persist this associative structure easily without any database because it should grow as I find more mismatches of the same word or sentence. A possible approach I think is to define this structure by means of a DSL, but I'm open to suggestions.
Well, there is no rule, at least a clear one.
My aim is to scrap from web some "structured" data that sometimes is incorrectly or incompletely typed. Some fields are descriptions and can be left as is. But some fields are suposedly to be "sets" but aren's correctly typed (as in my example). As a human can read that, he immediatelly knows what it means and can associate that with its meaning.
But I would like to automate as much as possible the process of reducing those possible mismatches to only one "string" (or symbol) before, for instance, saving it into a database. So, what I would need is a kindof hash or dictionary, as sawa correctly stated, that I can use to lookup any of such dirty strings to get the normalized string or symbol.
Also, of course, it would be desirable a way to make this hash (or whatelse it could be) to learn from new mismatches in some way and add a new association automatically (possibly it could be based on a distance measure between mismatched string and normalized string that, if lower than X, a new association is built). The whole association (i.e, hash) should grow as new mismatches and concepts arise and, though, it should be kept anywhere (possibly in an xml file, or something like what Mori answered below) for future uses.
Any new Idea?