WPF has an element called ScrollViewer, which is basically a panel that contains elements and shows scroll bars when the content inside is too big to fit in the size of the ScrollViewer’s visible area. Consider the following three cases.

Case 1: Finite-sized UI content within a ScrollViewer

In this case, obviously the scroll bars should only appear if the visible area of the ScrollViewer is too small to show the content. If the window is large enough, there entire finite-sized content will fit in the screen and no scroll bars are necessary (although we may want to still show them, disabled, for stylistic reasons).

Case 2: Infinite-sized UI content within a limited container (NOT a ScrollViewer)

Sometimes we have content that can use any size assigned to it. For example, a grid (in my case, DevExpress’ WPF GridControl) of data rows. Assuming a huge (or even infinite) data source, the grid’s size on the screen has no upper bound – it can always grow more and always show more content. The grid’s size in the UI must be limited somehow. There are two ways to limit the size of such a UI control:

1. Set a maximum size on the control, or
2. Place the infinitely-sized control in a container that has a maximum size defined.

In other words, the infinite control must lie in a tree of containers where at least one container up the ancestry must have defined a maximum size. If no parent container specifies a maximum size, eventually the top-level container – the window – DOES have a maximum size and the infinite-sized control will fill the whole window (and nothing more).

Case 3: Infinite-sized UI content within a ScrollViewer

Now, consider that the container of the infinite UI control (such as a grid with infinite rows in the data source), is actually container within a ScrollViewer. In this case, the ScrollViewer, being what it is, does NOT limit the size of its contents, so the infinitely-sized control will “explode” and will, by our algorithm, try to occupy an infinite size. Specifically in the case of a DevExpress WPF GridControl, the authors of that control know to detect that situation – and an exception is thrown, stating:

DevExpress.Wpf.Grid.InfiniteGridSizeException was unhandled
  Message=“By default, an infinite grid height is not allowed since all grid rows will be rendered and hence the grid will work very slowly. To fix this issue, you should place the grid into a container that will give a finite height to the grid, or you should manually specify the grid’s Height or MaxHeight. Note that you can also avoid this exception by setting the GridControl.AllowInfiniteGridSize static property to True, but in that case the grid will run slowly.”

Problem is, sometimes we want to put that grid in a ScrollViewer so that when the screen is too small, the grid will assume some minimal size, and a scroll bar will be shown if the screen (or window) is smaller than the minimum. If the window is huge, what we want is to expand the grid to fill the available space in the window – as big as the window can be, with no limit. If someone is using the application on a 5000-inch screen, we want to use all that space. If someone is using a 1-inch screen, we want the grid to be 3 inches and show a scroll bar.

So, the solution seems simple enough: we can tell the ScrollViewer to have dual behavior:

1. If the available screen size is smaller than some minimum, allow scrolling, and set the size available for the content to be that minimum size.
2. If the available screen size is larger than the minimum, behave like a regular container that gives its children only the space it has on the screen.

For example, if we decide the content requires at least 100 pixels, if the ScrollViewer has 80 pixels available – make the content within the scrollable area exactly 100 pixels, and show scroll bars. If the size available for the ScrollViewer is 200 pixels (more than the minimum 100 pixels) – don’t allow scrolling, and let the contained UI content use up to 200 pixels. Here’s a WPF behavior for ScrollViewer that does exactly that:

    public class ScrollViewerMaxSizeBehavior : Behavior<ScrollViewer>
    {
        public static readonly DependencyProperty MinContentHeightProperty = DependencyProperty.Register("MinContentHeight", typeof(int),
            typeof(ScrollViewerMaxSizeBehavior), new UIPropertyMetadata() { PropertyChangedCallback = MinSizeChanged } );
        public int MinContentHeight
        {
            get { return (int)GetValue(MinContentHeightProperty); }
            set { SetValue(MinContentHeightProperty, value); }
        }

        public static readonly DependencyProperty MinContentWidthProperty = DependencyProperty.Register("MinContentWidth", typeof(int),
            typeof(ScrollViewerMaxSizeBehavior), new UIPropertyMetadata() { PropertyChangedCallback = MinSizeChanged });
        public int MinContentWidth
        {
            get { return (int)GetValue(MinContentWidthProperty); }
            set { SetValue(MinContentWidthProperty, value); }
        }

        protected static void MinSizeChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
        {
            var self = d as ScrollViewerMaxSizeBehavior;
            if (null == self)
            {
                return;
            }
            self.Update();
        }

        protected override void OnAttached()
        {
            base.OnAttached();
            this.AssociatedObject.SizeChanged += this.ParentSizeChanged;
            this.Update();
        }

        protected override void OnDetaching()
        {
            this.AssociatedObject.SizeChanged -= this.ParentSizeChanged;
            base.OnDetaching();
        }

        protected void ParentSizeChanged(Object sender, SizeChangedEventArgs e)
        {
            this.Update();
        }

        private void Update()
        {
            if (null == this.AssociatedObject)
            {
                return;
            }
            var content = this.AssociatedObject.Content as FrameworkElement;

            if ((0 >= this.AssociatedObject.ActualHeight)
                || (0 >= this.AssociatedObject.ActualWidth))
            {
                // The attached ScrollViewer was probably not laid out yet, or has zero size.
                this.AssociatedObject.VerticalScrollBarVisibility = ScrollBarVisibility.Disabled;
                this.AssociatedObject.HorizontalScrollBarVisibility = ScrollBarVisibility.Disabled;
                return;
            }

            int minHeight = this.MinContentHeight;
            int minWidth = this.MinContentWidth;

            if ((minHeight <= 0) || (minWidth <= 0))
            {
                // Probably our attached properties were not initialized. By default we disable the scrolling completely,
                // to prevent exceptions from infinitely-sized objects within us.
                this.AssociatedObject.VerticalScrollBarVisibility = ScrollBarVisibility.Disabled;
                this.AssociatedObject.HorizontalScrollBarVisibility = ScrollBarVisibility.Disabled;
                return;
            }

            this.AssociatedObject.SizeChanged -= this.ParentSizeChanged;

            if (this.AssociatedObject.ActualHeight < minHeight)
            {
                this.AssociatedObject.VerticalScrollBarVisibility = ScrollBarVisibility.Auto;
                if (null != content)
                {
                    content.MaxHeight = minHeight - (content.Margin.Bottom + content.Margin.Top);
                }
            }
            else
            {
                this.AssociatedObject.VerticalScrollBarVisibility = ScrollBarVisibility.Disabled;
                if (null != content)
                {
                    content.MaxHeight = Double.PositiveInfinity;
                }
            }

            if (this.AssociatedObject.ActualWidth < minWidth)
            {
                this.AssociatedObject.HorizontalScrollBarVisibility = ScrollBarVisibility.Auto;
                if (null != content)
                {
                    content.MaxWidth = minWidth - (content.Margin.Left + content.Margin.Right);
                }
            }
            else
            {
                this.AssociatedObject.HorizontalScrollBarVisibility = ScrollBarVisibility.Disabled;
                if (null != content)
                {
                    content.MaxWidth = Double.PositiveInfinity;
                }
            }

            this.AssociatedObject.SizeChanged += this.ParentSizeChanged;
        }
    }

An here's how to use it in a XAML file (assuming the above class was defined in a namespace known as "custom" within the XML namespace):
Somewhere at the top: xmlns:Interactivity="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
Then:

    <ScrollViewer Style="{StaticResource AppHost_ScrollViewer}">
        <Interactivity:Interaction.Behaviors>
            <custom:ScrollViewerMaxSizeBehavior MinContentWidth="600"
                                                MinContentHeight="500"/>
        </Interactivity:Interaction.Behaviors>

        <!-- content -->

    </ScrollViewer>

Almost, but not quite

Continuing the 100-pixel example – what happens if we have some statically sized content (no infinite sizes) that requires more than what we defined as a minimum? For example, what if instead of a dynamically-sizable grid we have content that requires 200 pixels, and the window size is 100 pixels? In this case, the previous solution is bad: it will not allow scrolling to see the full 200 pixels. So our dual-behavior needs to know, somehow, if the content within it can expand at all an infinite size (and therefore requires the dual behavior defined above to prevent explosion to infinite size). Because if the content has a finite size, we simply want the ScrollViewer to behave as usual and allow scrolling to see that maximum size.

Conclusion – what’s missing in WPF (and possibly other UI frameworks)

What I’d expect is that there would be some property on UI controls specifying whether or not this element can expand infinitely (in height, width, or both). If any node in the UI’s element containment tree has this “infinite size” property set, then the ScrollViewer that contains this tree must act using the dual behavior and must have a minimum size defined (smaller size means we allow scrolling and set the content exactly to the minimum size; bigger-than-minimum size means we don’t allow scrolling and give the content whatever space we have and no more). If the “infinite size” property, propagated to the ScrollViewer from the contained tree is not set, the ScrollViewer acts like a regular ScrollViewer – allowing the content to grow to whatever size it needs, and showing scroll bars if needed.

For now, since there is no such feature in WPF, I’ll be using the aforementioned ScrollViewer behavior with appropriately defined minimum sizes for those screens that need them – hard coded, ugly, but works.

You can see the presentation I gave for my project:

Here is the robot from my project:

And here is a draft of the poster I made (click for larger version):

A picture from the projects conference:


#!/usr/bin/bash
RESULT=""
for arg
do
if [[ "" != "$arg" ]] && [[ -e $arg ]];
then
OUT=`cygpath -wa $arg`
else
if [[ $arg == -* ]];
then
OUT=$arg
else
OUT="'$arg'"
fi
fi
RESULT=$RESULT$OUT" "
done
echo "$RESULT"


The script tries to find any file or directory names in your command line arguments, and converts them to absolute, windows-style path names using cygpath -wa. You can then run something like:

explorer `~/cygwinify.sh /tmp`

And it will open Windows Explorer in the correct folder.

Also, the script to run kdiff3 becomes (just replace the path to the executable with your own):


#!/usr/bin/bash
"/cygdrive/d/Program Files (x86)/KDiff3/kdiff3.exe" `~/cygwinify.sh "$@"`


Second, create the following script somewhere (such as ~/kdiff3.sh, and change the location of your kdiff3.exe to an appropriate cygwin-style path to where you executable really is). The script is based on Pete Goodliffe’s one he used for svn. I’ve expanded on the idea to make it more flexible. See my next post for a more general version that can be used for any windows program

#!/bin/sh
RESULT=""
for arg
do
if [[ "" != "$arg" ]] && [[ -e $arg ]];
then
OUT=`cygpath -wa $arg`
else
OUT=$arg
if [[ $arg == -* ]];
then
OUT=$arg
else
OUT="'$arg'"
fi
fi
RESULT=$RESULT" "$OUT
done
/cygdrive/d/Program\ Files\ \(x86\)/KDiff3/kdiff3.exe $RESULT


Finally, configure your ~/.gitconfig to:

[diff]
tool = kdiff3
[merge]
tool = kdiff3
[mergetool "kdiff3"]
path = ~/kdiff3.sh
keepBackup = false
trustExitCode = false


No thanks to wordpress for ruining the whitespace formatting…

Try running git difftool (make sure you have some modified files) to make sure it works.

Insensitivity

The first property I defined, was given the made-up name of “insensitivity”:

If two inputs are almost the same… the output will be (almost?) the same.

Here are a few points about it. To make things clearer, let’s define “almost everywhere” as “everywhere except a set of measure zero”.

The reason for not using only continuity conditions on systems was to avoid the various pitfalls encountered by mathematicians as they developed integration and analysis. I’m no mathematician (not even an undergraduate one) but I do know that Lebesgue integration is considered the best (even final) solution to those various problems, and I’m trying to base my systems on this result. A good example is that of the characteristic function of the rationals (also known as Dirichlet’s function) which equals 1 for rationals and 0 for all other reals. Traditional integration is undefined on such functions – which means that integrals are not total functions. With Lebesgue integration, the issue is solved.

On the other hand, we do want our systems to “behave nicely” and not wildly change their outputs with every small change of input. I’m not talking about changes of the input signal in time – rather, I mean that if we replace the entire input signal with one that is very similar, the output should be similar. I’m still not sure how to cure this problem completely, but the way I defined “insensitivity” ensures that at least for inputs that differ at a very small (“almost nowhere”) subset of time, the output will be the same. I’m not sure, but we may still want to require systems to be continuous (changes in input that are more than “almost nowhere” cause small changes in the output).

This last point brings up the following question, raised by both Derek Elkins and Luke in the comments on that last post. Citing Derek:

…without the “almost” on the output you would disallow the identity “system” which I highly doubt you want to do.

The identity system is a good way to bring out the meaning of insensitivity. I do think that the guiding principle should be that “almost identical” signals are considered identical, and in the same spirit “almost identical” systems are also identical. Thus if two systems are the identity system almost everywhere, except for a zero-measure set of different values between the systems, they are still considered the same system. My opinion is that it’s better to not require the existence of a single identity system. Alternatively, we define that every two systems that produce the same output almost everywhere for all inputs, are “equal”.

Note I’ve added the “(almost?)” on the insensitivity requirement on the output (see above). I think I still want to keep that “almost” on the output. The reasoning is twofold. First, for consistency we should make no distinction between output signals that are the same almost everywhere. Secondly, I don’t want to force systems to give exactly the same output when inputs are not exactly the same (not just “almost everywhere”).  I’m not entirely certain about this, though.

In any case I don’t want the “almost” on the output be used as way to process events. Since we consider “almost identical” systems to be equal, such usage is pointless anyway. So what do we do with events?

Is this an implementation thing?

No, I’m not requiring insensitivity because the implementation may cause “glitches” in the output (if I understand correctly that was one of Derek’s questions). In fact I’m not considering implementation at all at this point. I’m trying to come up with the basic properties that we would require of systems in an ideal setting.

Wait! What about events?

Almost all the comments raised this point. Truth is I sort of ignored events when I wrote that post, but I did originally have them in mind (and then forgot about them completely). Since we ignore differences that occur on zero-measured subsets of the input, there is indeed no way to “detect” or differentiate between inputs that contain single-point values. So how do we handle events, or values that occur at single points in time?

Recall that we defined the time domain as an arbitrary ordered, measurable set. Here is where the generality of that definition comes in. If we ignore the idea of signals combining events and continuous values, I think we can solve this. We can try to handle events by defining an appropriate time domain, and allowing systems’ outputs and inputs have a different time domain (unlike the definition I gave in the previous post).

An attempt at defining event signals

The following is an attempted definition for event signals. Note that this attempt does not allow simultaneous events (which can be worked around by having compound types for the event values) or combined discrete/continuous time signals. Perhaps these two issues demand direct resolution, but to make progress in the current direction I’m ignoring them.

Let T (the time domain) be a countable set of positively increasing reals signifying event times. It is easy to define an ordering between disjoint interval-type subsets, based on the natural ordering of the reals. For a measure, we can count the number of elements in a subset (the counting measure). A single event (a subset containing one time element) would have measure 1, two events – measure 2, etc.

Thus, an event signal is a function T -> A that maps every element of the time set to an event value. Notice how the T here is necessarily different for each event signal (the times contained in the set are different). I’m not sure it’s bad – we can still define comparisons between event signals. The insensitivity condition in this case, is still valid: T is measurable and every non-empty subset in T has non-zero measure, so no events get “missed” by the insensitivity.

So to summarize, we can handle events by considering a different time domain (a discrete one, essentially) and use an appropriate measure on that domain. It makes sense to allow systems to have outputs with different time-types than the input – for example a “sampling system” takes real time in the input, and outputs in a discrete time. Remember, I’m not talking about how to implement or represent this in Haskell (or otherwise) – I’m just trying to define the desired model in an ideal setting.

Delta functions

Some (including myself) have suggested to use something akin to Dirac’s delta function (which isn’t a function, but a measure or a distribution) to represent events on real, continuous time. Adequate discussion is too long for this post. My guess is that since these “mathematical constructs” are not functions of time at all, and since they are originally used as measures, we will more or less need to re-invent them for our wider context.

One way to define the delta is given here. The δ function is an operator that takes a “test function” f of time, and then for any given time interval (or more generally, a subset of time) has one of two values. So <δ,f> on U where U is a subset of R, is:

• If U contains the origin (0 is zero in this font), the value is f(0).
• Otherwise, the value is 0.

The delta can be shifted to obtain the same on points other than the origin. Essentially, the delta function tells us whether the given subset of time contains a particular point, and then evaluates to either a default value (0) or the value of the given function at that point. The sum of two non-overlapping deltas is one which yields the value of the test function at two points, etc.

EDIT: The following definition is flawed. I correct it in the first comment.

An equivalent construct in our context is an operator that takes a subset of time and maps it to an event value (“Just x”) if the event has occurred within that subset. Otherwise, it maps it onto “Nothing”. We can then define “sums” (or more appropriately, mappend) of two of these operators: map to each of the preceding values if each event has occurred in the given time subset, just like the sum of two deltas. For completeness we must also deal with combination of simultaneous events, and maybe also with the question of how to define a system that can work with both these and plain functions of time.

If we follow this plan, it’s easy to see that using sums of deltas (“impulse train“) to define event streams resembles the definition of events as functions from real time to Maybe a. This possibility has been suggested previously and I’m sure it’s been discussed by FRP proponents – I’d like to know what conclusions or arguments were raised in this regard (enlighten me if you know).

However, the delta approach is not exactly the same as functions from time to Maybe. They are operators that take test functions and produce these Maybe total functions. The type can be written as (this is not really Haskell notation):

delta : (T -> A) -> T -> (U -> Maybe A)


Where U is the set of subsets of T, the first argument is the test function, the second argument is the time shift of the delta – the location of the event value, and the result is a function that yields Nothing everywhere except for subsets of time that happen to contain the shift value.

An event stream using this definition of delta would be a function from subsets of time (not from time values) to Maybe a. To incorporate these events in our model we’ll need can try different approaches. One way is to change the definition of a system to take inputs of this type (subsets of time → Maybe a), and to output a similar type. The only way I see to define the regular continuous time signals in this model is:

f : U -> Maybe (T -> A)

Where again U is the set of subsets of time. That is, for every subset of time, the function yields a function of time that gives the value of the signal at each point in the subset.

There is surely more to explore in the delta direction, but for now that’s all I can think of.

Conclusions

The idea of a measurable time domain apparently makes it possible to define both continuous and discrete timed signals and systems at once. In addition we explored the alternative route of using delta functions. The first approach (based on measurable time) for events seems simpler and more straightforward than the delta function approach. Maybe there’s a simpler formulation that uses the delta approach and incorporates also regular signals in one general definition.

I’ve been thinking about ways to lay firm, logical foundations for a model of FRP. Rather than trying to cook up the “next best thing”, we should perhaps review what we really want and try to infer what we need. Unfortunately I’ve very little time to think about this and I’ve hardly discussed this. Hopefully this blog post will give my effort another small push.

Goal

The idea is to define a set of building blocks that allow one to express only systems that satisfy a few basic properties. Specifically we want systems that don’t satisfy these properties, to be inexpressible within our model. It makes sense to start by defining the properties we want to satisfy, and then to try and deduce the most general model that satisfies them and only them.

The basic concept is that of a “system”, which we define as a function:

f :: (T -> A) -> (T -> B)

Where T is an ordered, measurable set, usually denoting time. This is what Conal Elliott called an “interactive behavior“, and what is known in Yampa as a “signal function”. I use the term “system” because that’s how this is called in engineering, and I see no reason to invent new names.

Desired properties of systems

Edit: the properties as defined below are not exactly what we want. See comments for discussion.

So, here are the requirements I’d like to propose. Every expressible system must satisfy the following:

1. Insensitivity: If two inputs are almost the same (differ at most at a set of measure zero), the output will be (almost?) the same.
2. Causality: For all t in T, output(t) can only depend on input(t-s) where s ≥ 0. Meaning, for every two inputs x1, x2 that have the same past, the output for the present is the same. And to be more precise, for every t, if x1(t-s) = x2(t-s) for almost all s ≥ 0, the output at t will be the same.
3. Markovity: Same as (2), but with the condition that |s| < ∞. In words, the output does not depend on inputs from the infinitely remote past or future.
   
4. Finite memory: given the current input (a single value), the current output depends additionally at most on a finite-length binary string (that may have been computed from past inputs).
5. Time invariance (optional): If x(t) produces output y(t), then x(t – s) produces output y(t – s).

Discussion

The first property means that the system is not overly sensitive. Integration is one example of a system that satisfies this property: changing the value of a function at finite number of points does not affect the value of its integral. I don’t know how to call this – if anyone knows a name for this property, please tell me. For now I’ll call it insensitivity.

The second property is causality. It stems from the physical intuition that we can’t know the future, and every value that we  (or our systems, or any other natural thing) compute at the present, should depend only on inputs from the past (or at most, the present). Otherwise, we’d have to wait until the future “arrives” to complete the computation.

Causality is one of the properties that are easily violated if we consider a model that allows us to arbitrarily sample our input, one that allows us to actually treat the input as a function of time. Mathematically, a function is just a mapping and has no rules regarding which part of the domain can be evaluated and when. So, the first realization from our requirements is that we can’t  have signals (inputs, outputs, etc.) as directly accessible values in our model, or that they shouldn’t be modeled as functions. Yampa (or in it’s other name, AFRP) imposes the no-access rule and doesn’t have signals as values that can be passed around. Instead, they are indirectly manipulated by constructing systems that transform them – a sort of “wiring up”. There’s a big debate on the pros and cons of an Arrow-based FRP, but I’ve yet to understand the full consequences.

As for a non-functional description of signals, I haven’t though about it enough to know if there’s any obviously useful alternative that solves the causality problem. So in my case, I choose to go the Yampa way – I won’t provide any means to access signals directly.

Besides causality, we also want to make sure the system does not depend on the infinitely remote past. Physical intuition says that we’ll never be able to know what happened that far back. This is the defining property of Markov processes (of any order), so I’ll call this Markovity. Note that the requirement is defined as going both ways, but our previous demand for causality means that it only has meaning regarding past inputs. Perhaps the more general formulation (that includes both past and future) is redundant, but to me it seems nicer to have it symmetric even though only one direction (past) matters in our case.

The fourth property is finite memory, which is physically intuitive. Especially in the context of computers, we don’t want our systems to endlessly accumulate information until we run out of memory. Mathematically, this requirement needs elaboration to be made precise. The formulation I’ve given above (depending on a finite-length binary string) is simple and describes what I want, but it will require extra work to figure out what implications it has on our systems.

Finally, time invariance can be interpreted as not being able to tell the absolute “wall clock” time. Physically this is true: we don’t know about any absolute time. Although in reality engineered systems do in fact evolve over time (wear and tear, for one) it is not some intrinsic property of the system that causes this change – rather it is that the entire observable universe serves as inputs to our systems, which can never be fully isolated. Thus the only thing that should matter for our system’s output is how the input evolves over time, not the exact position in global time of the input. We forbid sensitivity to input time shifts. I noted this requirement as optional because I’m not sure we really want it as a limitation. I do have a gut feeling that we don’t miss out any desirable systems by adding this limitation – please correct me if you have any ideas against this.

What’s next?

In this blog post I’ve identified the five basic properties that we desire in a system. The next step should be to define a set of operations that can serve as universal building blocks for any system that satisfies the requirements. Perhaps more importantly, our building blocks should prevent us from accidentally expressing systems that violate the requirements. I’ll even say that it’s ok if a few valid systems are inexpressible (our “systems filter” has false positives) as long as no violating system is expressible (no false negatives).

I’m waiting for your comments.

As part of my final project for an undergraduate degree in electrical engineering, I’ve demonstrated how FRP can be used to control a robot.

At first I meant to use one of the existing FRP frameworks. I wrote a prototype program (a visual graph editor) using Yampa but I had a few problems with it. First, I was confused by the mess in the library’s API. There are literally dozens of functions, some with apparently overlapping purposes, and it’s hard to figure out which ones I should be using and when. Secondly, I was looking for a library that has a semantic model, or at least an approximation of one – and Yampa only has this for the basic notions of signals and signal functions, but not for many of the “magic primitives” that appear in the API, such as “pre”. Specifically, the function “pre” is problematic because it doesn’t have any logical meaning in the context of continuous time. It’s ok to say that it’s only valid in the context of discrete time, but then the function can have different effects when the system has different sampling rates.

About the Reactive framework, from what I understand it is slightly too buggy to be useful. I hope the bugs will be fixed in Reactive and that Yampa undergoes reorganization so that these most serious attempts at implementing FRP will be more useful.

In any case I decided to implement a small subset of the FRP ideas in my own code (the “allocated-processor” package), add bindings for OpenCV and for controlling the Segway RMP, and provide high-level functional primitives for these. The robot in the video is the result of that effort.

We can’t arbitrarily check what a sensor input was at any point in the past. We can only tell what it is right now, in the present. Alternatively, we can store some information about a sensor’s input as time goes by, and later probe the store information to answer questions about the past. But one thing is clear: we are limited in what we can know about a past event, because our memory doesn’t perfectly describe reality and it also must be finite. We can call this “point-wise time access”, or maybe a better name would be “real time access”.

But if we can access only the current time, how is it possible to perform things such as integration, that seem to require knowledge of the value at least at a finite time interval? Obviously the way we do it is by accumulating the sum, not by remembering what the value was at every time instant and later summing those.

As a result of that idea and a few others, I wrote the short report titled “Behavioral Amnesia”. I’d be glad to hear feedback. It discusses also other various related points.

In short, the only new (to me) idea in there is that we can build a model that is point-wise (disallows arbitrary access in time) but still allows memory. One way to do so is to define a generalized operator that scans over time, I call it scanlT, and it works like this:

scanlT :: (a -> a -> DTime -> b -> b) -> [(Time,a)] -> [(Time,b)]
scanlT f y xs = scanl f' y xs'
  where f' ((t1,x1),(t2,x2)) = f x1 x2 (t2-t1)
        xs' = zip xs (tail xs)

Where the lists of (Time,a) and (Time,b) pairs are the time-dependent input and output values, respectively. The first argument, the function, performs the memory-full calculation. The implementation, and even the type-signature, live in the semantic domain – they describe what the model is, not how it is to be implemented.

If the time-dependent values are defined as lists, what about continuous time? The report describes a (admittedly naive) way to tackle the problem: the continuous version of scanlT is the limit on scanlT applied to the list of samples of the continuous input, where the limit is on the sampling rate going to infinity. I’m sure there are alternative, perhaps more general formulations – but this one suffices for me, at the present. One implication of the sampling representation is that the input must satisfy certain conditions (and if I’m correct, mainly that they be L2-integrable).

With scanlT defined it’s possible to work out integration:

integrate :: Fractional a => Temporal a -> Temporal a
integrate = scanlT psum 0
   where psum y1 y2 dt s = s + dt*(y1 + y2)/2

Where “Temporal a” is the yet-to-be-defined type of continuous time-dependent values. Note that there are many different formulations possible, because psum is not really trapezoidal approximation – remember that scanlT is taken at the limit of dt going to zero. Also note that obviously a real formulation of integrals would be defined for the most general type – probably vector spaces, measurable spaces or the such (excuse my sketchy math knowledge).

As far as I know, all publicized FRP formulations to date have used integrals as built-in primitives (correct me if I’m wrong!). The idea I’m trying to push is that there should be nothing magic or special about integration or even general accumulation. What we want is a general way to implement realistic, non-arbitrary-time, memory.

We can also define differentiation. Differentiation is weaker in that it is local, it doesn’t really need to know much about history to tell you the current value (note the _ in the definition):

differentiate :: Fractional a => Temporal a -> Temporal a
differentiate = scanlT pdiff 0
   where pdiff y1 y2 dt _ = (y2-y1) / dt

It’s fun to verify that pdiff and psum are inverses of each other, when you take the limit.

Finally, we can even implement maximum (or minimum). I use the imaginary typeclass “MinBounded” that contains the value MinBound:

maximum :: (Ord a, MinBounded a) => Temporal a -> Temporal a
maximum = scanlT pmax MinBound
   where pmax _ y2 _ m = max m y2

That’s basically the idea, I’d love to hear comments. The report I wrote contains more discussion, but is currently slightly outdated only with respect to the function definitions I just gave.

In the next part I’ll describe one possible model for FRP that uses this as its basis.

Lastly, comments are welcome!