Working with Mercurial
This is essentially the first time I'm using Mercurial for revision control, though I have used git before. However I quickly learned how to use it for the basic tasks that I need, committing, comparing files and checking the history. As mentioned in a previous post you can find my repository here [1].Coding style
When I started to work with the files I realized that they did not follow Octaves coding standard [2]. After a short discussion on the mailing list we decided that I will update the files I change to follow the standard coding style. Usually it is not a good idea to change coding style and add functionality in the same commit. However most of the changes to coding style are only white space changes so they can be ignored using the -w flag in Mercurial. Thus we decided that as long as the coding style changes are only such that it is ignored with -w I will do it in the same commit as the added functionality. If there are some coding style changes that's not only white space, the most common example is to long lines, I do a commit with only changes to the coding style first. So if you want to take a look at the functionality I have added you will probably want to use the -w flag. Note however that I have not updated the coding style for any files I have not changed otherwise.Committing
Normally I do one commit for each file, though in many cases the bare intervals and the decorated intervals have almost identical functions and in that case I commit changes to them both at the same time. Of course it also happens that I have to go back and do more changes to a files, in that case I just do another commit.The actual work
The work went much faster than I expected. The main reason for this is that Octave has very good support for indexing. For example expressions likeisnai(x.inf <= x.sup) = false;
works just as well for matrices as for N-dimensional arrays. In fact the constructor for bare intervals even worked for N-dimensional arrays from the beginning, there I only had to do slight modification to the documentation and add some tests!
Not all functions were that easy though. Some functions that have not been updated in a while clearly assumed the input was a matrix, for example in $hull$
sizes1 = cellfun ("size", l, 1);
sizes2 = cellfun ("size", l, 2);
In most cases I only needed to add more general indexing, often times even making the code clearer.
In some functions all I had to do was to remove the check on the input data so that it would accept N-dimensional arrays. This was true in for example $cat$ were all I had to do was to remove the check and do some minor modifications to the documentation.
I can conclude with saying that Octave has great support for working with N-dimensional arrays. Since internally the data for intervals are stored only as arrays I could make good use of it!
Noteworthy things
While most functions were straight forward to modify some required some thought. How should they even work for N-dimensional input?Disp
When modifying the $disp$-function I chose to mimic how Octave handles displaying N-dimensional arrays. I noticed that this is different from how Matlab handles it. In Matlab we have> x = zeros (2, 2, 2)
x(:,:,1) =
0 0
0 0
x(:,:,2) =
0 0
0 0
while in Octave it's
> x = zeros (2, 2, 2)
x =
ans(:,:,1) =
0 0
0 0
ans(:,:,2) =
0 0
0 0
I don't know the choice behind Octaves version. At least at first glance I think I prefer the way Matlab does it. But since I'm working in Octave I chose that style.
The next question was how to handle the subset symbol, $\subset$. The interval package uses $=$ or $\subset$ depending on if the string representation is exact or not. For example
> x = infsup (1/2048, 1 + 1/2048);
> format short; x
x ⊂ [0.00048828, 1.0005]
> format long; x
x = [0.00048828125, 1.00048828125]
How should this be handled for N-dimensional arrays? One way would be to switch all $=$ to $\subset$ is the representation is not exact. Another to use $\subset$ on all submatrices that does not have an exact string representation. The third way, and how it is implemented now, is to only change the first $=$ to $\subset$, the one after the variable name. Like this
> x(1,1,1:2) = infsup (1/2048, 1 + 1/2048)
x ⊂ 1×1×2 interval array
ans(:,:,1) = [0.00048828, 1.0005]
ans(:,:,2) = [0.00048828, 1.0005]
This might be a bit odd when you first look at it, on some places we use $=$ and on some $\subset$. Though I think it somehow makes sense, we are saying that $x$ is a subset of the $1\times1\times2$ interval array given by
ans(:,:,1) = [0.00048828, 1.0005]
ans(:,:,2) = [0.00048828, 1.0005]
which actually is true. Anyway I will leave like this for now and then we might decide to switch it up later.
linspace and mince
The standard implementation of $linspace$ only supports scalar or vector input. It could be generalized to N-dimensional arrays by for example returning a N+1-dimensional array were the last dimension corresponds to the linearly spaced elements. But since this has not been done in the standard implementation I will at least wait with adding for intervals.The function $mince$ can be seen as a interval generalization of $linspace$. It takes an interval and returns an array of intervals whose union cover it. This could similarly be expanded to N dimensions by creating the array along the N+1 dimension. But again we choose to at least wait with adding this.
meshgrid and ndgrid
The interval package already has an implementation of $meshgrid$. But since it previously did not support 3-dimensional arrays it had to fit 3-d data in a 2-d matrix. Now that it supports 3-d data it can output that instead.Currently the interval package does not implement $ndgrid$. When I looked into it I realized that the standard implementation of $ndgrid$ actually works for interval arrays as well. I have not looked into the internals but in principle it should only need the $cat$ function, which is implemented for intervals. Further I noticed that the standard $meshgrid$ also works for intervals. However the interval implementation differs in that it converts all input to intervals, were as the standard implementation allows for non-uniform output. Using the interval implementation of $meshgrid$ we have
> [X Y] = meshgrid (infsup (1:3), 4:6)
X = 3×3 interval matrix
[1] [2] [3]
[1] [2] [3]
[1] [2] [3]
Y = 3×3 interval matrix
[4] [4] [4]
[5] [5] [5]
[6] [6] [6]
but if we fall back to the standard implementation (by removing the interval implementation) we get
> [X Y] = meshgrid (infsup (1:3), 4:6)
X = 3×3 interval matrix
[1] [2] [3]
[1] [2] [3]
[1] [2] [3]
Y =
4 4 4
5 5 5
6 6 6
Note that the last matrix is not an interval matrix.
So the question is, should we implement a version of $ndgrid$ that converts everything to intervals or should we remove the implementation of $meshgrid$? It's at least most likely not a good idea that the functions are different. I think that removing the implementation of $meshgrid$ makes most sense. First of all it's less code to maintain, which is always nice. Secondly you can manually convert all input to the function to intervals if you want uniform output. If you do not want uniform output then the standard implementation works were as the interval implementation does not, so the standard implementation is more general in a sense.
We have to choose what to do, but for now I leave it as it is.
Non-generalizable functions
From what I have found there is no way to create a 3-dimensional array in Octave in the same way you can create a 2-dimensional one with for exampleM = [1, 2; 3, 4];
Instead higher dimensional arrays have to be created using other functions, for example $reshape$ or $zeros$, or by specifying the submatrices directly
M(:,:,1) = [1, 2; 3, 4];
M(:,:,2) = [5, 6; 7, 8];
This means that the functions $\_\_split\_interval\_literals\_\_$, which is used to split a string like $"[1, 2; 3, 4]"$ into its separate components, cannot really be generalized to N dimensions.
[1] https://sourceforge.net/u/urathai/octave/ci/default/tree/
[2] http://wiki.octave.org/Octave_style_guide
No comments:
Post a Comment