thegoodfellas/blogset-br huggingface dataset:
com a bola "VERMELHA"???Ok! Vamos la entao...E comum vermos uma crianca correr atras de uma bola verde e emitir respostas verbais como: "Olhem que bonita a minha bola vermelha!". Isso pode ocorrer simplesmente porque anteriormente a crianca foi reforcada por seus pais ao emitir a reposta verbal "vermelho" em relacao a uma bola que era realmente vermelha. Como sua nova bola verde possui diversas propriedades comuns a sua outra bola (tamanho, forma, etc.), e que ainda nao foram selecionadas por estimulos discriminativos e reforco diferencial, e normal que a crianca emita essa resposta verbal. Quando tais procedimentos forem aplicados, a crianca passara a responder adequadamente ao estimulo "vermelho".Podemos tambem reforcar a crianca por todos os comportamentos relacionados ao estimulo vermelho (reforco diferencial de um estimulo discriminativo: o vermelho) sem reforcar os comportamentos relacionados as outras propriedades fisicas da bola (isso provocara extincao, ou seja, o termino dos comportamentos relacionados a tais propriedades). Desse modo teremos uma abstracao, isto e, a crianca agora pode dizer "vermelho" sem vinculacao a outras propriedades de estimulo.O curioso e que muitos poderiam dizer que a crianca teve uma falha no processamente de informacao frente ao estimulo "vermelho". Entretanto, uma analise funcional nos revela que o ambiente selecionou o comportamento sem que precisassemos atribuir um papel causal a "cognicao".
aquilo que resta quando o que foi aprendido e esquecido"."Society attacks early, when the individual is helpless"."A sociedade tende a atacar, quando o individuo esta vulneravel". "A failure is not always a mistake, it may simply be the best one can do under the circumstances. The real mistake is to stop traying"."Uma falha nao e sempre um erro, pode ser simplesmente o melhor que alguem pode fazer sob as circunstancias em que se encontra. O real erro e parar de tantar". "The real problem is not whether machines think but whether men do"."O verdadeiro problema nao e se as maquinas pensam, mas se os homens tambem o fazem"."We shouldn't teach great books; we should teach a love of reading"."Nao deveriamos ensinar grande livros; deveriamos ensinar o amar pela leitura"."I did not direct my life. I didn't design it. I never made decisions. Things always came up and made them for me. That's what life is"."Eu nao dirigi minha vida. Eu nao fiz projetos. Eu nunca tomei decisoes. Coisas sempre vem a mim e acontecem pra mim. Isso e a vida"."If you're old, don't try to change yourself, change your environment"."Se voce e velho, nao tente mudar a si proprio, mude seu ambiente". LINUS PAULING"A melhor maneira de ter uma boa ideia e tendo muitas ideias".
contexto da entrevista por sua efetividade e adequacao ao estilo de personalidade do paciente. TERAPEUTA: Voce chegou aqui hoje e disse que estava pensando em reunir-se com uns amigos para bater no Claudio. Pediu minha opiniao, mas voce ja parece ter vindo com uma opiniao formada a respeito...CLEITON: (Olha um pouco zangado)TERAPEUTA: Na verdade, percebo que voce esta muito zangado nesse momento Cleiton, mas voce precisa ver que esse momento vai passar, mas o mesmo nem sempre ocorre com as consequencias de nossas acoes...TERAPEUTA: Voce lembra do que me disse da ultima vez em que tomou uma atitude semelhante?CLEITON: E, o desgracado do Sergio (uma rixa semelhante a atual que tem com Claudio) tinha uns amigos de farda, e eles vieram nos dar uma surra. Ai a gente se ferrou...TERAPEUTA: Exatamente.CLEITON: E, mas dessa vez nao vai acontecer...TERAPEUTA: Como pode ter tanta certeza?TERAPEUTA: Voce tem o habito de dizer isso, que as coisas nao ocorrem com voce. Mas ambos sabemos que as coisas nao funcionam assim...TERAPEUTA: Sua namorada discutiu muitas vezes com voce e por fim terminou com voce por causa disso, lembra?TERAPEUTA: Terminou por causa desses comportamentos.CLEITON: (O paciente fica em silencio; parece sentir-se contrariado, mas reconhece o argumento como valido).CLEITON: E, e foda, ela era boa de cama e fazia umas piadas engracadas.TERAPEUTA: Pois e. Me diga as coisas negativas que ocorreram com voce das ultimas vezes.CLEITON: Argh! Sei la, tomei multa aquela vez la na estrada pra Porto Alegre, tomei um coro dos seguranca da festa, e teve os caras de farda que eu falei. E perdi a guria tambem.TERAPEUTA: Sim, nao esta se esquecendo de nada?CLEITON: (Fica serio em silencio).TERAPEUTA: Voce tambem ganhou a inimizade de alguns caras que antes eram seus amigos, e tambem, terminou no hospital.TERAPEUTA: Voce gostaria mesmo de mais alguns problemas agora que esta indo tao bem no trabalho novo?CLEITON: E e. Mas agora so nao vai e vir me dizer que o cara tem mulher e filhos porque eu estou cagando pra eles. Quem mandou se meter comigo, esse filho da puta...TERAPEUTA: Eu nao estou dizendo isso Cleiton, e nem vou dizer, ate porque sei que voce nao e do tipo que adora criancas...CLEITON: (Ri)TERAPEUTA: Ainda assim, ha consequencias que nao afetam so a ele, mas tambem a voce. E quanto mais voce investe nisso, mais problemas voce tem.TERAPEUTA: Voce ja esteve preso ha alguns anos e corre o risco de ir pra a cadeia de novo, mas dessa vez a justica pode nao pegar tao leve com voce...TERAPEUTA: E dessa vez, o que voce acha que pode te acontecer?CLEITON: Sei la. Ah e, me disseram que o cara (Claudio) anda armado tambem. Mas eu nao tenho medo!TERAPEUTA: Percebo que voce e um cara corajoso, mas eu me pergunto se ele (Claudio) vale a pena?TERAPEUTA: Quando voce chegou aqui hoje, voce disse que ele te chamou de tudo que e nome. Mas se ele e um cara tao desgracado, pra que perder tanto tempo com ele. Nao vai me dizer que e apaixonado por ele ne? (terapeuta fala em tom de brincadeira)CLEITON: Que
isso cara, ta me estranhando?TERAPEUTA: (Sorri)CLEITON: Porra, vai te fude!.CLEITON: (Fica quieto por um tempo e comeca a rir).TERAPEUTA: (Ri)CLEITON: (continua rindo)TERAPEUTA: Pois e, sinceramente nao vejo porque perder tempo com isso. Mais vale voce investir o tempo no seu novo trabalho e conquistar aquela gatinha 2 de quem estava falando outro dia, lembra? E uma boa forma de nao perder o tempo...CLEITON: (Ri)CLEITON: Ta safo cara, e, tu finalmente resolveu falar minha lingua hoje.CLEITON: Foda-se o cara...CLEITON: Ta, ta safo, nosso tempo terminou por hoje, to indo (ainda rindo um pouco).CLEITON: (Ve o tempo terminando e se levanta pra sair)CLEITON: (Se direciona para a porta sorrindo)TERAPEUTA: Juizo Cleiton, juizo... Ate porque quero te ver inteiro pra proxima sessao... e quero saber como foi com a Juliana (a gatinha a quem o terapeuta se referiu anteriormente).REFLEXAO: O aconselhamento visou modificar o humor de Cleiton e persuadi-lo para que ele nao tomasse nenhuma atitude impulsiva, o que e comum nesse paciente. O estilo de personalidade utilizado pelo terapeuta e valido como estrategia de intervencao em um caso atipico (para maiores informacoes, pesquisem o livro: Psicoterapia cognitiva dos transtornos de personalidade - Aaron T. Beck e colaboradores).
uma. Mas essa reflexao serve simplesmente para mostrar que o ambiente desempenha um papel fundamental naquilo que fazemos.As criancas em nossa sociedade se comportam como o fazem porque foram determinadas a isso. Ate certa idade as criancas costumam brincar muito no chao. Uma possibilidade e que elas deixam esses comportamentos de lado na medida em que diversos reforcadores sociais e disposicao fisica dos objetos (tais como moveis) sao adaptados para a altura do adulto. Conforme a crianca fica maior com a idade, ela continuar brincando se arrastando no chao sera mais dificil, pois o ambiente fisico nao esta mais adaptado a sua altura. Desconforto fisico ja seria um bom exemplo de estimulo punitivo que reduziria a probabilidade de ocorrencia de certos comportamentos (punicao) e a retirada desses estimulos aumentaria a probabilidade de ocorrencia de outros comportamentos em seu lugar (reforco negativo).Em resumo, as criancas tornam-se adultas nao so por fatores maturacionais, mas porque seu corpo nao e mais reforcado ou punido pelas propriedades de diversos estimulos e por que os adultos sao os principais responsaveis pela disposicao das contingencias que as afetam. Os adultos as definem nao so porque detem o monopolio de diversos reforcadores infantis, mas tambem porque o monopolio da punicao; e todos sabemos que as criancas nao encontram defesa contra alguem absolutamente mais forte.Refleti tambem as razoes pelas quais e mais facil exercer controle sobre as pessoas em um discurso quando o orador se encontra em posicao elevada a seu publico (ex: o politico falando no palanque). E possivel que isso em parte ocorra porque em nossa historia pregressa, os adultos exerciam grande poder sobre nos, e eles e claro, sao mais altos.Para quem quer uma fonte de inspiracao para estudar a teoria comportamental, assistam aos filmes...
Belem como: O Estado do Para, A Provincia do Para, A Folha do Norte, A Semana, Belem Nova, A Tribuna Academica e A Palavra. Educador emerito que contribuiu para a boa formacao de muitos jovens da nossa terra. Vamos comemorar!!! Na programacao das comemoracoes teremos o 1o Soletrando da Escola Gabriel Lage e o Concurso Cultural de Poesias que vao ser realizados no dia 19/04/2013, com direito a bolo e parabens! As turmas premiadas vao ser contempladas com uma sessao de cinema.Participem!
No setimo FISL, assisti uma palestra sobre uma iniciativa do pessoal do KDE para revolucionar o desktop. Os conceitos apresentados la foram muito interessantes, comparando o desktop atual no Linux com uma simples copia do primeiro desktop, lancado ha 22 anos pela Apple, com poucos detalhes a mais. O que e um fato visivel.Como alternativa, o palestrante trouxe algumas ideias para tentar aproximar o computador do usuario final: drag-n-drop por todo desktop, eliminacao das barras, uma melhor comunicacao das informacoes para o usuario, e alguns detalhes esteticos - como preferencia por bordas arredondadas. Tudo em nome da similariedade com o mundo real. Icones devem ser mais descritivos e dizer o que contem, alem das acoes que podem ser feitas com ele. Ate ai, muito bom, mas nao diria que e um desktop que eu utilizaria.A ideia que ficou no ar, para mim, foi com relacao aos objetivos do projeto: e nobre tentar modificar o desktop para torna-lo mais simples de usar, mas ha tambem a usabilidade trazida por outras inovacoes, que estao sendo feitas em gerenciadores como o Pwm, o Ion, o Ratpoison e o wmii. As ideias destes ja evoluiram por um bom tempo, e apresentam ate certa maturidade: janelas non-overlapping, gerenciamento de frames, tabs ou ate tags em vez de simples workspaces, pouca necessidade de se utilizar o mouse, e varias outras.Talvez juntar ideias como um desktop mais facil de usar, mais eye candy e mais plugavel, com um sistema de janelas non-overlapping, uma filosofia UNIX para configurar e gerenciar o desktop, e com acessos rapidos via teclado para controlar qualquer funcao do ambiente, traria uma sinergia muito maior que as simples vantagens das duas abordagens somadas. Este poderia ate ser o ambiente grafico ideal para o Linux: alem de atender aos usuarios iniciantes e que desejam desktops simples de usar, poderia ser usado tambem pelos jockeys de teclado; sejam os administradores de sistemas ou apenas experientes usuarios, que passaram a dominar a interface grafica com o tempo e que aumentaram a sua produtividade por conhece-la melhor.Uma ideia ambiciosa, mas a tecnologia base ja esta ai e desenvolvida: e necessario "apenas" colocar a mao na massa e integrar tudo. So resta saber se e algo viavel.E e isso. Some time ago, Linus Torvalds have written some comments about the C++ language. It's hard to disagree with Linus in the point that C++ is a horrible language, but I find much harder to agree that C is a better language than C++ - even counting some "non-technical advantages" cited in the article.C++ language is about structures and abstraction. Big projects, like GNU or Linux, tend to recreate that kind of structure over C when good programming techniques are involved, facing things like generic containers which cannot be type checked and inhability to use some very useful paradigms - just to start naming a few disadvantages. Reducing the benefits of the language to things like "nice object-oriented libraries" or the design of "object model crap" is just buying OO gook - which does not stand for C++ as what it can be,
but for what it is when used by Java programmers. You can dislike virtually any language by bad programs and bad programmers which use it - even C - so this should not count when considering the merits of a language.Talking about the real advantages of C++ over C, some essential points come to my mind:You can define behaviours inside structures (or classes, if you prefer the sound of the name), and encaplusate what data will be accessible and what data will be opaque to the rest of the program. This allows you to define libraries for each needed feature/resource of your program (converting text encodings, manipulating strings, processing config files, etc) and combine them easily, reusing the code as needed. You can even use those advantages without objects, defining structures with only static methods;Memory management is something you will never leave you wake at night again, thanks to references. You can always assume that a reference would exist and be initialized, even a reference being essentially a pointer. That gives you the advantages of passing mutable values to functions, without needing to know where you would need to deallocate them. Manual memory allocation/deallocation with new/delete can be so scarce that you will count in your fingers how many manual allocations you will need to have in your program - even for projects with size bigger than 20.000 LOC.The critics used by Linus are actually very interesting, as they fit C as a glove. Let's talk about each one individually:> infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)This is actually real, STL and Boost give absurd template errors when you make coding mistakes, and they also may throw unwanted runtime exceptions if you use something incorrectly. The only real solution for the first is to fix the language (maybe 10 years from now) or to gain experience with C++ -- when you are a experienced C++ programmer, you learn to deduce what is wrong in your code based on the error messages. The second may be solved by documentation, or by searching at the library source code for "throw" clauses.These two problems are bad design decisions made when the language got those features - unfortunatelly, they still remain. But the main point here - or, being more dramatic, the real important point - is that the first problem (template error messages) is a compile-time error, while the second (if you consider checked exceptions) can be solved at compile time.In C, when your program does not work, the OS generates a nice "Segmentation fault" in the screen, which leaves you totally clueless, and with infinite piles of pain. I prefer that my programs just compile if they are right in the sense of "not crashing", and that the compiler - not the user - should verify that. The funniest thing is that you may have the same problems of C in C++, but only because you can program
in C while using C++. Finally, in my little experience of portability, I used both STL and Boost mainly in two operational systems (a little time in Windows XP, and the rest in tons of GNU/Linux distributions), and never had ANY problem compiling code in any of those systems, even using different compilers and compiler versions. Probably C++ compilers have evolved in the mean time, as they got mature projects.> inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.Sorry, but this argument is senseless: you can abstract anything incorretly in ANY language. And as far as my experience of programming goes, the pain of rewritting and application is much more severe in C than in any other language that can be called "high-level".Other common argument against C++ that I hear often (and that I've already used, while programming in an embedded environment), is that it is not as efficient as C - mostly because of the abstractions involved in the langage libraries. That is a fact, actually: conventional C++ libraries usually are bigger than writing your own set of C function for dealing with your problem, and memory consumption will be much higher than allocating everything manually and statically.However, it should be noted that good abstractions need good compilers, which can do good code optimizations. Recent GNU C++ compilers showed how a compiler can affect a language performance when new optimizations algorithms started being used. It is also important to mention that if you have a library written in C++, and you want to write the same thing in C, it would be bigger to codify, harder to maintain, and - specially if the library is some kind of container - unable to be checked for safety in the same extent C++ can.For embedded environments, or things that need critical per-instruction optimization, the best choice is always C or assembly: you can garantee the compiler won't get in your way, neither the code will run in an undefined time length. But for application programming, the only excuse for not using C++ is using a better language - whose group, C does NOT belong.And that's it.
Sacodindo a poeira do blog: encontrei uma entrevista com o criador da STL, falando sobre como concebeu a mesma, sobre paradigmas de programacao, e sobre linguagens de programacao em si.Adiantando, as melhores partes sao quando ele fala que:a) concebeu a STL durante uma infeccao bacteriana;b) a orientacao a objetos e um hoax;c) de todas as linguagens que ele aprendeu, Java e uma das poucas que nao acrescentou nada de novo ao que ele ja sabia.Ou seja: leitura altamente recomendada.E e isso. O FISL deste ano me deu uma ideia interessante. Observando todos aqueles programadores de Perl, PHP, Java fazendo palestras, e os programadores de Python, orgulhosos por o serem, citando a beleza do codigo da linguagem como uma das principais vantagens, pensei submeter um artigo para palestrar no proximo forum: programacao funcional e/ou logico-funcional, e as ferramentas SL disponiveis para utilizar esta tecnica.A principal motivacao talvez seja, num espaco onde muitos nao sao da computacao e conhecem apenas algumas ferramentas empurradas^W^H propostas pelo mercado e/ou criadas por icones da comunidade, mostrar que ha alternativas muito melhores e atuais para solucionar os problemas, de maneira simples, pratica, e com uma composibilidade muito melhor. Isso, claro, sem contar a fortissima base matematica por tras destas linguagens, o que facilita a formalizacao da mesma.Eu choveria no molhado se repetisse todo o que esta escrito aqui, especialmente a parte de verificacao, paradigmas de programacao e recursos das linguagens de programacao modernas (que e a parte pertinente para este post). Entao, aproveito para recomendar a leitura.Por enquanto, so tive umas ideias de algumas coisas importantes para comentar, e de como estruturar uma apresentacao desse tipo, que deve falar em linhas gerais sem tornar o conteudo massivamente tecnico ou fazer com que pareca uma aula de programacao funcional/logica. Se o projeto evoluir bem, em um proximo post trago mais informacoes, e possivelmente um "sumario" dos itens a tratar. Aberto a sugestoes, claro!E e isso. I am deeply thinking about starting to post in English here.Although I may not have the best skills to do so, and the posts will have some more delay - and more typos - I'm still very inclined to embrace the wider audience this might bring to the blog. There are not much portuguese speaking geeks hanging around there that have similar views about programming languages (specially ML or Haskell variants), that want to research in the same fields or have the same topics of interest that I do, and there is even less geeks that want to exchange information about personal experiences in the area.It's not very rewarding to open up this page every day and see little (or no) feedback. So, from now on, I will bring some posts translated into English, in an attempt to check if it's worth the effort. Some portuguese posts might still appear in a near future, but that's far from clear right now.Viewers are welcome to leave comments.See ya! Yesterday I was working on o project I've started sometime ago, for sending and receiving GSM audio over a socket (a client/server skype). I was implementing a
ring buffer, to be used by the encoder/decoder, the audio library (PortAudio) and the socket reading/writing function, when I started to wonder how could I make it really concurrent, and easy to understand.The first ring buffer was a C++ struct which simply copied the values inside and outside a pre-alocated memory area, in a thread safe way. The minor input / output for the GSM codec is 33 bytes / 160 shorts (320 bytes), so I started with a templated buffer which stored N values of type T. There was two functions for accessing the buffer:1 void consume(value_type &buffer);2 void produce(const value_type &buffer);These functions consume/produce one value_type at each call, copying the value inside 'buffer' to the write position of the ring buffer, or copying the value on the read position of the ring buffer inside 'buffer'. But that was not good enought.The second try involved a way to use the ring buffer directly, without copying buffers around. For that these functions arised:1 void consume_ptr(const value_type **buf);2 void consume_commit();3 4 void produce_ptr(value_type **buf);5 void produce_commit();The functions ending with 'ptr(..)' have a special meaning attached: they do not copy buffers, but return the pointer to the actual position of the ring buffer - according to the requested operation. If you want to write to the ring buffer, 'produce_ptr(..)' returns a pointer to a buffer which must be filled with values. When done, user must call 'produce_commit()' so that pointer is forwarded and sleeping threads are awaked. The 'consume_ptr(..)' function does the same, but in opposite way: buffer must be read, and after that, 'consume_commit()' must be called.But if I want to pass a function to the "produce" and "consume" of my ring buffer, which would be called receiving the needed pointer as argument, and whose return would automagically call the respective commit function? You can make this in C++, with functional objects. You'll get an interface like this:1 template <class T>2 struct Ringbuffer3 {4 template <class F>5 void produce(F f);6 7 template <class F>8 void consume(F f);9 }To use this feature, you'll need to make a code like this: 1 [...] 2 struct ring_read_abc 3 { 4 typedef Ringbuffer<short> R; 5 6 void operator()(R::value_type *v) 7 { /* send v via socket */ } 8 } 9 [...]10 int tmp1, tmp2;11 ring_read_abc::R rb;12 rb.produce(ring_read_abc());13 [...]The problem about this approach is simple: looking at the above example, you can see that the operator() has no access to the context where produce was called. It cannot access tmp1 or tmp2, for instance. For that, you'll need to pass the arguments in the constructor of the ring_read_abc struct. This "glue code" can beat very hard concepts of "separation of concerns" when you want to nest two or more calls to functional objects, using the interface above.The fourth interface goes beyond C++, and uses some features only present in functional languages. For that end, the Ringbuffer could have the same functions "produce" and "consume", each one receiving a function as argument, which made the interface like this (using Objective Caml syntax):1 type buffer = int array2 3