In A-Star algorithm did we replace the node in frontier if a better path is found to a node currently on the frontier (open list)?
For Example: frontier has node B having evaluation function value f(x)= 25 and while exploring the children of node C we have a path from C to B having f(x)= 15 do we replace this value in frontier?
A-Star data structures:
Open list: Contains nodes that have not been expanded. Sorted by evaluation function f(n) = g(n) + h(n). Initially contains the root. To expand a node you get the first one from the list. Besides you add the successors to the list.
Closed list: Contains nodes that have been expanded. When you are going to expand a node you check that it is not in the closed list. If it is you discard it.
Note that open list is sorted by evaluation function so that the node with the best evaluation function is placed in the front of the list.
Hope this helps.
Related
i am currently learning about IC physical design. I came across this set of TCL command which I understand only partially. I the second and third 'set' command, what does the '-only_leaf' and '-flat' refer to?
Please help me by giving some explanation.
Thank you guys.
Those are flags accepted by the all_fanout and all_fanin commands; the set is just storing the results in variables. (Tcl uses set to do basic assignment; it doesn't have top level operators.)
At a guess, -flat means "give me the results as a flat list" (instead of something more complicated such as a list of lists?) and -only_cells (or -only_leaf) acts as a filter to say which information is to be returned. I'd need to read the documentation for those commands to say for sure; it is definitely application-specific and I don't use the Synopsis tools at all.
Flat vs leaf is related to cells and pins in a hierarchical design. You might have a timing path that starts at registerA and ends at registerB. If your cell hierarchy is this:
top_cell
--child_A
--registerA
--child_B
--registerB
then registerA and registerB are leaf cells. The driver and receiver pins are the leaf pins. The net connection from registerA to registerB must also exit child_A and enter child_B through hierarchical pins. A flat collection will include both the leaf pins and the hierarchical pins.
In Synopsys tools, you can quickly get command descriptions with man.
For example, man all_fanin
all_fanin
Creates a collection of pins, ports, or cells in the fanin of
the specified sinks.
. . .
-flat Includes objects throughout the design hierarchy in the result.
This means that the only non-leaf objects in the result are
hierarchical sink pins.
If you do not specify this option, the result includes only
objects within the same hierarchical level as the current sink.
. . .
-only_cells
Includes only cells in the timing fanin of the specified sinks
in the result and not pins or ports.
. . .
There is no -only_leaf option to all_fanin or all_fanout. Returning only leaf objects is the default condition.
I've found many places that shows expression-trees that involve operators (+,-,*, &&, ||, etc). Here is a simple example:
But I can not find an example when functions (with zero or more arguments) are involved.
How would following expression be represented using an Expression-Tree?
mid( "This is a string", 1*2, ceil( 4.2 ) ) == "is i"
Thanks a million in advance.
After weeks of researching, I was not able to find the "official" (academic) answer to this question. So I took my own path and I can tell it works smoothly.
I'm offering it here because so far no one gave an answer: just in the case this could help someone.
By asking this question, I wanted to know if I should place the arguments passed to a function as child nodes of the 'function node' or as a property (data) of the 'function node'.
After evaluating pros and cons of both options, and as nodes in an AST tree can store as many information as you need/want/please (the 2 siblings 'left' and 'right' are just the minimum), I thought this was going to be the easiest approach; it is easy to be implemented and it works perfectly.
This was my choice: place the arguments of the function as data into the 'function node'.
But if any one has a better answer, I beg you to share it here.
It might help to think of an expression tree as already being a way of representing functions applied to a set of arguments. For example, a - node has two children, which you can think of as representing the two ordered inputs to the “minus” function.
With that in mind, you can generalize your expression tree by allowing each node to contain an arbitrary function with one child per argument to the function. For example, if you have a function max that returns the maximum of two values, the max node would have two children. If you have a function median that takes three arguments and returns the median, it would have three children.
I have been working through the Advent of Code problems in Perl6 this year and was attempting to use a grammar to parse the Day 3's input.
Given input in this form: #1 # 1,3: 4x4 and this grammar that I created:
grammar Claim {
token TOP {
'#' <id> \s* '#' \s* <coordinates> ':' \s* <dimensions>
}
token digits {
<digit>+
}
token id {
<digits>
}
token coordinates {
<digits> ',' <digits>
}
token dimensions {
<digits> 'x' <digits>
}
}
say Claim.parse('#1 # 1,3: 4x4');
I am interested in extracting the actual tokens that were matched i.e. id, x + y from coordinates, and height + width from the dimensions from the resulting parse. I understand that I can pull them from the resulting Match object of Claim.parse(<input>), but I have to dig down through each grammar production to get the value I need e.g.
say $match<id>.hash<digits>.<digit>;
this seems a little messy, is there a better way?
For the particular challenge you're solving, using a grammar is like using a sledgehammer to crack a nut.
Like #Scimon says, a single regex would be fine. You can keep it nicely readable by laying it out appropriately. You can name the captures and keep them all at the top level:
/ ^
'#' $<id>=(\d+) ' '
'# ' $<x>=(\d+) ',' $<y>=(\d+)
': ' $<w>=(\d+) x $<d>=(\d+)
$
/;
say ~$<id x y w d>; # 1 1 3 4 4
(The prefix ~ calls .Str on the value on its right hand side. Called on a Match object it stringifies to the matched strings.)
With that out the way, your question remains perfectly cromulent as it is because it's important to know how P6 scales in this regard from simple regexes like the one above to the largest and most complex parsing tasks. So that's what the rest of this answer covers, using your example as the starting point.
Digging less messily
say $match<id>.hash<digits>.<digit>; # [｢1｣]
this seems a little messy, is there a better way?
Your say includes unnecessary code and output nesting. You could just simplify to something like:
say ~$match<id> # 1
Digging a little deeper less messily
I am interested in extracting the actual tokens that were matched i.e. id, x + y from coordinates, and height + width from the dimensions from the resulting parse.
For matches of multiple tokens you no longer have the luxury of relying on Perl 6 guessing which one you mean. (When there's only one, guess which one it guesses you mean. :))
One way to write your say to get the y coordinate:
say ~$match<coordinates><digits>[1] # 3
If you want to drop the <digits> you can mark which parts of a pattern should be stored in a list of numbered captures. One way to do so is to put parentheses around those parts:
token coordinates { (<digits>) ',' (<digits>) }
Now you've eliminated the need to mention <digits>:
say ~$match<coordinates>[1] # 3
You could also name the new parenthesized captures:
token coordinates { $<x>=(<digits>) ',' $<y>=(<digits>) }
say ~$match<coordinates><y> # 3
Pre-digging
I have to dig down through each grammar production to get the value I need
The above techniques still all dig down into the automatically generated parse tree which by default precisely corresponds to the tree implicit in the grammar's hierarchy of rule calls. The above techniques just make the way you dig into it seem a little shallower.
Another step is to do the digging work as part of the parsing process so that the say is simple.
You could inline some code right into the TOP token to store just the interesting data you've made. Just insert a {...} block in the appropriate spot (for this sort of thing that means the end of the token given that you need the token pattern to have already done its matching work):
my $made;
grammar Claim {
token TOP {
'#' <id> \s* '#' \s* <coordinates> ':' \s* <dimensions>
{ $made = ~($<id>, $<coordinatess><x y>, $<dimensions><digits>[0,1]) }
}
...
Now you can write just:
say $made # 1 1 3 4 4
This illustrates that you can just write arbitrary code at any point in any rule -- something that's not possible with most parsing formalisms and their related tools -- and the code can access the parse state as it is at that point.
Pre-digging less messily
Inlining code is quick and dirty. So is using a variable.
The normal thing to do for storing data is to instead use the make function. This hangs data off the match object that's being constructed corresponding to a given rule. This can then be retrieved using the .made method. So instead of $make = you'd have:
{ make ~($<id>, $<coordinatess><x y>, $<dimensions><digits>[0,1]) }
And now you can write:
say $match.made # 1 1 3 4 4
That's much tidier. But there's more.
A sparse subtree of a parse tree
.oO ( 🎶 On the first day of an imagined 2019 Perl 6 Christmas Advent calendar 🎶 a StackOverflow title said to me ... )
In the above example I constructed a .made payload for just the TOP node. For larger grammars it's common to form a sparse subtree (a term I coined for this because I couldn't find a standard existing term).
This sparse subtree consists of the .made payload for the TOP that's a data structure referring to .made payloads of lower level rules which in turn refer to lower level rules and so on, skipping uninteresting intermediate rules.
The canonical use case for this is to form an Abstract Syntax Tree after parsing some programming code.
In fact there's an alias for .made, namely .ast:
say $match.ast # 1 1 3 4 4
While this is trivial to use, it's also fully general. P6 uses a P6 grammar to parse P6 code -- and then builds an AST using this mechanism.
Making it all elegant
For maintainability and reusability you can and typically should not insert code inline at the end of rules but should instead use Action objects.
In summary
There are a range of general mechanisms that scale from simple to complex scenarios and can be combined as best fits any given use case.
Add parentheses as I explained above, naming the capture that those parentheses zero in on, if that is a nice simplification for digging into the parse tree.
Inline any action you wish to take during parsing of a rule. You get full access to the parse state at that point. This is great for making it easy to extract just the data you want from a parse because you can use the make convenience function. And you can abstract all actions that are to be taken at the end of successfully matching rules out of a grammar, ensuring this is a clean solution code-wise and that a single grammar remains reusable for multiple actions.
One final thing. You may wish to prune the parse tree to omit unnecessary leaf detail (to reduce memory consumption and/or simplify parse tree displays). To do so, write <.foo>, with a dot preceding the rule name, to switch the default automatic capturing off for that rule.
You can refer to each of you named portions directly. So to get the cordinates you can access :
say $match.<coordinates>.<digits>
this will return you the Array of digits matches. Ig you just want the values the easiest way is probably :
say $match.<coordinates>.<digits>.map( *.Int) or say $match.<coordinates>.<digits>>>.Int or even say $match.<coordinates>.<digits>».Int
to cast them to Ints
For the id field it's even easier you can just cast the <id> match to an Int :
say $match.<id>.Int
Could anyone explain what node means in MySQL?
This one is talking about nested set.
I am reading a document from Codeigniter's wiki and I am not sure what I am supposed to add for $node.
getSubTreeAsHTML (line 704)
Renders the fields for each node starting at the given node
* return: Sample HTML render of tree
string getSubTreeAsHTML (array $node, [array $fields = array()])
* array $node: The node to start with
* array $fields: The fields to display for each node
The code you are looking at is part of BackendPro. The full code of the function can be viewed here.
"Node" in this case refers to a data node of a nested set. Nested sets are nice because they allow you to quickly select a whole branch of a hierarchy with only the starting node.
It looks like the function specified renders part of a tree in HTML starting at the node you specify. The BackendPro interface must render hierarchical data somewhere.
EDIT: Nested sets are not a MySQL-only concept, but there is a good article about nested sets and MySQL here:
http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/
What is a way to uniquely identify all DOM nodes in an HTML document. To illustrate what I mean, here is a (fictional) example:
Script X randomly selects a DOM node from document.html.
Script X needs to tell script Y which DOM node it has chosen.
How does script X uniquely identify the DOM node it has chosen so that script Y knows exactly which node it is in document.html?
I'm really interested in how to uniquely identify the DOM node so that the script Y can identify it and manipulate it. Preferably, it should work with text nodes as well. I was thinking of XPath maybe, but I'm not sure how to generate a unique XPath to any given node.
You should be able to determine a unique XPath by working backwards from the node to the root node, and tracking the node you're on, and which sibling it is, such that you get something like:
/a[1]/b[2]/c[101]/text()
so that's the 101st C node under the second B node, etc. As such, that's a unique path and can be copied around with reference to the original document
You might want to take a look at XPathGen https://github.com/amouat/XPathGen
It will create a unique XPath of the form /node()[1]/node()[1] for a given DOM node. However, there are some issues with XPath, namely non-coalesced text nodes and "prolog" nodes, which cannot be uniquely identified purely with XPath. For example if you have the following document in DOM:
<a>b</a>
And add a text node to become:
<a>bc</a>
The XPath to nodes b and c will be the same, but you will still have separate DOM nodes (unless you call normalize on the document). If you need to handle this situation you will need to store offsets and lengths for text nodes.
Well, an XPath expression that results in a single node should be unique. What do you mean by "how to generate a unique XPath to any given node"?
Ordinal child positions along XPath axes. Nodes are strongly ordered, and so saying:
child 1 of child 3 of child 4 of child 5.
should do it.