I'm running a glmer model with a three-way interaction, which causes me to receive the following warning:
Warning:
In optwrap(optimizer, devfun, start, rho$lower, control = control, :
convergence code 1 from nlminbwrap
The warning is not there when the 3-way interaction is omitted, so I suspect it has to do with model complexity.
Unfortunately, there is no further information about the nature of the convergence issue in the warning (and also not in the model summary), which makes it hard to resolve. [I've tried different optimizers and increasing the nr of function evaluations already].
Is there any way of finding out what precisely convergence code 1 means? Also, I'm wondering whether it is as serious as when it says Model failed to converge? I've been looking for an answer in the R help pages and in the GLMM FAQs, but can't seem to find any. Any help is much appreciated!
Okay, so I've done some reading here with the hope of being able to help out a fellow linguist. Let's start with the model you specified in the comments:
model=glmer(Correct_or_incorrect~ (condition|CASE) + condition + sound + syll + condition:sound + condition:syll + syll:sound + condition:sound:syll, dataMelt, control=glmerControl(optimizer="nlminbwrap"), family = binomial)
The warning message code didn't say anything useful, but convergence code 1 from bobyqa at the very least used to be about exceeding the maximum number of function evaluations. How high did you try and go with the iterations? All you're going to lose is a few hours, so I would try and set it really high and see if the warning message goes away. All you'd be losing is computer time, and I personally think that's a small price to pay for a model that doesn't throw warnings.
You also mentioned that the warning was not there when the 3-way interaction is omitted, and I would be inclined to think that you are right concerning model complexity. If you don't have any specific hypotheses about that interaction I would leave it out and be done, but if you do, I think there are a few options that you haven't mentioned that you have tried yet.
There is a function called allFit() that will fit the model with all available optimizers. This would be a quick and easy way to see if your estimates are roughly the same among all the different optimizers. You run it on an already fitted model, like this:
allFit(model)
There is a good walkthough of using allFit() and it's different arguments here:https://joshua-nugent.github.io/allFit/ This page also has a lot of other potential solutions to your problem.
If you can, I would take advantage of a machine with multiple cores and run allFit with as many iterations as you can swing, and see if any of the optimizers don't give this warning, which is presumably about not minimizing the loss function before the iterations run out.
I see such code segment in proposer_task(xcom_base.c)
if(threephase || ep->p->force_delivery){
push_msg_3p(ep->site, ep->p, ep->prepare_msg, ep->msgno, normal);
}else{
push_msg_2p(ep->site, ep->p);
}
the threepahse is int const threephase = 0 and force_delivery == 0 here
push_msg_eq is normal paxos include prepare, accept and learn phase
but push_msg_2p will skip prepare phase and directly send accept request
I want to know why, Thanks a lot.
If you look at the paper Paxos Made Simple page 10 paragraph 3 says:
A newly chosen leader executes phase 1 for infinitely many instances
of the consensus algorithm [...]
Then paragraph 4:
Since failure of the leader and election of a new one should be rare
events, the effective cost of executing a state machine command—that
is, of achieving consensus on the command/value—is the cost of
executing only phase 2 of the consensus algorithm. It can be shown
that phase 2 of the Paxos consensus algorithm has the minimum possible
cost of any algorithm for reaching agreement in the presence of faults.
Hence, the Paxos algorithm is essentially optimal.
This is saying that a leader only issues a prepare during a leader failover. After that it streams accept messages. It then has "optimal messaging" in that the leader only needs one round trip to know a value is chosen (the accept message and its acknowledgment).
In a three node cluster, a leader self-accepts instantaneously, then only needs one accept acknowledgment from a second node to have a majority. It then knows the value is chosen without having to await the response from the 3rd node (which could be down). That is as efficient as you can get. The value is known to be accepted at a second node with strong consistency.
Given that is how paxos works to get maximum efficiency we should expect that mysql xcom has a mode that skips the prepare message phase in steady state.
You can read more about the Paxos Made Simple techniques on my blog here.
You might be interested to know about the latest developments of Paxos where you don't need a majority response for accept messages in the cluster using FPaxos and tricks like the even nodes optimization.
Is there any way to understand if the card(emv or magnetic) is used first time at ATM or POS?
For EMV card ATC is reliable?
The "first time" could be different.
You can ask for ATC after selection ( command 80CA9F5200 ) and if it equals 0000, Get Processing Options wasn't performed, what means there wasn't any transaction.
Bit if if > 0000, it does not mean what "full" transaction was on card. ATC shows number of launch command Get Processing Options.
For Visa card you can find specific bit in CVR ( CVR3, BIT5 ) "New card". He shows if successful online transaction was performed with card.
You can trust ATC for EMV transaction but there is no counter for magnetic transaction.
There is one bit( new card bit) that was set in first EMV transaction. If the Last Online ATC Register is 0 then “New card” bit in the TVR will be set to 1. You could check that bit to see if this transaction is first for this card.
I found ATC is incremented just after GPO is performed. It is possible that transaction falied just after GPO,
Next time when we fire GPO, we get the value > 0 ( ATC already incremented) here we can't say that card is not new because yet to processed first transaction successfully.
so I think ATC value is not a parameter to find out whether card is new or already used. [Sometime as per setting we need to check the card is new or not to perform certain activity]
There are two ATC-related values could be read using GET_DATA: the current ATC and Last Online ATC. For a new card that never went online the Last Online ATC would be zero. This should be true for a 'classical' scheme of the EMV technology employment by a traditional payment system.
Hope this helps
Is there an upper limit to the number of bugs contained in a given program? If the number of instructions are known, could one say the program cannot contain more than 'n' bugs? For example, how many bugs could the following function contain?
double calcInterest(double amount) {
return -O.07 / amount;
}
A parser would count four terms in the function, and I could count these errors:
wrong number syntax
wrong interest rate (business requirements error)
wrong calculation (should be multiply)
Potential divide by zero
Clearly the number of bugs is not infinite given a finite number of instructions. Alternatively, one could say the function accepts 2^64 inputs, and of those, how many produce the correct output. However, is there any way to formally prove an upper limit?
If bug is "a requirement not met by the program", then there is no limit on the number of bugs (per line or otherwise), since there is no limit on the number of requirements.
print "hello world"
Might contain a million bugs. It doesn't create a pink elephant. I leave it to the reader to come up with 999999 other requirements not satisfied by this program.
Number of instructions have nothing to do with whether the program does what the user wants it to do. I mean, look at how poorly GCC does balancing my check book. Buggy as all get out, down right useless!
This would all depend on how you define a 'bug'.
If you define a program as a function from some input to some output, and a specification as a definition of that function, and a bug as any difference in output from the specification on a given input, then yes, you can conceivably have countably infinite bugs - however this is a somewhat useless definition of a bug.
The upper limit is the number of states your program can be in. Since this number is finite on real machines you could number the states from 1 to n. For each state you could label if this state is a bug or not. So yes, but even a small program having 16 bytes of memory has 2^128 states and the problem of analyzing all the different states is intractable.
There is a theoretical upper limit for bugs, but for all but the most trivial programs it is very nearly impossible to calculate, although engines such as Pex do give it the old college try.
Law of programming:
"If You will find all compile-time bugs, then n logical ones are still hidden, waiting to surprise You at run-time."
Depends on how you count bugs, which leads me to say "nope, no limit." I don't know about you, but I can easily write several bugs in the same line of code. For instance, how many bugs are in this Java code? :-P
public int addTwoNumbers(int x, String y)
{{
z == x + y;
return y;
}
As little as one if the bug is significant enough.
I'm quite anal about form validation. So while creating a validator for a "data of birth" (DOB) field in one of my current projects for a job application form (platform/language is neutral in this context), I wanted something to prevent 'punky' inputs.
I used a date picker and restricted the max date to be XX years from the current day. XX make sense for this scenario as anyone younger shouldn't be even applying for the job.
The validation error message is: You seem too young for the job.
Then I began to get adventurous. How about?
If DOB is more than 120 years ago, message: "You cannot be that old!!!"
If DOB is in the future, message: "You must be kidding, you are not born yet!!!"
In the end, I deployed without the last 2, too cheeky for my no-nonsense client.
I would like to know how far/much would you guys go to validate DOB fields for good usability (or humor)?
Similarly for dates like, "Date of marriage", "Year of graduation" etc...
PS: As I was about to submit this post, there's a warning under the title textbox:
"The question you're asking appears subjective and is likely to be closed."
Fingers crossed.
To add:
I'm quite surprised that some/most of the guys are not too concern about the validation. I repeat one of my comments here:
If the user entered the date wrongly (something very obvious) whether by intent or by mistake; that's one of the purposes of the validators to catch it. When data goes into the system, the site owner only know the input is wrong, he/she would not know the actual value without asking the user. If this field is highly important, it will not be a pretty scenario.
Think about the times you've filled out forms. How many times have you been frustrated because some "overly clever" programmer inserted some "validation" that just happened to be incorrect for your circumstance? I say, trust the user. Come to think of it, as time goes on I guess people are living longer and getting on the net at earlier ages, anyway. :P
don't forget you can also warn the user against unlikely values. In most cases, a typo is more likely than deliberately being awkward.
So for your application, maybe something like this:
Age < min. applicant age - error
Age > common retirement age - warning
Age > expected life span - error
Validation vs. Correctness
The point of input validation is to ensure all elements are within the range allowed for and expected by further processing - i.e. if your database guarantees all applicants in the DB are 18 years or older, validate that. If your database also accepts school kids applying for internships, don't.
Everything unusual is just a warning. Yes, a value of 120 years is crazy, you should warn the user and possibly flag this record as suspicous / for review. However, there's no point in rejecting it (unless you have a business rule that e.g. all applicants are younger than 70).
Fake trust
Imagine what happens if you tell one user that "you rule out unlikely DOBs at the input". She might tell her co-worker that DOB is "already validated". He ends up with an unfounded trust that the applicant is 90, and if it were a fake you would have rejected it.
All further processing - by human or by computer - must still assume the DOB may be incorrect - just because of a typo. You are trying to create a guarantee you can't actually make. Many users trust the computer they use every day more than a stranger, you are trying to enforce this trust - which is IMO s fallacy.
Transmutation
Many applications live much longer than the original implementer imagined, and quite some will be used for purposes beyond his wildest dreams. Building in artificial limits that neither simplify the actual processing nor the job of the operator don't actually help.
(That puts me probably into the no-nonsense category of your client - but thst's my way to be "anal about validation": knowing when to stop :))
I think validation is incredibly important, but not necessarily in your situation. Which isn't to say that your situation is trivial, I just have my own date-oriented nits to pick.
Specifically, my concerns are always in keeping things in logical order. If someone says they were born in 1802, that's fine (sorta), I just want their date of graduation to be greater than their date of birth. But you run into itchy little problems when it comes to time (as in hours and minutes), for instance, if a user chooses 8:30 as the start time and then chooses 9:15 as the end time, but then realizes that the end time was 8:45. They decide to change the 9 to an 8 with the intention of changing the minutes to :45. But my validation script is too busy saying "Hey Wait! 8:15 is before 8:30, nice try!" but I can't risk letting them leave it wrong, etc etc.
For your situation specifically, I would lean toward what is ethical right. Because as it's been pointed out, someone could be entering a family history (with DOBs in the 1600's) or future purchases (with dates after today), so there is no realistic limit on dates in general. But there are limits to your scenario, ie:
If Age is less than legal working age (16 in most parts of the US), don't even offer anything higher than that year as an option (if you are using drop down).
If Age is beyond reasonable working age (which can be a sensitive subject) offer the highest value based on retirement age and simply add a ">" in front of that year. If someone is 75 and applying for an admin-level job, they will be more pleased that you made things simple rather than offended that you didn't have their year of birth listed. If anything, they will be impressed (I think) that you went this route instead of nothing at all, implying they shouldn't waste their time.
In the end you have a simple drop down very easy to script (example in PHP):
$currentYear = date('Y');
echo "<select name=\"YearOfBirth\">";
for($i = 16; $i <= 64; $i++) {
$optionYear = $currentYear - $i;
echo "<option value=\"$optionYear\">$optionYear</option>";
}
$greaterYear = $currentYear - 65;
echo "<option value=\">$greaterYear\">>$greaterYear</option>";
echo "</select>";
When asking living people for their birthdate, only reject values that are definitely wrong. Any birthdate in the future is definitely wrong. And I would draw a line and say that any birthdate before (say) 1880 is definitely wrong. Anything else is a valid birthdate.
So any birthdate that fails the above tests is rejected with a message at field level, like "This date is in the future/too far in the past. Please enter your birthdate."
Any other birthdate is valid (maybe the user really is 11 years old, or 108). But the overall form may be rejected by business rules. For example, "You must be at least 18 years old to apply."
The idea is to separate individual field validation from form validation. Conflating them yields complicated rules. Separating means you can re-use the rules for the field (e.g. "DOB of a living person must be between 1/1/1880 and today") in other contexts.
If you're doing this for anything professional - like a job application - I might not use "!" in messages to users. Take a look at any well done website you'd like, you're not going to find it in common use.
Valid date: check
Date not in future: maybe (I deal with medical applications, so I suppose you could be treating unborn babies)
Date not older than 120 years: probably
I'm not a big fan of over-engineering these things, particular if a user mistake is relative harmless and can be spotted and fixed easily. That's how I approach it anyway.
Valid Date:
I'll go to the extend of checking whether this date exists or not. i.e. leap year 29th Feb and so on
Date in the future:
we usually check the age (this year - dob given) and must be at least a certain age to sign up.
Date older than 120 years or not:
I won't check. 200 years would be a safer limit? (in case a 121 year old man wants to use the computer *chuckles*)
I think you should consider your actual requirements when designing validations. Yes if the field is a date field (and perhaps more importantly if it stores a date but some less than stellar dba made it a varchar),make sure only a valid date is submitted. This is critical. Invalid dates cause all sorts of issues with querying the data. If it is a date that must of necessity have occurred in the past, limit the date range to the present date or earlier.
After that go with what your client wants. If they want to pay for you to eliminate people younger than work age, they will tell you. Disallowing a top age limit can get you into legal trouble for age discrimination. The client may not want you to do this either.
Humour is a pretty subjective thing and very project specific so it’s a bit difficult to answer along those lines. Having said that, if the application supports a formal process such as applying for a job I’d probably err on the side of caution and keep it pretty factual.
As for validation, I believe the effort so you go to here should be proportional to the impact of invalid data making its way through from the UI. Going back to the job application form, I imagine there will be a human review process at some time so the risk of invalid data is minimal whether the data was intentionally or inadvertently entered incorrectly.
If you’re worried about “punky” or bot driven inputs then use Captcha. Having said all that, I reckon you’re pretty safe with the validation rules you’ve used.
Well I'm not a programer (More of a BA) though I'm trying to gain some development skills as I think it may help me be a better BA. I've done a bit of VBA (Don't laugh).
Anyway in thinking about this here's my two cents
1) Dropping the humour. Whats funny to you now won't be to someone else. Furthermore, whats funny after two or three goes isn't funny after 25 or 30 - its just tiresome even if you are dealing with a jokey crowd!
2) I am coming round to the idea that unless you can definitively validate something as being plain wrong, E.g. you don't want to let someone enter a value < 0, then you should consider warning rather than prevention via dialogues or whatever the OS standard happens to be.
Hey what do I know, In a week I'll have changed my mind (I'm a Business Analyst) and will be demanding instant repsonses from developers ;->
Let's just use two digit years everywhere. No one's going to be using our software after 1999!
Below are the checks that you can do while validating the DOB:
calculate the age from the DOB and do the following checks
AGE > XX [XX is the min age required to apply]
AGE < XX {SHould throw a message mentioning that you are not old enough}
AGE = XX
If there is no upper limit of age then we can take it as retirement age else verify with the upper limit for the next two checks
AGE < Retirement Age
AGE > Retirement Age {Should throw a message mentiong that you are too old to apply}
AGE = retirement Age
DOB is a valid date (by giving valid date)
DOB is invalid -
Enter 0 in either of day/month/Year
Enter some negative Value
Enter some invalid date e.g. 30th feb or 32 Jan etc
Enter valid date with different separators (although the date is a valid one but due to different separators it will become an invalid one)
Enter date with different formats such as by giving dd/mm/yyyy, dd/mm/yy, dd/MON/yyyy etc.
Enter some future date (Invalid here as your purpose is something different)
being a perfectionist i would go here for 150 :D
as low as the chances are, people have passed the 120, and who know what shall happens in the coming 30 years :D
i don't find it that important however..
It all depends on the application. A line of business (LOB) application for order processing is very different to tracking historical or future data.
One can agree it needs to be a valid date, but consider there are multiple calendars (e.g. month number can be 13, year can be over 5000).
Validate for an integer and to be helpful; I think anything else: an abusive/big brother/over-enginereed system is a bad idea.
People should be allowed to lie on these forms if they wish; it's not a legal thing, it's a website.
Don't take it so seriously.
Just let the user pick a date. The user should be in control..not the system/developer. The only date you should avoid with respect to DOB is the future as that is incorrect (i.e. preventing error by design). The date picker you provide should handle any date format issues.
And definitely do not throw up any cheeky exceptions/messages. Your message should aid the user in recognising & recoverying from an error.
Hope that helps.