Jump to content

Програмери

Оцени ову тему


Препоручена порука

И да заборавих рећи, јесте тешко научити 10 језика, они који раде комерцијалне апликације и гдје се свака грешка плаћа знају врло добро о чему причам.

U pravu si.
Pametne telefone sam koristio od kad su se pojavili. Razlika na primer u aplikacijama u njima je velika.
Razlika je u svemu.
Prvo sam kotistio symbian i i dalje je kao doxa. Teze pada, aplikacije ozbiljnije i rade kako treba. Winmobile necda komentarisem pogotovo ovo sto su napravili od njega.
Ali dolazi Android u koga se neki nazovi strucnjaci kunu. Otvoren kod ali 99%aplikacija neozbiljno uradjeno. Problem je i sto kad neko radi sam aplikaciju a nema klijenta treba da ima znanje u dizajnu aplikacije. Mislim na onaj degde treba da zna sta ce u njoj ljudima trebati, koje opcije treba da sadrzi, intuitivno uradjen, a ne uradio sam nesto pa ipak to radi i JA SAM PROGRAMER.
Kao sto u obicnom zivotu vidimo mnogonih koji kazu ali znanja nemaju tako i u programiranju.
Ozbiljni, pravi programeri rade za zahtevne klijente.

Sent from my SM-G7102 using Pouke.org mobile app

Link to comment
Подели на овим сајтовима

  • 2 weeks later...

Драго ми је да има пајтоноваца овде. Ја стигох до класа мада сам претходно заглавио na closuresima  (synthetic shugar) и нисам баш најбоље скапирао ,,како?``. Иначе ми је први језик за сада, тако да и не могу да кажем да је лак за учење..Ал забаван свакако јесте.

Link to comment
Подели на овим сајтовима

пре 1 минут, Давор73 рече

Ја стигох до класа мада сам претходно заглавио na closuresima  (synthetic shugar) и нисам баш најбоље скапирао ,,како?``

Шта те тачно мучи?

Link to comment
Подели на овим сајтовима

Пре свега енглески изгледа...Направио сам мали излет ван књига из којих учим па сам натрчао на ,,тврдо``.Одгледах гомилу туторијала на ову тему а и даље не могу да похватам да ли си клоужури функција у функцији (што мислим да јесу, и то донекле и разумем) или функција као атрибут (ово је колико сам скапирао тзв. синт. шугар) . Код овог потоњег се дебело мучим како да изведем. Одрадим нешто папагајски али није то то...

Link to comment
Подели на овим сајтовима

  • 8 months later...
пре 42 минута, Иван ♪♫ рече

Šta mislite da je budućnost i u šta ulagati vreme i znanje? Ja kontam machine learning. Mada i internet of things postaje popularan, pa možda bude i embedded stvari. Šta mislite?

Питање од милијарду долара... :)

Рекао би да ће AI бити велика ствар. Пре свега примена за решавање конкретних проблема.

Link to comment
Подели на овим сајтовима

пре 9 часа, Иван ♪♫ рече

Šta mislite da je budućnost i u šta ulagati vreme i znanje? Ja kontam machine learning. Mada i internet of things postaje popularan, pa možda bude i embedded stvari. Šta mislite?

Још jедан глас за machine learning. 

Ево једног занимљивог осврта на тему:

https://medium.com/@karpathy/software-2-0-a64152b37c35?source=linkShare-d1bebb948740-1515477894

Link to comment
Подели на овим сајтовима

Шта знам, то је оно што очекујем у блиској будућности (10г рецимо), да добије већу заступљеност у индустрији. Мада ти кад погледаш, нема ту ништа спектакуларно ново у задњих некоколико деценија, само расте хардверска моћ, и смањују се димензије, па ствари могу из теорије да пређу у праксу и/или коначно сиђу у народ. Не очекујем неке нарочите промене генерално, односно постојећа знања и вештине неће изгубити на значају, само ће се мењати форма, као и до сад.

Link to comment
Подели на овим сајтовима

  • 2 weeks later...

Making Money Using Math

Modern applications are increasingly using probabilistic machine-learned models.

 

Erik Meijer 

 

Цитат

Erik Meijer has been working on "democratizing the cloud" for the past 15 years. He is perhaps best known for his work on, amongst others, the Haskell, C#, Visual Basic, and Dart programming languages, as well as for his contributions to LINQ and the Reactive Framework (Rx).

 

"If Google were created from scratch today, much of it would be learned, not coded." —Jeff Dean, Google Senior Fellow, Systems and Infrastructure Group

 

Machine learning, or ML, is all the rage today, and there are good reasons for that. Models created by machine-learning algorithms for problems such as spam filtering, speech and image recognition, language translation, and text understanding have many advantages over code written by human developers. Machine learning, however, is not as magical as it sounds at first. In fact, it is rather analogous to how human developers create code using test-driven development.4 Given a training set of input-output pairs {(a,b)|a∈A,b∈B}, guess a function f∈A➝B that passes all the given tests but also generalizes to unspecified input values.

A big difference between human-written code and learned models is that the latter are usually not represented by text and hence are not understandable by human developers or manipulable by existing tools. The consequence is that none of the traditional software engineering techniques for conventional programs (such as code reviews, source control, and debugging) are applicable anymore. Since incomprehensibility is not unique to learned code, these aspects are not of concern here.

A more interesting divergence between machines and humans is that machines are less arrogant than humans, and they acknowledge uncertainty in their code by returning a probability distribution or confidence interval of possible answers f∈A➝ℙ(B) instead of claiming to know the precise result for every input. For example, a learned image-recognition function by a major cloud provider will predict with 95 percent certainty that I have hair, but is less confident about whether or not I am professional (figure 1).

E1yjJjG.png

The implication of incorporating learned models in human-written code is that you cannot get around the fact that the building blocks from which humans compose applications are fundamentally probabilistic. This is a challenge for mainstream programming languages, which all assume that computations are precise and deterministic. Fortunately, the 18th-century Presbyterian minister Thomas Bayes anticipated the need for dealing with uncertainty and formulated Bayes's rule6:

ℙ(A|B)*ℙ(B) = ℙ(A&B) = ℙ(B|A)*ℙ(A)

As it turns out, Bayes's rule is exactly what the doctor ordered when it comes to bridging the gap between ML and contemporary programming languages.

Many of the mathematical explanations of Bayes's rule are deeply confusing for the working computer scientist, but, remarkably, when interpreted from a functional programming point of view, Bayes's rule is a theorem about composability and invertibility of monadic functions. Let's break down Bayes's rule piece by piece and rebuild it slowly based on developer intuition.

Probability Distributions

First let's explore what probability distributions ℙ(A) are. The Wikipedia definition, "a probability distribution is a mathematical description of a random phenomenon in terms of the probabilities of events," is rather confusing from a developer perspective. If you click around for a bit, however, it turns out that a discrete distribution is just a generic list of pairs of values and probabilities ℙ(A)=[A↦ℝ] such that the probabilities add up to 1. This is the Bayesian representation for distributions. Isomorphically, you can use the frequentist representation of distributions as infinite lists of type dist∈[A] such that as ngets larger, sampling from the collection and counting the frequencies of each element

from a in dist.Take(n) group by a into g select g.Key↦g.Sum()/n

approximates the Bayesian representation of the distribution. When converting from the Bayesian to the frequentist implementation, the probabilities do not have to add up to 1, and the sampling process will ensure that the ratios are properly normalized.

Like true mathematicians, we will silently switch between these two representations of distributions whenever convenient. Unlike mathematicians, however, to keep things simple we will not consider continuous distributions. We want our distribution to hold generically for any type A, and most of the types we deal with in code are discrete and not "measurable" or real number-like.

Because the values we care about are usually not even comparable, we will also avoid cumulative distributions. One reason that mathematicians like standard continuous distributions— such as Gaussian, beta, binomial, and uniform—is because of their nice algebraic properties, called conjugate priors.2For example, a uniform prior combined with a binomial likelihood results in a beta posterior. This makes 18th- and 19th-century probabilistic computations using pencil and paper feasible, but that is not necessary now that there are powerful computers that can run millions of simulations per second.

In programming examples, distributions typically come from outside data as discrete frequentist collections of data with an unknown distribution, or they are defined explicitly as a Bayesian representation by enumerating a list of value/probability pairs. For example, here is the distribution of weight of adults in the United States, according to the CDC (Centers for Disease Control):

CDC∈ℙ(Weight) 
CDC = [obese↦0.4, skinny↦0.6]

Цитат

Efficiently sampling from composed distributions is, indeed, rocket science. Just like database query optimizers, advanced sampling methods leverage properties of the leaf distributions and the structure of the query9 or program3 that computes the distribution. It leverages deep and complex mathematical techniques such as importance sampling, Metropolis-Hastings, Markov chain Monte Carlo, and Gibbs sampling that are far outside the scope of this article but that are important for making real-world computations over probability distributions feasible. As Bayesian analysis consultant John D. Cook remarked "... Bayesian statistics goes back over 200 years, but it didn't take off until the 1980s because that's when people discovered practical numerical methods for computing with it..."

To illustrate the sophistication involved in efficiently sampling known discrete distributions, imagine converting the example distribution CDCinto a frequentist representation.8

Perhaps the most obvious method stacks the columns for skinny and obeseon top of each other and draws one random number—say, p—between 0and 1 and then checks if p ≤ 0.4 yields obese, and otherwise yields skinny. In general, this search is linear in the number values in the distribution, but using tricks like binary search tree can speed things up. Mathematicians call this the inverse transfer method.

Another way is first to select a random integer—say, weight—to select between obese and skinny, and then choose a random double between 0and 1—say, p—and if CDC[weight] ≤ p, then yield weight, as shown in figure 2. Mathematicians call this algorithm rejection sampling, and as the histogram shows, half of the attempts to sample a value from the distribution will fail (the pink part). This can be improved by picking a tighter envelope distribution, like that in the second histogram, but that still rejects 2 out of 12 samples.

The last method pads the lower probabilities by borrowing from the higher probabilities. Amazingly, it is always possible to do this in a way such that every column represents the probabilities for, at most, two values, so we need only one comparison to pick the right value. This comparison can be implemented using a second index table, and hence mathematicians call this sampling algorithm the alias method.

MPi8Ujv.png

Conditional Probability Distributions

Now that we have explained probability distributions ℙ(A), let's examine conditional probability distributions ℙ(B|A), which, according to Wikipedia, are "a measure of the probability of an event given that (by assumption, presumption, assertion, or evidence) another event has occurred." To developer ears that sounds exactly like a function A➝ℙ(B) that returns a distribution, just like a learned model. The remainder of this article uses the notations ℙ(B|A) and A➝ℙ(B) interchangeably.

Going back to the example, we have the following model Doctor∈ℙ(Food|Weight)of food preference, given weight, that we could have obtained by asking patients what kind of food they consume:

Doctor∈ℙ(Food|Weight) = Weight➝ℙ(Food) 
Doctor(obese) = [burger↦0.9, celery↦0.1] 
Doctor(skinny) = [burger↦0.3 celery↦0.7] 

As argued in the introduction, these probabilistic functions, such as ℙ(Object|Image)ℙ(Text|Audio)ℙ(Spam|Text), etc., are increasingly the result of training some ML algorithm or neural net, instead of being coded by expensive and flaky human developers.

Now that you know that conditional probabilities are probabilistic functions, things are starting to get interesting, since this means that multiplication (*)used in Bayes's rule is an operator that applies a probabilistic function to a probability distribution as a parameter—that is, it has the following type signature:

ℙ(B|A)*ℙ(A)∈ℙ(A&B)

Using the Bayesian representation of distributions, you can implement a probabilistic function application likelihood*prior where likelihood∈ℙ(B|A) and prior∈ℙ(A), using the following correlated query:

likelihood*prior = 
   from a↦p in prior 
   from b↦q in likelihood(a) 
   select (a,b)↦p*q 

Applying this definition to compute the result of Doctor*CDC, we obtain the table shown in figure 3 for the joint probability distribution ℙ(Food&Weight).

QiCqGB3.png

Because the distributions for ℙ(Weight) and ℙ(Food) appear in the margins of this table, mathematicians call them marginal probabilities, and similarly the process of summing up the columns/rows is called marginalization. When computing a joint distribution using (*), mathematicians often use the name likelihood for the function and prior for the argument.

The beauty of the frequentist representation is that there is no need for multiplying probabilities. Sampling ensures that the underlying ratio of occurrence of values in the result will automatically reflect the proper product of values from the prior and likelihood. For example, if we implement the prior CDC by an infinite collection with odds obese:skinny = 4:6, and the result of Doctor(skinny) by an infinite collection with odds burger:celery = 3:7, and, respectively, that of Doctor(obese) by a collection with odds burger:celery = 9:1, then sampling from the infinite collection Doctor*CDC, which results from applying the prior to the likelihood, will have a ratio (obese:burger):(obese,celery):(skinny,burger):(skinnny:celery) = 36:4:18:24.

The keen reader will note that (*) is a slight variation of the well-known monadic bind operator, which, depending on your favorite programming language, is known under the names (>>=)SelectMany, or flatMap. Indeed, probability distributions form a monad. Mathematicians call it the Giry monad, but Reverend Bayes beat everyone to it by nearly two centuries.

Note that as formulated, Bayes's rule has a type error that went unnoticed for centuries. The left-hand side returns a distribution of pairs ℙ(A&B), while the right-hand side returns a distribution of pairs ℙ(B&A). Not a big deal for mathematicians since & is commutative. For brevity we'll be sloppy about this as well. Since we often want to convert from ℙ(A&B) to ℙ(A) or ℙ(B) by dropping one side of the pair, we prefer the C# variant of SelectMany that takes a combiner function A⊕B∈C to post-process the pair of samples from the prior and likelihood:

likelihood*prior = 
   from a↦p in prior 
   from b↦q in likelihood(a) 
   select a⊕b↦p*q 

Now that we know that (*) is monadic bind, we can start using syntactic sugar such as LINQ queries or for/monad comprehensions. All that is really saying is that it is safe to drop the explicit tracking of probabilities from any query written over distributions (i.e., the code on the left in figure 4 is simply sugar for the code on the right, which itself can be alternatively implemented with the frequentist approach using sampling).

RlDXveT.png

Another way of saying this is that we can use query comprehensions as a DSL (domain-specific language) for specifying probabilistic functions. This opens the road to explore other standard query operators besides application that can work over distributions and that can be added to our repertoire. The first one that comes to mind is filtering, or projection as the mathematicians prefer to call it.

Given a predicate (A➝?), we can drop all values in a distribution for which the predicate does not hold using the division operator (÷):

ℙ(A)÷(A➝?)∈ℙ(A) 
prior ÷ condition = from a in prior where condition(a) select a 

The traditional division of a distribution ℙ(A&B) by distribution ℙ(B) can be defined similarly as

joint ÷ evidence = 
   λb.from (a,b) in joint from b' in evidence where b=b' select (a,b) 

We can show that (f*d)÷d = f. Applying the latter version to Bayes's rule results in the following equivalence:

ℙ(A|B) = ℙ(B|A)*ℙ(A) ÷ ℙ(B)

In practice, it is most convenient to use query comprehensions directly instead of operators, and write code like this:

posterior∈ℙ(C|B)=B➝ℙ(C) 
posterior(b) = 
   from a in prior 
   from b' in likelihood(a) where b = b' 
   select a⊕b 

Whichever way you spin it, this is incredibly cool! Bayes's rule shows how to invert a probabilistic function of type ℙ(B|A) = A➝ℙ(B) into a probabilistic function of type ℙ(A|B) = B➝ℙ(A) using conditioning.

When function inversion is applied to the running example, the probabilistic function PredictWeightFromFood∈ℙ(Weight|Food) can be defined as follows:

PredictWeightFromFood∈Food➝ℙ(Weight) 
PredictWeightFromFood(food) = (Doctor*CDC) ÷ (_ = food) 

Removing all syntactic sugar and using the value/probability pairs implementation amounts to the following probabilistic function:

PredictWeightFromFood∈Food➝ℙ(Weight) 
PredictWeightFromFood(burger) = [obese↦36, skinny↦18] 
PredictWeightFromFood(celery) = [obese↦4, skinny↦42] 

In practice, most monads have an unsafe run function of type ℙ(A)➝M(A) that teleports you out of the monad into some concrete container M. Mathematicians call this the forgetful functor. For distributions dist∈ℙ(A), a common way to exit the monad is by picking the value a∈A with the highest probability in dist. Mathematicians use the higher-order function arg max for this, and call it MLE (maximum likelihood estimator) or MAP (maximum a posteriori). In practice it is often more convenient to return the pair a↦p from dist with the highest probability.

A simple way to find the value with the maximal likelihood from a frequentist representation of a distribution is to blow up the source distribution ℙ(A) into a distribution of distributions ℙ(ℙ(A)), where the outer distribution is an infinite frequentist list of inner Bayesian distributions [A↦ℝ], computed by grouping and summing, that over time will converge to the true underlying distribution. Then you can select the nth inner distribution and take its maximum value.

WeightFromFood∈Food➝[A↦ℝ] 
WeightFromFood food = PredictWeightFromFood(food).Run().ElementAt(1000) 

Using the query-style DSL for composing and conditioning probabilistic functions is great, but it falls short of being a real programming language with arbitrary control flow, loops, try/catch blocks, recursion, etc. Since distributions are a variant of the continuation monad, it is possible to integrate probabilistic computations into a regular imperative language similar to the async await syntax that is now available in many programming languages. An example of an imperative probabilistic programming language is WebPPL (http://webppl.org), which embeds the distribution monad into regular JavaScript. In WebPPL, the running example looks as follows:

var cdc = function() { 
   return Categorical({ ps: [4, 6], vs: ["obese", "skinny"] }) 

  
var doctor = function(weight) { 
   if("obese" == weight) 
      return Categorical({ ps: [9, 1], vs: ["burger", "celery"] } }) 
   if("skinny" == weight) 
      return Categorical({ ps: [3, 7], vs: ["burger", "celery"] } }) 

  
var predict = function(food) { 
   var weight = sample(cdc()) 
   var food_ = sample(doctor(weight)) 
   condition(food == food_) 
   return weight; 

The assignment + sample statement

var a = sample(prior) 
... rest of the program... 

is exactly like the query fragment

from a in prior 
... rest of the query ... 

and randomly picks a value a∈A from a distribution prior∈ℙ(A). The condition(p)statement corresponds to a where clause in a query.

To "run" this program, we pass the predict function into the WebPPL inference engine as follows:

Infer({method: enumerate, samples: 10000}, function(){return predict("burger")})

This samples from the distribution described by the program using the Inferfunction with the specified sampling method (which includes enumeraterejection, and MCMC) that reifies the resulting distribution into a Bayesian representation.

Applications Of Probabilistic Programming

Suppose ordinary developers had access to a probabilistic programming language. What scenarios would this open up?

If we take a step back and look at a typical web or mobile application, it implements the standard reinforcement learning design pattern shown in figure 5. We have to predict an action to send to the user, based on the user's state and the dollar value extracted from the user, such that the sum of the rewards over time is maximized.

Iszqqwo.png

For games such as AlphaGo,10 the agent code is often a neural network, but if we abstract the pattern to apply to applications as a whole, it is likely a combination of ML learned models and regular imperative code. This hybrid situation is true even today, where things such as ad placement and search-result ranking are probabilistic but opaquely embedded into imperative code. Probabilistic programming and machine learning will allow developers to create applications that are highly specialized for each user.

One of the attractions of IDEs (integrated development environments) is autocomplete, where the IDE predicts what a user is going to type, based on what has been typed thus far. In most IDEs, autocomplete is driven by static type information. For example, if the user types ppl, the JetBrains Rider IDE shows all the properties of the string type as potential completions, as shown in figure 6.

QVCDLwD.png

Note that the completion list is shown in deterministic alphabetical order, rather than being probabilistically ranked using some learned model based on which methods on string are the most likely in the given context. Hence, the IDE should implement autocomplete using a probabilistic function autoComplete∈ℙ([Completion]|Context) that returns a distribution of possible completions based on the current user context.7 Another recent application of ML and probabilistic programming in the compiler space is to infer pretty-print rules by learning from patterns in a large corpus of code prettyPrint∈ℙ(String|AST).5

For an example application of exposing the representation of distributions, let's revisit the feedback loop between user and application. Assume in this case that we want to determine the optimal title for this article that would maximize click-through on the ACM Queue website. That is, should we use "Probabilistic Programming for Dummies" instead of the current title "Making Money Using Math"?

In this case, we create the model shown in figure 7, the set of all users as a conditional distribution of a user clicking on the article given the title:

user∈ℙ(Click|Title)

n3dmtjB.png

Note we do not want to make any a priori assumptions about the underlying distributions other than the frequentist stream of clicks received, given the frequentist stream of titles served to the users.

The agent in this case wants to find out over time which possible title for a story will generate the most clicks from the users, and hence we will model the agent by the higher-order function that takes the users and from that creates a distribution of titles:

agent∈(Title➝ℙ(Click))➝ℙ(Title)

Mathematicians call the implementation of user a Bayesian bandit,11 and they leverage the fact that Bernoulli and beta distributions are conjugate priors.12They call the variant of the run function we will be using Thompson sampling.1

When viewed from a computer scientist's point of view, the operational solution is relatively straightforward. We convert the user behavior that returns a distribution of clicks user∈Title➝ℙ(Click) into a function Title➝ℙ(Title&Click↦ℝ) that returns a distribution of pairs of titles and clicks using run as explained earlier (this corresponds to the beta distribution part of the algorithm. We do not track the "uncertainty" about ℙ(Click), but we can easily compute that together with the click probability if that is useful). A small tweak is needed in that we are interested only in clicks that are true, and not in those that are false (this is the Bernoulli part of the algorithm).

This allows us to observe how the probability that the user will click on each title evolves over time as we see more clicks from the users. Whenever we need to produce a new title, we use the Title for which the most recent Title&Click↦ℝ has the highest probability (this is the Thompson sampling part of the algorithm). In other words, the Bayesian bandit is essentially a merge sort over the reified underlying probability distributions of the clicks from the users.

The computational model underneath modern applications such as self-driving cars, speech and image recognition, personalized recommendations, etc. is changing from classical deterministic computations to probabilistic machine-learned models. Currently, building such applications requires deep knowledge and expertise of the underlying details of the ML algorithms using custom tools. 
 

Conclusion

Probabilistic programming aims to democratize the application of machine learning by allowing regular programmers to incorporate ML in general-purpose programming languages without friction. As illustrated in this article, from a semantics point of view, a probabilistic language simply adds the probability monad to the set of ambient side effects and leverages Bayes's rule to compose and condition probability distributions. Efficiently implementing probabilistic languages and providing the proper software engineering tooling, however, will keep compiler and programming-language experts busy for a long time.

References

1. Agrawal, S., Goyal, N. 2012. Analysis of Thompson sampling for the multi-armed bandit problem. Journal of Machine Learning Research: Workshop and Conference Proceedings 23; http://jmlr.org/proceedings/papers/v23/agrawal12/agrawal12.pdf.

2. Fink, D. 1997. A compendium of conjugate priors. Montana State University; http://www.johndcook.com/CompendiumOfConjugatePriors.pdf.

3. Goodman, N. D. 2013. The principles and practice of probabilistic programming. Proceedings of the 40th annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages; http://dl.acm.org/citation.cfm?id=2429117.

4. Norvig, P. 2015. Machine learning for programming. InfoQueue; https://www.infoq.com/presentations/machine-learning-general-programming.

5. Parr, T., Vinju, J. 2016. Towards a universal code formatter through machine learning. Proceedings of the ACM SIGPLAN International Conference on Software Language Engineering; http://dl.acm.org/citation.cfm?id=2997383.

6. Paulos, J. A. 2011. The mathematics of changing your mind. New York Times Sunday Book Reviewhttp://www.nytimes.com/2011/08/07/books/review/the-theory-that-would-not-die-by-sharon-bertsch-mcgrayne-book-review.html.

7. Raychev, V., Bielik, P., Vechev, M. 2016. Probabilistic model for code with decision trees. Proceedings of the ACM SIGPLAN International Conference on Object-oriented Programming, Systems, Languages, and Applications; http://dl.acm.org/citation.cfm?doid=2983990.2984041.

8. Schwarz, K. 2011. Darts, dice, and coins: sampling from a discrete distribution; http://www.keithschwarz.com/darts-dice-coins/.

9. Ścibior, A., Ghahramani, Z., Gordon, A. D. 2015. Practical probabilistic programming with monads. Proceedings of the 2015 ACM SIGPLAN Symposium on Haskell; http://dl.acm.org/citation.cfm?id=2804317.

10. Silver, D., et al. 2016. Mastering the game of Go with deep neural networks and tree search; https://gogameguru.com/i/2016/03/deepmind-mastering-go.pdf.

11. Stucchio, C. 2013. Bayesian bandits—optimizing click-throughs with statistics; https://www.chrisstucchio.com/blog/2013/bayesian_bandit.html.

12. Wikipedia. Conjugate prior: discrete distributions; https://en.wikipedia.org/wiki/Conjugate_prior#Discrete_distributions.

 

Izvor

Link to comment
Подели на овим сајтовима

  • 6 months later...

Придружите се разговору

Можете одговорити сада, а касније да се региструјете на Поуке.орг Ако имате налог, пријавите се сада да бисте објавили на свом налогу.

Guest
Имаш нешто да додаш? Одговори на ову тему

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Чланови који сада читају   0 чланова

    Нема регистрованих чланова који гледају ову страницу

×
×
  • Креирај ново...