Start of topic | Skip to actions
This page contains the scribe notes for the Fall 2008 COMP 617 seminar. The scribe should add a new heading and section below on this page, or attach a separate file to this page. The heading or the file should then be linked from the course schedule.

09/03/2008: How to Give Good Presentations

Speaker: Walid

  • We should get two clocks for the DH 3110 conference room, and mount them on facing walls. That way, the speaker and the audience can easily keep track of time.
  • Cherif was asked to help the speakers with the setup of the projector. The newly introduced time keeper is now helping with the setup of the projector.
  • We used the talk feedback forms for the first time
    • There were two questions with errors:
      • The question "Did the speaker have enough things to say in the allocated time?" should have "Yes (1) No (0)".
      • The last question "Did the talk get you interested to learn more about the subject?" should have "Yes (1) No (0)".
    • In the response to the question "How did the speaker express his/her point?", we should say in our own words what we believe was the main point of the presentation.
    • We should number the questions, and add a place for the score on the first page: "___ / n", where n is the total number of questions.
  • We decided to have a separate time keeper, so we need to add a third column to the schedule and assign the job of time keeper to the participants.

-- MathiasRicken - 03 Sep 2008

09/05/2008: Verilog: Array Bounds Checking

Speaker: Cherif

Checking for Synthesizability

  • Verilog description, maybe with abstractions, is fed to the type checker, then to the preprocessor to produced an elaborated verilog description.
    • The type checker ensures that neither the preprocessing nor the synthesis can go wrong.
    • The final product is well-typed, abstraction-free, synthesizablke, has no wire mismatches

Example of synthesizability edge cases

  • buses of different sizes are assigned (connected together)
    • input size < output size: pad output with zeros
    • input size > output size: discard some bits in input
  • is it really sensible to call this synthesizable?

Corky: do circuit designers think this synthesizability is OK? Kapil: not really, but you get warnings Walid: problem with warnings is that it's hard/menial to figure out which ones are important and which ones aren't.

Correct synthesis

  • We want correct synthesis; previous examples are probably bogus.
  • Type checker should ensure correct synthesis.
    • For size-mismatches, add explicit coercion

Challenges

  • parameters, array indices, etc complicate type checking

Strategy

  • generate constraints for certain operations
  • see if the constraints are always satisfiable (provable) given assumptions from declarations and signatures
  • satisfiability is checked by Yices, an SMT solver

  • From signal declarations, we can derive the max and min indices for each bus
  • The index ranges and the negations of the constraints are turned to Yices formula: Yices says "unsat" if the constraints cannot be violated (i.e. if the circuit is OK)

Mathias: (wrt Ex.1) forall isn't necessary for this partciular example, right? Cherif: actually you do. Walid: We're trying to find counterexamples (with the goal of showing there isn't any) so we need to universally quantify.

Limitations

  • Yices limitations
    • No min/max
    • Only linear arithmetic
    • Support for quantifiers incomplete
      • Cherif: I actually ran into this.
  • Constraint generation limitations
    • Loop invariants are hard to infer

Current Status

  • Type checker & preprocessor updated
  • constraint generator working
  • Still testing Yices

Walid: All listeners are to keep time themselves and record them onto the sheet separately, independently.

Corky: What's in Yices? Presburger arithmetic? Perhaps linear programming solutions is better. This one works with rationals, which entails the integers .

Ed: Do you need all the power of a full SMT? Cherif: I started writing my own, but completed SMT solvers can just do more than I could implement. It's hard to find a system that exactly fits the requirements. I need to look for one.

Kapil: What about 2-dimensional arrays? Cherif: Problem is that 2-dimensional arrays can easily lead to non-linear constraints.

Kapil: How to calculate module signature? Cherif: generated from module name and parameters. Unused input will not be eliminated.

Ed: Said array bounds checking but you're really doing wire-size checks. Cherif: They come down to the same thing.

Walid: I think it was a good talk. Some issues with main point. Some people had questions as to what the main point was. Personally, I think you should focus on the designer's perspective. What does all this work mean to the hardware designer? That's the main thing we should communicate to them.

SMT was stated without definition. Beginning was too fast. Make it as accessible to a wide audience.

09/08/2008: Internship Report

Speaker: Hisham

  • Intro
    • AUB last year student
    • Interested to pursue graduate studies
    • Hands-on experience
    • Worked on two-projects with Dr. Walid Taha at Rice

  • Project 1: Testing the Monty Python Compiler
    • More than 150 test scripts
    • Preparing benchmarks to be tested
    • Hunted bugs
    • Major bugs reported
      • Printing floating point numbers
      • echo()
      • xrange()
      • No support for finally
      • No support for exec() and eval()
    • Bugs are hard to find
      • Example 1: Division by complex zero
        • Mathias: are you sure it's not a parenthisizatio issue?
        • Hisham: Yes I am sure
        • Walid: What was the source of the bug? How was it solved?
        • Hisham: My job was reporting bugs
      • Example 2: abs call on values returned from cmath
      • Exmaple 3: Array length (the maximum length of arrays in OCaml is hardcoded)
    • Gained
      • Learned Python and functional language programming through Ocaml
      • Exposure to real-life problem
      • Testing is important, finding bugs is tricky
      • Reducing bugs to one-liners
      • Developed a Tetris game with Yilong using Python
  • Project 2: FPGA Programming
    • 8-point FFT for Spartan-3 Starter Kit
    • Trade-off between speed and resources
    • Command and Conquer, butterfly graph
    • N-point FFT requires log2N stages
    • Could be reduced to only one stage with stage-reuse
      • Walid: This needs to be checked
    • Learned
      • Verilog, Xilinx tools
  • Discussion:
    • Mathias: Isn't there a correctness test suite that is used to accept that the compiler is correct
    • Hisham: This was my first intuition and I was told that one existed but I searched hard for one on the official python site in vain
    • Walid: There is one included with the distribution but it relies on reflections and other features we opted not to support

    • Angela: Are there any FFT benchmarks you could compare your implementation against?
    • Hisham: Yes but this is still work in progress

    • Walid: Good talk. You did a great job testing python with Yilong. It's amazing how far you have gone without knowing any of the internals of the compiler. This is almost the opposite of what verification people do. Maybe you should have focused your talk on the first project only since the second one is still in a very early phase.

09/10/2008: Verifying Multi-Stage Programs

Speaker: Jun

  • Intro
    • Verification is an important way to make sure the program is correct.
    • Program generation is an useful method to improve programming productivity, however, it usually makes the program not very efficient and slow during execution.
    • Multi-stage programming is an important technique to improve the speed of generated program.
  • Subject of today: how to verify multi-stage programs.
    • Walid: I like the diagram (of the verification framework).
  • What is staging.
    • &lt, &gt produce code.
    • ~ escape the program from inside code.
    • Example 3 should be x*(x*1) instead of x*x*1
  • Slide 5: how to verify
    • Walid: This pages shows the results that you came up with, so you should make it clear (that its your results).
  • Slide 6:
    • Jun said verification of termination for staged program is trivial. Matthias suspects that. Jun change the word trivial to straightforward.
  • Slide 7:
    • Jun used two examples to illustrate that staging annotation can change termination properties.
  • Slide 8:
    • Walid: it is good if you can show the reduction semantics here, at least mention there is a semantics for reduction. It is mainly three rules:
      • run cancels brackets.
      • escape cancels brackets.
      • function was left as before.

  • Q & A
    • Angela: Do you need to verify that staging annotations are added correctly? * Jun: The type checker will take care of this. Only correct programs will type check. * Walid: For pure functional language, once the program survives from type checking, it is guaranteed to terminate.
    • Eddy: Forth item on slide 5: What do you mean by the annotation doesn't affect result? * Jun: Here the result means the return value of the program. The return value of a program should be the same in both staged and unstaged case.
    • Eddy: Can you do the pow example with type &lt float -> float &gt code? * Walid: Yes, you can. And this is an excellent question. In general, you want to push the brackets to the leafs of the program/type. This is better, since it makes the staged program more efficient.
    • Corkey: You use structural reduction in your verification framework. Whether that will make it hard for formal proving? * Walid: Moshe has a student who just finished his master thesis. It is stated there that, in concurrent programs, observational equivalence is Holly Gray. It gains you huge benefit. * Eddy: Actually operational semantics is easier to be formalized in Coq.
  • Conclusion:
    • Walid: This is a great talk, specially for general audience.

09/17/2008 Java Type Inference is Broken: Can we fix it

Speaker: Daniel smith

  • Start with a type inference example:
        Iterable <Herbivore> hs2 = Util.<Herbivore>Compose()

        E var = method(A1,...,Am);
        <> R method(F1,...,Fm) {...}
        Pi extends [Pi]
  • Inference Algorithm:
    1. Traverse structures/supertypes of Ai and Fi to infer simple bounds on Sigma Pj
    2. Where Sigma Pj has at least one inferred lower bound, L1,...,Lp, choose Pj -> join(L1,..,Lp)
    3. For all other Pj
  • Broken? Java Language Specification (JLS)
    • Poorly specified, contains a number of bugs
    • Is inconsistent with implementations including javac
    • Is unsound (by design)
    • Is incomplete (by design)
    • Prohibits some useful language features
       Integer <: Number
       ArrayList<Integer> <: List <Integer>
       List<Integer> </: List<Number>
       List<Integer> </: List <? extends Number>
       List<Number <: List <? super Integer>
  • Bugs: Examples
    • Example program that typechecks but causes a ClassCastException? at run time
  • Unsoundness/Incompleteness
    • 2 bullets
    • 2 corresponding example
    • In the second example the heuristic algorithm will infer "Object" while "Number" is a better value to infer (more intuitive) and in fact javac is inconsistent with the specification algorithm and infers "Number"
  • Prohibited language features
  • proposals:
    1. Define formally correct join
    2. Disjunctive constraints
    3. Eliminating Recursive References (the only source of incompleteness remaining in the proposed solution)
    4. Using Context always
  • Conclusion:
    • Problems in inference algorithm in spec. Propose to replace it with one that is sound and complete.
    • How will this affect existing programs
  • Q&A
    • Eddy: The big C in your slides are type or class?
      • Daniel: It means class.
    • Eddy: Is the type inference is also broken?
      • Daniel: In some sense, yes.
    • Eddy: What do you mean by implementation not consistent with specification, have you checked them?
      • Also some of the implementation is not open source, we found a way to know how it is implemented.
    • Jun: When you propose use "or" operator in your method, will that cause P-space complexity problem?
      • Daniel:
  • Suggestions
    • Jun: When using examples to a broad audience, try to make it example driven rather than syntax driven.
    • Corky: You should tune your talk to the context of the audience, especially in case there may be people not familiar with Java.
    • Walid: Problem description takes too much time.

09/19/2008 Synthesis of Verilog Descriptions

Speaker: Kapil

Verilog is C-like HDL

Can be described at

  • behavioral
  • register transfer
  • gate
levels

Workflow is like:

  • English spec
  • executable program (abstract behavior)
  • sequential machine (behavior on each clock tick)
  • logic gates (literals, gate depth etc specified)

Verilog has constructs at different description levels

  • behavioral
    • e.g. if-else, while
  • structural constructs
    • e.g. "generate for (...) full_adder (...)" gives ripple-carry adder
  • logic gate constructs

Angela: these levels are not in correspondence with the levels described immediately before!

Eddy: I was a little lost until slide 8 also.

Walid: You seem to be trying to explain the same thing in two different ways. Don't do that. Pick 1 way of explaining things, and stick to it throughout the talk.

Hardware circuits can be

  • combinational
  • sequential
    • has memory

There is synthesis for each level

  • behavioral synthesis
  • logic synthesis
  • physical synthesis

How can be describe circuits at a high-level, while ensuring synthesizability? Challenges are:

  • Multiple ways to synthesize a single description
  • Need to satisfy multiple-level constraint
  • Algorithms for synthesis is slow

Solution

  • Language should provide generic construct to generate more code
    • generated code is always structural hence synthesizable
  • BUT, not all primitives can be implemented generically
    • could force us to describe design at low level

Non-synthesizable Verilog code

  • delay and wait are not synthesizable but required for verification
    • Walid: this is very synthesizable. The code would produce a circuit.
    • Kapil: No, we don't get a circuit we expect
    • Walid: How about just using inverters? (referring to `wait')
    • Kapil: How do you know you will have the right delay in terms of physical seconds?
  • initial, force, release, repeat et are not synthesizable

Conclusion

  • Circuits generated from high-level is always suboptimal
  • Synthesis is high-complexity process
  • Exploring uses of generic constructs to alleviate the problem

Eddy: Tell me more about your approach.

Kapil: We're designing a modified Verilog that spits out Verilog code. Cherif has already designed the language.

Walid: You've already done a lot of work independently. You should focus on your own contribution more.

Eddy: Are you going to work on a preprocessor?

Kapil: We will incorporate a preprocessor that tells you things about synthesizability.

Walid: Cherif and Kapil are working on different parts of the same system. Kapil is (intially) going to be focused on using this language and demonstrating how it can be used. Kapil did a good job of explaining the current work flow. He's trying to improve it by making the actual circuit more visible at the high level. This means you need to devise complex algorithms for the synthesis. It's sort of like type signatures.

The problem you stated was not exactly what you solved/are in the process of solving.

09/22/2008 Java Annotations for Invariant Specification

Speaker: Mathias Ricken

- Comments are typically dumb

- Example is discussed for: if a key is not mapped inside a class, then a null pointer exception can happen at run time

- we may explicitly write the "null" during object declaration but that is not compatible with Java, so a compiler error will occur

- Annotations can be used to solve the above problem but they may be supported in Java 7 only (not completely in Java 5)

- Annotations can be used as pluggable type systems

- Annotations can be used anywhere in the Java code but Local variable annotations are completely ignored by the Java 5 compiler

- Another example of Concurrency invariants is discussed: wherein it is noticed that a race condition may occur if a funtion is called from two threads at the same time

- using annotations before the declaration of a function can help us in detecting the possible race condition at run time by giving warnings. Note that it does not avoid race condition.

- In the aformentioned context, annotations are compared with assert statements in Java

- Javadoc (it is tool to produce HTML pages from java source) produces an easy to use overview of the invariants required.

- Invariant annotations are also inherited down the hierarchies in Java, i.e in all the subclasses

- Two examples are shown for inheritance of annotations in Java: one for annotation attached with object and other for annotation attached with the function

- Mathias provided some invariant annotations in java, so they are limited in number

- As we know that Assert can be used to test any arbitrary predicate, so Mathias is trying to explore that how can we make the annotations as powerful as the "Assert" statement

- Invariant annotations are linked to predicate methods that can perform arbitrary computations making the annotations as powerful as assert

- Limitations of annotations are discussed: there can be only one occurance of an annotation class per target, i.e.

Sample code showing the limitation: @OnlyThreadWithName("main") // illegal; and is @OnlyThreadWithName("other") // this "and" or "or"? void myMethod() { … }

- The problem in this code is that the same annotation is used more than once which is not allowed

- The another problem here is that it is not clear whether we should satisfy both the annotations in a logical "AND" manner or in a logical "OR" manner.

- Suggested solution is to use @Or or @And annotation explicitly but that is not easily possible as of now because of lack of subtyping for annotations in Java

- Another limitation of annotations is that the subtyping of annotations is not allowed, i.e. there does not exist any common supertype for annotations.

- Mathias changed Java compiler and named that to "xajavac Modified Compiler", which allows subtyping for annotations

- Results are shown and following things are claimed by the speaker when he provided support for Annotations with Subtyping:

- had made only minimal changes to the compiler to achieve this

- No changes to class file format

- Reduced invariant checker by ~1500 lines

- Improved code reuse

- following results are shown for Invariant Annotations:

- Annotated part of Swing and DrJava?

- Discovered and fixed some bugs in DrJava?

- Hard to do retroactively and without inside knowledge

- Mathias said: he needs to add run-time support for annotations with subtyping. He also wants to add subtyping for annotations to the prospective Java 7 compiler (JSR 308 is the prospectove compiler)

* Questionaire session:

Walid: Why cant we put annoations anywhere in the code?

Mathias: Sun just decided this

Eddy: Are the annotations just like strings?

Mathias: No, they can contain complex data as long as it is a compile time constant

Corkey said that it would have been nice to provide little more background

Many wanted to have the syntax for annotation to be early in the presentation.

Finally Walid said that it was a nice presentation.

Thanks

09/24/2008 Semantics of PhyDL?

Speaker: Angela

Intro: How to simulate physical systems Slide 2: String system. Example of a cube and spring system with mass that is expressed in code. * This problem form is known as Initial Value Slide 3: Problem. Initial Value Problem. Solution should be a function of time.

    • Mathematica cannot solve arbitrary initial value problems, but solve closed forms
Slide 4: How to find solution?
    • Numerical Method: Use a set of points to represent time (E.g. Euler); Straightforward but imprecise
Walid: What is error?: Angela: (Explained order). You want order to be big so it makes smaller error. Order refers to n-1
    • Interval Arithmetic: Gives you an interval closes correct answer inside.
Corkey: Still have an inexact answer, controlling floating point. Huge mathematical jump. Walid: Using Interval Arithmetic, not only using smart operators but must look at arithmetic equation. Slide 5: How to find a solution?
    • Picard Theorem: Solution to IVP is a fixed point of an operator.
    • Use Picard operator
Angela: Not sure if an example to show how Picard use is exponential Walid: He likes this now.
    • Still not sure how to solve arbitrary function
Slide 6: Proposed Idea 1. Use numerical method to find solution 2. Estimate error and find interval valued enclosed in exact solution 3. Use Picard operator to refine the enclosure. The fixed point of the iteration should be the exact answer. Slide 7: Outline
    • Theoretical correctness of the method: Convergence based on two papers
    • Problems: How to integrate arbitrary function
Slide 8: Correctness of the Idea
    • Main solution is a fixed point that is refined from a converged solution
Slide 9: Implementation Issues
    • Global error estimation: We can use technique, but don’t rely on it
Walid: Who is they? Angela: From existing papers out that explain numerical method error. Slide 10: Conclusion and Future Work
    • Advantage of method: * Theoretic correctness is guaranteed *Method can be implemented * Fast * Indicates how much error there is
    • Problems and Future Work: * Some experiment results not satisfactory
        • Round-off errors

Corkey: If you did not have round off error, things would be easier. As you get more accuracy, need longer intervals. Not clear what method is better. Talks about a person who has looked at interval arithmetic.

Cherif: We are trying to solve an approximation using numerical methods and then doing an integration using numerical method? Angela: We aren notusing a numerical method, using a Taylor expansion. In our expansion we capture everything in interval. You can still capture error, although interval is grown. Edwin: How do you approximate f?

Corkey: It would be nice to have some theory.

Walid: Did you hear what he said? There are questions when you apply these methods. It isn’t clear what is going on in overall picture. Can’t be shown by showing what you’ve done. Important things missing.

Kapil: Does matlab have any similar functions?

Kapil What is PhyDL?

Angela: PhyDL? is program used to simulate systems

09/26/2008 State of the Art Material for Self-Teaching Java

Speaker: Richard

The talk surveys currently available self-teaching material for a complete novice, someone who has never seen Java before.

  • How do we find material to teach yourself Java?
  • Currently, it is difficult to find.

What development environments can be used? There are two broad categories:

  • command line and Notepad/TextEdit
  • IDEs like DrJava?, Eclipse

What kind of material is available? Three major forms:

  • books
  • online texts
  • video tutorials

There is was recent research done about what the best environment for novices is. Most articles address this question for advanced users.

Criteria to evaluate the usefulness of a development environment:

  • OS support: It should be available and the same on many platforms.
  • Ease of use
  • Fosters understanding of Java
  • Error correction

Evaluation of programming environments:

  • command line
    • bare minimum support
    • different from OS to OS, need to learn something different for each OS
    • no debugger
    • no graphical aids
    • no smart identing
    • hard to forster understanding of Java because of all of the other issues that come up

  • Eclipse
    • most used IDE by universities and businesses
    • available for Windows, Mac OS X and Linux
    • lots of advanced tools, shortcuts
    • novices should learn without these shortcuts, because they could create bad habits
    • has debugger, but it requires a lot of knowledge about Java already, and it is not included from the start

  • BlueJ?
    • developed for class use
    • available for Windows, Mac OS X and Linux
    • user draws programs at figures, classes are represented as icons
    • user double-clicks to add Java source
    • this allows to do much programming using the mouse
    • but without a teacher, it is hard to understand graphical layer and how it relates to Java source code
    • has error correction, but does not give good description of the type of error

  • DrJava?
    • developed for class use
    • available for Windows, Mac OS X and Linux
    • three main parts of the window
      • main frame: typing program and debugging
      • interactions: practice area and code output
      • compiler output: errors
    • forces programmer to learn syntax, there are no shortcuts
    • interactions allows the user to test confusing syntax
    • shows good error diagnostics

Which would Richard choose? DrJava?

  • good OS support
  • easy to understand w/out teacher
  • good descriptions of errors
  • forces novice to learn the syntax of Java

To compare the quality of the teaching material available, the following criteria were used:

  • setup speed: How long does it take to get started?
  • speed of learning: How fast does a student learn once he or she got started?
  • comprehension: How easy is it to understand?
  • coverage of fundamentals: How well does it cover the most important aspects?
  • quality of resource: How professional is the material produced?
  • cost: How much does it cost?

The rating scale (1-3, 3=best, covers fundamentals completely) is a bit subjective. The main arguments for the rating come from the cited article.

Result:

  • There is no clear winner among books, video tutorials and online texts.
  • We need to understand what these kinds of material do well and what they are lacking.

Books:

  • Books at top universities are more used for references, and not so much for teaching.
  • Interesting point: The recommendations at Amazon.com differ from the mostly used textbooks at universities.

  • Positive aspects of books:
    • very in-depth, with many examples
    • often cover advanced features
  • Negative:
    • often outdated
    • usually lack Java and IDE installation instructions, it is hard to get started
    • books cost money, they are not free

Video tutorials

  • Often found on YouTube?. Higher resolution videos available at special sites listed in the slides.
  • Some universities are putting their class lectures online: Stanford has a whole Java course as video.
  • There is a sharp divide between amateur-produced material and professional videos from universities.

  • Positive aspects of video tutorials:
    • start with the very beginning, provide walk-through for Java and IDE setup
    • help novices to "visually think" in Java
  • Negative:
    • time-consuming, Stanford videos are one hour per video, and the first hour just covers the syllabus
    • not geared to self-teaching:
      • 14,000 viewers for Stanford's 1st video
      • 700 viewers for the 10th video
    • YouTube? has low resolution, and amateur videos are not well produced
    • Amateur videos are shorter, but students need to watch many videos from lots of different people; there is no good correlation between the videos

Online texts:

  • many books are also going online
    • Sam's Teach Yourself Java 2 in 24 Hours
    • Thinking in Java

  • Positive aspects of online texts:
    • great coverage of Java fundamentals
    • just as good as books today
    • provide links to helpful resources
    • it is easy to get example source code
  • Negative:
    • typically don't help with setup
    • it is hard to get a visual understanding initially

What roles should these kinds of resources play in self-teaching?

  • Video tutsorials should be the "starter switch" and help students think visually in Java,
  • Then students should progress to online texts, to cover fundamentals with examples.
  • Books can serve as reference and provide additional material to study.

What questions need to be addressed when creating self-teaching material?

  • There is a lack of high quality videos for self-teaching.
  • The material should create combination of links to video tutorials, online texts and books.

Conclusion: Suggested structure for self-teaching material.

  • Video intro
    • 30 minutes
    • get students excited
    • help students get Java and IDE installed and customized
    • show how to write simple programs
  • Online texts
    • cover fundamentals
  • Perhaps an online test to let students test themselves.

Question session:

  • What are bad habits created by Eclipse?
    • Auto-completion, adding parentheses automatically lead to less thinking by programmers, and this can be bad for beginners.

  • What is the work you have done so far?
    • just created initial Wiki.

  • Have you read any of the books listed in your slides?
    • No, but Richard read book reviews, there was not enough time
    • But Richard says he does have the novice's point of view to evaluate the books properly.

  • How did you get IDE usage statistics?
    • Eclipse most used by universities
    • only BlueJ? and DrJava? developed for class room
    • checked IDEs on Wikipedia

  • What about NetBeans??
    • not for class room

  • Eddy mentioned a graphical environment developed at Washington University, St. Louis
    • could not remember name
    • start with classes visually, edit program graphically
    • so many IDEs, easy to miss one

  • How did you pick criteria on slide 16 (for comparing resources)?
    • Speed of setup vs. speed of learning: setup needs good intro (i. e. video), but for learning video is too slow
    • As you start getting towards advanced materials, video tutorials aren't available and harder to do
    • How professional? Most videos done by amateurs, noise in background.
    • How expensive? Is it available free?

  • But how did you select them?
    • Richard was teaching myself, so the criteria are based on the issues and problems he ran into.

  • What about object-oriented programming (OOP)? Design patterns? Matters of style?
    • those are advanced
    • Richard looked at the best books and video tutorials for novices

  • Aren't there lists of these things already?
    • Yes, but it's lists of books, or lists of video tutorials
    • We need a combination of these resources.
    • The existing work doesn't provide the right combination.
    • Ideally, there would be additional commentary (perhaps as video?) for difficult or confusing things.

  • Are there mailing lists that can help Java novices?
    • Richard had not considered this
    • Is there a general Java mailing list?
    • There are Sun's Java forums.

Suggestions to Richard:

  • Should state that the goal is to create a self-teaching resource, and that you did the survey to figure out what is good.
  • State whether this will this be available to Rice students or everyone.

-- MathiasRicken - 26 Sep 2008

09/29/2008 Evaluating Acumen

Speaker: Marisa

  • Introduction
    • physically safe computing: Modeling behavior of physical system. Acumen is a simulation framework
  • Goal: Evaluating Acumen
    • translate physical systems to code
  • Example: A simple pendulem
  • PhyDL?:
    • Simulation, external ridl, external matlab, boundary and system modules
  • Analysis: Usability
    • PhyDL? is straightforward, RIDL program requires some effort.
    • RIDL:
  • equations describing system 2
    • Eddy has a question regarding the direction of D.
  • Acumen code
    • Observes is ridl observes from PhyDL?
    • clock => 5*neg(1) reverse the direction.
  • Conclusion:
    • PhyDL? is easy to model physical system, RIDL needs more effort
  • Q and A
    • Eddy: PhyDL? let you express things in differential equations, it should not resort to the clock. It seems that there are more natural way to do so. The breeze is continuous, but ridl is discrete.
      • Walid: RIDL is for modeling discrete behavior, not continuous behaviors like breeze.
    • Walid: hard coding the period when breeze exists is not a good way since the period may change

10/01/2008 Gradual Typing

Speaker: Ronald Garcia

  • Introduction
    • Static (OCaml) and Dynamic (Scheme) type systems have been at odds. They have complimentary strengths. Static: More checking and safety. Dynamic: rapid development and fast adaptation. Why not have both in the same language?

  • Approach of gradual typing
    • The idea is to treat programs without type annotations as dynamically typed and incrementally add type annotations and these are statically typed. The more type annotations you add, the more static type checking can be. Typically in early development phases you might start with very few or no annotations at all but these will increase as you move forward
  • Example types without gradual typing:
      T ::= int | bool | T -> T
  • Example types with gradual typing:
    • Same as in normal typing except that you can coerce dynamic type (?) to any other type.
      T ::= ? | int | bool | T -> T
  • Statically typed Example:
      In Typed lambda calculus:
      \lambda x:int. x

      In C: 
      int f(int x) {
         return x;
      }

      In mathematical notation:
      f: int -> int
      f(x) = x

      Using map notation:
      x -> x
  • Dynamically typed example:
      \lambda x.x
  • Coercions to and from ?
    • Coerce means force
    • Example:
 
         (\lambda x.x + 1) 1
         x has type ?
         1 has type int
         + has type int*int -> int
         Because of the type of +, x is coerced from ? to int (noted ? => int)
         Also the applied 1 is coerced from int to ? (noted int => ?)
  • Coercions between compounds types
  • Gradual typing still detects type errors statically:
    • Example:
         (\lambda f:int -> int. f 1) (1)
         --> error

  • Simple type system:
    • Typing rule for application:
         \Gamma |- e_1 : T1 -> T2          \Gamma |- e_2 : T1
        ------------------------------------------------------
                       \Gamma |- e_1  e_2 : T2 
    • The equality of types can be made more explicit as follows:
         \Gamma |- e_1 : T1 -> T2        \Gamma |- e_2 : T3        T1=T3
        -----------------------------------------------------------------
                       \Gamma |- e_1  e_2 : T2 
  • Gradual type system:
    • Typing rule for application becomes:
         \Gamma |- e_1 : T1 -> T2        \Gamma |- e_2 : T3        T1~T3
        -----------------------------------------------------------------
                       \Gamma |- e_1  e_2 : T2 
    • The types must be consistent (noted ~) not necessarily equal. This is the key in gradual typing. Consistency means that types are compared structurally and they must be equal when concrete types are encountered but when a concrete type and a ? are met, they are considered consistent
    • Examples:
         int ~ int
         int not(~) bool
         int->int ~ ?->int
  • Compiler inserts run-time checks. It insert explicit coercion.
  • Main Results:
    • Gradually typed programs don't signal type errors
      • May signal cast errors
    • When a program is fully annotated graduate typing is exactly the same as full static typing.
  • Q and A:
    • Angela: Can if conditions have different types in different branches?
    • Ron: No except if you explicitly case them both to dynamic type.
    • Ed: You could write an if macro that allows that
    • Walid: can a program that is totally untyped get rejected?
    • Ron: Yes
    • Walid: I mean that Scheme programs cannot be typed in as they are
    • Ron: Yes you cannot in some cases but you can get there by adding explicit dynamic casts.
    • Kapil: What do you mean by space leaks
    • Ron: recursive functions with inserted coercions cause coercions to grow and these can be collapsed but you loose information about the source of the error because these casts embed source location information.
    • Angela: Why do the coercions grow once every two calls in the even/odd example?
    • Ron: It's because of the way the even and odd functions are defined. In fact there is a missing coercion that needs to be inserted in the even definition.

10/01/2008 Simulating a LEGO Rover in Acumen

Speaker: Yilong

Accumen is a physical simulation language, consisting of

  • PhyDL?, for the physical properties
  • RIDL, for reactions

Compare the simulated rover to rover in real live.

Split the task into smaller parts:

  • Build model in PhyDL?
    • size
    • weight
    • velocity
  • Build programs in NQC ("not quite C") and RIDL
  • Create 3D model for animation
  • Compare 3D simulation with real live data taken from rover

The Acumen Bot is LEGO Mindstorms robot with input sensors (2 touch, 1 light) and two motors.

Just a simple model for the first comparison:

  • Rover moves forward at a const velocity v until it hits an obstacle
  • When the rover touches obstacle, it begins to move backwards at negative v
  • The model uses just one dimension
  • x is the position, initially 0. The obstacle is at x = 12.
  • v is the velocity, initially 4.82 in/s (We measured the velocity of the real rover).

The LEGO Mindstorms software is too simplistic. Instead, Yilong used NQC:

  • NQC has a C-like syntax, so it is similar to other programming languages and easy to learn.
  • The NQC programs can be compiled and transmitted to the rover through a terminal.
  • There is native NQC software for Mac OS X and Linux (Mindstorms apparently doesn't provide this).

Comparison between NQC and RIDL:

  • The slides show the NQC program to control the real rover, and the RIDL program to control the simulation.

In this model, because of discretization, the rover actually runs into the obstacle; how far depends on the size of the simulation time step. Later model will be better and compute the actual point of intersection.

Used Autodesk Maya for 3D animation:

  • 3D modeling software
  • supports keyframes, used data from simulation as keyframes, Maya automatically interpolates in between
  • can create models to scale, so the simulated rover has the same dimensions as the real one
  • free version available

Mismatch between Acumen Data Rate and Maya Frames per Second:

Acumen: 3 seconds with 100 data points/s Maya: 24 frames per second Had to convert the data rate.

A comparison of the 3D animation to video of real model gives the feeling that the simulation is a good approximation.

Future work:

  • Create better PhyDL? model that can handle turning and more sensors. More complicated environments and tasks.
  • Create a way of translating NQC code directly to RIDL.

Questions:

  • Why from NQC to RIDL?
    • RIDL is a simulation of the actual software. It seemed to make more sense to go from actual programs to the simulation.
  • Would RIDL to NQC be easier?
    • Perhaps. I'll look at it.
  • When did you start learning RIDL?
    • Just a week ago.
  • Was RIDL simpler than NQC?
    • NQC is based on C, so it was not hard to learn either.
  • How did you learn RIDL?
    • I talked to Angela and looked at the documentation.
  • Have Yilong and Marisa considered working together?
    • No, not yet, but we should.

Further discussion:

Walid said:

  • Make sure to have titles on the Wiki schedule!

  • We need to make sure that our manuals are good. If someone reads the documentation, please give feedback. The people in charge of the project should then take that feedback into account.

  • In the future, the model should not just be a point, it should be the whole body (holonomic model). Feedback will be difficult. We can't just say the robot moves at 4.82 in/s, because there might be friction, wind, so we might have to measure the actual speed, location.

  • Going from RIDL to NQC might be a good idea. Roumen did work on translations from RIDL to other languages.

  • Good job using talk notes, didn't seem like you were reading off them. Next time, give it a shot to talk freely.

  • Deadlines coming up! Give feedback about abstracts. Send these comments to the mailing list.

Ron said:

  • There is an article called "Scrutiny of the Abstract". Take a look at it.

10/01/2008 Checking the Sanity of Verilog Descriptions

Speaker: Cherif

Synthesizability is not enough to guarantee good circuits.

Wire width mismatch example:

  • Input [7:0] is connected to output [8:0]
  • Verilog synthesizes code but this is most likely a bug.

Array Bounds Violation

  • Iterate 8 times on 7-bit wide bus
  • Verilog generates spurious wires that are not connected to or from anywhere, sometimes such that they waste power.

Eddy: elaboration is expensive Cherif: it is. You might not alwas find the error too.

Approach: collect constraints as to the width of the bus, the range of the index, etc. At places where they're used in conjunction with one another, feed to Yices (SMT) to see if safety conditions are satisfied.

Yices has no support for min/max. Soln 1 resolve before sending formula to Yices; Soln 2 use Yiecs's uninterp fcns and subtyping to implement min/max.

Soln2: Yices doesn't know how to compute min/max, but it can reason about it from its defining constraints on the output.

(define min::(-> x::int y::int (subtype r::int) (and (<= r x) (<= r y) (or (= r x) (= r y)))

Yices' support for quantifiers incomplete. Foralls can't be handled directly => negate (turning foralls to exists) and check *un*satisfiability.

Gathering constraints in an if statement:

Have more information in each branch than outside of it. Can detect dead code.

Loop constraints:

Inferring loop invariants is undecidable in general, but easy with enough restrictions.

  • only loops with headers of certain forms (the variable controlling termination is increasing or decreasing at a constant rate, with a reasonable termination condition)
  • these cases are easy to prove termination for

Summary: use dependent types to express properties of wires;

input [7:0] x gives x type wire(min(7,0), max(7,0))

Gather constraints (givens) from conditionals, loop invariants, etc. Then verify them with Yices.

Yices Limitations as of last presentation: no min/max (solved); support for quantifiers incomplete (solved); only linear arithmetic; constraint generation limitations

Currently have implementation that has type checker with dependent types and constratins verification. Can actually verify examples that only require operators defined in Yices proper; guarantees synthesizability

Cherif: all operators (on wires) should have dependent types but not all does. e.g. + operator. Walid: al verilog operators are array operators. Cherif: Yes. Operators for constants are not for arrays and do not have dependent types

Angela: what do you mean by estimate results Cherif: number of gates used, area and power used by generated circuits, Angela: for limitations, constraint generation limitations? Cherif: e.g. it's hard to infer invariants in general but by restricting our attention

Eddy: you said you can solve dead code? are you going to prove it? it seems hard to define Cherif: before elaboration we can guarantee that there's no dead code. module parameters are taken into account. some constraints were inconsistent when I didn't detect them so I guess I have to prove elimination Walid: eliminating all dead code is undecidable Cherif: [...] Walid: you have a specific notion of deadness then Cherif: look at a paper by Hongwel Xi on dependent types. He might have actually had the same experiences.

Kapil: you're saying everythin in hardware gets implemented anyway. what about like and(1, x)? Cherif: DCE is different from inlining/optimizing away. Conditional expressions in Verilogs must be level 0. If conds in generate construct are restricted.

Matthias: some instantiations of modules might have dead code that is actually used in other instantiations Cherif: My defn of DCE means dead in every instantiation.

Walid: we are focusing now on something more specific than synthesizability. Focus more specifically on the current work.

10/08/2008 Staged Monad Transformers

Speaker: Eddy

In this talk, Eddy discusses how to use staged monad transformers in interpreters.

Building interpreters

  • The traditional design space for interpreters looks like this:
    Abstraction <--> Performance
    Monad transformers   Hacks and kludges
    higher level, easier to maintain and debug   not maintainable, hard to debug
    lower performance   higher performance

But we want both abstraction and performance.

  • Staging reduces performance cost of abstractions.
  • Staged monad transformers are somewhere in the middle of the above spectrum.

Our contribution (Eddy's and Jun's)

  • Staged some monad transformers
  • Measured performance improvements
    • Quantified impact of monad transformers (overhead that is added to the computation itself)

What is a staged monad transformer? We should define each word:

What is a monad?

  • A monad is an abstract notion of a computation
    • e.g. mutable state, continuations, nondeterminism
  • A computation is made up of individual steps
    step1 --> step2 --> step3 --> step4 --> ...
    • perform step1
    • side effects and results are transmitted to step2
    • step2 performs in that context
    • etc.
  • Steps can return a value
    • Written: return v
      • Passes v to the next step
          v  
        step1 --> step2 --> step3 --> step4 --> ...
  • Steps can be combined into bigger steps
    • Written: bind c f
      • Value of computation c passed to function f
      • f then returns the next step depending on input
          + ------- ------- ------- +  
        step1 --> ! c --> f ! --> step4 --> ...
          + ------- ------- ------- +  
          bind c f  

A monad is:

  • A type constructor m
    • 'a m is a type of computations with return type 'a
  • A return function
    • return: 'a -> 'a m
    • take type 'a and perform a computation on type 'a
  • A bind function
    • bind : 'a m -> ('a -> 'b m) -> 'b m
    • perform the first computation and pass its result to the next

Example monad: mutable state

  • type 'a m = s -> (s * 'a)
    • take a starting state, return a value that is a pair of s and 'a
  • return x = fun s -> (s, x)
    • state remains unchanged
  • bind x f = fun s1 -> let (s2, v) = (x s1) in (f v s2)
    • state s1 passed to the computation x (x is run with state s1)
    • x returns a value and a result state, the pair (s2, v)
    • the resulting state s2 and value v are passed to computation f

Walid adds on the whiteboard:

int   (int * S)
5   St -> St', 5

The monad for an int returns 5. The monad for (int * S) returns a (potentially changed) state and =5.

Example 1: (i = ?) -> (i=17, 5)

  • The monad takes any kind of state, and returns the state 17 and 5.

Example 2: (i,j) -> (i, i+j, 5)

  • The monad takes the state comprised of i,j, and returns the state i,i+j and 5, i.e. the i part of the state remains the same, but the j part of the state gets set to the sum of i and j in the previous state.

The state monad is a transformation that can change the state and still return a value (here 5). There are important connections to sequentiality

Eddy comments about the board: We can use state just in terms of this functional language.

Trade-offs in using Monads:

  • Positive
    • encapsulation and modularity
      • write computations with high level constructs
      • monads can be debugged and maintained separately from the places where these things are used
      • Example: we can first write a monad to maintain a state, make sure that this works, and then use it elsewhere
  • Negative
    • overhead
      • each bind adds at least one function call
      • overhead = O(length of computation)

What are Monad Transformers?

  • A monad transformer takes a monad and returns another monad, i.e. it is a function from monad -> monad
  • State monad transformer
    • (T M) takes a monad M and adds the feature provided by T
    • Example: (StateT? M) is a monad M with mutable state
  • We can "mix and match" features
    • T1 (T2 M) is the monad M with the features from T1 and T2
    • T1 (T3 M) is the monad M with the features from T1 and T3

Bigger trade-off with monad transformers

  • Positive
    • increased modularity
      • define and debug features separately
  • Negative
    • each transformer adds level of indirection
      • additional function call in bind for each transformer
      • overhead = O(number of features * length of computation)

Staging to the Rescue!

  • Definition of staging: code as data
    • stage n produces code to run at stage n+1
  • We can amortize extra overhead
    • Extra work only in one stage

Staged Monads:

  • write computations with staged monads
    • This produces code with the binding operations removed,
      1. e. it runs all the operations, but doesn't have the indirections for the binds
        step1 --> step2 --> step3 --> step4 --> ...
        becomes
        step1, step2, step3, step4 --> ...

Staged operations:

  • staged operations work on code
  • we need staged versions of return and bind
  • sreturn takes code from outside the monad and turns it into code in the monad
    • 'a code -> ('a m) code
  • sbind combines code from two computations
    • ('a m) code -> ('a code --> ('b m) code) -> ('b m) code
  • staged operations = operations + staging
    • straight-forward to write

Staged monad transformers:

  • A staged monad transformer takes a staged monad and return another staged monad
    • defines new sreturn and sbind
  • We only need to add staging annotations to existing monad transformers
    • easy to write

Results:

  • staging transformers is straight-forward
    • only required to add staging annotations
    • staging took about a day
  • preliminary results
    • 2x - 3x speedup
    • not as good as expected
      • perhaps because we use byte code, not native code
      • perhaps our tests don't use special features
  • still need to work out some issues with compilers

Future work:

  • fix issues with compilers
  • get more speed-up
  • stage more monad transformers

Conclusion:

  • Staging gives us abstraction and performance
  • Staged monad transformers...
    • are as modular as monad transformers
    • offer greater performance

Questions:

  • Corky: How monad transformers and mixins compare?
    • There was a somewhat general discussion.
    • Are mixins multiple inheritance? Well, not really.
    • Mixins are parameterized classes that extend one of the type parameters.
      • class C extends T { ... }
    • Monad transformers seem to do this but use only functions.

  • Angela: When you stage monad transformers, do you stage the monad or the transformer?
    • A monad transformer takes a monad to another monad.
    • A staged monad transformer takes a staged monad to another staged monad.
    • A staged monad transformer has to define these two operations sreturn and sbind that return code.
    • Unstaged monad transformers just define return and sbind.
    • A staged monad transformer uses staged monads to create a new staged monad.
    • You have to stage the transformer too, otherwise it would take staged monads and use it in an unstaged way.

  • Corky: How does the monad type correspond to the value type?
    • A monad is a structure with a type constructor and a return and a bind, and the return and the bind have to satisfy certain properties.
    • The value type is the 'a.
    • Example: List is a type constructor. List int is a type constructor that takes a type int and creates another type that represents lists of integers.
      • So List maps types to types.
    • The monad is the constructor (like List, List actually is a monad, not further explained).

  • Corky: What is run?
    • run is not a monadic operator
    • run is defined in an ad hoc way for each monad.
    • You cannot write run generally, because monads represent computations. You need to have a start value (with state monad, define start value), and you can't do this generally.

-- MathiasRicken - 08 Oct 2008

10/10/2008: If I Had Known Then What I Know Now: Lessons from an LLC

Speaker: Adam Wulf

Overview: Details of starting a company, from conception to purchase

Jotlet is an online calendaring tool, "the Gmail of calendars" It's built using AJAX technology, it's fast, and built to be integrated with other business products.

The software differentiates itself by its desktop application feel. The software is very fast and stable.

Company built by two people: Matt Wilson - The Designer Adam Wulf - The Developer (plus they took on all the roles)

Timeline

Matt and Adam were friends from High School. Adam went to college at Rice Matt went to college at Texas A&M

The first draft of Jotlet was built in 2001 while the two were in college The second draft was built in 2003, also during college

On graduation they had a non-scalable prototype.

Jotlet.net was built in 2006, after graduation from college

People

It is crucial to find the right people if you are going to start up a company. You have to work with these people to solve problems, and there are few of you. This requires high quality people who can work together. Matt and Adam worked very well together, but they should have also found at least a sales person as well earlier in their process.

Timing

Adam decided not to get a PhD? but instead to start a company shortly after graduation. The market was ripe for a calendaring tool (no quality options out there). It would not still be at the end of a PhD? program.

Good Decisions come from Experience comes from...Bad Decisions

First venture: Promotro - social eventing (wrong idea), but failed fast (good) They Knew how to build stuff, not how to market it. This venture demanded marketing They took a lot of lessons away though (how to build fast UIs in a browser)

Their differentiator: Obsessive focus on quality. clean, Religiously OO, clean design patterns, extensible and lightweight. Cacheing optimizations built-in from day 1.

Budget:

You NEED money. Self-financed, worked out of house, got a 9-5 job (in computers!)

Worked a whole whole lot! did not spend money, work, work, work.

(had a child, quit day job)

Marketing Marketing Marketing!

Early on they relied on the internet and "viral marketing" for publicity Badly used a blog to get the word out Personal responses to feedback Asked publications to review their product Some Interviews Naive Belief: "Obviously people will recognize, appreciate, and flock to a quality product..." Nope!

Marketing Pays Off Big Time

Office 2.0 conference - first major advertising push First major advertising expense met lots of companies, got people interested (i.e. marketing money paid off, huge success, what made them successful) Met Jive Software, acquired as a result Acquired 6 months after conference (lots of talks, negotiations,) whole period of time was everything but software: lawyers, paperwork, negotiations

What Would He Have Done Differently

Find more of the right people sooner: lawyer, accountant, salesman, negotiator They could have streamlined the marketing and acquisition processes immensely. It's crucial to have a salesman too.

Quality is a tradeoff...too much quality means wasting time better spent selling, or other things

More advertising!

Be more willing to spend some money, strategically, especially toward marketing. Also spend some time to find good people and pursue active publicity

Clarify your market -- theirs was too broad ("everyone needs a calendar") Tighten your market: Business? Personal? Health Care? Schools? The responses they were getting: "This product is awesome, but only does 80% of what I need, What about <application specific need>, i.e., the other 20%?" They tried to fix too any people's needs moderately instead of hitting one of them awesomely.

Lessons Learned

Field of Dreams is just a dream ("if you build it they will come"). Need REAL ACTIVE MARKETING!

Quality does not sell itself. Necessary, but not sufficient. They won't recognize quality, you have to tell them it's quality "Good enough quality, perfect over time"

Viral marketing means you don't have a marketing plan

The most important lesson? Nothing Matters Except Marketing (depressing)

Means versus Ends (these are means) quality, scalibility, corporate structure, perfection

The means are necessities, but the end is "Sales" (i.e. money, being bought, etc)

Take Aways

Do what you're great at Know and narrow your target market (broaden over time) Quality First Sell it!

With the sale of other freely available calendars, they moved toward integration with other products.

Jive Software, Portland OR

How to develop product ideas? In his case, doing freelance coding he landed on a need in the marketplace.

How to value a small company? Two ways: 1) what is our cost to build what we have (cost another company would have to pay to rebuild what you've done)

2) We're growing at this rate with this expected revenue...projected revenue over some period of time.

10/15/2008 Exploring on Problems Faced During Writing Structural Codes in Verilog

Speaker: Kapil Dev

Slide 1: There are different ways to write for a designer (e.g. structural or behavioral) There are different abstraction levels.

Slide 2: Main Point: Discussing the possibility of enhancing the generate construct in verilog to give more flexibility to the designer

Slide 3: Three kinds of construct: 1) Behavioral, 2) Structural, 3) Generate Note: No discrete one to one correspondence between constructs available in Verilog

Slide 4: Designer wants to write code at a high level, because it is easy for him/ however this is not the optimal way. You want to have optimal implementation of design

Slide 5: If you write code a behavior level, it may be synthesized a different way. To improve, you want to make it one level.

  • Walid: to clarify are both behavior?
  • Kapil: both are behavior. The reason two examples have different levels is because the interprets it in different structural ways. Problem is designer can’t pick how the program is synthesized.

Slide 8: Problem is all code can’t be written in low level

Slide 7: Example: Carry Look Ahead Adder (CLA)

Slide 8: This checks when you are sure a Carry is 1. You won’t need 15 levels of delay, you can do this example with 2 levels. Trade off is adding more area. This allows you to improve performance.

Slide 11: Example is shown that can’t be compacted

  • Walid: Can you deal with this problem by putting in a loop that produces a sequence of Ands

Slide 12: Proposal 1 to add a new parameter to tell size of component picked. Add all the possible inputs in the argument list. This code reduces standard Verilog code

Slide 13: Proposal 2. Introduce the recursive function

Slide 14: Future Work and Conclusion: Finding best way to express the variable feature size components.

Discussion:

  • Ed: Didn’t really understand proposals
  • Kapil: My proposed solution is adding in a number of ORs.
  • Walid: I understand and_size is just the size.
  • Kapil; No and_size is not just size.
  • Walid: Ah, And_ is a keyword, size is the variable./ Other part is arguments, how do you pass in variable number of arguments.
  • Kapil: We may not no in beginning how many outputs have. For future work I will explore another method.
  • Walid: Suggestion: Variability is in one argument. Why don’t you pass in a temporary array of the appropriate size.
  • Cherif: It is not enough. Array sizes change in each loop.
  • Walid: Each array is independently created. Compile time arrays. It is one array. Another things is if you construct arrays, you might need linear types. Can you still do array balance checking?
  • Ed: This is a structural idea. You want to write programs that manipulate Verilog. This is a two level language that expands the first level.
  • Angela: Can you give an example of linear type?
  • Walid: If you have a type system that allows you to use a variable exactly only once. That’s a linear type system. Gregory presented an example of this. We may have used this in feather-weight Verilog, but we said to forget about this since more interesting things occurring. Put this on wish list for next semester.
  • Jun:You were focused on & and OR. Any other useful constructs you are looking into?
  • Kapil: And and OR are most useful. But also look at NAND gates.
  • Walid: That’s a good insight. What is interesting is the question, does this limitation arise at higher levels, And, NAND, these are primitives. At higher levels, this solved with an array. Your proposal is to treat Ands as parameters.
  • Kapil: I used & gate to optimize a portion of the codes.
  • Walid: Problem is solved by treating And as a generic module. Problem solved except for doing compile time arrays. Array at run time is really just a bunch of wires. It is a virtual data structure.
  • Walid: Good problem is what you fixed. What you state is good motivation as big concept. I suggest you say the problem is dealing with…and this is what I propose….. And then these are other things I can do when I solved that problem.
  • Mathias/Ed: Don’t give a high level talk while only on title slide
  • Walid: Give more weight to my feedback. Usually when getting criticism, there are other things going on. Be careful when interpreting feedback. A lot of time, it is how you got to point.

10/20/2008 Creating an Online Tutorial for Teaching Java

Speaker: Richard Latimer

Presentation

Overall question: How do we improve on currently available online tutorials? Teaching setup of java Using resource-aware twiki

Existing tutorials: Online books: Sam Teach Yourself Java 2, etc. These suffer from flaws: good for teaching programming, but how do you install it? How do you install integreated development environment? They overlook this.

Answer: video tutorial that walks user through installation. Create resource’aware twiki that organizes material in 1 place, easy to access.

For creating video tutorial: “write a script, prepare files, short videos better than long, plan for improvements.”

Existing: “Java Video Tutorial 1: Installing the Java Development Kit” on youtube. Flaw—hard to read, not apple friendly.

No video exists to show installing drjava.

In response, Richard has created 3 videos: installing JDK, installing and customizing drjava, explaining DrJava? features.

Improvements: zooms into words

Used Camtasia Studio and ZoomIt?.

Shows existing video. It’s hard to read. His improvement: zooms, easier to read, higher resolution. “Feels nice,” improves quality.

Next step: creating tutorial on resource-aware twiki. Organization of tutorial: Introduction: explains general questions Video tutorial setup Link to an online book Additional reading Tips and tricks: DrJava? help, links to glossary and API page, quizzes Comments: feedback for improvements

Comment section very important, to maintain quality and constantly improve.

Problems run into with adding comments to Twiki:

  • they are only accessible to COMP 617
  • force a new version history of the page
  • leaves the page with ugly text
Solution: twiki supports javascript, which is cleaner and easier to use.

  • Ed asked what is wrong with new version history: “it is not so much a problem necessarily but easier not to have”
  • Mathias asked about implementing—
Richard will look more into it

Future issues to research: improving the tutorial

  • Research the copyright laws of twiki and video site for upload videos
  • Include copyright laws on twiki
  • Look into twiki skins to improve appearance
  • Explore ways to evaluate effectiveness Find ways to keep track of page views and downloads Test it in Comp 211, since they use DrJava?. Does it work for them?

Finally: How to make site easily accessible to public

  • keywords to improve ranking in youtube or google searches
  • posting info on blogs or forums
  • posting flyers around campus
  • explore other ways of making site known

Questions:

  • Ed: You seem focused on videos. Personal preference?

  • Richard: It’s kind of new. Books are everywhere, but the step of getting Java onto computer is less explored. Having a video tutorial clarifies a lot for the first time user.

  • Ed: True. But other ways? List of instructions, etc. For serious research on a good way to teach java, there is a lot of literature/research out there on teaching, so there are options.

  • Mathias: You mentioned 3 videos. Have you created them?

  • Richard: Yes, on my computer.

  • Mathias: give me a link, we’ll put them on the DrJava? site. Also, no voice?

  • Richard: I turned it off. It’s there.

  • Mathias: Have you created transcripts?

  • Richard: No, I haven’t.

  • Mathias: good idea to do. Another prob with videos is sometimes go too fast, so reading along with a transcript helps that. Also, when you’ve figured out how you want to announce things, send an email to [list], mostly high school teachers, would find this useful.

  • Ron: With transcripts, make it possible to click a spot in transcript and it will key the video to that spot. Helpful.

  • Mathias: Not every word, but few lines or so.

  • Richard: Where can I get info?

  • Ron: I don’t have technical information, but saw it done.

  • Walid: Subtitles are also useful. The more ways you communicate your message, the more effective it is for teaching.

Comments after presentation:

  • Ed: Cool presentation. You’re taking it seriously, I learned some things, it was interesting. But you could be more direct with here are “the problems,” then address them, instead of sort of choosing one problem at a time, here and there.

  • Mathias: Summarize your previous talk, since you reference it. “This is what I decided to do and why.” That way, when discussing your videos, you will add a little structure and framework to your current work. Also, why you came up with your particular solutions.

  • Walid: Exciting topic. Presentation is not where I’d like it to be. It is passable, but you are taking the seminar and using the work for Century Scholars, so I’d like to hold you to a very high standard. Marks [for the presentation] somewhat inflated. The topic is exciting and important, but it’s really important to make a convincing presentation/argument, and really think about what problem is being solved. Tutorials not telling how to install—is that THE problem? Remember, you define the problem, as the researcher. The problem is what you solve in your work. It wasn’t clear in your presentation, with the buildup to the problem that needs to be solved. Better to express problem in very beginning, and by end, you describe exactly what you’ve done to fix it. Also, need to make sure that a real contribution has been made. You have done a lot of creative stuff, which is great, but you need a table saying how “the world works” for this tool, that captures this problem. Put the problems [that the tool solves] together in a coherent whole to improve the structure. Redo this talk and tighten it. Copyright issue is very important. Small flaws, such as accessibility and user permissions, might be solved by talking to Cherif or someone maintaining the Wiki. You want to make sure you are solving big problems, really reflecting your creativity and hard work, not just bogging down your work with small issues.
Also, ‘flaws’ not a good word choice. Use ‘problems’ instead. Avoids criticism/negativity. Approach from the standpoint of “there is a problem,” which you can fix, as opposed to “this doesn’t work, it has flaws or fails in some way.” More positive.

  • Ed: Is it a matter of just saying, “current research is this, and problem is this”? Something used generally, or specific to this talk?

  • Walid: Specific to this talk, the use of ‘flaw’ was strange.

  • Ron: Essential point is, you want to build off the shoulders of others’ work, not implying moral corruption or something!

  • Walid: Did flaw rub you the wrong way, I mean, as a word choice?

  • Ron: True, I don’t think it’s the best choice.

  • Jun: Have you looked at statistics of what people have problems with? You looked at installation, but in my experience the problems are usually after installation, with getting started running it, for example. One thing you might try is go to a forum, randomly select posts, see what common problems are.

  • Walid: Let me jump in. Excellent point. This project is useful, fun, and exciting,
but one of your challenges is to measure that there is a problem, and we are doing something about the problem.

  • Mathias: At least a third of support requests that we get on Java website are installation problems, so having the video could really help.

  • Richard: Can I get the data?

  • Mathias: I’ll add you to the site. There are lots of simple things that can go wrong with installation, so this is good.

  • Walid: If you can show that the number of problems with installation goes down, that would be an excellent way to measure. [referring to the questions asked of website]
Also, JDK needed for DrJava?—didn’t make that clear in talk. Important to clarify.

  • Jun: You should always be careful of biases, and not only look at DrJava?, but other systems, and generic Java forums, and see what questions are actually related to DrJava?.

  • Richard: Can I do that by seeing what are the comments that people reply with, for problems?

  • Walid: Yes. And another broader thing: if there was a standardized java test that people could take, it would be a way of quantifying how well they know it, and using your tutorial helped them, etc.

  • Mathias: People that would benefit from this work are the ones that usually wouldn’t finish.

  • Ed: It’s all about how you design things so people can use them, and that’s what you’re doing—not only creating the product, but measuring its effect. I knew someone who was very interested in teaching to middle schoolers, for example, and one thing you can look into is user studies. Think of retention, etc. (other aspects of learning).

  • Walid: One of the dimensions of creativity in this work is getting the same kind of stuff done on a much smaller scale than the multimillion dollar proposals.

  • Ed: I feel like there have to be these types of studies out there, known studies on how good tests are at measuring learning, etc, and it would lend credibility.

  • Walid: Absolutely right…and my advice is, it’s a good idea to try something to see if its useful/popular, and then next semester, if he wants to continue, Richard could then be looking into these statistics and so forth that we’re talking about. Don’t want to stifle the creativity with too much formality.

10/22/2008 Writing Interpreters Using Monads

speaker: Eddy Westbrook

  • We still don't have a good understanding about how to use Monads. So in this presentation I will try to give you a better feel.
  • Imagine writing an interpreter for literals and addition expressions: Very simple.
  • What if we want to add functions?
    • We need environment that must be propagated all over the place (all recursive calls, even in cases that has nothing to do with the added feature)
  • What if we want to add references?
    • Need to trace array of references which is a state that needs to be passed around
    • Ron: Why don't we use OCaml imperative features?
    • Ed: In this particular case we could, but what if we want to backtrack or what if we are writing in Haskel
  • Each feature adds complexity and affects all the cases
    • Most cases just "do the default"
    • We want a way to abstract away these features
  • Monads to the Rescue!
    • Many features definable with monads (whose definition is separate from its use)
    • Most code is independent of new features
  • Metaphor: A Monad is like a "recipe"
    • ex: int m = type of recipes for ints
    • Recipes are made from steps
    • You don't need the ingredients when writing the recipe
  • Two operations
    • ret x
      • "Make x": return x and do the default thing
      • has type: 'a -> 'a m
    • bind r f
      • "combine two recipes": perform recipe r and pass result to f
      • has type: 'a m -> ('a -> 'b m) -> ('b m)
  • Examples on using ret and bind
  • Environment Monad need 2 extra operations:
    • rd_env:
      • "Read current environment"
      • has type: env m
    • in_env e r
      • Perform recipe r in environment e
      • has type: : env -> 'a m -> 'a m
  • Example of extending the interpreter with functions
  • Example of defining monad operations
  • Conclusions
    • Monads abstract PL features
    • Can add features abstractly
  • Future work
    • Adding features makes more complex monad
    • Features can be defined separately as transformers

Discussion:

  • Jun: The environment monad is not a good choice to explain monads. Mutable state should be simpler at least conceptually.
  • Ed: This is probably true but it seemed the simpler thing to add to an interpreter.
  • Ron: Using a metaphor is a good approach but you need to develop it more and stick to it in your explanations. I am not aware of any great metaphor for monads. In my opinion, recipes might not be the best metaphor but you can prove me wrong on that.
  • The environmnent monad is a hard one.
  • Try to be more precise.
  • Gestures can be added in the slides themselves.
  • Jun: Background color is not great because it is both dark and light.

10/29/2008 Modeling Oscillating Motion: A User's Assessment

Speaker: Marisa Peralta

Presentation

Looking at Oscillating Motion

Comparing the results of modeling using Acumen versus using Matlab

Spring-Damper System It's a simple model that could be extended for more complicated modeling. Two masses connected with a spring and a damper.

Physically, on a surface with no friction, imagine a person moving M1 (see the slides). The goal is to predict the position of M2 over time.

PhyDL? describes the physical layout of the system (the physics equations) RIDL describes the control of the system (that which manipulates the system).

Model is built out of 5 modules

Issue about the model: [Walid] m1 should not have the same mass as m2. m1 should be immediately movable anywhere. Constraints should be put on the damper because it is affected by the instantaneous speed of m1, and the forces upon the damper must not be infinite.

Head-to-head: It takes substantially more Matlab code to implement the Acumen model.

Questions:

What was the initial value problem? Acumen can introduce a possible error. An initial value in RIDL had to be an integer and could not be a vector. Rounding error because you can't enter the initial value as you think about it. Walid: Both languages should accept vectors and arithmetic expressions for initial values

Memory errors with Higher precision under Matlab: This problem can be solved, so don't suggest it as a big advantage over Matlab.

Current model is building a big array to potentially hold all the values and then populating it, rather than throwing away intermediate steps. This is a general issue: when performing comparisons to another system, it's necessary to find an expert in that other system so that you can do a fair comparison. Though it does raise the quesiton: can a "high-school" graduate do what I need to get done in my system compared to the other person. Then to provide context show what an expert would do and where the disconnect is.

The Matlab example was doing differentiation inline. It could have been broken up more clearly (so that it's fair wrt readability). Second question, are there more concise ways to do differentiation, etc. in Matlab.

Mistake in the description of position. It seems that position should be solved by the system, and velocity should be jumping between positive and negative.

Really important to articulate the system as equations before modeling them in acumen. Once you are confident with the model, then put it into acumen. The system description should really look like the math (if statements and the like are suspicious).

Can the interface be made interactive. Would be really helpful to have such an interface.

Really good talk. The description of Phydl without showing the code was really good.

11/12/2008: Exploration of Resources for Self-Teaching Java

Speaker: Richard Latimer

Java education is happening outside of the classroom more often, (especially on the internet), and there is much room for improvement of these resources

How do we create an effective, state-of-the-art, and publicly available Java teaching resource?

Prior work: books, transitioning into IDEs and online content for learning Java. At the same time, technology for producing online teaching content in general improves.

Which IDEs are the best for learning: Dr. Java is the best according to some criteria selected from an external publication.

BlueJ? and DrJava? are the two IDEs developed for the classroom.

Command-line interface - nonuniform across operating systems.

Walid: How do IDEs hinder education?

Mathias: IDE features like intellisense hinder learning by fostering easy ways to produce code automatically without having to understand it (i.e. be able to generate it from scratch)

Comparison of various teaching materials for learning Java (books, video tutorials,

Richard showed an annotated version of the most popular Java installation video and pointed out the flaws in it.

Mathias: Can analyze Apache logs for tracking users (thereby getting feedback on the site). Online tracking services raise copyright issues

Corky: In choosing color schemes, use dark on light background if you're going to be in a light room.

Walid: When is this site going to be deployed?

Richard: We could do it now.

Corky: This is important because Universities should be disseminating information. This is a new modality for doing so.

Mathias: A link on the Rice website to this would raise the page rank substantially in Google.

Walid: might be good to have a "relative zoom" square off to the side during a zoom so that the viewer could see what part of the larger window you are zoomed into.

Walid: With respect to deployment, make the site, ask for feedback from the class.

Mathias: Debuggers are not necessarily helpful to new programmers. You don't necessarily want new programmers setting breakpoints and stepping through the code.

11/17/2008: Staging Monadic Interpreters

Speaker: Eddy Westbrook

Slide 1: Monads and interpreters—motivation: monads great for interpreters -can define many language features as monads

-modularity
separate feature definition from use, add/ modify features without changing interpreter -allow increased modularity with monad transformers: each feature defined separately

Slide 2: Problem: Monads add overhead Example given, showing that bind is required.

Slide 3: Eliminate Overhead with staging (multi-stage programming) -new construct: monads + staging operations -best of both: modularity and abstraction of monads without the overhead

Slide 4: General Approach -staged particular monads exist previously -new here: general form of staged monads -staging itself is abstracted and modular, works with monad transformers

Slide 5: Outline: -staging review: staging an interpreter -staging a monadic interpreter -staging a monad -staged monad operations -prelim results on staging monads

Slide 6: Review of Staging -3 constructs: brackets (create code), run (run code and produce a value), and escape (splice code inside code)

Slide 7: Staging an Interpreter -start with original interpreter and add staging annotations (brackets and escape) -so, if want to interpret negation expression, interpret t that gives you code, then splice (using escape) into bigger code (using brackets) that does the negation

Slide 8: Staging a Monadic Interpreter -mon interps have interp code and monad code, and both must be staged -interp + staging = staged interpreter -monad + staging = staged monadic interpreter

Slide 9: Example -use bind with (interp t) to apply a function

Slide 10: Staging a Monadic Interpreter -staged interpreter: sret and sbind –staged versions of ret and bind, which gives code, which can then be spliced into bigger code that gives the negation (or whatever function), as with staging regular interpreters

Sret and sbind have same types as ret and bind.

Slide 11: Staged Monads -start with original monad and add staging annotations -monads defined by: type constructor ‘a m, and operations ret and bind -staged monads defined by: type constructor ‘a sm, and operations sret and sbind

Slide 12: Example of the State Monad

Slide 13: Example: External Counter -monadic program to increment counter leads to unnecessary overhead (function call)

Slide 14: To stage this, add type ‘a sm, so computations wait for code to input state and return value and code for output state

Slide 15: External Counter Staged version: function call is now at stage 1

Slide 16: Staged Monad Operations -staged monads have 3 staging operations: flatten (staged monad to code), unflatten (code back to staged monad), local_flatten (locally flatten to allow splicing)

Slide 17: Flattening -Reason we need it is because we get code from staged monadic interpreter. Essentially, want to flip the code outside/inside.

Slide 18: Example The staged monad is kind of a complicated piece of code that takes in code and manipulates it, and the flattened code is just code. Function call removed.

Slide 19: Unflatten: Can undo flattening. Useful for values unknown until runtime, or if reading from a file and don’t know contents until actually reading from the file (actually running the code).

Slide 20: Example unflattening: “Expensive” to do, but can be done when necessary. Function called at stage 2, and has to be called twice.

Slide 21: Handling multiple value types: -in previous examples, interpreter returned integers -now, let’s handle integers and functions -need value type Int and fun are “tags”

Cherif: The way you define them in the first slide, it looked like they are similar but getting more into it, they seem less similar. Eddy: It may be a tenuous connection for me to draw, maybe I shouldn’t have made that connection.

Slide 22 and 23: Handing Multiple Value Types: interpreter now needs to check tags

Mathias: So if any computation results in error, the error gets propagated out? Eddy: Yes, that’s the idea, it just propagates outward and no more real computation happens.

Slide 24: Handling Multiple Value Types Cannot stage: cannot splice sret and serror, because not code. Should we use flatten? Does not work: types are wrong, lose “implicit context” of staged monad (eg code for current mutable state), and will need to unflatten later, and that is expensive.

Slide 25: Need a local flatten: keep implicit context, do necessary splicing

Slide 26: Call local_flatten, using f where using flatten before, and it makes it into code so you can splice it. Doesn’t specify what kind of code it is (“hidden” by monad), just get code and can splice it in.

Slide 27: Local Flattening Local_flatten acts as a form of CPS -CPS often used in staging, and this is where I got the idea of local_flatten -gives benefits of CPS in staging: tag elimination

Slide 28: Results: wrote a number of staged monad transformers -this was possible, where previous attempts were not -created a few tagged monads with above -manually inspected code produced by these (overhead of binds successfully removed) -tag elimination was straightforward (greater efficiency)

Slide 29: Conclusions Introduced staged monads: 3 staging operations -appear to be the right abstraction -abstraction and modularity of monads (as advantages), overhead removed w staging -Flattening gives you control over how much staging.

Slide 30: Future work Finish implementation (how much performance impact?) -need concrete understanding of semantics, -can we “cheat” by using OCaml features? (such as exceptions for error handling)

Questions:

-Cherif: I got the main idea, you did things in the right order to convey your point, but I think I still need to meditate on what’s going on. -Mathias: I think it really pulled things together from monads and staging interpreters, nice on that point. I think something like a flow chart with arrows showing order might have been good on slide 14 for the state monad example. -Eddy: Good point, I don’t like this slide as much. -Mathias: Presentation seemed pretty polished. Also, Dr Scheme shows binding and bound occurrences, so to stick to a more syntactic level vs graphic representation, that may be an improvement. -Eddy: Yeah, I feel like it’s a balancing act about how much detail to include, because you want to include enough to make sense/ make it worth it. -Mathias: I think it was a good amount of detail.

-Richard: Maybe in the beginning, give a more graphical representation of transformers, etc. instead of just code. Code went over my head a little. -Mathias: Certain amount of just language shock or something like that. Even I have to see, okay, how does this go? And as a freshman, without much programming experience, this would be difficult to grasp right away.

11/26/2008: Monad Transformers and Modular Interpreters (Take 2)

Speaker: Jun

High level view of interpreter architecture:

  • object language (OL, interpreted language)
  • implementation language (IL, the language the interpreter is written in)

  • program (in OL) + input -> interpreter (in IL) -> output data

Features:

  • object language might have state, backtracking, continuations, functions, variables
  • interpreter must have code for each of these features

  • traditionally no clear separation between these features in the interpreter
    • "everything is everywhere"

Example:

  • interpreter for language with integer constants and addition
  • program text input is parsed into a tree-like structure (AST)
  • interpreter works on AST and produces result
    • defined by case analysis of the expression
      • addition: evaluate sub-expressions and add
      • constant: return constant

Changes to interpreter when adding features:

  • Add functions: add environment everywhere
    • even in Const and Add
  • Add state: add state everywhere
    • even in Const, Add, Fun and App
  • Backtracking: add code everywhere
    • Getting worse and worse

Can we isolate changes better?

  • For example, can we say: addbacktracking (addstate (addfcn basicinterp))
  • Ignoring performance for now

Functions/variable bindings:

  • ability to give names to intermediate results
  • even though we can modularize this, this is so fundamental, Jun is taking this for granted in this discussion

Optional feature: Mutable state

  • memory cell that can be read and written
  • imperative computation: consult & modify state
  • explicit return value is the value the program returns
  • but the state also has a final value -- but this is not (necessarily) the return value
    • e.g. counter to label leaves in a tree
  • primitives of interpreters with state: read and write

Optional feature: Backtracking

  • Example: 4-queens problem
    • natural solution: trial & error
      • try to put a queen in a square, backtrack if it doesn't work
  • need to keep track of the alternatives and which ones are still left
  • would be nice to have language support for it:
    • "here are the alternatives, I don't care about the order, but I want you to try them"

  • Example: four_q n fills up the first n columns
    • four_q 0 is []
    • <+> means an alternative from the left and an alternative from the right
    • fail means there are no alternative

Why do we have to change the interpreter even in places that shouldn't be affected?

  • because we add "innocence" assertions
    • like "...and don't modify or depend on the state"
    • the interpreter must explicitly say that it did not change the state
  • because we add bookkeeping information
    • let x = e1 in e2, if we have backtracking, e1 must pass information about the alternatives to e2, in case e2 fails

Solution to get modularity: Monads

  • Observation: it's easy to support a feature in the OL if the IL has the feature
    • the bookkeeping and the "innocence" assertions are included in the semantics of the IL
  • but we can't assume the IL has everything -- why make new languages?

Everything can be solved by a layer of indirection:

  • Add monadic metalanguage
  • Implement OL in monadic metalanguage
  • Represent monadic metalanguage as data in the IL

State monad:

  • extends the IL (with functions) to a monadic metalanguage (with functions and state)
  • Type of state monad: M a = StateM? a = State -> (a, State)
    • takes a State and returns an a and a State
  • Representation of "42"
    • ret x = \s -> (x, s)
  • Allow bindings
    • bind m f = \s -> let (v, s') = m s in f v s'
  • Representation of "let x = 5 in x+x" in metalanguage
    • bind (ret 5) (\x -> x + x)

  • ret deals with the "innocence" assertions
  • bind deals with the bookkeeping

  • ret and bind create mirror images of constructs in the impl language in the meta language
    • just pass the state along
  • read and write in meta language depend on or modify the state
  • read = \s -> (s, s)
    • returns the state also as explicit return value
  • write new_s = \s -> (unit, s)

  • the monadic interpreter doesn't return a value
    • it returns a computation that can return a value
    • needs to be given an initial state
    • result will be the explicit return value and the final state
      • if you just want the explicit return value, throw away the state

Backtracking monad:

  • represent alternatives as list
  • ret x = [x]
    • don't do anything with x, just return the one-element list of x
  • bind m f = concatMap f m
  • fail []
    • no alternatives left
  • <+>
    • list concatenation

But what if we use state and backtracking?

  • Should the backtracking "undo" the state changes?
  • Both yes and no are reasonable choices
    • If you think of backtracking as parallel computations, then you want "no": undo the state changes

Solution: Monad Transformers

  • take a monad M1 and produces another monad M2
  • the metalanguage of M2 should be an extension of the metalanguage of M1
    • so there needs to be a way to "lift" constructs in M1 to constructs in M2

How do I lift special functions like read or fail?

  • Ad hoc approach, because features interact with each other

Monads give a systematic way to represent programs in an enriched version of the IL

  • with the enriched language, the different parts of the interpreter interfere less with each other

12/01/2008: REPTILE Acumen

Speaker: Angela Zhu

Purpose is to design a language to design a simulator

This project has three phrases:

1. Prototype simulation, now known as Acumen

2. Simulate tractor model and control

3. Synthesis of embedded controllers done by Rice

Change of plans: Want to use Matlab, also model in Acumen

Want to compare Matlab and Acumen models

First example case: drilling an oil well. Sometimes walls of an oil well collapse. When cement is poured, it is called a “cased hole” Before cement is placed, it is called open hole. Also have terms “power stroke”, meaning pushing against wall, and “return stroke”, meaning returning to the original position.

A 2-sonde design: As an object, called “sondes,” moves along the wall, it uses grippers to move along wall. The power to move this system produces a lot of heat.

A 3-sonde design: Always having two grippers moving at the same time. This reduces the torque required by each tractor.

Additional designs exist with 4-sondes, which has three grips at one time.

Sometimes we want to grip wall before cement is poured, but sometimes cannot grip wall. Therefore, if only one sondes is gripping wall, slow down the sonde. By slowing down the sonde, you might lose synchronization.

Need Tractor System Model to determine: 1) synchronization, 2) well geometry, 3) motor of each sonde, 4) load sharing

If you have high friction, it requires power stroke to be stronger.

In Acumen, we see just text output of simulation. In Simulink we get animation.

-Mathias: Text code is easier for programmers, but for scientists it is easier to see more graphical objects

Now, modeling an system that includes washed out well walls, meaning we cannot grip the wall.

If all 3-sondes cannot grip wall, the tractor should stop.

We have compared results from Simulink and Acumen, we see simulation results are very close.

-Jun: what does a .2% difference mean?

-Angela: Difference keeps increasing, but always seems less.

-Walid: Are you sure it is always less, maybe you need to check?

All stages of the project have been successfully completed.

Additional Comments:

-Eddy: Do tractors get stuck?

-Angela: Yes, they need to pull it out.

-Eddy: Can they get data from the well in the field?

-Angela: Yes they can