Details

    • Type: Wish Wish
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0
    • Labels:
      None

      Description

      I'd love it if Commons Math could add support for the Kalman filter. Here are a few implementations that might be able to be used for reference or included if they're using compatible licenses:
      http://code.google.com/p/efficient-java-matrix-library/wiki/KalmanFilterExamples
      http://mathstat.asu.edu/~eubank/
      http://www.fit.vutbr.cz/research/prod/index.php.en?id=53&notitle=1
      http://sourceforge.net/projects/jkalman/
      http://www.vni.com/products/imsl/jmsl/v30/api/com/imsl/stat/KalmanFilterEx1.html

      1. filter.xml
        8 kB
        Thomas Neidhart
      2. KalmanFilterTest.java
        10 kB
        Thomas Neidhart
      3. MATH-485.patch
        25 kB
        Thomas Neidhart
      4. MATH-485-cleanup2.patch
        27 kB
        Thomas Neidhart
      5. MATH-485-update1.patch
        29 kB
        Thomas Neidhart

        Activity

        Hide
        Luc Maisonobe added a comment -

        For some work I am doing in my daytime job (space flight dynamics), I would also need that.
        Note that the first link you provide is distributed under LGPL, the second one has no license terms, the two following ones are distributed under the GPL, and the last one is a commercial product. None of them seem suitable for inclusion.
        Since this algorithm is fairly simple and we have all the required linear algebra building blocks, we can do our own implementation.

        Show
        Luc Maisonobe added a comment - For some work I am doing in my daytime job (space flight dynamics), I would also need that. Note that the first link you provide is distributed under LGPL, the second one has no license terms, the two following ones are distributed under the GPL, and the last one is a commercial product. None of them seem suitable for inclusion. Since this algorithm is fairly simple and we have all the required linear algebra building blocks, we can do our own implementation.
        Hide
        Mikkel Meyer Andersen added a comment -

        I'm quite busy the next couple of weeks, but I'd love to implement this, hopefully sometime in February.

        Show
        Mikkel Meyer Andersen added a comment - I'm quite busy the next couple of weeks, but I'd love to implement this, hopefully sometime in February.
        Hide
        Thomas Neidhart added a comment -

        As I have been playing around with Kalman filters for some time now, I gave this feature request a try.

        Please find attached a patch for a Kalman filter together with a (simple) test case and two examples (separate file, requires jfreechart to print some graphs).

        The implementation is derived from the paper of Greg Welch and Gary Bishop and an example from Dan Simon (see javadoc for links).

        This is a first, initial version, so any comments and suggestions are welcome. I tried to explain as much as possible with inline comments to ease the review process.

        The test case is very rudimentary, maybe somebody has additional ideas for test cases.

        Show
        Thomas Neidhart added a comment - As I have been playing around with Kalman filters for some time now, I gave this feature request a try. Please find attached a patch for a Kalman filter together with a (simple) test case and two examples (separate file, requires jfreechart to print some graphs). The implementation is derived from the paper of Greg Welch and Gary Bishop and an example from Dan Simon (see javadoc for links). This is a first, initial version, so any comments and suggestions are welcome. I tried to explain as much as possible with inline comments to ease the review process. The test case is very rudimentary, maybe somebody has additional ideas for test cases.
        Hide
        Thomas Neidhart added a comment -

        some additional rationale to the current interface design:

        • predict and correct methods exist for both, double[] and RealVector input parameters for convenience reasons
        • the constructor only supports RealMatrix objects, as there are a number of required parameters, but a separate one could be added that takes double[][] if this is deemed helpful
        • the initial state and error covariance can be set after construction to reduce the number of parameters in the constructor (no check is yet being made if the filter is still in initialization mode)
        Show
        Thomas Neidhart added a comment - some additional rationale to the current interface design: predict and correct methods exist for both, double[] and RealVector input parameters for convenience reasons the constructor only supports RealMatrix objects, as there are a number of required parameters, but a separate one could be added that takes double[][] if this is deemed helpful the initial state and error covariance can be set after construction to reduce the number of parameters in the constructor (no check is yet being made if the filter is still in initialization mode)
        Hide
        Gilles added a comment -

        Thanks! Just a few general remarks (I haven't reviewed the algorithm):

        1. I wonder whether such classes should be "Serializable".
          [There should be a separate discussion about the criteria. Or was there already a decision on that subject?]
        2. Even if so, I don't understand why the matrices are "transient" and deserialized with the methods from "MatrixUtils".
          Since the class creates instances of "Array2DRowRealMatrix", it seems that the default serialization should work.
        3. It is customary to not use capital letters for the initials of method arguments, fields and local variables. [For matrices, it indeed contradicts mathematical notation.]
        4. For the test cases, wouldn't it be interesting to include the examples (stripping the dependencies to "JFreeChart")?
        Show
        Gilles added a comment - Thanks! Just a few general remarks (I haven't reviewed the algorithm): I wonder whether such classes should be "Serializable". [There should be a separate discussion about the criteria. Or was there already a decision on that subject?] Even if so, I don't understand why the matrices are "transient" and deserialized with the methods from "MatrixUtils". Since the class creates instances of "Array2DRowRealMatrix", it seems that the default serialization should work. It is customary to not use capital letters for the initials of method arguments, fields and local variables. [For matrices, it indeed contradicts mathematical notation.] For the test cases, wouldn't it be interesting to include the examples (stripping the dependencies to "JFreeChart")?
        Hide
        Thomas Neidhart added a comment - - edited

        Thanks for the comments!

        @1 & 2: I do not know about a general decision if algo classes should be serializable, but I thought it makes sense in this case. The serialization method was derived from SimplexTableau and the corresponding description in MathUtils. As the different matrix object can also be set from external, they may not all be Array2DRowRealMatrix, but I do not know if this makes a difference for the serialization.

        @3: ack, the member variables have been adjusted already, but the constructor has to be cleaned up

        @4: the constant voltage example (from the paper of Welch & Bishop) is the basis for the test case, but I was really unsure which reasonable test criteria to use for algorithm validation. The very naive approach I currently use is to basically test if the estimated state has less diff to the real value than the artificially imposed measurement/process noise and whether the error covariance converges to some value (although this is not complete yet).

        After some reflection, maybe it makes more sense to split the internal data of the Kalman filter into two parts:

        • elements that model the process to be estimated (transition matrix, measurement matrix, control matrix, initial state)
        • elements that define how the filter tries to estimate the state (mainly the noise covariance matrizen)

        The constructor would then look something like this:

        KalmanFilter(FilterProcessModel model, RealMatrix measurementNoiseCov, RealMatrix processNoiseCov)

        The FilterProcessModel would be serializable, while the KalmanFilter is not.

        Show
        Thomas Neidhart added a comment - - edited Thanks for the comments! @1 & 2: I do not know about a general decision if algo classes should be serializable, but I thought it makes sense in this case. The serialization method was derived from SimplexTableau and the corresponding description in MathUtils. As the different matrix object can also be set from external, they may not all be Array2DRowRealMatrix, but I do not know if this makes a difference for the serialization. @3: ack, the member variables have been adjusted already, but the constructor has to be cleaned up @4: the constant voltage example (from the paper of Welch & Bishop) is the basis for the test case, but I was really unsure which reasonable test criteria to use for algorithm validation. The very naive approach I currently use is to basically test if the estimated state has less diff to the real value than the artificially imposed measurement/process noise and whether the error covariance converges to some value (although this is not complete yet). After some reflection, maybe it makes more sense to split the internal data of the Kalman filter into two parts: elements that model the process to be estimated (transition matrix, measurement matrix, control matrix, initial state) elements that define how the filter tries to estimate the state (mainly the noise covariance matrizen) The constructor would then look something like this: KalmanFilter(FilterProcessModel model, RealMatrix measurementNoiseCov, RealMatrix processNoiseCov) The FilterProcessModel would be serializable, while the KalmanFilter is not.
        Hide
        Benjamin McCann added a comment -

        Thanks for submitting a patch for this!
        I'd agree it probably makes sense not to make it serializable. (I'm surprised the SimplexTableau is serializable since I wrote it and I hate Java serialization)

        Show
        Benjamin McCann added a comment - Thanks for submitting a patch for this! I'd agree it probably makes sense not to make it serializable. (I'm surprised the SimplexTableau is serializable since I wrote it and I hate Java serialization)
        Hide
        Thomas Neidhart added a comment -

        Following the comments from Gilles and Benjamin, I have updated the patch and removed the serialization code.

        Additionally, I have added ProcessModel and MeasurementModel interfaces and default implementations for them that take either double[][] or RealMatrix/RealVector input values. These classes basically serve as data holder. I would be pleased to get some feedback about this change from somebody else.

        Note: sorry for the formatting, but the apache-commons formatting style I have found on the web (from luc) makes the code unreadable, so I have used the default one provided by eclipse.

        Show
        Thomas Neidhart added a comment - Following the comments from Gilles and Benjamin, I have updated the patch and removed the serialization code. Additionally, I have added ProcessModel and MeasurementModel interfaces and default implementations for them that take either double[][] or RealMatrix/RealVector input values. These classes basically serve as data holder. I would be pleased to get some feedback about this change from somebody else. Note: sorry for the formatting, but the apache-commons formatting style I have found on the web (from luc) makes the code unreadable, so I have used the default one provided by eclipse.
        Hide
        Luc Maisonobe added a comment -

        From a quick look, this seems good to me.
        There are still some missing javadoc (on private fields) and missing </i> in the html. It would also be nice to have in the javadoc for KalmanFilter class an explanation of the meaning of the matrices and vectors (A = transition matrix, B control matrix, u control vector ...).

        There is one point that bothers me. The ProcessModel and MeasurementModel interfaces define methods to retrieve the process noise and measurement noise that don't have any parameter. Thus the user can only implement constant noises, not time-dependant noises when he implement the interfaces (or use the default implementation, which are constant). Wouldn't it be more general to add an integer parameter for the step number ? The default implementation would ignore it and always return the same matrices, but users may want to have custom implementation using the informatio of the current step.

        Concerning the formatting you should check the style with checkstyle. Typically, tabulation is completely forbidden and for line breaks, the operators should remain at the end of the previous line, not at the beginning of the next line.

        Show
        Luc Maisonobe added a comment - From a quick look, this seems good to me. There are still some missing javadoc (on private fields) and missing </i> in the html. It would also be nice to have in the javadoc for KalmanFilter class an explanation of the meaning of the matrices and vectors (A = transition matrix, B control matrix, u control vector ...). There is one point that bothers me. The ProcessModel and MeasurementModel interfaces define methods to retrieve the process noise and measurement noise that don't have any parameter. Thus the user can only implement constant noises, not time-dependant noises when he implement the interfaces (or use the default implementation, which are constant). Wouldn't it be more general to add an integer parameter for the step number ? The default implementation would ignore it and always return the same matrices, but users may want to have custom implementation using the informatio of the current step. Concerning the formatting you should check the style with checkstyle. Typically, tabulation is completely forbidden and for line breaks, the operators should remain at the end of the previous line, not at the beginning of the next line.
        Hide
        Gilles added a comment -

        I've corrected most formatting problems (tabs, trailing spaces, etc).
        Initial implementation committed in revision 1134779.

        Show
        Gilles added a comment - I've corrected most formatting problems (tabs, trailing spaces, etc). Initial implementation committed in revision 1134779.
        Hide
        Thomas Neidhart added a comment -

        Thanks for already committing the patch .

        I have worked on the comments from Luc and provided a cleanup patch that corrects the following:

        • added missing javadoc comments
        • fixed checkstyle errors (ignoring method extension warnings as I do not know exactly how or if to resolve them)
        • added package.html
        • processNoise and measurementNoise are now correctly retrieved from the respective models every predict/correct step

        @time-dependant noises:

        I think this makes perfect sense, but I was unsure how to solve this in an optimal way. By now, one could create a specific ProcessModel implementation that returns the "right" process noise at the correct time-step. For a more general case, one would also need the mentioned integer parameter in the predict/correct methods, or do you think about keeping track of the iteration internally in the Kalman filter?

        Show
        Thomas Neidhart added a comment - Thanks for already committing the patch . I have worked on the comments from Luc and provided a cleanup patch that corrects the following: added missing javadoc comments fixed checkstyle errors (ignoring method extension warnings as I do not know exactly how or if to resolve them) added package.html processNoise and measurementNoise are now correctly retrieved from the respective models every predict/correct step @time-dependant noises: I think this makes perfect sense, but I was unsure how to solve this in an optimal way. By now, one could create a specific ProcessModel implementation that returns the "right" process noise at the correct time-step. For a more general case, one would also need the mentioned integer parameter in the predict/correct methods, or do you think about keeping track of the iteration internally in the Kalman filter?
        Hide
        Gilles added a comment -

        Your "cleanup" patch reverts most formatting corrections I had performed . Several statements do not correspond to the most common layouts used elsewhere in the code, making it difficult to read. Could you please use the latest version in trunk and only change what is necessary?

        Show
        Gilles added a comment - Your "cleanup" patch reverts most formatting corrections I had performed . Several statements do not correspond to the most common layouts used elsewhere in the code, making it difficult to read. Could you please use the latest version in trunk and only change what is necessary?
        Hide
        Thomas Neidhart added a comment -

        hmm, actually I have created the diff to the latest trunk version.

        Actually, I have now installed the checkstyle plugin in eclipse and created a formatting profile from the given checkstyle.xml. The only small change I did myself was to remove empty lines before javadoc tags as checkstyle was keeping to complain about them, so this may have been a mistake.

        For the rest, I have made mainly parameter name changes and removed unchecked exceptions in the throws definition.

        It looks like the formatting style I use, wraps lines to quickly sometimes. Is a maximum line width of 80 correct?

        Show
        Thomas Neidhart added a comment - hmm, actually I have created the diff to the latest trunk version. Actually, I have now installed the checkstyle plugin in eclipse and created a formatting profile from the given checkstyle.xml. The only small change I did myself was to remove empty lines before javadoc tags as checkstyle was keeping to complain about them, so this may have been a mistake. For the rest, I have made mainly parameter name changes and removed unchecked exceptions in the throws definition. It looks like the formatting style I use, wraps lines to quickly sometimes. Is a maximum line width of 80 correct?
        Hide
        Gilles added a comment -

        It's a pity that Eclipse would automatically reformat a whole existing file! As people quite possibly use different editors and formatting tools, this could lead to flip-flop of formatting changes...
        Seeing what comes out of the template you have used, it seems best to do the formatting by hand.

        CheckStyle was not complaining about empty lines but lines that end with one or more space characters. Again a single space after the '*' character in a Javadoc comment is probably automatically created by Eclipse. Maybe the CheckStyle rule should be relaxed to allow trailing spaces in comments...

        I think that an 80-character line should not be a hard limit. If there remains only a few characters to finish a statement, I prefer a longer line.
        When the line is really going to be too long, I always try to figure out a layout that will not be too "unnatural".

        Show
        Gilles added a comment - It's a pity that Eclipse would automatically reformat a whole existing file! As people quite possibly use different editors and formatting tools, this could lead to flip-flop of formatting changes... Seeing what comes out of the template you have used, it seems best to do the formatting by hand. CheckStyle was not complaining about empty lines but lines that end with one or more space characters. Again a single space after the '*' character in a Javadoc comment is probably automatically created by Eclipse. Maybe the CheckStyle rule should be relaxed to allow trailing spaces in comments... I think that an 80-character line should not be a hard limit. If there remains only a few characters to finish a statement, I prefer a longer line. When the line is really going to be too long, I always try to figure out a layout that will not be too "unnatural".
        Hide
        Thomas Neidhart added a comment -

        ok thanks for the clarifications, I will take your suggestions into account and provide a new patch.

        Show
        Thomas Neidhart added a comment - ok thanks for the clarifications, I will take your suggestions into account and provide a new patch.
        Hide
        Luc Maisonobe added a comment -

        This is strange. Eclipse does not reformat everything in a file except if you ask it to do so.
        I use Eclipse for [math] development and the only problem I have with formatting is indentation of throws declaration in methods signatures. Everything else works with the Apache-commons profile I set up and published in my Apache web page (I guess it's the one Thomas spoke about in his June 8th comment).

        Do you have some auto-reformatting feature activated or something similar ?

        Show
        Luc Maisonobe added a comment - This is strange. Eclipse does not reformat everything in a file except if you ask it to do so. I use Eclipse for [math] development and the only problem I have with formatting is indentation of throws declaration in methods signatures. Everything else works with the Apache-commons profile I set up and published in my Apache web page (I guess it's the one Thomas spoke about in his June 8th comment). Do you have some auto-reformatting feature activated or something similar ?
        Hide
        Thomas Neidhart added a comment -

        so, this cleanup patch hopefully reverts everything back to the original commit of Gilles (and includes the changes of course).

        Actually you were right, eclipse adds an additional whitespace and thats the reason checkstyle complained.
        Also eclipse did not reformat automatically, but I usually prefer to force a reformat, which works pretty well when the formatter does exactly what you want .

        But I should have asked in advance how it is handled in commons-math, sadly the developer guide is not very clear about that topic.

        Show
        Thomas Neidhart added a comment - so, this cleanup patch hopefully reverts everything back to the original commit of Gilles (and includes the changes of course). Actually you were right, eclipse adds an additional whitespace and thats the reason checkstyle complained. Also eclipse did not reformat automatically, but I usually prefer to force a reformat, which works pretty well when the formatter does exactly what you want . But I should have asked in advance how it is handled in commons-math, sadly the developer guide is not very clear about that topic.
        Hide
        Gilles added a comment -

        [...] sadly the developer guide is not very clear about that topic.

        I agree.

        Latest patch committed in revision 1138461.

        Show
        Gilles added a comment - [...] sadly the developer guide is not very clear about that topic. I agree. Latest patch committed in revision 1138461.
        Hide
        Phil Steitz added a comment -

        Thomas - thanks for the patch!

        One clarifying comment on the formatting trauma. The Developers Guide says only that committed code should generate no checkstyle errors. We don't require or endorse any specific IDE. For all we care, you can use vi. Just run mvn site and look at the checkstyle report or run the checks from the command line. We can talk about relaxing checks on the dev list if we think they are too onerous or picky. Committers can also commit work in progress code that generates errors and fix them as the code is collaboratively refined. We like to keep the code as clean as possible since we end up having to clean it all up when we prepare releases and that is a thankless, boring task.

        Show
        Phil Steitz added a comment - Thomas - thanks for the patch! One clarifying comment on the formatting trauma. The Developers Guide says only that committed code should generate no checkstyle errors. We don't require or endorse any specific IDE. For all we care, you can use vi. Just run mvn site and look at the checkstyle report or run the checks from the command line. We can talk about relaxing checks on the dev list if we think they are too onerous or picky. Committers can also commit work in progress code that generates errors and fix them as the code is collaboratively refined. We like to keep the code as clean as possible since we end up having to clean it all up when we prepare releases and that is a thankless, boring task.
        Hide
        Thomas Neidhart added a comment -

        Thanks for the clarification. The way it is handled is fine for me, also the code formatted by Gilles looks nice.

        There were some problems that made the whole process a bit confusing. The code uses quite long variable names and some method chaining which produced weird results with the original formatter (from luc). As I thought that also other people use automatic formatting, I did not take so much care when originally contributing the patch.

        So, lesson learned for the next time

        Show
        Thomas Neidhart added a comment - Thanks for the clarification. The way it is handled is fine for me, also the code formatted by Gilles looks nice. There were some problems that made the whole process a bit confusing. The code uses quite long variable names and some method chaining which produced weird results with the original formatter (from luc). As I thought that also other people use automatic formatting, I did not take so much care when originally contributing the patch. So, lesson learned for the next time
        Hide
        Luc Maisonobe added a comment -

        So I think the issue has been resolved about one month ago.
        Do everyone agree ?

        Show
        Luc Maisonobe added a comment - So I think the issue has been resolved about one month ago. Do everyone agree ?
        Hide
        Gilles added a comment -

        Coming back to my pet topic, I'd like to note that exceptions from another package (o.a.c.m.linear) are used in this package (o.a.c.m.filter). That means that those exceptions would have been better placed in o.a.c.m.exception (IMHO, of course). Unless it would make sense that the filter package be moved under linear...

        Show
        Gilles added a comment - Coming back to my pet topic, I'd like to note that exceptions from another package ( o.a.c.m.linear ) are used in this package ( o.a.c.m.filter ). That means that those exceptions would have been better placed in o.a.c.m.exception (IMHO, of course). Unless it would make sense that the filter package be moved under linear ...
        Hide
        Luc Maisonobe added a comment -

        As now these exceptions are used in several packages, yes, they should go to the general exception package.

        Show
        Luc Maisonobe added a comment - As now these exceptions are used in several packages, yes, they should go to the general exception package.
        Hide
        Phil Steitz added a comment -

        I don't want to launch another endless exception design discussion, but I disagree with that statement. That is like saying that matrices themselves should move to whatever package uses them. The exceptions have to do with linear algebraic objects. It makes sense and is generally accepted best practice to define the exceptions in the packages where associated objects are found. Other packages, user code, etc. import the exceptions associated with the objects that they use.

        Show
        Phil Steitz added a comment - I don't want to launch another endless exception design discussion, but I disagree with that statement. That is like saying that matrices themselves should move to whatever package uses them. The exceptions have to do with linear algebraic objects. It makes sense and is generally accepted best practice to define the exceptions in the packages where associated objects are found. Other packages, user code, etc. import the exceptions associated with the objects that they use.
        Hide
        Benjamin McCann added a comment -

        Hey guys, just wanted to say thanks for implementing this feature request!
        I can't comment on this particular case since I'm not familiar enough with the code, but in general it makes sense for exceptions to be used outside of the packages they live in. E.g. think about how many places catch and use Java's IOException. Of course it still may make sense to refactor in this case, but I can't say one way or the other.

        Show
        Benjamin McCann added a comment - Hey guys, just wanted to say thanks for implementing this feature request! I can't comment on this particular case since I'm not familiar enough with the code, but in general it makes sense for exceptions to be used outside of the packages they live in. E.g. think about how many places catch and use Java's IOException. Of course it still may make sense to refactor in this case, but I can't say one way or the other.
        Hide
        Thomas Neidhart added a comment -

        Hi all,

        just wanted to note that I am still working on a user guide and more unit tests, but I can create a new issue for this when I am ready, in order to close this one.

        Show
        Thomas Neidhart added a comment - Hi all, just wanted to note that I am still working on a user guide and more unit tests, but I can create a new issue for this when I am ready, in order to close this one.
        Hide
        Gilles added a comment -

        > > [...] That means that those exceptions would have been better placed in o.a.c.m.exception [...]
        >
        > [...] That is like saying that matrices themselves should move to whatever package uses them.
        > The exceptions have to do with linear algebraic objects. It makes sense and is generally
        > accepted best practice to define the exceptions in the packages where associated objects are
        > found. [...]

        I consider that a lot of exceptions are at the same level as any other class of the library: They are not subsumed to a particular data structure but to the various uses of that data structure. A matrix is not right or wrong in itself[1]; whether to throw a NonSquareMatrixException depends on the algorithm in which the matrix is used and absolutely not on the matrix concept itself.
        So I think that in CM, we can make a difference between exceptions that are tied to a specific data structure[2] and those which are first-class citizens and of general use, in which case they should go in their own "exception" package.

        [1] Unlike, say, a string which can be a valid or an invalid representation of a number.
        [2] For cases where there exists a link like between Number and NumberFormatException.

        Show
        Gilles added a comment - > > [...] That means that those exceptions would have been better placed in o.a.c.m.exception [...] > > [...] That is like saying that matrices themselves should move to whatever package uses them. > The exceptions have to do with linear algebraic objects. It makes sense and is generally > accepted best practice to define the exceptions in the packages where associated objects are > found. [...] I consider that a lot of exceptions are at the same level as any other class of the library: They are not subsumed to a particular data structure but to the various uses of that data structure. A matrix is not right or wrong in itself [1] ; whether to throw a NonSquareMatrixException depends on the algorithm in which the matrix is used and absolutely not on the matrix concept itself. So I think that in CM, we can make a difference between exceptions that are tied to a specific data structure [2] and those which are first-class citizens and of general use, in which case they should go in their own "exception" package. [1] Unlike, say, a string which can be a valid or an invalid representation of a number. [2] For cases where there exists a link like between Number and NumberFormatException .
        Hide
        Luc Maisonobe added a comment -

        Can we consider this issue solved ?

        Show
        Luc Maisonobe added a comment - Can we consider this issue solved ?
        Hide
        Gilles added a comment -

        Well, the sub-issue of where to place the exceptions is not. But I guess that we'll settle for the minority's opinion...

        Show
        Gilles added a comment - Well, the sub-issue of where to place the exceptions is not. But I guess that we'll settle for the minority's opinion...
        Hide
        Thomas Neidhart added a comment -

        I have been a bit lazy with the guide and unit tests, but please find attached an update of the unit tests for the Kalman Filter and a first draft of a user guide to be included into the site.

        The guide contains a lot of code, but I wanted to give a working example of how to use the Kalman filter. Any comments are welcome.

        Show
        Thomas Neidhart added a comment - I have been a bit lazy with the guide and unit tests, but please find attached an update of the unit tests for the Kalman Filter and a first draft of a user guide to be included into the site. The guide contains a lot of code, but I wanted to give a working example of how to use the Kalman filter. Any comments are welcome.
        Hide
        Luc Maisonobe added a comment -

        Latest patch applied, with new tests and user guide.

        Thanks for the patch!

        Show
        Luc Maisonobe added a comment - Latest patch applied, with new tests and user guide. Thanks for the patch!

          People

          • Assignee:
            Unassigned
            Reporter:
            Benjamin McCann
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development