Why can't C++ be parsed with a LR(1) parser?

Question: I was reading about parsers and parser generators and found this statement in wikipedia's LR parsing -page:

Many programming languages can be parsed using some variation of an LR parser. One notable exception is C++.

Why is it so? What particular property of C++ causes it to be impossible to parse with LR parsers?
Using google, I only found that C can be perfectly parsed with LR(1) but C++ requires LR(∞).
Comment: Just like: you need to understand recursion to learn recursion ;-).
Comment: "You'll understand parsers once you'll parse this phrase."
Answer: LR parsers can't handle ambiguous grammar rules, by design. (Made the theory easier back in the 1970s when the ideas were being worked out).
C and C++ both allow the following statement:
x * y ;

It has two different parses:

It can be the declaration of y, as pointer to type x
It can be a multiply of x and y, throwing away the answer.

Now, you might think the latter is stupid and should be ignored.
Most would agree with you; however, there are cases where it might
have a side effect (e.g., if multiply is overloaded). but that isn't the point.
The point is there are two different parses, and therefore a program
can mean different things depending on how this should have been parsed.
The compiler must accept the appropriate one under the appropriate circumstances, and in the absence of any other information (e.g., knowledge of the type of x) must collect both in order to decide later what to do. Thus a grammar must allow this.  And that makes the grammar ambiguous.
Thus pure LR parsing can't handle this.  Nor can many other widely available parser generators, such as Antlr, JavaCC, YACC, or traditional Bison, or even PEG-style parsers, used in a "pure" way.
There are lots of more complicated cases (parsing template syntax requires arbitrary lookahead, whereas LALR(k) can look ahead at most k tokens), but only it only takes one counterexample to shoot down pure LR (or the others) parsing.
Most real C/C++ parsers handle this example by using some
kind of deterministic parser with an extra hack: they intertwine parsing with symbol table
collection... so that by the time "x" is encountered,
the parser knows if x is a type or not, and can thus
choose between the two potential parses.  But a parser
that does this isn't context free, and LR parsers
(the pure ones, etc.) are (at best) context free.
One can cheat, and add per-rule reduction-time semantic checks in the
to LR parsers to do this disambiguation.   (This code often isn't simple).  Most of the other parser types
have some means to add semantic checks at various points
in the parsing, that can be used to do this.
And if you cheat enough, you can make LR parsers work for
C and C++.  The GCC guys did for awhile, but gave it
up for hand-coded parsing, I think because they wanted
better error diagnostics.
There's another approach, though, which is nice and clean
and parses C and C++ just fine without any symbol table
hackery: GLR parsers.
These are full context free parsers (having effectively infinite
lookahead).  GLR parsers simply accept both parses,
producing a "tree" (actually a directed acyclic graph that is mostly tree like)
that represents the ambiguous parse.
A post-parsing pass can resolve the ambiguities.
We use this technique in the C and C++ front ends for our
DMS Software Reengineering Tookit (as of June 2017
these handle full C++17 in MS and GNU dialects).
They have been used to process millions of lines
of large C and C++ systems, with complete, precise parses producing ASTs with complete details of the source code.  (See the AST for C++'s most vexing parse.)
Comment: @altie Surely no one would overload a bit-shift operator to make it write most variable types to a stream, right?
Comment: My answser had already observed that C had the same problem, I think you missed that.  No, it can't be parsed by LR(1), for the same reason.   Er, what do you mean 'y' can be a typedef? Perhaps you meant 'x'?  That doesn't change anything.
Comment: While the 'x * y' example is interesting, the same can happen in C ('y' can be a typedef or a variable).  But C can be parsed by a LR(1) parser, so what's the difference with C++?
Comment: I looked at `x * y` and chuckled - it's amazing how little one thinks of nifty little ambiguities like this.
Comment: Parse 2 is not necessarily stupid in C++, as * could be overridden to have side effects.
Comment: The question is about the difference between C and C++ - C can be parsed by LALR(1) with the lexer hack (which you describe), while it seems (from other answers) that even that is impossible for C++.
Comment: @Blaisorblad: you don't have a lot of choice.  If your parser accepts "too little", you probably reject real programs.  You can't make a parser accept *exactly* a valid string unless your parser is Turing capable.  So, you build a context free parser that accepts too much, and hack away the excess that it accepts.
Comment: @IraBaxter There are similarities, although it seems like concatenation is a logical interpretation of "adding" when applied to strings, much more than bit-shifting an output stream.  If I asked a non-programmer to "add 'abc' to 'def'", I feel I have a decent chance of getting 'defabc' as the answer.  If I ask them to "shift the output by 'xyzzy' bits", I feel a very confused expression is about the best I can hope for.
Comment: (x)-x is also an example of ambiguity, where (x) may be interpreted as an expression or as a type casting. Moreover, this expression may be used in any meaningful context, avoiding the discussion about overloading *.
Comment: In the provided example, it doesn't have any side effects.  You are right, there's variations on this theme (say, overloaded "*") which could have side effects.   As stated, people *might* think it was stupid.  I've adjusted the text.
Comment: I would count overloading a stateless operator to include side effects as a dumb use (flame bait but I'll elaborate).  I always had that problem with operator overloading: none of the properties of an operator that would make it a reasonable analogy to the original use are guaranteed.  For example, the comparison operators < > <= >= absolutely don't have to work as a partial order.
Comment: @altie: agreed, when you have overloading you want something like the Liskov substitution principle, which says the key properties of the overloaded operator are preserved.  Alas, none of the OO langauges I know about (except Liskov's CLU) insist on that.  So, you can object that the overload in C++ is dumb, but it is legal.
Comment: @IraBaxter: indeed, apparently the PhD thesis cited by Rob Walker, about Fog, implements a parser for C++ (in the middle of implementing some other goal) consisting of a LALR(1) superset grammar and defers significant processing to resolve ambiguities to subsequent stages. So in a way you're right - although this is much uglier than what's needed for C.

In another sense, though, not just C but many other programming languages have some context-sensitive semantic processing after parsing, like for instance identifier resolution and type-checking (I don't know about scripting languages).
Comment: @Blaisorblade: What people do is get some parser technology that works for most cases, and then hack it handle other cases, either by accepting "too much" and eliminating that later, or by bending the parsing machinery (lexer hack as one example, ad hoc look-ahead, etc.)  So I think you can do it; its just awful.
Comment: @Troy:  How is that different than Java overloading the add operator "+" to concenate two strings?
Comment: @Troy: yes, I kind of agree about the intuition (although if you ask most non-C/C++ programmers what "<<" does, you won't get an answer).  But in either case, the semantics of the different interpretations are simply... different.    So its case of what arbitrary semantics, do you want to attach to what arbitrary syntax?
Comment: Grasshopper: you are swimming against the current.  You can argue that C's grammar is unnecessarily complex; if you follow that argument to the limit you can always define your language as S-expressions as LISP does, and then parsers are basically trivial.  If you think that LISP S-expressions are clumsy, then you will design a language with lots of idiomatic forms.  Over time, people graft extra stuff in.  ....
Comment: ... The modern version of pretty much every language I'm familiar with, has things that make recursive descent parsing harder than you'd like.  If you use the right parser generator, you stop caring because these variations are all handled by the parser generator without fuss. (Seriously, check out GLL or GLR Parsing).   Regarding C, you'll find parsing it harder than you think due to the need to implement an accurate preprocessor, and (if you insist on recursive descent), the need to track types during parsing.  That latter for me tangles parsing and symbol tables, and that's just stupid.
Comment: If I understand things correctly, modern C++ allowing a type definition `typedef int x;` as part of a class definition before or _after_ some method of said class containing `x * y;`, would ostensibly make the program unparsable for LR parsers with insufficient look-ahead, _specifically_ even those that would employ a "hack" utilizing symbol collection. The problem lies in that they'd simply have to defer determining nature of `x`, until a _later_ `typedef`, if there's one at all. Solving that would make for a far more complicated hack, wouldn't it?
Comment: @ArmenMichaeli:  (Yes).  If you insist your parser needs type information for identifiers, and your language allows identifer use earlier in the source, with type declaration later, then LALR parsing will be a complete disaster precisely because it is *left* to right parsing.  It will encounter the identifier without type information... now what does it do to proceed?  You can hack the LALR parser to backtrack, and then perhaps you can assume a type on first encounter and verify it later.   Even that will fail if an identifier use *might* be of many types because of too much backtracking.
Answer: There is an interesting thread on Lambda the Ultimate that discusses the LALR grammar for C++.
It includes a link to a PhD thesis that includes a discussion of C++ parsing, which states that:

"C++ grammar is ambiguous,
  context-dependent and potentially
  requires infinite lookahead to resolve
  some ambiguities".

It goes on to give a number of examples (see page 147 of the pdf).
The example is:
int(x), y, *const z;

meaning
int x;
int y;
int *const z;

Compare to:
int(x), y, new int;

meaning
(int(x)), (y), (new int));

(a comma-separated expression).
The two token sequences have the same initial subsequence but different parse trees, which depend on the last element. There can be arbitrarily many tokens before the disambiguating one.
Comment: It'd be cool to have some summary about the page 147 on this page. I'm going to read that page though. (+1)
Comment: The example is:
int(x), y, *const z; //meaning: int x; int y; int *const z; (a sequence of declarations)
int(x), y, new int; //meaning: (int(x)), (y), (new int)); (a comma-separated expression)
The two token sequences have the same initial subsequence but different parse trees, which depend on the last element. There can be arbitrarily many tokens before the disambiguating one.
Comment: Well, in that context ∞ means "arbitrarily many" because the lookahead will always be bounded by the input length.
Comment: I'm quite puzzled by the citation extracted from a PhD Thesis. If there is an ambiguïty, then, by definition, NO lookahead may ever "resolve" the ambiguity (i.e. decide which parse is the correct oen, as at least 2 parses are considered correct by the grammar). Moreover, the citation mentions the ambiguity of C but the explanation, does not show an ambiguity, but only a non ambiguous example where parsing decision can only be taken after an arbitrary long look-ahead.
Answer: The problem is never defined like this, whereas it should be interesting :
what is the smallest set of modifications to C++ grammar that would be necessary so that this new grammar could be perfectly parsed by a "non-context-free" yacc parser ? (making use only of one 'hack' : the typename/identifier disambiguation, the parser informing the lexer of every typedef/class/struct)
I see a few ones:

Type Type; is forbidden. An identifier declared as a typename cannot become a non-typename identifier (note that struct Type Type is not ambiguous and could be still allowed).
There are 3 types of names tokens :

types : builtin-type or because of a typedef/class/struct
template-functions
identifiers : functions/methods and variables/objects

Considering template-functions as different tokens solves the func< ambiguity. If func is a template-function name, then < must be the beginning of a template parameter list, otherwise func is a function pointer and < is the comparison operator.
Type a(2); is an object instantiation.
Type a(); and Type a(int) are function prototypes.
int (k);  is completely forbidden, should be written int k;
typedef int func_type();  and
typedef int (func_type)(); are forbidden.
A function typedef must be a function pointer typedef : typedef int (*func_ptr_type)();
template recursion is limited to 1024, otherwise an increased maximum could be passed as an option to the compiler.
int a,b,c[9],*d,(*f)(), (*g)()[9], h(char);  could be forbidden too, replaced by  int a,b,c[9],*d;
int (*f)();
int (*g)()[9];
int h(char);
one line per function prototype or function pointer declaration.
An highly preferred alternative would be to change the awful function pointer syntax,
int (MyClass::*MethodPtr)(char*);
being resyntaxed as:
int (MyClass::*)(char*) MethodPtr;
this being coherent with the cast operator  (int (MyClass::*)(char*))
typedef int type, *type_ptr;  could be forbidden too : one line per typedef. Thus it would become
typedef int type;
typedef int  *type_ptr;
sizeof int, sizeof char, sizeof long long and co. could be declared in each source file.
Thus, each source file making use of the type int should begin with
#type int : signed_integer(4)
and unsigned_integer(4) would be forbidden outside of that #type  directive
this would be a big step into the stupid sizeof int ambiguity present in so many C++ headers

The compiler implementing the resyntaxed C++ would, if encountering a C++ source making use of ambiguous syntax, move source.cpp too an ambiguous_syntax folder, and would create automatically an unambiguous translated source.cpp before compiling it.
Please add your ambiguous C++ syntaxes if you know some!
Comment: C++ is too well entrenched.  Nobody will do this in practice.  Those folks (like us) that build front ends simply bite the bullet and do the engineering to make the parsers work.  And, as long as templates exist in the language, you're not going to get a pure context-free parser.
Comment: @SO_fix_the_vote_sorting_bug:  So, 10 years after my last remark, somebody tries to build such a tool.  Herb is very smart guy, and he has built himself a toy (quote: "hilariously incomplete").  When it is production quality and widely accepted, we can re-discuss whether it will take over from standard C++.
Comment: @IraBaxter, and then along came good ol' Herb with [cppfront](https://github.com/hsutter/cppfront).  He even states he wants a CFG for C++.
Answer: As you can see in my answer here, C++ contains syntax that cannot be deterministically parsed by an LL or LR parser due to the type resolution stage (typically post-parsing) changing the order of operations, and therefore the fundamental shape of the AST (typically expected to be provided by a first-stage parse).
Comment: Parsing technology that handles ambiguity simply produces *both* AST variants as they parse, and simply eliminate the incorrect one depending on the type information.
Comment: @IraBaxter There seems to be new developments on GLL: see this 2010 paper about GLL http://dotat.at/tmp/gll.pdf
Comment: @Ira: Yes, that is correct. The particular advantage of that is it allows you maintain the separation of the first-stage parse. While it's most commonly known in the GLR parser, there's no particular reason I see that you couldn't hit C++ with a "GLL?" parser as well.
Comment: "GLL"?  Well, sure, but you'll have to go figure out the theory and write up a paper for the rest of to use.  More likely, you could use a top down hand coded parser, or a backtracking LALR() parser (but keep the "rejected") parses, or run an Earley parser.  GLR has the advantage of being a pretty damn good solution, is well documented and by now well proved.  A GLL technology would have to have some pretty significant advantages to display GLR.
Comment: The Rascal project (Netherlands) is claiming they are building a scannerless GLL parser. Work in progress, might be hard to find any online information.   http://en.wikipedia.org/wiki/RascalMPL
Answer: I think you are pretty close to the answer.
LR(1) means that parsing from left to right needs only one token to look-ahead for the context, whereas LR(∞) means an infinite look-ahead. That is, the parser would have to know everything that was coming in order to figure out where it is now.
Comment: No, there's an impassable mountain of a difference between n and infinity.
Comment: "Isn't the answer: Yes, given an infinite amount of time?" -- No: the phrase 'given an infinite amount of time' is just a non-sensical, short-hand way of saying "cannot be done given any finite amount of time". When you see "infinite", think: "not any finite".
Comment: Actually, by my *vague* recollection of how LR(n) -> LR(1) takes place, it involves creating new intermediate states, so the runtime is some non-constant function of 'n'.  Translating LR(inf) -> LR(1) would take infinite time.
Comment: I recall from my compilers class that LR(n) for n > 0 is mathematically reducable to LR(1).  Is that not true for n = infinity?
Comment: Isn't the answer: Yes, given an infinite amount of time? :)
Comment: Infinite lookahead may be necessary, but it isn't sufficient.  See my answer on the necessity to use context to resolve the choice.
Answer: The "typedef" problem in C++ can be parsed with an LALR(1) parser that builds a symbol table while parsing (not a pure LALR parser). The "template" problem probably cannot be solved with this method. The advantage of this kind of LALR(1) parser is that the grammar (shown below) is an LALR(1) grammar (no ambiguity).
/* C Typedef Solution. */

/* Terminal Declarations. */

   <identifier> => lookup();  /* Symbol table lookup. */

/* Rules. */

   Goal        -> [Declaration]... <eof>               +> goal_

   Declaration -> Type... VarList ';'                  +> decl_
               -> typedef Type... TypeVarList ';'      +> typedecl_

   VarList     -> Var /','...
   TypeVarList -> TypeVar /','...

   Var         -> [Ptr]... Identifier
   TypeVar     -> [Ptr]... TypeIdentifier

   Identifier     -> <identifier>       +> identifier_(1)
   TypeIdentifier -> <identifier>      =+> typedefidentifier_(1,{typedef})

// The above line will assign {typedef} to the <identifier>,
// because {typedef} is the second argument of the action typeidentifier_().
// This handles the context-sensitive feature of the C++ language.

   Ptr          -> '*'                  +> ptr_

   Type         -> char                 +> type_(1)
                -> int                  +> type_(1)
                -> short                +> type_(1)
                -> unsigned             +> type_(1)
                -> {typedef}            +> type_(1)

/* End Of Grammar. */

The following input can be parsed without a problem:
 typedef int x;
 x * y;

 typedef unsigned int uint, *uintptr;
 uint    a, b, c;
 uintptr p, q, r;

The LRSTAR parser generator reads the above grammar notation and generates a parser that handles the "typedef" problem without ambiguity in the parse tree or AST. (Disclosure: I am the guy who created LRSTAR.)
Comment: That's the standard hack used by GCC with its former LR parser to handle the ambiguity of things like "x*y;"   Alas, there's still the arbitrarily large lookahead requirement to parse other constructs, so LR(k) fails to be a solution any fixed k. (GCC switched to recursive descent with more ad hockery).
Comment: LRSTAR is at https://sourceforge.net/projects/lrstar/
Comment: "LRSTAR is at sourceforge.net/projects/lrstar"

seems to be a link that is no longer valid !


Por que validar mesmo com um valor por defeito?

Question: Quando estou a preparar algo, por mais simples que seja, surge-me sempre a questão:

Devo confiar no meu código?

Este enigma está geralmente associado ao fato de que "amanhã" posso não ser eu a dar suporte ao projeto, erros podem acontecer, e o código deve estar preparado para lidar com eles.
Pegando em exemplos simples:

Parametros de uma função
function consultaGrupos($dbh, $limit=0) {

  if (intval($limit)>0) {
    // ...
  }

  //...
}

A função aceita dois parâmetros, um objeto da ligação à base de dados e um inteiro indicando que é pretendido limitar a consulta em X registos.
O inteiro já é por padrão 0, mas ao escrever a verificação de existência de um valor >=1 acabo por verificar se a conversão do valor recebido para inteiro é maior que 0 assegurando que não vem por exemplo batatas.
Um valor numa matriz
$moduleTitle = $this->vocabulary["text"][1];

if (empty($moduleTitle)) {
  $moduleTitle = 'Um valor padrão...';
}

A entrada na matriz que contém o vocabulário existe e pela "especificação" deve estar preenchida, mas por algum motivo bizarro a mesma pode calhar de vir vazia, pelo que verificamos isso mesmo.
Uma propriedade de um objeto
Código normal:
$dbObj = consultaProduto($dbh, 1);

if (!is_object($dbObj)) {
  // ups... não foi possível obter o produto #1
}

Código extra validado:
$dbObj = consultaProduto($dbh, 1);

if (!is_object($dbObj)) {
  // ups... não foi possível obter o produto #1
}
else if (!property_exists($bdObj,'url') || empty($bdObj->url)) {
  // ups... não foi possível apurar o URL do produto #1
}

A consulta à base de dados devolve um objeto, neste exemplo uma das propriedades desse objeto de nome url existe sempre. Contudo, não só verificamos se obtivemos um resultado na consulta realizada como verificamos se a propriedade efetivamente existe.
Aqui, tal como no exemplo em cima, existe também a verificação se o valor de url está ou não vazio.

Pergunta
Estarei a ser demasiado protetor ao validar algo que já está assumido e contém um valor por padrão, ou de fato não devo confiar e devo validar os valores recebidos?
Comment: Esta pergunta seria o mesmo que essa outra? http://pt.stackoverflow.com/q/42597/14584. Minha visão: partir da **não validação** (opção primária) e validar quando houver necessidade clara e uma expectativa bem definida sobre o resultado da validação.
Comment: @Caffé São realmente parecidas, apesar de que na que tu referes não vejo uma resposta ao que eu pergunto... O meu exemplo é um função, mas a pergunta visa obter o por que de se validar algo que supostamente já está definido e contém um _fallback_! Não limitado ao exemplo dado. Se relevante, posso editar e aplicar outros exemplos.
Comment: Infelizmente, com PHP você não tem tipagem de retorno então se o recurso X depende de algo retornado pelo recurso Y, então sim, você deve validar mesmo que você seja o programador mais meticuloso da equipe. Agora, no caso de um recurso vindo de um banco de dados, você pode popular uma Model pré-definida com os dados retornados, dessa forma ele sempre vai existir e do jeito correto (caso contrário não teria sido inserido, já que passaria pela mesma Model).
Comment: @BrunoAugusto Bom ponto de vista, convido-te a deixares uma resposta com o mesmo ;)
Comment: Infelizmente eu não me arriscaria porque meu conhecimento de banco de dados é bastante restrito e minhas incursões com ORM e os Design Patterns relacionados, apesar de [prontos e funcionais](https://github.com/nextframework/next/tree/dev/DB) podem ter equívocos conceituais que poderia ser danoso ao tópico.
Answer: Uma resposta definitiva não é possível. Há controvérsias sobre o que é melhor.
Vou repetir o que sempre digo e o AP sabe disso. O mais importante é padronizar o que a equipe faz e seguir sempre o mesmo padrão. O que não pode é ficar cada hora fazendo uma coisa diferente. Criar a expectativa que algo está no código e depois não estar não é bom.
Valor default
Não vejo um motivo para diferenciar se o parâmetro tem um valor padrão (por defeito) ou não. Afinal se a função for chamada sem passar um argumento para este parâmetro é certo que o valor dele estará correto. Mas se se vier um valor? Quem garante que este valor esteja correto?
Vejo qualquer parâmetro da mesma maneira. Neste ponto acho que não há discussão.
Verificar resultados
Depende um pouco do que será feito em seguida, mas em geral, acho que o ideal é verificar se está tudo ok com o resultado. Porque se não estiver você poderá ter um resultado inesperado.
A pergunta diz que existe uma especificação dizendo que não pode ter um valor vazio. Tudo que é especificado deve ir para o código de alguma forma.
A não ser que tenha um claro e bom motivo para não colocar.
Quanto mais próximo da especificação, melhor. E quando mais precisa, mais localizada for a identificação do erro, melhor também.
A grande questão é se é possível gerar um resultado inesperado e principalmente indesejado se a informação não for exatamente a que você acha que deve obter.
Em códigos robustos é primordial que não faça nada com dados duvidosos.
Considere inclusive analisar se esta verificação não pode ser feita dentro da função que está chamando e gerando o resultado em questão. Não são só os parâmetros que devemos verificar, o retorno da função também pode ser verificado antes de encerrar a função e tomar uma ação mais apropriada quando se sabe que vai retornar algo que não será útil.
Claro que colocar esta verificação dentro da função implica nela ficar mais específica. Pode ser que você tenha os dois usos. Ainda assim considere ter duas versões da função, uma que permite, por exemplo, retornar vazio e outra que impede este retorno.
Verificar argumentos antes de passá-los
É útil para informar melhor onde está o erro. Em geral agrega pouca informação fazer esta verificação antes. Em tese a função deve indicar bem que houve um problema na sua chamada.
Mas existe uma exceção onde a validação é fundamental. Há casos em que um argumento pode ser válido para aquele parâmetro (o mesmo vale para um índice de um array que não deixa de ser um argumento) mas naquela situação específica um determinado valor naquele momento pode não ser adequado, pode trazer resultados inesperados se ele for usado. É algo que só o programador ali na hora sabe que pode haver problema em usar aquele valor.
Fica óbvio que é um caso para verificar antes se ele está dentro da necessidade.
Alguns poderão dizer que no fundo isso é uma variação do caso anterior onde o valor já é verificado logo quando ele é recebido como retorno de uma função (ou operação qualquer que retorne algum valor).
O que está fazendo?
Depende um pouco do tipo de código que está sendo produzido.
Vou descartar um script simples de provável duração curta, de acordo com a descrição da pergunta. Também vou considerar apenas as premissas colocadas na pergunta. Desconsiderarei o caso do programador ser único no projeto (que eu responderia de forma diferente).
Biblioteca
Está fazendo uma biblioteca genérica que será usada por outros pessoas? É quase certo que deveria verificar e dar a melhor informação possível para o usuário da função saber o que ele fez errado.
Não consigo ver outra forma para garantir o uso da função de biblioteca corretamente sem fazer isso. Especialmente em PHP.
Há um custo de performance em verificar, mas ele normalmente é ínfimo. Quase nunca faz diferença, e se fizer provavelmente é melhor fazer esta função em outra linguagem e expor ao PHP. Portanto não vou considerar a performance um argumento para não colocar uma verificação tão importante.
Código de aplicação
De uma certa forma códigos que serão usados por várias pessoas em tempo prolongado, mesmo que seja código específico do aplicativo, não deixa de se comportar como um código de biblioteca.
Então a decisão se deve validar ou não passa pela cultura das pessoas envolvidas no projeto.
Se você não pode garantir quem serão estas pessoas ou sabe que elas não são sistemáticas e/ou não costumam usar outras formas de verificação de código, a resposta mais óbvia é fazer a verificação.
Você só pode ter certeza que a função será usada corretamente se fizer a verificação.
Testes externos
Hoje há a ideia de que a verificação deve ser feita por testes externos. É uma boa ideia, mas isto só garante a verificação se alguém fizer o teste corretamente no código consumidor.
O teste de uma função de forma isolada só consegue testar o que está internamente nela, o que ela tem controle. Então é possível testar o que ela faz e o valor default que ela recebe (você tem controle sobre este valor).
Os testes da função só poderão verificar situações simuladas de uso dela. É possível testar o comportamento da função em determinadas situações, em determinados valores recebidos.
Há o entendimento que raramente você testará 100% das situações. Isto por si só deve questionar se o teste isoladamente é solução efetiva.
Mas vamos considerar que o teste cobriu 100% das situações. Isto apenas mostra o que a função executará em caso de uso indevido. Ele não evita o uso indevido.
Para garantir que não tenha uso indevido você terá que testar o uso da função. E estes testes deverão ser feitos no código consumidor da função se baseando na documentação dela.
Haverá disciplina e entendimento total para que isso sempre seja feito e obtenha um resultado satisfatório?
Mesmo que isso seja possível, vale à pena?
Testar todos os códigos consumidores dá muito mais trabalho que testar apenas uma vez no código produtor do resultado desejado.
E mais, é garantido que ele sempre será executado corretamente (desde que tenha sido escrito corretamente). Testes não garantem nada.
Claro que testes perfeitos podem garantir, mas quem garante que eles são perfeitos?
Neste momento me parece que valer-se apenas dos testes um pouco ingênuo e nada produtivo.
Em toda função é necessário verificar os parâmetros?
Em acho que é uma questão de consistência. Mas compreendo quem ache que alguns casos é desnecessário.
Se o parâmetro serve imediatamente de argumento para outra função que fará uma verificação provavelmente não trará maiores problemas. É um caso em que a economia de código de verificação pode ser justificada.
Claro que você pode acabar em uma sequência enorme de funções que não verificam parâmetros delegando para a função chamada seguinte.
A única grande desvantagem é que o erro ocorrerá em um nível superior da pilha de chamadas indicando que o erro ocorreu em um local que pode estar distante da verdadeira fonte do problema obrigando o programador precorrer todo o stack trace e olhando a documentação de todas as funções da cadeia de chamadas para achar onde está o erro.
Com a verificação em todas as funções você sempre terá a informação na real origem do problema simplificando a depuração manual (no olhômetro) ou através de uma ferramenta, poupando tempo do usuário da função.
Apesar das funções do PHP serem documentadas os programadores vivem passando dados errados para elas. Imagine se não tivesse nenhuma verificação e ele assumisse um valor qualquer, como pioraria a situação. De fato algumas funções fazem isso e é uma das coisas mais criticadas no PHP.
Vamos dizer que você coloque um nome expressivo no parâmetro para mostrar o que pode ou não pode passar (não que isto garanta alguma coisa). Que nome você escolheria para indicar que precisa ser um valor numérico que não pode ser negativo? E se for uma faixa mais estrita de valores? E se tiver algumas faixas? O nome do parâmetro deve conter informação sobre a regra dele? E se mudar a regra? Este seria o pior caso de notação húngara que eu já vi.
Claro, você pode confiar na documentação escrita e que ela será seguida. Isso não dá robustez, simplesmente não dá. Você pode confiar ou não, esta é uma decisão sua e obviamente você não quer que ninguém decida por você. Aqui apenas tem algumas informações para ajudar a decidir.
O que fazer
Uma função deve impedir seu funcionamento ou resolver um problema sempre que um parâmetro esteja impróprio para uso.
O que pode acontecer de errado?
Se não tiver uma verificação, não tiver um teste perfeito que detecte um argumento passado errado, a linguagem não ter uma forma de verificar tudo o que seja necessário e o código consumidor chamar a função com argumento errado, ela executará de forma errada, possivelmente produzindo um resultado inesperado.
O "possivelmente" pode parecer um atenuador mas na verdade é um agravante. Pode passar a falsa sensação de confiabilidade em algumas situações.
Por sorte em alguns casos o problema será tão grave e tão constante que o programador logo perceberá o erro.
Quer contar com a sorte em seu código?
Ainda assim pode ser que ele não tenha a melhor informação possível acerca do problema.
Mas o que acontece com frequência é que a função executa normalmente sem apresentar erros aparentes. Apenas dá um resultado diferente do esperado. E pode ficar assim, sem ninguém perceber por anos, causando prejuízos.
O mesmo vale para a continuidade de códigos que dependam de retornos de funções.
Eu não vi o resto do código nos exemplos postados mas muito provavelmente algum erro sutil acontecerá se retirar as verificações. E provavelmente você e as pessoas que foram mexer com isso terão uma perda de tempo considerável para descobrir o que está acontecendo.
Novamente, se der sorte o erro será catastrófico logo de cara e perda de tempo será pequena.
Se precisar tirar essa verificação, o que fazer?
Se for imprescindível que a verificação seja removida do código, provavelmente por performance, documente muito bem como a função deve ser usada e como testar seu uso. Se possível crie uma ferramenta que ajude testá-la.
Neste caso você pode delegar a verificar para o código consumidor onde a verificação seja feita em um ponto que não afete a performance.
Conclusão
Particularmente, na situação descrita (fazer para futuros programadores) não é exagero fazer todo tipo de verificação possível. Na dúvida, verifique. Nunca é inútil evitar que o programador use algo de forma errada.
Uma boa recomendação seria: se você pode provar que um dado ruim não causará nenhum problema, não verifique.
Nesta situação um dos maiores perigos é achar que os programadores vão usar tudo certinho sempre e não vão cometer deslizes que não serão facilmente detectados. Aqui mesmo no SOpt vemos todos os dias programadores cometerem erros bobos e não conseguirem achar o problema muitas vezes porque o código não deixa ele óbvio. Convenções não ajudam muito achar erros.
Você não aprendeu que sempre deve validar o que o usuário faz? Por mais absurdo que possa ser o dado ele sempre pode acontecer. Pois bem, estamos falando de validar o que um usuário está fazendo. No caso o usuário é o programador que usa o código que você fez. Por que deveríamos tratar programadores como super-humanos que não cometem erros?
Em PHP qualquer parâmetro pode vir qualquer coisa, não importa se ele tem um valor default ou não. Então é preciso verificar o que vem.
É o que eu costumo dizer em diversas respostas minhas. A regra serve para orientar, mas existem muitas regras. Quando aplicar a correta nem sempre é fácil saber. É preciso experiência e principalmente não se apegar com unhas e dentes à uma delas. Entenda o contexto antes de aplicar uma regra. Não acredite cegamente no que leu em um livro porque ele não sabe o seu contexto.
Outras linguagens
Somente em linguagens que tem mais controle em compilação sobre o conteúdo que pode ser usado durante o consumo da função é que dá para relaxar algumas verificações mas não todas. Algumas linguagens podem evitar a necessidade de verificar tipos ou se um valor é nulo. Outras mais sofisticadas podem até ter uma assinatura que podem ser usadas em tempo de compilação para analisar a característica do valor e decidir se ele é aceitável. Mas note que no fundo você escreverá uma verificação também mesmo que a sintaxe simplifique isso.
Quando evitar
Você pode evitar a verificação nos casos em que tenha certeza (de verdade) que um dado errado produzirá resultado adequado também. Há casos, por exemplo, que retornar um vazio tem uma semântica adequada. O resto do código saberá como se comportar com isso, poderá até ter um efeito colateral desejável.
Outra possibilidade é querer assumir o risco. Confiar que todos lerão a documentação, farão todos os testes perfeitos e quando isso não ocorrer não vai causar grande problema. Não é uma recomendação, apenas uma constatação.
E é claro que se a situação for outra, se você tem total controle sobre a aplicação, se o código não for feito para outras pessoas utilizarem ou dar manutenção, então você pode relaxar um pouco mais. O problema é saber quanto dá para fazer isso sem se comprometer negativamente.
Referência adicional
Eu falo mais sobre isso nessa resposta. Especialmente sobe verificação de tipos onde normalmente é menos necessário verificar em algumas linguagens. Há uma tendência de erros de tipos causarem um problema muito visível. Claro que linguagem com casting automático mal pensado aumenta o risco.
Coloquei no GitHub para referência futura.
Comment: Eu continuo lendo muito texto aprovando a validação generalizada de tipos de parâmetros e mesmo com tanto texto não aparece o básico: quais os benefícios da validação generalizada? Pode dar alguns exemplos do que pode acontecer sem a validação generalizada e de como ficaria melhor com ela?
Comment: Entendo a recomendação pró-validação, mas lendo as suas duas respostas ainda não entendi se você é favorável a sempre validar os *tipos* dos argumentos (no caso dessas perguntas, em PHP e JS). Porque se for pra sempre validar tipo nessas linguagens, não seria melhor partir de uma vez para uma linguagem com tipagem mais rígida?
Comment: Tipos eu acho que não é interessante fazer sempre. Mas depende do que está fazendo. Se for uma biblioteca eu acho que deve fazer sempre sim. Não seria melhor "optar" por uma linguagem estática de todas as situações por pelo menos duas razões: 1) como você vai optar por linguagem estática para rodar no *browser*? Se você só sabe uma linguagem ou só pode usar aquela, não tem escolha, a maioria das pessoas não escolhem PHP 2) Linguagem estática não permite várias construções flexíveis que uma dinâmica permite, não é só questão de verificar tipo em compilação ou não.
Comment: Mas você tem um pouco de razão. A questão aí é que as linguagens dinâmicas são usadas quando o programador tem controle sobre tudo o que ele está fazendo, tem uma equipe muito coesa, há muito disciplina na programação ou quando não se exige robustez. Mas se quer algo robusto tem que verificar tudo mesmo. Como eu falei, em alguns casos até dá para deixar para a última função chamada verificar o tipo. Não tem dá uma informação certeira sobre o erro mas não causa maiores problemas. O seu caso é diferente da pergunta aqui. Você tem controle sobre todo o software.
Answer: Precisamos de código mais significativo em vez de mais código
Quando o código é bem expressivo, é mais fácil para os programadores saberem o que esperar dele. Isso diminui o medo que nos leva a adicionar mais e mais código em busca de robustez - o que geralmente é uma tarefa ingrata pois por mais que validemos, nunca validaremos o suficiente.
Quando o C# (como sabemos, uma linguagem que nasceu como estaticamente tipada) introduziu o var houve uma ampla discussão - para muitos, quando usado para declarar tipos não anônimos isso diminuiria a legibilidade do código. Um exemplo de um destes argumentadores era que
List<ContaaPagar> contasVencidas = contasaPagar.ObtemContasVencidas();

era mais expressivo que:
var contasVencidas = contasaPagar.ObtemContasVencidas();

Então um contra-argumentador questionou: o que mais pode ser retornado por contasaPagar.ObtemContasVencidas() do que uma lista de contas a pagar? Uma lista de sacos de batata? E, num contexto de contas a pagar, o que mais pode residir numa variável contasVencidas além de uma lista de contas a pagar vencidas?
É claro que se o primeiro argumentador tivesse mostrado um exemplo como este:
List<ContaaPagar> cts = ctPg.getVenc();

todos iriam concordar que, neste caso, explicitar o tipo da variável cai muito bem (só não cai melhor do que refatorar este código feio).
Este foi só um exemplo, trazido de uma linguagem que nasceu fortemente e estaticamente tipada, para demonstrar que o mais importante é que o nosso código seja expressivo.
Vou entrar em cada um dos exemplos na pergunta.
Exemplo 1 - Validar tipo do parâmetro
function consultaGrupos($dbh, $limit=0) {

    // se $limit contém outra coisa que não um inteiro,
    //  lança uma exceção.
}

A assinatura desta função, dependendo do contexto e da cultura do projeto, até que já está bem expressiva. Mas só para garantir, vamos reescrevê-la:
function obtemGrupos($contextoDb, $qtdMaximaResultados=0)

O que mais esta função pode retornar e o que mais eu posso passar para ela além do que já foi deixado óbvio na assinatura? Quais são as chances de alguém passar "batatas" no segundo parâmetro? Vale a pena lançar uma outra exceção além da exceção padrão que o PHP vai lançar quando ele tentar usar "batatas" como se fosse um inteiro?
É claro que eu estou considerando que "Grupo" é um termo de negócio muito bem definido e não ambíguo no contexto.
Exemplo 2 - Validar existência de um item em um dicionário
$moduleTitle = $this->vocabulary["text"][1];

if (empty($moduleTitle)) {
  $moduleTitle = 'Um valor padrão...';
}

Se eu compreendi o contexto, isto não é apenas uma validação - trata-se de uma regra de negócio que admite que nem todos os itens necessários podem estar presentes, e que se não estiverem o aplicativo continua a funcionar com um valor padrão. É claro que provavelmente você iria querer encapsular isto em uma função de modo a poder reutilizar esta checagem em vez de repetir o código todas as vezes. Ficaria mais ou menos assim:
obtemPrimeiroSinonimo($texto) {

    $primeiroSinonimo = $this->vocabulario[$texto][1];

    if (empty($primeiroSinonimo)) {
        $primeiroSinonimo = 'Um valor padrão...';
    }
}

Veja que mais uma vez eu considerei que existe algum conhecimento do contexto por parte do programador, e que o código expressa bem este contexto de modo que o próprio código ajuda no aprendizado do programador.
Exemplo 3 - Validar uma propriedade de um objeto recebido de uma função
$dbObj = consultaProduto($dbh, 1);

if (!is_object($dbObj)) {
  // ups... não foi possível obter o produto #1
}
else if (!property_exists($bdObj,'url') || empty($bdObj->url)) {
  // ups... não foi possível apurar o URL do produto #1
}

Esta segunda validação está correta dependendo da modelagem da solução ou do sistema como um todo. Um exemplo de quando ela está correta: url não é um atributo obrigatório do produto, esta consulta acontece na hora de tentar criar um link pra ele, e é esperado pelo negócio que um produto sem url simplesmente fique sem um link nesta visualização em particular. Observe então que não se trata de uma validação apenas, mas sim de um fluxo previsto pelo negócio, e o que houve não é um "não foi possível apurar" mas sim um "este produto simplesmente não tem url e é um direito dele, por isso eu verifiquei".
A primeira validação também está correta se um teste automatizado (fui um pouco mais longe agora) demonstra que o comportamento esperado de consultaProduto é retornar "nada" se não houver produto disponível. Mas, mais uma vez, não se trata de um "não foi possível obter" mas sim um "não existe produto aqui pra você". Por fim, seria melhor, em vez de retornar "nada", retornar uma lista vazia já que a assinatura do método sugere uma lista como retorno.
O que não está correto aí é a expressividade do código: dbObj dificilmente é um termo de negócio e este nome não tem nenhum valor para um humano.
Conclusão

Escrevemos validações para tratar exceções previstas pelo negócio. Este é o melhor motivo para escrever uma validação.

Escrevemos validações quando não conseguimos ser suficientemente claros na API do nosso framework ou biblioteca e sabemos que os consumidores, por não entender como utilizar, vão utilizar errado. Então a mensagem de erro da validação explica o que falhamos em deixar auto-explicado pela API.

Escrevemos validações quando não temos testes automatizados para validar e explicar os comportamentos menos óbveis do nosso sistema.

Não escrevemos validações genéricas sem compreender muito bem o motivo, ou seja, sem compreender o que de mal poderia acontecer sem a validação e de que maneira ela está ajudando a prevenir o problema. Por que não fazemos isso? O principal motivo é evitar o desperdício de escrever código potencialmente inútil e que pode até atrapalhar.
Answer: Em minha opinião, independentemente se já há valor padrão definido ou não para o parâmetro na função exposta, vejo sua validação como algo bom. Na verdade, quase excelente, uma vez que estamos falando de uma linguagem de programação em que não nos preocupamos com tipos de variáveis. Enfim, não vejo isso como demasia, e sim com uma ótima preocupação.
Comment: E quais os benefícios dessa validação? Quero dizer, pode listar alguns efeitos práticos positivos?
Comment: Aprimorei a pergunta com mais exemplos de forma a não estarmos limitados ao exemplo dado de uma função, mas sim concentrados na pergunta em si e no motivo pelo qual devemos validar mesmo sabendo que "de trás" já vem algo por padrão.
Comment: O problema é que o @bigown também não listou nenhum benefício ainda. Como a validação generalizada garante que "seu código funcione como você espera que ele funcione"?
Comment: O benefício está exatamente no que o amigo @bigown falou aí acima. PHP é uma liguagem fracamente tipada, isso significa que em parâmetros de funções podem vir absolutamente qualquer coisa. Ou seja, o maior benefício é você garantir que seu código funcione como você espera que ele funcione. Além disso, exatamente por manter estas validações, outros programadores poderão manter seu código de forma mais coerente, afinal, sabe-se que determinado método ou função só funcionará de tal jeito. Enfim, mais validações, menos exceções.
Comment: O benefício é exatamente esse, garantir que seu código funcione como você espera. No exemplo você espera que o valor do parâmetro seja um inteiro, se não for inteiro, ele não entra na condição e não faz nada. Está funcionando do jeito que você espera? Não. É uma validação generalizada, mas ela serve de apoio pra você e para outros programadores. Como eu disse, mais validações menos exceções.


When is OLS numerically unstable?

Question: When is OLS numerically unstable? How can we solve this problem? I do not quite understand what does "numerically unstable" mean. Does it mean that it does not have a closed form solution such that we can only find a local optimum and being unstable means this local optimum keeps changing?
Comment: The stability of least squares solutions depends on the algorithm used to obtain the solution.
Comment: @fcop I would agree with you if the question was "when is OLS unstable", but the question was specifically about numerically unstable. This is a term typically reserved for the kind of problems touched on by Glen_b. However, multiconlinearity could still cause both kinds of instability, but the problem, and thus the solution, is a different one.
Comment: I would say that it means that the estimates can change substantially when uning another sample to re-estimate them.  It can be the case when you have a multicollinearity problem ?
Comment: @Maarten Buis OK I see, it seems that Lennart also thinks in that direction in his answer?
Answer: What do we mean by numerically unstable?
Say you want to calculate the ODE:
\begin{align}
y'   &= λy,\quad t\Rightarrow 0  \\
y(0) &= y0
\end{align}
And you calculate this with some method (Euler forward, RK-method or whatever).
If you receive a decreasing solution for each step, $h$, and the actual solution is increasing then the error increases. A method is unstable if the error increases exponentially.
A stable method might look something like this:

Figure 1.
Where $y(t)$ is the solution, $t$ is the time, and $h$ is given. The red dotted line represents your numerically calculated solution and you can see that the calculated solution converges to the actual solution (blue line)—this is called convergence.
An unstable method might look something like this:

Figure 2. Source: http://virtual.cvut.cz/odl/partners/tut/unit2/node8.html
Where the red dotted line is the numerically calculated solution and the block dotted line is the actual solution.
Now, how can we solve it, you ask.
We can solve it by either lowering the step size, $h$ (which will make the solution take a longer time to calculate), or changing the method. If a method is unsmooth, for example if the integral is very jagged, then implicit methods are useful such as Euler backward. Implicit methods have larger stable span than explicit methods.
We want to analyze the stability of the ODE above with Euler forward.
\begin{align}
y_{n+1} &= y_n + h(f(x_n, y_n)  \\
      &= y_n + h(λy_n)  \\
      &= y_n(1+λh)
\end{align}
For a stable solution $y_{n+1} \rightarrow 0$ if $n \rightarrow \infty$, that is $y_n(1+λh) -> 0$:
\begin{align}
y_n(1+λh) &= y_0(1+λh)^n  \\
          &\rightarrow  \\
 |1+λh| &< 1  \\
-1 &< 1+λh < 1  \\
-2 &< λh < 0  \\
 h &< -2/λ
\end{align}
In other words, you can chose the step size for the method with Euler forward based on the criteria $h < -2/λ$.
Numerical stability in the context of OLS
In the context of OLS stability the objective is to minimize the error in the function that is being constructed. The function is constructed as:
$$(X^\top X)\hat\beta = X^\top y$$
and small changes in $X$ might affect the solution—make it jagged or unsmoothed. When will this occur? This might occur when there are numbers in X that differ a lot, sometimes order of magnitudes. A common example is putting the year (2001, 2002, etc.) and a small value, for example,  concentration of an atmospheric substance ($3.3\times 10^{.4}, 4.\times 10^{-4}$) in $X$. If you then $X^\top X$ the difference in the values will become huge. How one solves this is a big topic, a common procedure is to normalize the data or perhaps add a variable to $X$, called ridge regression.
Ridge Regression
Instead of:
$$(X^\top X)\hat\beta = X^\top y$$
you can use (difference is adding the variable in the parenthesis):
$$\hat\beta= (X^\top X + \Gamma^\top \Gamma)^{-1}X^\top y$$
with this you can try out RMSE vs. ridge parameter and find out which ridge parameter is sufficient and use that value.
Comment: Nice explanation of what numerical instability means for ODEs. Can you make the connection with OLS to answer the OPs question?
Comment: What is the mathematical condition for inverting $X^T X$ to be numerically unstable? Small determinant?
Comment: I took the liberty of editing this to format it using the $\LaTeX$ markdown CV affords. Please ensure it still says what you want it to.

When is OLS numerically unstable?


Video doesn't fit properly

Question: Hi I have a VideoView in my app, provided the layout width and height as fill parent. But still my video is displayed only in half the portion of the videoView. So I tried providing the width and height in dip. But still the video displays in the same manner.
Can anyone help me with this?
Comment: it's hard to help without seeing your code / layout
Answer: I had the same problem. I solved it by creating an own VideoView class extending VideoView, then pass in the width and height from
new VideoPlayer(this, getWindowManager().getDefaultDisplay().getWidth(), getWindowManager().getDefaultDisplay().getHeight());

And this is the VideoPlayer class
public class VideoPlayer extends VideoView {

private int width;
private int height;

public VideoPlayer(Context context, int width, int height) {
    super(context);
    this.width = width;
    this.height = height;
}

public VideoPlayer(Context context, AttributeSet attrs) {
    super(context, attrs);
}
@Override
protected void onMeasure (int widthMeasureSpec, int heightMeasureSpec)
{
     setMeasuredDimension(width, height);
}
}

I then added the VideoPlayer view by code to the layout using ViewGroup.addView(VideoPlayer)

Video doesn't fit properly


Multiselect dropdown closing after one select

Question: I have a multi-select dropdown for listing and selecting some items.
I am using the following code for the multi-select dropdown.
     <Multiselect
            v-model="abc"
            valueProp="xyz"
            label="userName"
            mode="multiple"
            placeholder="Select Recipients"
            class="multiselect-blue"
            :hideSelected="false"
            :options="recipients"
          >
     </Multiselect>

the problem is when I select one option, the dropdown closes.
I want to close the drop-down only after selecting options as much I want.
is there any way to implement that
Answer: set the on close select property to false like
:close-on-select="false",

Answer: Don't know if this helps you out, but just use:
<multiple/> without the mode=
Than it's not a real dropdown it's a multi selection field..
Comment: problem resolved by adding  :closeOnSelect="false"
Comment: just for additional info! Using ```:value``` will make you able to choose only one selection!


Can I improvise inversions when my piece has slash cords?

Question: I'm new to learning to play piano from a fake book.  I've read that when you play a slash cord, the note on the bottom of the slash is supposed to be played in the bass.  However, I've also read that the improviser can invert chords when they want to help create a smoother bass line.
I'm wondering what I should do when I'm playing a piece that contains both slash cords and non-slash cords.  Does this mean I'm free to invert the non-slash chords whenever I feel it's a good idea, or does the presence of slash chords imply that the other chords are meant to be played in root position?
Comment: Sometimes, slash chords are inversions ;). See https://music.stackexchange.com/questions/104163/what-does-the-chord-notation-x-y-slash-notation-mean
Answer:
what I should do when I'm playing a piece that contains both slash cords and non-slash cords.

Fake books normally don't contain original arrangements or compositions. Like the editor or arranger has supposed to play  a chord in root position or a slash chord (which might be an inversion - s. the comment by Tom) it is always up to you as improviser to play the bass line like you want (root or inversions) and what you think sounds fine. You can also play passing tones as many as you like to make an interesting bass line or play some riffs below the chords.

Does this mean I'm free to invert the non-slash chords whenever I feel it's a good idea?

Exactly, you are now the arranger, composer, you are not the slave of any other.

Does the presence of slash chords imply that the other chords are meant to be played in root position?

No, except of the final chord!  Most  others could be inversions, but you will find out that often on the beginning of a phrase the root position is preferable, or at the 1st beat in a measure, every second beat could be the fourth or a passing tone.
Play some chorals, pop songs and analyze when there are inversions.
Even if  the book doesn't propose an inversion you can e.g. play a progression I-Ib7-IV-IVm in the bass C - Bb - A - Ab etc.
It's like you say: If you feel it's a good idea ... just do what you want!
Answer: Inversions are largely up for grabs, except when they aren't!   And the places where they aren't are where you're likely to find a slash chord symbol.
Here's two ways of ending 'The Saints'  (the cliche @Albrecht Hügli was referring to in his answer, I think.)  With slash chords and without.   Play what you like!  But you deserve to be offered the information in the second version, whether as notation or as slash chord symbols.


Como nomear tabela pivot Many-to-Many

Question: Como nomear tabelas pivot no Laravel, de forma que não seja necessário informar o nome da mesma no método de relacionamento (belongsToMany)?
Na documentação achei essa referência:

Many-to-many relations are slightly more complicated than hasOne and
  hasMany relationships. An example of such a relationship is a user
  with many roles, where the roles are also shared by other users. For
  example, many users may have the role of "Admin". To define this
  relationship, three database tables are needed: users, roles, and
  role_user. The role_user table is derived from the alphabetical order
  of the related model names, and contains the user_id and role_id
  columns.
...

Resumindo, é informado que posso pegar o nome dos dois modelo envolvidas e criar uma nomenclatura representando a junção alfabética destes, ou seja, se tenho uma tabela produto e outra usuario, ficaria produto_usuario, com isso não precisaria passar o nome da pivot no método belongsToMany()
A questão é, seria a ordem alfabética das models ou migrations?
Answer:
A questão é, seria a ordem alfabética das models ou migrations?

No finalzinho da tradução diz: tradução Google Tradutor: A tabela role_user é derivada da ordem alfabética dos nomes dos modelos relacionados e contém as colunas user_id e role_id.
Ou seja, o nome da tabela intermediária começa por ordem alfabética sendo que R é antes de U, respectivamente role e user e foi gerado a tabela role_user.
Um outro exemplo para esclarecer:
Se no seu projeto for criado duas tabela com o nome de autor e livro o nome da tabela intermediária seria autor_livro e os campos autor_id e livro_id e a migration como exemplo:

Migration autor

<?php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class Autor extends Migration
{
    public function up()
    {
        Schema::create('autor', function (Blueprint $table) {
            $table->increments('id');
            $table->string('name', 100)->index();
            $table->timestamps();
        });
    }
    public function down()
    {
        Schema::dropIfExists('autor');
    }
}

Migration livro

<?php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class Livro extends Migration
{
    public function up()
    {
        Schema::create('livro', function (Blueprint $table) {
            $table->increments('id');
            $table->string('title', 100)->index();
            $table->timestamps();
        });
    }
    public function down()
    {
        Schema::dropIfExists('livro');
    }
}

Migration autor_livro

<?php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class AutorLivro extends Migration
{

    public function up()
    {
        Schema::create('autor_livro', function (Blueprint $table) {
            $table->integer('autor_id')->unsigned();
            $table->integer('livro_id')->unsigned();
            $table->primary(['autor_id', 'livro_id']);
            $table->timestamps();

            $table->foreign('autor_id')
                ->references('id')
                ->on('autor');

            $table->foreign('livro_id')
                ->references('id')
                ->on('livro');

        });
    }

    public function down()
    {
        Schema::dropIfExists('autor_livro');
    }
}

e consequentemente seus models:

Model Autor

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Autor extends Model
{
    protected $table = 'autor';
    protected $dates = ['created_at','updated_at'];
    protected $fillable = ['name'];
    public $timestamps = true;

    public function livros()
    {
        return $this->belongsToMany(Livro::class);
    }
}

Model Livro

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Livro extends Model
{
    protected $table = 'livro';
    protected $dates = ['created_at','updated_at'];
    protected $fillable = ['title'];
    public $timestamps = true;

    public function autores()
    {
        return $this->belongsToMany(Autor::class);
    }
}

mas, vale lembrar que a primeira configuração é obrigatória as demais seguiram a nomenclatura padrão descrito na documentação.
Já tem aqui um outro exemplo, mas, diferente desse detalha como deve configurar sem a nomenclatura padrão descrita na documentação e outros exemplos

Laravel checkbox checado ou não checado conforme Banco de dados
Salvar varios atributos para um mesmo objeto no Laravel

Como nomear tabela pivot Many-to-Many


Rails polymorphic association error on user destroy

Question: I'm trying to link notifications to users like so.
<code>  belongs_to :notified_by, class_name: 'User'
</code>
My user has_many notifications.
<code>  has_many :notifications, dependent: :delete_all
</code>
The problem is, when I try to destroy a user, I get an error when it goes to delete all the notifications.
<code>ActiveRecord::StatementInvalid (PG::UndefinedColumn: ERROR:  column notifications.user_id does not exist)
LINE 1: DELETE FROM "notifications" WHERE "notifications"."user_id" ...
</code>
There is no user_id in the Notifications table, just a notified_by_id. I have tried using that in place of notified_by, but that didn't work either.
Answer: I had to set the foreign key in the User model to recognize notified_by_id as the column to look for.
<code>  has_many :notifications, foreign_key: 'notified_by_id', dependent: :delete_all
</code>


setting display property in the code behind

Question: How can i set the display property to block in the code behind?
<asp:Panel ID="pnlHedgingTypeI"  Style="display:none" runat="server">

pnl.Attributes.Add("display", "block");

is not helping me ..Could you please help me to resolve this?
Answer: You can also do
pnl.Style["display"] = "block";

Answer: pnl.Attributes.Add("style", "display:block"); is correct ... got it.
Answer: Try this :
pnl.Style.Add("display", "block");


Array multiplication multiplies occurence of values instead of values itself

Question: I have written the following Python code:
numbers = [42, 4224, 42422424, -250]
products = numbers*157
products

This leads to the following output:
42,
 4224,
 42422424,
 -250,
 42,
 4224,
 42422424,
 -250,
 42,
 4224,
 42422424,
 -250,

etc: this order is repeated several times, probably 157 times.
Why does this code not multiply each of the array elements with 157? This should be:
[6594, 663168, 6660320568, -39250]

Comment: That's what `*` does in a list context. You probably wanted `products = [x * 157 for x in numbers]`
Comment: If you want that behavior try the module `numpy``. It's fabulous for that sort of thing and for many others.
Comment: That would work for numpy array i.e. `(np.array([42, 4224, 42422424, -250])*157` produces the desired result
Comment: *"Array multiplication multiplies occurence of values instead of values itself"* - correct. It does. And that is why it doesn't do what you want.
Comment: Ask yourself: what does it mean to multiply a number with a list? You might want the answer to be "it should multiply that number with every element of the list". But what if the list doesn't just have numbers in it? If you think about it, you'll find that getting 157 copies of the original list in a single list makes a bit more sense, although this is a bit surprising as well. At least it always means the same thing, regardless of the contents of the list.
Answer: Multiplying a list by any constant c will repeat the elements in the list by a c number of times.
To better understand what's going on here, you should start by multiplying the list by a smaller constant and eventually work your way up to 157. Let's start by multiplying the list by 1:
products = numbers*1
print(products)
[42, 4224, 42422424, -250]

We can see that multiplying the list by 1 will just send us back our original list, since the elements are only included once in the list. Next, we'll multiply the list by 2:
products = numbers*2
print(products)
[42, 4224, 42422424, -250, 42, 4224, 42422424, -250]

We can see that the elements are repeated twice in the same list. You can increase the constant on your own to observe the increased amount of repetition.

As others have suggested, you can simply use either list comprehension or numpy arrays to retrieve your desired output:
Method 1: List Comprehension
products = [i*157 for i in numbers]
print(products)
[6594, 663168, 6660320568, -39250]

List comprehension is essentially shorthand for writing a loop that multiplies each individual element by 157, in our situation.
Method 2: Numpy Arrays
products = np.array(numbers)*157
print(products)
array([6594, 663168, 6660320568, -39250])

Numpy is a module used for array-processing and data manipulation. You can read more about the benefits of numpy here.
Performance Testing
I'll include some performance differences below. This is also a good example that includes multiplying a list by a constant and multiplying its elements by a constant.
>>> timeit.timeit('[i*157 for i in numbers]', 'numbers=[42, 4224, 42422424, -250]', number=1000000)
0.35015837100013414
>>> timeit.timeit('numbers*157', 'import numpy as np;numbers=np.array([42, 4224, 42422424,-250])', number=1000000)
0.639420188000031
>>> timeit.timeit('[i*157 for i in numbers]', 'numbers=[42, 4224, 42422424,-250]*500', number=1000000)
91.96342155899993
>>> timeit.timeit('numbers*157', 'import numpy as np;numbers=np.array([42, 4224, 42422424,-250]*500)', number=1000000)
1.3476544480001849

Typically, numpy arrays are known to perform better than ordinary Python lists for larger array-like data. However, there are certain instances where Python lists can perform better than numpy arrays, which you can read more about here.
Answer: Why does this code not multiply each of the array elements with 157?
You've already got an excellent answer about how to solve your problem of multiplying the numbers in a list by 157. I'll try to address the question of why numbers * 157 behaves the way that it does in Python, rather than the way you think it should.
Being able to repeat the sequence in a list to create a new, longer list is rather useful for initialising a list with some constant initial value. For example, if you want a list of 100 zeroes, you can write [0] * 100. This is a common thing to want to do, so Python makes it easy, and if you read a lot of Python code then you'll become familiar with this "idiom". You might also see for example [None] * 100 to create a list populated with None values.
That second example raises another point; lists in Python can contain any type of data, not just numbers. It would be strange if Python's lists privileged numbers in some way, by having operations which only worked when the list elements were numbers. For example, the expression ['hello', 'world'] * 10 would be an error if this * meant multiplication of numbers.
Another good reason for the behaviour of * on lists is to be consistent with the behaviour of +. In Python when you have two lists and you write list1 + list2, the result will be a new list containing everything in list1 followed by everything in list2. This is called concatenation, and it is very common to want to concatenate lists or other sequences, so Python makes it easy. Given this, it makes sense that numbers + numbers should mean the same thing as numbers * 2; both expressions create a list containing everything from the list numbers, twice.
Answer: What you want to do is achieved by numpy arrays. In a normal list array, doing numbers * 157 will do the repetition that you obtained. For your desired output,
import numpy as np
products = np.array(numbers) * 157

This outputs
array([      6594,     663168, 6660320568,     -39250])


How to store ObjectID in MongoDb without references?

Question: I have three models:
class User
  include Mongoid::Document
  field :name, :type => String

  has_many :comments
  embeds_many :posts
end

class Post
  include Mongoid::Document
  field :title, :type => String
  field :body, :type => String

  embeds_many :comments
  belongs_to :user
end

class Comment
  include Mongoid::Document
  field :text, :type => String

  belongs_to :user
  embedded_in :post
end

And I have this error:
Referencing a(n) Comment document from the User document via a relational association is not allowed since the Comment is embedded.

Ok, thats right. But how can I store, who wrote a comment?
Answer: The belongs_to user in the Comment is what's throwing it off.  Just use a normal field to store the foreign key.
class Comment
  include Mongoid::Document

  embedded_in :post

  field :text, :type => String
  field :commenter_id
end

Comment: ty! it was easier than I thought :)


Apache stops responding

Question: I have wampserver 2.4 installed on a computer and Apache stops responding to web requests.  If I try to access the site nothing happens.  It will work fine for a day, or about 69 hours in this last case and then, seemingly randomly, it stops.
It can always be resolved by restarting the apache service.
I don't see anything in the apache_error.log file either.
What else can I do to find the cause of this problem?
Comment: When Apache goes AWOL like this, and you call netstat -an, do you see the connection from the client in the ESTABLISHED state?  In other words, is the traffic from the client getting to the TCP stack on the server?
Comment: It looks like there were about 40 connections on port 80, most of them had the state "CLOSE_WAIT" Would that cause apache to not be able to respond?
Comment: no, but they should not be sticking around for very long.  CLOSE_WAIT state means that the server has received a FIN from the client and the socket is waiting for the application (apache) to issue a close() system call on the socket.  If that isn't happening, then something funky is going on inside Apache and over a period of time you will run out of socket descriptors and hang.  But don't assume a bug: it could just as easily be that Apache is tied up doing something (say, a module/webapp writing something to a database that is sloow).
Answer: Check your httpd.conf file and if these entries do not exist try adding them
AcceptFilter http none
EnableSendfile Off
EnableMMAP off

This has fixed this issue in the past.
Comment: I have silmiler issue, can you please explain how this abouve code can fix the issue, Thanks in Advance :)

Apache stops responding


Find the image of the set

Question: Given set $$D=\{(x,y): x\geq -1, y-x\geq1, y+x\leq1\}$$ and the regular transformation $$\phi:\begin{cases}u=x^2+y^2\\v=x+y\end{cases}$$ How to find out the image of $D$, i.e. $\phi (D)$?
Comment: What does $D$ look like in $\Bbb{R}^2$?
Comment: It is triangle.
Answer: $D$ is a triangle like you said in the comments, there are three sides. The first one is:
$$
l_1 = \{x=-1, 0\leq y\leq 2\}: r_1 = (-1,t), t\in [0,2].
$$
The second one is:
$$
l_2 = \{0\leq x\leq 1, y= 1-x\}: r_2 = (t,1-t), t\in [-1,0].
$$
The third one is:
$$
l_3 = \{-1\leq x\leq 0, y= 1+x\}: r_2 = (t,1+t), t\in [-1,0].
$$
Under $\phi$, $l^1$ is mapped to:
\begin{cases}u=(-1)^2+t^2,\\v=-1+t,\end{cases}
which is
$$
u = 1 + (v+1)^2\quad \text{ for } v\in [-1,1].\tag{1}
$$
$l^2$ is mapped to
\begin{cases}u=t^2+(1-t)^2,\\v=1,\end{cases}
here $$u\in [1,5],\quad v = 1.\tag{2}$$
$l^3$ is mapped to
\begin{cases}u=t^2+(1+t)^2,\\v=1+2t,\end{cases}
this implies
$$
u = \frac{v^2 +1}{2} \quad \text{ for } v\in [-1,1].\tag{3}
$$
In the $vu$-plane, $\phi(D)$ is the region bounded by (1), (2), and (3):
$$
\phi(D) = \{(v,u): v\in [-1,1], \frac{v^2 +1}{2}\leq u\leq v^2+2v+2\}.
$$

Find the image of the set


mvc3 How can I read on razor a list created by joining two tables?

Question: I have this mvc3 project, I am learning actually and here I am joining 2 tables from the same database, but I don't know how I can return it to the View, and on the View I don't know how to read it.
public ActionResult Index()
    {
        ViewBag.Message = "List of Domain Names already crawlered";
        domainNamesEntities de = new domainNamesEntities();

        var datos = from nombres in de.tableDomNames
                    join titulos in de.tableTitleNames on nombres.domName equals titulos.domName
                    select new { Dominio = nombres.domName, Titulo = titulos.titleN };

        return View(datos.ToList());
    }

And here is my problem:
       @model ???????????????
       @{
             ViewBag.Title = "Index";
        }

Index

      @foreach (var item in collection???????)
{

}

Any ideas?
thanks!
Answer: The variable datos has an anonymous type.  While you can pass that into a view, you cannot specify a strong type for Model in the view.
If you need a strong type, create a helper object containing your properties, e.g.
public class MyHelper
{
    public string Dominio { get; set; }
    public string Titulo { get; set; }
}

and use
select new MyHelper { Dominio = nombres.domName, Titulo = titulos.titleN };

In the view, you would then specify
@model IEnumerable<MyHelper>

@foreach (var item in Model) // or MyHelper item in Model

Comment: I was waiting for that extra edit to describe the IEnumerable bit before upvoting :) I figured it was coming with as often as quick as your edits were coming.
Comment: @JoelEtherton: Yeah I went back and checked the question, saw that part was missing.  Thanks for the upvote.


What is the name of such a chord or what type of chord is it?

Question: This is a simple progression of chords, but if the first two chords are just "Bbm", "Ab", they have names, no problem, but then what are the last two? How can I interpret them?
Context: progression of chords on which a musical composition is built;
Comment: With a Bbm chord quoted as having A# and C#, I'd move on to a site where they actually knew what they were talking about!
Comment: Fix the enharmonic spelling errors first, then analyze it including identifying melody and non-chord tones from harmonic tones, then if you still have a question about a chord identity or harmonic function, post that specific question. Otherwise your question amounts to "teach me harmony."
Comment: @MichaelCurtis Thanks for your comment, what terms and definitions should i google to answer my question?
Comment: @MichaelCurtis maybe youtube channels or books or another useful stuff
Comment: This is a pretty good starting resource: https://www.musictheory.net/lessons
Comment: @AndyBonner Thanks ☀
Answer: A few points:

"Enharmonic spelling" matters. "Enharmonic," meaning two different names for the same piano key, like how C# and Db are the same. A Bbm chord is spelled "Bb Db F." Yes, the Bb is the same piano key as A# and Db is same as C#, but if we want a Bbm chord, we'd choose the spelling with the flats. The general idea is that the notes of a simple ("triadic") chord in root position should "look like a snowman" in staff notation: You skip a letter in between each note: "Bb (skip C) Db (skip E) F."
A. Why does this matter? If enharmonic notes are the same, who cares what name we use? Because as soon as we start naming chords, we move into subjective analysis. An objective description of this passage would just be that certain keys were pressed together. Once we start naming the chords, we're saying something about what they mean all together in context.

"Voicing" doesn't matter to identifying a chord. A C chord contains C, E, and G, but any one of them can be on the bottom. And you could have more than one E, or even leave the E out. (In that case, people would guess that it's a C major chord from context.) So, for example, the last chord contains two D#s; that doesn't matter. I'd rename the pitches shown to Eb, Ab, and C, then find "root position" by imagining the notes on the staff and rearranging them to form a "snowman" and discover that that happens when Ab is on the bottom; it's an Ab major chord, just like the second chord.

Sometimes you have to guess, based on context. The third chord is the weird thing here. It's unlikely to have both an F and an F#; let's rename that F# to Gb (and C# to Db). If we plot these on the staff, there's no way to make a snowman. I think there's an "implied" note left out. If there were a Bb, we could make a 4-note "snowman" with Gb, Bb, Db, F: a seventh chord, G flat major 7th.

So what about the context led me to that guess? First, look at the bass notes. They walk down in steps at first: Bb, Ab, Gb. In fact, the second chord just takes all the notes of the first chord and lowers them. (The middle note moves only a half step, while the outer notes move a whole step, just because that's how the notes in the key of Bb go.) If the pattern continued, the next chord would be Gb. But the pianist decides to let the right hand follow an oscillating pattern: (Db F), (C Eb), and then repeats (Db F), (C Eb). Combined with the motion of the left hand, we "fill in" the missing Bb of the third chord in our imagination.
Comment: I reckon you could leave out the G, but not the E, to guess that it's a C  major chord. Which, I'm guessing, is what you meant! (2). Or am I missing something?
Comment: I don't think voicing doesn't matter. E.g., if you put 9, or 6 or 13 in the bass voice that will likely change the identity of the chord.
Comment: @user1079505 - I guess Andy's talking about basic triads, or at most 4 note chords, where, in fact, voicing doesn't really matter.
Comment: @Tim yes, I understand it, but one needs to be careful when formulating general conclusions from simple examples.
Comment: @user1079505 I *somewhat* agree with you—and somewhat stand by my position. I'm thinking of a classical rather than jazz context. In classical, the composer just puts dots on the page and it's up to the theorist to decide what to call them. In jazz, the composer often puts *chords names* on the page, and the performer constructs them. The flow is reversed! But as long as we are performing analysis rather than composing, we're deciding what chord name to assign a given bunch of dots, and sure, the note in the bass is a pretty good clue, but overall harmonic context is even more important. ...
Comment: ... This kind of plays into @Tim's first question, too: it's all about context. If I play Twinkle Twinkle Little Star in C and end with no third in my final C chord... well sure, it *could* be minor... but it's very unlikely. And the listener will probably "hear" major.


What does it mean for a sequence of random vectors to converge to a random vector?

Question: I am reading about convergence of random variables from Wikipedia and I come across this.

Note that the condition that $Y_n$ converges to a constant is important, if it were to converge to a random variable $Y$ then we wouldn't be able to conclude that $(X_n, Y_n)$ converges to $(X,Y)$.

This makes me conclude that
$\lim_{n \to \infty}(X_n, Y_n)$ and $(\lim_{n \to \infty}(X_n), \lim_{n \to \infty}(Y_n))$ are different things. Could you please help me understand why the two are different? Would really appreciate an example
Answer: The distribution of $(X,Y)$ is not particularly well defined here unless one is almost surely constant.  In general you would need to know more than $\lim\limits_{n \to \infty}X_n$ and $\lim\limits_{n \to \infty}Y_n$ can tell you.
For example suppose $X \sim N(0,1)$ and $Y \sim N(0,1)$.  You would not know from this whether $X$ and $Y$ are always equal to each other (correlation $1$) or independent of each other (correlation $0$) or something else.
So you would not know  the distribution of $(X,Y)$ or the limiting distribution of $(X_n,Y_n)$, at least without further information.
Comment: But, then how can we say that $(X_n, Y_n)$ always converges to $(X, Y)$ in probability if $X_n$ converges to $X$ and $Y_n$ converges to $Y$ in probability. Convergence in probability does not always mean convergence to a degenerate distribution with only one possible value. e.g: sequence $X + \mathcal(N)(0,1/n)$ converges in probability to $X$. Here also the notion of $(X,Y)$ is not well defined
Comment: If $\lim\limits_{n\to\infty}\Pr\big(d_1(X_n,X) > \varepsilon\big) = 0$ and $\lim\limits_{n\to\infty}\Pr\big(d_1(Y_n,Y) > \varepsilon\big) = 0$ for some sensible 1D distance function $d_1$ such as $d(x,y)=|x-y|$ then it is reasonable to have this imply $\lim\limits_{n\to\infty}\Pr\big(d_2((X_n,Y_n),(X,Y)) > \varepsilon\big) = 0$ for some sensible 2D distance function and prove it with an $\varepsilon-\delta$ argument


Determine value of harmonic function at origin given boundary values on a regular hexagon

Question: Let $E$ be a regular hexagon centered at the origin of $\mathbb{R}^2$. Let $f$ be the harmonic function in $E$ with boundary value 1 on one of the sides of $E$ and boundary value $0$ on each of the remaining sides. What is the value of $f$ at the origin?
This question has shown up on an old PDE qual I am studying. This problem is causing me a lot of concern, because $f$ seems to be discontinuous on the boundary of $E$. But, given that $f$ is harmonic (and thus continuous) in $E$, shouldn't the boundary values of $f$ also define a continuous function?
Hints or explanations are greatly appreciated!
Comment: I have undone the last edit. See Old John's answer below.
Answer: The solution is harmonic and thus analytic in the interior of $E$ and continuous up to the boundary, except at the end points of the segment where it is equal to 1.
When you rotate the segments, you'll get six functions of this form which are rotational images of each other (by uniqueness) and thus all have the same value at the origin. Adding these six functions, you get a harmonic function with boundary values equal to 1, hence it is 1 everywhere.
Therefore, $f(0) = 1/6$.
This is also the probability that a Brownian motion exits through one of the side of the hexagon assuming it starts at the origin (which could be turned into another proof).
Answer: Edit: Please note that the OP has recently edited the question and removed the part that my comments below (to long to be a single comment) refer to.
Harmonic functions do have to be well-behaved inside a region where hey are defined, and in fact they have to be smooth there (infinitely differentiable), but the behaviour at the boundary can be much worse, and indeed as your question implies, it is quite possible to have a function which is harmonic at every point in the interior of the hexagon, but is discontinuous on the boundary itself.
For example, you might consider the harmonic measure. A good book on this is by Garnett: "Harmonic Measure" (Cambridge), and on page 1 he shows that the harmonic measure of an interval on the $x$-axis gives a harmonic function on the upper half-plane, but has boundary values which are $\pi$ inside the interval and zero elsewhere.
Comment: I don't understand the relevance of this post to the question. I'm afraid this does not answer the question at all.
Comment: Please take a look at the question as it was originally posted! The second half of his question (now deleted) was what I was commenting about, but it was too long to fit into a single comment.
Comment: Of course, now I see. I have undone the last edit of the original question to prevent this misunderstanding to happen again. I wonder why the OP did that edit in the first place.


Android: I get an error inserting a date in SQLite

Question: It's not quite an error but a problem.
I do not receive any errors, nor the app crashes. All works fine except, when I download the db to my PC and access it with KiSQLite, the date I inserted in the table appears as "Invalid date".
I tried 2 ways:
1.
public void SaveInfo(String value){
        SQLiteDatabase mDatabase = new myDbHelper(getApplicationContext()).getWritableDatabase();
        SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        Date date = new Date();
        String dt = dateFormat.format(date);
        mDatabase.execSQL("insert into mytableinfo(datakm,km) values ('"+dt+"',"+value+")");
        mDatabase.close();
    }

2.
public void SaveInfo(String value){
        SQLiteDatabase mDatabase = new myDbHelper(getApplicationContext()).getWritableDatabase();
        mDatabase.execSQL("insert into mytableinfo(datakm,km) values (datetime(),"+value+")");
        mDatabase.close();
    }

All I want to do is insert a record in that table, with a date of today (now) and another value.
How should I do it?
Both methods seem to insert Invalid date values...
Please help
Thank you
EDIT
This is my table declaration
sqlu = "CREATE TABLE IF NOT EXISTS " + TABLE_PARCURS + " (_id INTEGER PRIMARY KEY AUTOINCREMENT, " +
                PARC_DATA + " DATE NOT NULL, " +
                PARC_KM + " TEXT) ";
        Log.e("CREATE tbl:", sqlu);
        db.execSQL(sqlu);

Is it wrong? Should I declare the date as TEXT instead of DATE?
Answer: Try like this
String mydate = dateFormat.format(Calendar.getInstance().getTime());

Comment: I don't think it's the way I get the date. Maybe it's the way I insert it..?!?!?
Comment: So then do one thing. just print the date in log before storing into database.
Comment: I did what you asked, still Invalid date. Here are the log lines:` 04-24 13:10:46.860    9706-9706/ro.myapp.app E/MyDATE:﹕ 2014-04-24 13:10:46
Comment: I also logged the text of the insert : 04-24 13:10:46.880    9706-9706/ro.myapp.app E/MyDATE INSERT:﹕ insert into parcurs(datakm,km) values ('2014-04-24 13:10:46',23434534)`
Comment: And like I said... the date ends up invalid in the table
Answer: i cant tell what wrong in your code but you might do it like i do.
   ContentValues newValues = new ContentValues();

    // Assign values for each row.
    newValues.put(Constants.EVENT_TYPE_ID, event.getEvent_type_id().getId());
    newValues.put(Constants.EVENT_TITLE, event.getEvent_title());
    newValues.put(Constants.EVENT_TEXT, event.getEvent_text());
    newValues.put(Constants.EVENT_DATE, event.getEvent_date());
    newValues.put(Constants.CREATE_DATE, event.getCreate_date());
    newValues.put(Constants.EVENT_PIC, event.getEvent_pic());
    newValues.put(Constants.EVENT_DISPLAY_DATE, event.getDisplay_date());
    newValues.put(Constants.EVENT_INTERVAL, 0.0);
    newValues.put(Constants.EVENT_SONG, "");
    newValues.put(Constants.EVENT_VIDEO, "");
    long numOfCulm = myDataBase.insert(Constants.TABLE_EVENTS, null, newValues);

Constants - is my class where i save all the keys.
Answer: Looks like the solution to my problem is to declare the date field as TEXT and insert formatted date in the field. Apparently, the SQLite/Android will treat the TEXT field like DATE if I do so.
So, table declaration will be :
sqlu = "CREATE TABLE IF NOT EXISTS " + TABLE_PARCURS + " (_id INTEGER PRIMARY KEY AUTOINCREMENT, " +
                PARC_DATA + " TEXT NOT NULL, " + // <-- here is what I changed
                PARC_KM + " TEXT) ";
        Log.e("CREATE tbl:", sqlu);
        db.execSQL(sqlu);

And insert code will be the same (with formatted date)
Later I can query the table using DATE utils like
SELECT * FROM table where date(datakm)=date(datetime())

(this will return all the rows in the table that have the current date in datakm field)
So basically, my problem is solved.
Thanks for your time, but I found the solution myself. I wrote the solution as an answer so that other developers that have this issue will have a solution to their problem.
Good luck


Can we compile a literature review to append to this site?

Question: There are a huge variety of different topics in economics, many open ended and divided. I think it'd be great if we could have some sort of wiki with a literature review of recommended papers (to read for undergraduates, laymen, researchers, et cetera). Just divide it up into topics like equilibrium, business cycle theory, rationality, game theory, et cetera.
It'd be nice to give such a wiki as a resource so people could potentially refer to the literature review instead of asking vague or general questions.
Comment: At Space Exploration SE we do it with [meta community wiki posts](https://meta.space.stackexchange.com/questions/249/resources-and-references-considered-as-literary-canons-on-the-topic-of-interpl).
Answer: I was tempted to say that this is largely accomplished by Palgrave, JEP, and the Handbooks of Economics series, but then I recalled this piece by Valerie Ramey, which notes some missing review in a Handbook chapter -- which itself I would never have found without a pointer from another economist. So yes, I could be convinced that there is a use for a wiki of this sort.
Answer: I agree with the OP.
What can be done is: somebody can make a community wiki question, properly worded. Each answer is an economics specialization. There are added appropriate literature to each answer. Title the question: "recommended economic literature." That way, when somebody searches, the topic headings in the answer and the "literature" makes it the first result in a search.
Big-list questions are available on many SE websites. (For example, this on the mathoverflow site )
Answer: Tag wikis could serve this purpose. On Stack Overflow, there are some pretty comprehensive tag wikis - see, for example, the one on the programming language C#
The problem is that the detailed tag wiki is near-invisible - I suspect that few people ever click on the tags, and of those that do, few of them ever click on the "learn more..." link that takes you to the detailed tag wiki.
Community wiki questions used to be used for this, but are no longer, and big-list questions are retreating across almost all the Stack Exchange network. There are exceptions, such as Math Overflow, that continue to do big lists and more frequent use of community wiki. But there is a reason why Math Overflow is so different: it grew up outside the SE network, and was imported as a mature site, with its own culture that had evolved very differently to the SE network,
Comment: It's not really maturity of mathoverflow that makes it work. It's the fact that it's restricted to research level questions. Typical poor quality posts are very rare simply because they can be removed as strictly off topic. (A poor quality answer or question is typically not research level, by coincidence!) The various "big lists" are usually good quality therefore by coincidence, too, and do not end up cluttered.


Cannot change version facet Dynamic Web Module to 4.0. Maven

Question: Eu tive esse problema e achei que tivesse solucionado, porem quando abri o eclipse hj o problema simplesmente voltou a acontecer, o estranho é que o mesmo só ocorre dentro da IDE, pois se eu compilar e colocar o war no wildfly o mesmo executa sem problemas.
O problema fica ainda mais estranho devido ao fato que quando entro em "projeto -> propriedades -> project facets" o "Dynamic Web Module"  está definido como 4.0
segue o arquivo de configuração do projeto que tem tal informação, chamado "org.eclipse.wst.common.project.facet.core.xml":
<?xml version="1.0" encoding="UTF-8"?>
<faceted-project>
  <fixed facet="wst.jsdt.web"/>
  <installed facet="wst.jsdt.web" version="1.0"/>
  <installed facet="java" version="1.8"/>
  <installed facet="jst.web" version="4.0"/>
  <installed facet="jst.jsf" version="2.2"/>
  <installed facet="jst.jaxrs" version="2.0"/>
</faceted-project>

meu pom.xml:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>br.com.lsoft</groupId>
  <artifactId>gamesapi</artifactId>
  <packaging>war</packaging>
  <version>0.0.1-SNAPSHOT</version>
  <name>gamesapi Maven Webapp</name>
  <url>http://maven.apache.org</url>
  <dependencies>

    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>

    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>javax.servlet-api</artifactId>
        <version>4.0.0</version>
        <scope>provided</scope>
    </dependency>

    <dependency>
        <groupId>javax.servlet.jsp</groupId>
        <artifactId>javax.servlet.jsp-api</artifactId>
        <version>2.3.1</version>
        <scope>provided</scope>
    </dependency>

    <dependency>
        <groupId>org.wildfly</groupId>
        <artifactId>wildfly-spec-api</artifactId>
        <version>13.0.0.Final</version>
        <type>pom</type>
    </dependency>

  </dependencies>
  <build>
    <finalName>gamesapi</finalName>

    <plugins>

        <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
              <source>1.8</source>
              <target>1.8</target>
            </configuration>
        </plugin>

    </plugins>

  </build>
</project>

web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
    id="WebApp_ID"
    version="4.0">

  <display-name>Archetype Created Web Application</display-name>

  <welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>index.htm</welcome-file>
    <welcome-file>index.jsp</welcome-file>
    <welcome-file>default.html</welcome-file>
    <welcome-file>default.htm</welcome-file>
    <welcome-file>default.jsp</welcome-file>
  </welcome-file-list>
</web-app>

ja tentei baixar o eclipse novamente, pensando que talvez a versão que eu tinha pego estava com problema, porem não adiantou
não faço ideia do que pode estar acontecendo, alguém sabe me dizer o que poderia estar causando isso????
IDE: eclipse
projeto: maven(maven-archetype-webapp)
segue o link do post que criei anteriormente:
https://cursos.alura.com.br/forum/topico-como-fazer-o-build-e-executar-pela-ide-79891
Answer: Altere no arquivo org.eclipse.wst.common.project.facet.core.xml a facet jst.web para 3.0 ou desejada:
<installed facet="jst.web" version="3.0"/>

Altere também seu web.xml as informações do deployment descriptor (o atributo version e o schemaLocation) para refletir a versão desejada:
<web-app xmlns="http://java.sun.com/xml/ns/javaee"   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   xsi:schemaLocation="http://java.sun.com/xml/ns/javaee   http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"      version="3.0">

Você pode encontrar aqui(artigo em inglês) mais deployment descriptors.


Solving a nonlinear algebraic system representing the equilibrium of a system of ODEs

Question: Given the following system:
$$ a_1+(a_3+a_4)V-a_5WX = 0 \\
(a_7+a_4)Y-a_6WZ = 0 \\
a_2-W(a_4+a_5X+a_6Z)+(a_3+a_8)V+a_7Y = 0 \\
a_5WX-(a_3+a_8+a_4)V = 0 \\
a_6WZ-(a_7+a_4)Y = 0 $$
where $a_1$ to $a_8$ are positive constants and $V,W,X,Y,Z$ are positive-valued variables, is it possible to solve by hand for $V,W,X,Y,Z$ in terms of the constants?
The only nonlinear terms in the system are $WX$ and $WZ$, and $X$ always occurs with $W.$
I have tried many things to solve this (i.e., Matlab and Maple), but am not getting explicit solutions for all, even though I have $5$ equations in $5$ variables. I always get one free variable.
I would appreciate help.
Answer: Your second and fifth equation are equivalent.  This might be immediately clear from the first display below.
From $$\begin{align}
    a_1 + a_3 V + a_4 V - a_5 WX &= 0 & (1) \\
    a_4 Y + a_7 Y - a_6 WZ &= 0  & (2) \\
    a_2 + a_3 V + a_8 V - a_4 W - a_5 W + a_7 Y - a_6 WZ &= 0 & (3) \\
    -a_3 V - a_4 V - a_8 V + a_5 WX &= 0 &(4) \\
    -a_4 Y - a_7 Y + a_6 WZ &= 0 & (5)
\end{align}$$
eliminate $WX$ and simplify some obvious things, yielding $$\begin{align}
    a_1 &= a_8 V  & \text{ from (1) and (4)}\\
    a_2 &= -a_3 V - a_8 V + a_4 W + a_5 W + a_4 Y  & \text{ (3) + (5) }\\
    a_6 WZ &= (a_4 + a_7) Y  & \text{ from (2) or (5) }
\end{align}$$
We're down to three equations in four unknowns, so there will be a free variable.  Also, this system is extremely simple to finish by hand.