Show that the following grammar is ambiguous. (To show that a grammar is ambiguous, you must demonstrate that it can generate two parse trees for the same string.) `
`person::= woman|man
woman::= willma|betty|empty
man::=fred|barney|empty
below is what I did.
person
|
woman
|
willma
|
woman
|
betty
|
woman
|
empty
----------
person
|
man
|
fred
|
man
|
barney
|
man
|
empty
empty could be a leaf under both man and woman and is thus ambiguous. It should be a direct child of person.
person::= woman|man|empty
woman::= willma|betty
man::=fred|barney
Related
I have two excel files; the original file contains 10K+ patient names and medical condition, the goal is to identify patients (about 400+) with special conditions so that the mail that gets sent to them is different than the rest of the list.
Original File Template:
Last Name
First Name
Diagnosis
Doe
John
Cancer
Smith
John
HIV
Smith
Jayne
Broken Arm
Rock
Dwayne
Common Cold
Foster
Jane
Common Cold
Mailing Template:
Last Name
First Name
Type of Mail
Doe
John
Smith
John
Smith
Jayne
Rock
Dwayne
Foster
Jane
In the Mailing Template, I want to classify the Type of Mail based on the diagnosis. Common diagnosis would be "LV1" and anything that I would identify as a special diagnosis, like cancer or HIV, would be "LV2"
My initial approach would be to filter the Original File by the special diagnosis and then use a True/False condition of that filtered list against the Mailing template and manually flag LV1 or LV2. But is there a method or formula that could scan the Original File to look for the keywords (eg cancer and HIV) and automatically assign the corresponding names in the Mailing List with "LV1" or "LV2"?
I believe if you can cover all the cases you're interested in, it's possible with a IF(OR) statement, for example:
Let's say B5 is the cell with the diagnosis, in your target cell (where you want "LV1" or "LV2" to appear) you will write the next formula:
=IF(OR(B5="Common*", B5="Broken*"), "LV1", "LV2")
Note the "*" in the diagnosis condition text, it will allow any cell that begins with such text to be considered true. For example, "Common*" will consider both "Common Cold" and "Common Fever" as "LV1" cases.
This solution may be problematic if you have a lot of different diagnoses to cover.
Exact Matches
If you expect to add additional condition/mailing types down the road, =XLOOKUP() would be a good option.
In column D this would match the diagnosis to a set of values in column F, and return the value in column G.
You can add as many diagnosis/mailing type values as you need without changing formulas.
In cell D2: =XLOOKUP(C2,F:F,G:G):
| | A | B | C | D | E | F | G |
|---+-----------+------------+-------------+----------------------+---+-------------+-------|
| 1 | Last Name | First Name | Diagnosis | Type of Mail | | Match | Index |
| 2 | Doe | John | Cancer | =XLOOKUP(C2,F:F,G:G) | | Cancer | LV2 |
| 3 | Smith | John | HIV | LV2 | | HIV | LV2 |
| 4 | Smith | Jayne | Broken Arm | LV1 | | Broken Arm | LV1 |
| 5 | Rock | Dwayne | Common Cold | LV1 | | Common Cold | LV1 |
| 6 | Foster | Jane | Common Cold | LV1 | | | |
Note =XLOOKUP() uses the same concept as using =INDEX(G:G, MATCH(C2, F:F, 0)) in previous versions of excel (and produces identical results).
Wildcard Matching
To support using keywords, you would then need to set the [match_mode] argument in =XLOOKUP() equal to 2, which adds the ability to use wildcards (eg * and ?).
The following would match any diagnosis where the first word matches any first wordcommon using common*.
In cell D2: =XLOOKUP(LEFT(C2, IFERROR(SEARCH(" ", C2)-1, LEN(C2)))&"*",F:F,G:G,0,2)
| | A | B | C | D | E | F | G |
|---+-----------+------------+-----------------+-------------------------------------------------------------------------+---+------------+----------------|
| 1 | Last Name | First Name | Diagnosis | Type of Mail | | Match | Index |
| 2 | Doe | John | Cancer | =XLOOKUP(LEFT(C2, IFERROR(SEARCH(" ", C2)-1, LEN(C2)))&"*",F:F,G:G,0,2) | | Cancer | LV2 |
| 3 | Smith | John | HIV | LV2 | | HIV | LV2 |
| 4 | Smith | Jayne | Broken Arm | LV1 | | Broken Arm | LV1 |
| 5 | Rock | Dwayne | Common Cold | Matches Common | | Common | Matches Common |
| 6 | Foster | Jane | Common Anything | Matches Common | | | |
You would need to adjust some in the event there is crossover in keywords or to search for multi-word keyword, but this should be a good place to start.
We are creating Gherkin feature files for our application to create executable specifications. Currently we have files that look like this:
Given product <type> is found
When the product is clicked
Then detailed information on the product appears
And the field text has a value
And the field price has a value
And the field buy is available
We are wondering if this whole list of and keywords that validate if fields are visible on the screen is the way to go, or if we should shorten that to something like 'validate input'.
We have a similar case in that our service can return a lot of 10's of elements for each case that we could validate. We do not validate every element for each interaction, we only test the elements that are relevant to the test case.
To make it easier to maintain and switch which elements we are using, we use scenario outlines and tables of examples.
Scenario Outline: PO Boxes correctly located
When we search in the USA for "<Input>"
Then the address contains
| Label | Text |
| PO Box | <PoBox> |
| City name | <CityName> |
| State code | <StateCode> |
| ZIP Code | <ZipCode> |
| +4 code | <ZipPlus4> |
Examples:
| ID | Input | PoBox | CityName | StateCode | ZipCode |
| 01 | PO Box 123, 12345 | PO Box 123 | Boston | MA | 12345 |
| 02 | PO Box 321, Whitefish | PO Box 123 | Whitefish | MN | 54321 |
By doing it this way, we have a generic step "the address contains" that uses the 'Label' and 'Text' to test the individual elements. It is a neat and tidy way to test a lot of potential combinations - but it probably depends on your individual use case - how important all of the fields are.
You only need to validate the ones that provide business value, which is probably all of them. I would avoid using tech terms like "field" because it isn't related to a behavior. Al Mills is right on for using the tables.
I'd word it like this:
Scenario Outline: Review product details
Given I find the product <Type>
When I select the product
Then detailed information on the product appears including
| Description | <Description> |
| Price | <Price> |
And I can buy the product
Examples:
| Type | Description | Price |
| Hose | Rubber Hose | 31.99 |
| Sprinkler | Rotating Sprinker | 12.99 |
The words I chose are behaviors or whats, not technical implementations or hows.
Consider you want to insert Errors and Warnings into the same database entity. How would you call the table?
Example:
+----+-------+---------+
| ID | TYPE | MESSAGE |
+----+-------+---------+
| 1 | ERROR | FOO |
| 2 | WARNG | BAR |
| 3 | ERROR | TXT |
+----+-------+---------+
Message would be my best personal guess, but English is not my mother tounge.
I would use Anomaly. It is also a nice Matrix reference, so some users may chuckle. :)
A collegue thinks Signal would be the generic term from a process point of view.
I've got a handful of specflow tests that look something like this:
Scenario: Person is new and needs an email
Given a person
And the person does not exist in the repository
When I run the new user batch job
Then the person should be sent an email
Scenario: Person is not new and needs an email
Given a person
And the person does exist in the repository
When I run the new user batch job
Then the person should not be sent an email
Except instead of just 2 scenarios, I've got 10 very similar scenarios, all with the type of steps so I want to use a "Scenario Outline". Unfortunately, I'm having a really hard time coming up with a readable way to re-write my steps.
Currently, I've come up with this but looks clunky:
Scenario: Email batch job is run
Given a person
And the person '<personDoes/NotExist>' exist in the repository
When I run the new user batch job
Then the person '<personShould/NotGetEmail>' be sent an email
Examples:
| !notes | personDoes/NotExist | personShould/NotGetEmail |
| Exists | does not | should |
| No Exist | does | should not |
I also considered this, and while it is cleaner it doesn't convey meaning nearly as well
Scenario: Email batch job is run
Given a person
And the person does exist in the repository (is '<personExist>')
When I run the new user batch job
Then the person should be sent an email (is '<sendEmail>')
Examples:
| !notes | personExist | sendEmail |
| Exists | false | true |
| No Exist | does | false |
Does anybody have a better way of parameterizing concepts like "does", "does not", "should", "should not", "has", "has not"? At this point, I'm thinking about leaving the everything as a different scenario because it is more readable.
Here is what I've done in the past:
Given these people exist in the external system
| Id | First Name | Last Name | Email |
| 1 | John | Galt | x |
| 2 | Howard | Roark | y |
And the following people exist in the account repository
| Id | External Id | First Name | Last Name |
| 45 | 1 | John | Galt |
When I run the new user batch job
Then the following people should exist in the account repository
| External Id | First Name | Last Name | Email |
| 1 | John | Galt | x |
| 2 | Howard | Roark | y |
And the following accounts should have been sent an email
| External Id | Email |
| 2 | y |
You can use the table.CreateSet() and table.CreateSet() helper methods in SpecFlow to quickly turn the tables into data for your fake external system repository and your account table in the database.
Then you can use table.CompareToSet(accountRepository.GetAccounts() to compare the table in your "Then" clause to the records in your database.
The neat thing is, all of the steps you wrote are reusable for multiple situations. All you do is change the data in the tables, and SpecFlow writes the tests for you.
Hope that helps!
Maybe you should split them into two scenarios
Scenario Outline: User exists in the repository
Given a person
| Field | Value |
| First | <first> |
| Last | <last> |
And the person exists in the repository
When the user attempts to register
Then the person should be sent an email
Examples:
| first | last |
| Bob | Smith |
| Sarah | Jane |
And then another scenario for the opposite. This keeps the scenario meaning very clear. If your common steps are worded genericly you can reuse them. I also try to come from the approach of the user
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking for an diagram tool for producing diagrams from text. I only really need sequence and state type diagrams for now, but I'm curious as to what people would recommend? I need something which is standalone, not a web based tool that works on Linux, OSX and Windows.
I'm not positive what you mean by "producing diagrams from text", but if you mean a tool where diagrams are specified by a text file, Graphviz is good. If you mean something that literally converts ascii art like
+--------+ +-------+ +-------+
| | --+ ditaa +--> | |
| Text | +-------+ |diagram|
|Document| |!magic!| | |
| {d}| | | | |
+---+----+ +-------+ +-------+
: ^
| Lots of work |
+-------------------------+
to a graphic:
You can try ditaa (that ascii art is from their website, so it's a good example of the input format it expects)
Look at PlantUML, LaTeX+MetaUML, sdedit, TextUML, yUML, ...
There is a plenty of quite good tools.
I recommend TextDiagram http://weidagang.github.com/text-diagram/. It creates UML sequence diagram from pure text.
Example input
object April Todd Monad
note left of April: Lunch is ready
April->Todd: Todd, what are you doing?
note right of Todd: Programming #_#
Todd->April: Well, I'm programming.
April->Monad: And you?
Monad->April: I'm reading book.
April->Monad: Good boy!
note right of Monad: Smile ^_^
produces:
+-------+ +-------+ +-------+
| April | | Todd | | Monad |
+-------+ +-------+ +-------+
-----------------\ | | |
| Lunch is ready |-| | |
------------------ | | |
| | |
| Todd, what are you doing? | |
|------------------------------>| |
| | ------------------\ |
| |-| Programming #_# | |
| | ------------------- |
| | |
| Well, I'm programming. | |
|<------------------------------| |
| | |
| And you? | |
|------------------------------------------------------>|
| | |
| | I'm reading book. |
|<------------------------------------------------------|
| | |
| Good boy! | |
|------------------------------------------------------>|
| | | ------------\
| | |-| Smile ^_^ |
| | | -------------
| | |
I'd recomment PlantUML. It is an excellent tools that lets you draw all kinds of UML diagrams from simple textual specification.
EventStudio supports generation of sequence diagrams and collaboration diagrams from text input.