Home

Feedback

FAQ

Getting Started

Discussions

Site operation discussions

Recent Posts

(new topic)

Departments

Courses

Research Papers

Design Docs

Quotations

Genealogical Diagrams

Archives

pLogo anyone?

FD n wouldn't move the turtle n units. It would move it n+/- 10% (with a normal distribution around n, say). So,

REPEAT 4 [FD 50 RT 90]

wouldn't make you a perfect square all likely.

But, natrually, I want this probabilistic behaviour to be "all the way down," and not specific to FD (for starters RT should be probabilistic to, of course :-)

Of course, you need constructs that will allow you to write reliable code in the presence of noisy behaviour from prmitives. I can think of a couple of possible approaches for dealing with this aspect of the language design.

Why?

More to the point, it is well known that people aren't thatgreat when it come to probabilistic reasoning. Why not provide kids with a place to improve their intuition?

Is it just that adults commonly suppose themselves to have better things to do with their time?

No, it's just that adults are usually beyond help (and hope).

people aren't that great when it come to probabilistic reasoning

Why do Frequency Formats Improve Bayesian Reasoning? Cognitive Algorithms Work on Information, Which Needs Representation

Especially in engineering, where measurement is also imprecise, this means that instructions need to be self correcting. So instead of FD 1000, you'd rewrite it as FD 10, ... check bearings, ... correct, ... and then move again. Perhaps this could be part of 1st year programming curriculum for engineers.

A great deal of school learning tends to deal with precise data. $2.00 + $3.00 . et. c, but in the real world, you have to factor in quality of debt, et c..

It would be interesting to run a pilot and see if it improves qualitative reasoning?

Exactly. You'd want the child to be able to discover this idea for himself (but notice that the checking operations might also be noisy).

Yeah, that's pretty much the idea.

This isn't a full language, but you might be interested in Sungwoo Park's "A Calculus for Probabilistic Languages".

_{I figure it's time to shed the lurker status and register an account. Greetings to Dave Herman, by the way, and thanks for the monad write-up.}

In some ways, this idea is reminicent of McCarthy's ambiguity operator. Both introduce an element of non-determinism.

<off-topic> Hi Andrew! Your profile doesn't have an email address - drop me a line and say hi (my web address is in my profile, and you can find my email address from there). </off-topic>

It's pretty clear when you play with something like this that kids will hate it (I sure did). You try to draw a house, but nothing works as expected... Which helps us think more carefully about the language design.

Suppose we had a button with which to control just how feeble minded the turtle actually is. At first the turtle would be sharp, and behave as expected. But later we can run our procedures with turtles that are more and more feeble minded (i.e., the probability distribution is wider or the probability of error is larger). At what point exactly does the drawing become a total mess? Can we make our procedures more robust? (the child asks, hopefully)

Now we can think about running to turtles in parallel - an exact one, and a feeble minded one [we want a construct to capture this pattern].

There's more to tell, but I am not sure anyone else is interested in this trivial experiment.

But while you are here: does anyone know of a version of the PLT turtle package which supports different pen colors, hiding the turtle, and absolute positioning (move-to-x-y)?

I have written a monadic turtle package that uses OpenGL, and therefore support different pen colours and absolute positioning (it doesn't display a turtle). It is part of the lsystem package you can find at PLaneT: http://planet.plt-scheme.org/

These noisy actuators turn the deterministic world into a Markov Decision Process. I don't know if that is interesting to you but there is a lot of literature on planning and learning in MDPs

"Mondaic turtles" - must say I love the ring of that...

"A Semantics for Logo, or, Turtles All the Way Down"

Still don't grasp what you want to do with it. Turtles with build-in PID controllers, or something? Is that it?

Why would we need a new language for this? Isn't it enough to make certain libraries probabilistic? For some deranged reason, schools seem to love torturing kids with Java, yet Java is surely powerful enough to make a probabilistic turtles library.

You can easily make a library or proabilistic turtles - that's what I described above. But is that really useful enough?

Suppose you want the child to discover that he can speculatively run several turtles and average their behavior, in order to achieve greater accuracy. If it's in the context of a library we need to provide relevant procedures (get-tutrtle-pos etc.) But the building blocks are rather low-level. It might be nicer (and yes, these are *design* decisions) to provide higher level constructs such as eval which evaluates exp n times, from the same starting position. How about eval! which doesn't change the drawing but keeps other side effects (so can save info about the end-position of the turtle, perhaps).

These higher level operations can also be part of a library (if you have high order functions they pose no real difficulty). But perhaps providing syntax to cover patterns you think are important is a better way to go.

Keep in mind that the distinction between language design and library design is rather arbitrary, if you discard syntactic issues and use a powerful enough language. For example, Logo is a language, yet PLT Scheme as well as many other languages provide tutrtle graphics libraries.

Logo is more that just turtle graphics, I know.

This is not for kids as far as I know, but it looks like an interesting sort of probabilistic computing: HLSIM

Well, if all you're after is some language to play with to get some more intuition about probabilities and such I think Torben Mogensens domain specific language for die rolling, called Die, should suit you well. The design of the language is not perfect but it works. The evaluator can both run the programs or calculate the probablities of the various outcomes.

I'll take a look.

My first thought about what a "probablistic" language would be, involved "random variables". In the sense that rather than having "exact values", a value is instead a probability distribution function describing the likelihood of it being close to particular value. This comes from my EE background where in some of my classes we started replacing component values in a circuit with random variables(e.g. 2Kohm resistor, + or - 10%, Gaussian distribution), and then did circuit analysis with these fuzzy values, which produced random variables as the output.

Of course, Markov processes and "fuzzy state machines" started popping into my head as well.

Then I remembered my idea for a spell system for an online RPG I had a while back. The system was based around kind of a data flow, and each component was connected to others and operated on its inputs, with probabilities for correct output or "reversed" output(i.e. failure). The idea was a truly powerful system allowing spells like "Kill Everyone", but also making the probability for failure so high, that more likely, the earth would open up and swallow you instead. I dunno if this may be more like what you were talking about or not, just offering some suggestions.

My first thought about what a "probablistic" language would be, involved "random variables". In the sense that rather than having "exact values", a value is instead a probability distribution function describing the likelihood of it being close to particular value. This comes from my EE background where in some of my classes we started replacing component values in a circuit with random variables(e.g. 2Kohm resistor, + or - 10%, Gaussian distribution ), and then did circuit analysis with these fuzzy values, which produced random variables as the output.

The running example is precisely the computation of the impedance of a simple circuit. I should have made the Random numbers into the Num and Fractional classes so that we can use the conventional arithmetic operators *, -, etc.

We have designed a DSEL for probabilistic programming in Haskell. In addition to the Monte Carlo method employed by the parent example, our system allows the entire distribution to be computed if desired. Also, I should point out that the example given (the impedance) doesn't seem to make well use of the monad. In our system, either a Monte Carlo or full distribution computation of the given example could be done with:

impedance inductance capacitance freq resistance = do in Our system can be found on-line at http://web.engr.oregonstate.edu/~erwig/pfp/.

Our system can be found on-line at http://web.engr.oregonstate.edu/~erwig/pfp/.

Also, I should point out that the example given (the impedance) doesn't seem to make well use of the monad.

impedance inductance capacitance freq resistance = do in <- inductance ca <- capcacitance fr <- freq r <- resistance return ( sqrt ( ((fr * in) - 1 )**2.0 + r**2.0) )

impedance inductance capacitance freq resistance = sqrtM $ (sqrM (freq `mul` inductance) `sub` ((return 1) `divM` (capacitance `mul` freq))) `add` (sqrM resistance)

impedance inductance capacitance freq resistance = sqrtM $ (sqrM (freq * inductance) - (1 / (capacitance * freq))) + (sqrM resistance)

The expressions look different -- but in appearance only. Once we notice that mul is defined as liftM2 (*), we see that the "do" form is equivalent to the "do-free" form. The random-var-monad article showed that we can compute the arbitrary number of moments of the distribution, that is, we compute the whole distribution. Jerzy Karczmarczuk pointed out (in the cited post to comp.lang.functional) how to compute the distribution analytically, by approximating source distributions by combinations of Gaussians.

mul

liftM2 (*)

When I saw this thread pop up again I came to think about CFDG which were mentioned previously on LtU. That could be a fun language to play with for kids perhaps.

You might be interested in the Stochastic Lambda Calculus. This was presented at POPL'02 and is over my head -- not sure about your kids :-).

## Recent comments

2 days 11 hours ago

4 days 6 hours ago

2 weeks 1 day ago

3 weeks 11 hours ago

4 weeks 9 hours ago

5 weeks 5 days ago

6 weeks 1 day ago

7 weeks 2 days ago

7 weeks 5 days ago

7 weeks 5 days ago