I'm wondering how I union two DFA's, when one has an error state. Specifically, the first DFA is this:
The second one doesn't really matter, but it doesn't need an error state in that at every state it takes either an 'a' or a 'b'. So I can use product construction just fine up to when I get to state q3. Let's say the machine is at (q3,z) (where z is a random state from the second DFA) and then reads an a. The second can go on happily, but the first DFA should go to an error state and not accept any more input. Because this is union and not intersection of course, I need to keep simulating the second to see if it reaches an error state.
How can I show this when constructing a union-ed DFA?
An error state is a non-accepting state for which all symbols loop back to the same state. (A "sink"). It's not clear to me whether you meant q3 to be a accepting state with no outgoing transitions, or whether you meant q3 to be an error state with {q0, q1, and q2} all being accepting states. But the solution is not that different; if you don't already have a sink, create one; all illegal transitions from any other state go to the error state.
Now, you can use the product construction without problem; DFA1 reaches the error state and stays there, and DFA2 continues to do transitions. When both DFAs reach a sink, then no more transitions are possible.
Related
In my Anylogic model I have a hub which can store 5 containers. So it has a capacity parameter with value 5. I also have given it a variable with the numberOfContainers stored at the hub at that moment. When I run the model I see that the variable works (it changes over time to the number of containers that is stored at that moment).
Now I want another agent in my model to make a decision based on whether the capacity of the hub is reached at that moment (within its statechart). I tried to create a branche with the following condition:
main.hub.numberOfContainers > main.hub.capacity
but it doesn't work, the statechart acts like the capacity is never reached, even if the number of containers is much higher than the capacity. Does anybody know how to make this work?
Typically, condition branches are tricky because the condition may not be evaluated at the time you want it to be. Here is an example.
At time n there are 3 containers in the hub
At time n+1 there are 10 containers in the hub
At time n+2 there are 2 containers in the hub
The model may have missed evaluating the condition at time (n+1) which is why your transition would not be triggered.
To address this issue, I have 3 possible suggestions:
Do not use a condition transition. Instead, use a message. For example, if you are storing the containers in a queue, then, on the "On Enter" and "On Exit" fields of the queue, add the condition:
if(queue.size >= main.hub.numberOfContainers)
<send msg to the statechart>
Use a cyclic event to check if the condition is met every second or millisecond or whatever time period makes sense to you. When the condition is met, send a message to trigger the transition. But the problem with this method is that it might slow down your model with poor performance.
Use the onChange() function. This function is used to signal to your model that a change happened and the condition trigger needs to be evaluated. So, you need to make sure to place onChange() whenever a change that might cause the condition to become true happens. In the example provided under option 1 above, that would be in the fields of the queue "On Enter" and "On Exit".
In a vrp problem, I want to employ different probability distribitions for all moveSelectors depending on where in the chain the planning is being done. More concretely, I want to employ a block distribution for the first entity in the chain and parabolic for anywhere else in the (same) chain.
Now, I could configure identical moves one with block distribution and one with parabolic, but this is going to get cluttered very quick. So, instead I am wondering what will happen if I state that in the implemented NearbyDistanceMeter the distance is 0 if it is the first entity in the chain and a value > 0 if it is not the first entity. Will this work as intended ?
It will not.
The NearbyDistanceMeter should be idempotent (give the same result when called twice), regardless of the state of the planning variables.
In fact, it's called & cached before solving really starts.
We are trying to use Gemfire in our work. We have a region where we store each request coming in and it goes through its lifecycle (For example, states are A --> B --> C --> D)
But we also have a requirement that we need to update the state to C only if the current state is B (as the state D is getting updated Async by some other process). We used to achieve it in cassandra by using ONLY IF key word. Looking for something similar in Gemfire. Obviously we cannot do Read, Check State and Update because its not atomic.
Other option was to do this by taking a distribted lock and then perform check-update as mentioned above. But this option comes with a performance overhead.
We were also thinking of attaching a CacheWriter and check the state in beforeUpdate(..). But came to know that what we get as parameter to beforeUpdate is a copy of the value and not the real value.
Does anyone have an idea of how to achieve it in a atomic fashion that we can try?
What you are looking for is this, Region.replace(key, oldValue, newValue). This is an atomic operation.
UPDATE: I should also clarify that is not currently possible to inspect certain properties of the mapped object value (e.g. someObject.state = XYZ) to ascertain whether to perform the update/replace. For that you will need a properly implemented Object.equals() method.
So I was doing practice problems in my book and I spotted this question.
Construct an npda accepting the language L on sigma(a,b,c).
L={w: number of a= number of b+1}
so I am interpreting it as it accepts all strings that has one more a then the letter b. I believe that all the states should have a loop that has a transition (c,landa, landa) since we do not really care about the c's. After this I get really confused because there are so many cases to cover since the placement of a's and b's are arbitrary. What is the way to get this problem figured out? Thanks!!
A PDA can use a stack to remember arbitrary amounts of information. This makes PDAs infinitely more capable than finite automata. The key to determining the PDA is figuring out how the stack will be used and then building a PDA around that.
How can we use a stack to ensure the number of as is equal to the number of bs, plus one? Well, the stack can easily keep track of the running balance of symbols that have been seen. For instance, if we have seen four as and two bs, our stack might represent this fact by containing aaZ, where Z is the "bottom of stack" symbol. Of course, there are other methods we might use and other representations, but this is a particularly neat one for this class of problem. To fully explain the representation:
The stack is initially Z, just the bottom of stack symbol.
If we see an a and the top of the stack is a or Z, we add another a.
If we see an a and the top of the stack is b, we remove one b.
If we see a b and the top of the stack is b or Z, we add another b.
If we see a b and the top of the stack is a, we remove one a.
If we see a c, leave the stack alone.
If we do this over and over again for all the input, then the content of the stack will be equal to x^m, where x is whichever of a and b occurs more frequently, and m is the absolute value of the difference of the numbers of each symbol.
To accept your language, you must simply recognize the case where the input is exhausted and the stack consists is equal to aZ. This can be done by adding some state(s) and lambda/epsilon transitions to clear the stack and/or enter an accepting state.
Thanks to Peter Leupold for pointing out that the rest of the original answer got the grammar wrong. I made an attempt to fix it and didn't like how long the answer was getting, so I omitted that. I will simply add that another possibility is to produce a CFG for a language and use an algorithm to derive a PDA for it. In this case, for me, giving the PDA directly was a lot less wordy.
In my organisation, I see a lot of places where code has been put inside monitor blocks (RPG's version of try..except) to prevent raising exceptions on arithmetic errors. For instance:
Monitor;
Pxxhour = Bctime/60;
PxxMin = %Rem(Bctime:60);
On-Error;
Pxxhour = 0;
PxxMin = 0;
Pxxhour and Pxxmin are screen fields that will be displayed to users. So if there is an error in the operations, these get a value of 0. Though this prevents the program from crashing, how does it help? Users keep seeing the wrong values on the screen. Similarly, I see code which assigns the highest possible value for a given variable rather than allowing an overflow exception. Though this will prevent the program from blowing up, how does it help in the long run? Wouldn't calculations have wrong values and result in wrong business data?
The answers given below by #jmarkmurphy and #Charles successfully address the question from an RPG and IBM midrange perspective, which is what I was after.
There's two use cases for a MONITOR block...
Expected errors
Unexpected errors
For expected errors, replacing bad or invalid data with an accepted value is a valid solution in some cases. The trick is knowing which cases. The answer to that is something your business people would need to help decide. Depends of what the program is doing and what data has the problem.
For instance, given some sort of internal sales report, you might have something like so:
dcl-c DIVIDE_BY_ZERO const(00102);
dcl-c RESULT_TO_LARGE const(00103);
monitor;
averageSale = totalSalesAmount / numberSales;
on-error DIVIDE_BY_ZERO;
averageSale = 0;
on-error RESULT_TO_LARGE;
averageSale = *HIVAL;
endmon;
What's important about the above is that I'm expecting one of two possible errors and I've decided to handle them a certain way. The business people don't care that technically averageSale is undefined when numberSales is *ZERO. They'y just want a zero to appear on the report. They also understand that there's only so much room on the page and that if the number is all nines, the actual value might be bigger.
And unexpected error, such as a decimal data error, would not be caught be this MONITOR block.
For an unexpected caught by a monitor block via a ON-ERROR with *ALL or no error code specified, I'd expect to see some sort of logging of the issue followed by either skipping the problem record or cleaning shutting down depending on what the program is doing in the first place.
It appears that your code is expecting certain error(s), but without explicitly defining which error(s) codes it's willing to handle. This is lazy and not a good practice.
As far as your questions about rather or not the handling of those expected errors is valid...only you and your users can decide that
You might want to take a look at Chapter 7 - Exception and error handling of the IBM Redbook Who Knew You Could Do That with RPG IV? Modern RPG for the Modern Programmer
What Should I Do When I Have Errors in my Calculations
Programs that blow up on users are bad, even if it is the user's fault. It makes the user believe that the program is buggy, and then anything unexpected that happens becomes the program's fault; something to be fixed. Things can get really out of hand in this manner causing help desk calls for ordinary occurrences that just appear a little odd, even when the outcome is actually correct.
One option is to validate the user input to prevent calculation errors, but what do you do when you can't really prevent all of them. In our world, one of these situations is in invoicing. 5250 screens have limited real estate and you can't always make the fields big enough to hold all eventualities. So there are tradeoffs. Maybe you need to be able to sell thousands of some small items on a single invoice, but the largest total invoice you have ever had is $100K. So you size your fields like this:
dcl-s quantity Packed(5:0);
dcl-s unitPrice Packed(7:2);
dcl-s ammount Packed(9:2);
All are odd because they take up the same space on disk as the next lower even precision. You don't sell fractional quantities, and the maximum value in each field is:
quantity = 99,999;
unitPrice = $99,999.99;
amount = $9,999,999.99;
Now you can see that these maximums should easily handle all valid invoices, but it also leaves plenty of potential for calculation errors. If the user keys in maximum numbers for quantity and unitPrice, the resulting number would require a Packed(12:2) field. That would cause an overflow. In an invoice when the unit price is stored in the invoice detail, we can add an edit when the quantity and unit price is entered that checks for an extended amount overflow, and send an appropriate error message. But what if unit prices are not stored in the invoice detail, but instead in a pricing table. Now there is not a good way, if a price is changed for example to ensure that none of the existing invoices will be affected adversely.
So what do you do about a decimal overflow, or any other calculation error, be it a data problem, or something else? And what happens if the error occurs Blowing up the program is not a good option. Another option, the one that seems to be taken in the question is to apply some default value that the users will quickly recognize is out of the ordinary. It will appear in reports, and on screens. When the users see those excessively large, or small numbers, then they can know to go back and check the data.