chebfun / chebfun

Chebfun: numerical computing with functions.

About

Chebfun is an open-source software system for numerical computing with functions. The mathematical basis of Chebfun is piecewise polynomial interpolation implemented with what we call “Chebyshev technology”. The foundations are described, with Chebfun examples, in the book Approximation Theory and Approximation Practice. Chebfun has extensive capabilities for dealing with linear and nonlinear differential and integral operators, and it also includes continuous analogues of linear algebra notions like QR and singular value decomposition. The Chebfun2 extension works with functions of two variables defined on a rectangle in the x-y plane. To get a sense of the breadth and power of Chebfun, a great place to start is by looking at our Examples.

Installation and requirements

Chebfun is compatible with MATLAB 7.8 (R2009a) and later.

To install, you can either clone the directory with Git or download a .zip file. Note that a call to clear classes is required if you had a previous version of Chebfun installed.

Option 1: Download .zip file

Download a .zip of Chebfun from

• https://github.com/chebfun/chebfun/archive/master.zip

After unzipping, you will need to add Chebfun to the MATLAB path. You can do this either (a) by typing

addpath(chebfunroot), savepath

where chebfunroot is the path to the unzipped directory, (b) by selecting the chebfun directory with the pathtool command, or (c) though the File > Set Path... dialog from the MATLAB menubar.

Option 2: Clone with Git

To clone the Chebfun repository, first navigate in a terminal to where you want the repository cloned, then type

git clone https://github.com/chebfun/chebfun.git

To use Chebfun in MATLAB, you will need to add the chebfun directory to the MATLAB path as above.

Getting started

We recommend taking a look at the Chebfun Guide and the Examples collection. The Guide is an in-depth tour of Chebfun's mathematical capabilities. The Examples, which number well over one hundred, illustrate everything from rootfinding to optimization to nonlinear differential equations and vector calculus. Many users use the Examples as templates for their own problems.

To get a taste of what computing with Chebfun is like, type

x = chebfun('x');

and start playing. The variable x is a chebfun and can be manipulated in a way that feels symbolic, although everything Chebfun does is numeric. So try, for instance:

f = sin(12*x).*exp(-x);         % A function on [-1, 1]
g = max(f, 1./(x+2));           % The max of f and 1./(x+2)
plot(g)                         % A function with discontinuous derivative
sum(g)                          % The integral of g
plot(diff(g))                   % The derivative of g
h = g + x - .8;                 % A function with several roots in [-1, 1]
rr = roots(h);                  % Compute the roots of h
plot(h, 'k', rr, h(rr), 'ro')   % Plot h and its roots

License

See LICENSE.txt for Chebfun's licensing information.

chebfun's Issues

chebpoly of an array-valued chebfun

If f is an array-valued chebfun, then the chebpoly command seems to return the transpose of the correct result. Is there a fundamental reason for this?

For example,

f = chebfun(@(x) [x x.^2]);
chebpoly(f)

ans =

     0    1.0000         0
0.5000         0    0.5000

Since f is a chebfun of size Inf-by-2, should chebpoly return a 3-by-2 matrix instead?

Tests for the plotting subsystem.

I think I shied away from this earlier, but I'm going to come out in full support of it now: we need some tests for the plotting subsystem. It's way too easy to muck around with something in any of the plotData() methods and break functionality in subtle ways, especially when array-valued chebfuns are involved. The tests can only be automated to the extent that it checks to see if things crash, but that may be good enough for many purposes. If serious changes are made to the plotting subsystem, we can run the tests manually and examine the results.

'jumpline' is missing

The jumpline option in PLOT needs to be implemented.

Bug in mergeDomains causing infinite loop

This is my first post, so please be kind.

I discovered a bug in mergeDomains causing an infinite loop when testing some of the new linop stuff. Code to create the bug:

d = [-2,0];
I = linop.eye(d);

The issue is related to the choice of domain and appears to be at line 38:

tol = 10*eps*max(cellfun(@max, doms));

Since the maximum value in doms (which is set equal to d) is 0, tol is set equal to zero which causes the while loop at line 49 to never terminate.

The bug is that line 38 should be determining the maximum value, in magnitude of doms.

I fixed the bug by replacing line 38 with the code:

tol = 10*eps*max(abs(cell2mat(doms)));

My (limited) testing seemed to indicate that this indeed corrected the issue.

I have no idea yet how to use git to put this change in the repository. Hopefully someone can help me with that.

-Grady

Bug for isempty of array-valued chebfuns

f = chebfun(@(x) x);
g = chebfun(@(x) x.^2);
h = [f g];

isempty(h)
Error using numel
Bad subscripting index.

Error in chebfun/isempty (line 9)
if ( (numel(f.funs) > 0) && ~isempty(f.funs(1)) )

null() is missing in feature-chebfun-divide

Plotting of constant CHEBFUN objects fails

>> plot(chebfun(1))
Error using set
Bad property value found.
Object Name: axes
Property Name: 'YLim'
Values must be increasing and non-NaN.
Error in chebfun/plot (line 152)
set(gca, 'ylim', ylimit) 

I believe that the issue is caused by the need for functions which blowup to adjust their ylims.

chebfun.mat2cell() and chebfun.num2cell() do not conform to their built-in counterparts.

The syntax for chebfun.mat2cell() offers a shortcut mat2cell(f) which splits each fun of f into a cell in a cell array. If A is a matrix, MATLAB mat2cell(A) puts the entire matrix A into a single cell, and a warning is issued indicating that single-argument calls to mat2cell() are deprecated. If you want each element of A to be put into a cell of its own you must either pass the appropriate other arguments to mat2cell() or call num2cell(A) as a shortcut.

There is thus a discrepancy between chebfun.mat2cell() and the built-in mat2cell(). Moreover, the existence of the shortcut syntax for chebfun.mat2cell() makes chebfun.num2cell() completely redundant. We should either (A) decide that we don't want to worry about conforming to MATLAB on this and remove chebfun.num2cell() or (B) fix the syntax of these functions to be the same as their built-in counterparts.

This is not terribly important, and it can be fixed whenever someone has some spare time.

Constructing the Gamma function

The following works in V4, but fails catastrophically in V5:

>> gam = chebfun('gamma(x)',[-4 4],'blowup','on','splitting','on')
gam = 
   chebfun column (38 smooth pieces)
       interval       length   endpoint values   endpoint exponents
[      -4,      -4]       62   5.6e+11        0         [0      0]  
[      -4,      -4]       61   2.1e+08  6.3e+06         [0      0]  
[      -4,      -4]       62   6.3e+06  1.9e+05         [0      0]  
[      -4,      -4]      124   1.9e+05        0         [0      0]  
[      -4,      -3]        1         0        0         [1.2e-10      0]  
[      -3,      -3]       62   2.2e+07  2.2e+09         [0      0]  
[      -3,      -3]       62         0  6.1e+12         [0.0012      0]  
[      -3,      -3]       30  -9.8e+13        0         [0      0]  
[      -3,      -3]       30  -1.7e+11        0         [0      0]  
[      -3,      -3]       62  -1.7e+09 -1.7e+07         [0      0]  
[      -3,      -3]      104  -1.7e+07 -1.7e+05         [0      0]  
[      -3,      -3]      125  -1.7e+05 -1.7e+03         [0      0]  
[      -3,      -2]        3         0        0         [8e-11      0]  
[      -2,      -2]       62  -2.8e+07 -2.8e+09         [0      0]  
[      -2,      -2]       62         0 -2.8e+11         [0      0]  
[      -2,      -2]      126         0 -1.6e+15         [0.039      0]  
[      -2,      -2]      126   4.8e+12        0         [0      0]  
[      -2,      -2]       10   4.4e+08  2.2e+08         [0      0]  
[      -2,      -2]       11   2.2e+08  1.1e+08         [0      0]  
[      -2,      -2]       13   1.1e+08  5.5e+07         [0      0]  
[      -2,      -2]       11   5.5e+07  2.7e+07         [0      0]  
[      -2,      -2]      121   2.7e+07  1.1e+05         [0      0]  
[      -2,      -2]       57   1.1e+05  8.3e+02         [0      0]  
[      -2,      -1]       13         0        0         [2e-11      0]  
[      -1,      -1]       62   1.1e+08  1.1e+10         [0      0]  
[      -1,      -1]       30         0    1e+12         [0      0]  
[      -1,      -1]      126         0  6.8e+15         [0.037      0]  
[      -1,      -1]      126  -9.7e+12        0         [0      0]  
[      -1,      -1]       10  -8.9e+08 -4.5e+08         [0      0]  
[      -1,      -1]       11  -4.5e+08 -2.2e+08         [0      0]  
[      -1,      -1]       11  -2.2e+08 -1.1e+08         [0      0]  
[      -1,      -1]       12  -1.1e+08 -5.6e+07         [0      0]  
[      -1,      -1]       12  -5.6e+07 -2.8e+07         [0      0]  
[      -1,      -1]       12  -2.8e+07 -1.4e+07         [0      0]  
[      -1,      -1]      118  -1.4e+07 -5.4e+04         [0      0]  
[      -1,      -1]       61  -5.4e+04        0         [0      0]  
[      -1,2.2e-308]       11         0     -Inf         [0      -1]  
[2.2e-308,       4]       27       Inf        6         [-1      0]  
Epslevel = 1.000000e-04.  Vscale = 6632608757803206.  Total length = 2029.

Constructing from constant strings.

This is supported in V4 (and used in a number of examples), but breaks in V5:

>> chebfun('1')
Error using chebfun>str2op (line 433)
Incorrect number of independent variables in string input.
Error in chebfun>parseInputs (line 539)
        op = str2op(op);
Error in chebfun (line 144)
            [op, dom, pref] = parseInputs(varargin{:});

Methods properties

In classdef files, Matlab does not require you to state method properties if they are the default ones, i.e. non-static, non-abstract, public, etc. As a good programming and code-style habit, do we want to declare these properties nevertheless in the classdef files, as it adds a bit of clarity (and I don't see it removing any, or causing any issues)? This is something we'd just have to do once and presumably requires no maintenance.

Add a permute() method for chebfun.

This would basically be a wrapper for transpose(). If we do this, we can have the block at the end of the clause in subsref() which handles '()' indexing types handle both chebfun and numeric outputs in the same manner.

What is the vScale of a SINGFUN?

The vScale off a CHEBTECH is the largest value contained in its .values field. SINGFUN simply borrows this as its own vScale.

However, the exponents in SINGFUN warp this value, and at the CHEBFUN level something this can therefore return something meaningless.

>> f = abs(x).^1.01
f = 
   chebfun column (2 smooth pieces)
       interval       length   endpoint values   exponents 
[      -1,       0]        1         1        0   0    1   
[       0,       1]        1         0        1   1    0   
Epslevel = 6.492624e-16.  Vscale = 5.000000e-01.  Total length = 2.

A user might expect the above to have a vScale approx = 1, but here it is a half.

It's probably easy to come up with much more extreme examples.

Vertcat of chebfun objects

I cannot remember what we wanted the vertcat of chebfun objects to do. Probably we want a chebmatrix. Is that right? At the moment it gives an error:

t = chebfun('t');
[t;t];
Undefined function 'chebmatrix' for input arguments of
type 'cell'.

Error in chebfun/vertcat (line 17)
out = chebmatrix(varargin.');

Chebpts and jacpts on general intervals [a,b]

When chebpts and jacpts are upstream then bug #319 from trac needs fixing in version 5.

Overwrite the chebpref default display

To show more information for the substructures, e.g. singPrefs and techPrefs.

Copyright statement

Just as a reminder, we want to update the copyright information in all files to include 2014 before the beta release.

Bug in chebfun/plot3

There is a bug in plot3:

x = chebfun('x');
y = chebfun('y');
z = chebfun('z');
plot3(x,y,z)

Error using plot3
Vectors must be the same lengths.

Error in chebfun/plot3 (line 106)
h3 = plot3(data.xJumps, data.yJumps, data.zJumps,
varargin{:});

It should be returning the same plot as:

plot3([-1 1],[-1 1],[-1 1])

Execution time of CHEBTESTS.

I propose that tests should generally take less than two seconds to run. If they take more they should (where possible) be split in to different files.

The reason for this is mostly cosmetic, but it's important to give a good impression. In particular when it's taking 10 seconds for a test to pass by, the system looks slow; when many test whiz by in a few seconds, it looks fast.

VANDER() is not consistent with MATLAB built-in

>> vander(chebpts(5))
ans =
    1.0000   -1.0000    1.0000   -1.0000    1.0000
    0.2500   -0.3536    0.5000   -0.7071    1.0000
         0         0         0         0    1.0000
    0.2500    0.3536    0.5000    0.7071    1.0000
    1.0000    1.0000    1.0000    1.0000    1.0000
>> get(vander(chebfun('x'), 5), 'values')
ans =
    1.0000   -1.0000    1.0000   -1.0000    1.0000
    1.0000   -0.7071    0.5000   -0.3536    0.2500
    1.0000         0         0         0         0
    1.0000    0.7071    0.5000    0.3536    0.2500
    1.0000    1.0000    1.0000    1.0000    1.0000

Probably all that is needed is a FLIPLR() of the result.

SIMPLIFY not receiving PREF.TOL from chebtech/times.m

In the @chebtech folder, the TIMES command is not passing the tolerance in PREF to the command SIMPLIFY. It probably should be.

This is on the feature-chebtech-coeffs branch, if that makes a difference.

Legpoly should be the right degree

I count this as a bug:

legpoly(100)

ans =

chebfun column (1 smooth piece)
interval length endpoint values
[ -1, 1] 202 1 1
Epslevel = 2.220446e-16. Vscale = 1.000000e+00.

The length is always 2(N+1) because the inner product is enforced using Clenshaw-Curtis quadrature, and a 2(N+1) rule ensures exactness. One could get around this by doing:

legpoly(100,[-1,1],0,1)

ans =

chebfun column (1 smooth piece)
interval length endpoint values
[ -1, 1] 101 1 1
vertical scale = 1

but that seems excessive!

chebfun(f) where f is a chebfun

In v4 we've been able to do g = chebfun(f), where f is a chebfun (useful for a bunch of applications). This needs to be implemented in v5.

chebellipseplot is missing

chebellipseplot needs to be implemented

Use real eigenvalue problems in roots() for complex chebfuns.

Nick Hale suggests that since eigenvalue problems are presumably faster in real arithmetic, when we go to compute the roots of a complex-valued chebfun f, we might consider computing the roots of real(f) instead and then checking to make sure that f is small at each value.

another kind of plot for a complex chebfun

The way Chebfun plots a complex chebfun is as a curve in the complex plane. I would like to have an alternative way to plot a complex chebfun (specified either as a flag or by another function entirely) that plots the real and imaginary parts over each other, as in this plot.

In MATLAB this can currently be accomplished by the simple code

plot(real(f), 'b', imag(f), 'r-')

but I think it deserves to be incorporated as a part of the system.

Plotting functions which diverge to infinity

We need a more reliable way of adjusting the y axis limits for functions which blow up.

V4 seemed OK at this, so perhaps we should just mimic that behaviour.

Clenshaw algorithm

Profiling CHEBTEST('chebtech') shows that a lot of time is spent in CHEBTECH/CLENSHAW_SCL() by the two lines

    bk2 = bk1; 
    bk1 = bk;

(See below for the full code). Using DEAL() is even slower.

One can get around this by always taking two steps within the same FOR loop, and adjusting at the end if the degree of the CHEBTECH is odd.

In particular, here is some alternative code:

function y = clenshaw_scl(x, c)
% Clenshaw scheme for scalar-valued functions.
bk1 = zeros(size(x)); 
bk2 = bk1;
x = 2*x;
n = size(c,1)-1;
for k = 1:2:n-1
    bk2 = c(k) + x.*bk1 - bk2;
    bk1 = c(k+1) + x.*bk2 - bk1;
end
if ( mod(n, 2) )
    [bk1, bk2] = deal(c(n) + x.*bk1 - bk2, bk1);
end
y = c(end) + .5*x.*bk1 - bk2;
end

Using this I find the time for CHEBTEST('chebtech') drops from around 10 seconds to around 8.5 seconds on my machine. (Note, there may be some reason to believe that the length is more likely to be odd than even - for example, during construction - so it might be worth changing this slightly). Also, there's no reason to not to expect CLENSHAW_VEC() to be improved by a similar approach.

Here is the existing code for comparison:

function y = clenshaw_scl(x, c)
% Clenshaw scheme for scalar-valued functions.
bk1 = zeros(size(x)); 
bk2 = bk1;
x = 2*x;
for k = 1:size(c,1)-1
    bk = c(k) + x.*bk1 - bk2;
    bk2 = bk1; 
    bk1 = bk;
end
y = c(end) + .5*x.*bk1 - bk2;
end

Inconsistency between CHEBFUN/CHEBPOLY() and CHEBFUN/LEGPOLY()

Take, for example, the absolute value function:

>> f = chebfun(@abs, [-1 0 1]);

This is the syntax for using CHEBPOLY(): (The zeros indicates 'global')

>> chebpoly(f, 0, 10)
ans =
  Columns 1 through 4
   0.000000000000000  -0.020210151503733   0.000000000000000   0.036378272706718
  Columns 5 through 8
   0.000000000000000  -0.084882636315678  -0.000000000000000   0.424413181578387
  Columns 9 through 10
  -0.000000000000000   0.636619772367581

And here's LEGPOLY():

>> legpoly(f, 10)
ans =
  Columns 1 through 4
   0.047851562499999   0.000000000000000  -0.066406249999999  -0.000000000000000
  Columns 5 through 8
   0.101562500000002  -0.000000000000000  -0.187500000000000   0.000000000000000
  Columns 9 through 11
   0.625000000000000                   0   0.500000000000000

Also note that one has length 10, and the other length 11..

max in chebfun when one argument is double

For a chebfun x, this fails:
hat = max(2_abs(x)-1, 0 )
however, this works:
hat = max(2_abs(x)-1, chebfun(0) )

A quick look at chebfun/max reveals that the case when one argument is a double is not dealt with. Probably this should be part of the test as well.

Mohsin

a minor error in chebtech?

Line 201 in chebtech.m@chebtech
if ( strcmpi(pref.chebtech.tech, 'chebtech1') )

Should the character string against which we compare be 'cheb1'?

Plotting chebmatrices

When plotting chebmatrices consisting of chebfuns, the color property does not always seem to be as one expects:

x = chebfun('x');
xx = [x; 2*x];
plot(xx, '.-')

Here, I'd expect the plot to have two lines, blue and green respectively, with dots at the Chebyshev points. Instead, both lines turn out to be blue.

This issue arises in feature-newlinop, and branches derived from it.

@SINGFUN/COMPOSE() doesn't exist

>> f = chebfun(@(x) sqrt(x), [0 1], 'blowup', 'on')
f = 
   chebfun column (1 smooth piece)
       interval       length   endpoint values   endpoint exponents
[       0,       1]        1         0        1         [0.5      0]  
Epslevel = 6.492624e-16.  Vscale = 7.071068e-01.

>> sin(f)
Undefined function 'compose' for input arguments of type 'singfun'.
Error in bndfun/compose (line 62)
        f.onefun = compose(f.onefun, op, g, pref);
Error in chebfun/compose>columnCompose (line 182)
        newFun = compose(f.funs{k}, op, [], pref);
Error in chebfun/compose (line 131)
        f = columnCompose(f, op, g, pref, opIsBinary);
Error in chebfun/sin (line 21)
F = compose(F, @sin, varargin{:}); 

understand the algorithm for subspace and improve the test

I would have given a super-low-priority label if there is such a thing in github.

Add 'interval' option to chebfun.plot().

In Chebfun v4, we can plot a function on a subinterval using either plot(f, 'interval', [a b]) or plot(f, [a b]). We need to reinstate this functionality in Chebfun v5.

Tests for *pts().

The *pts() family of functions are all in need of tests. This includes:

• chebpts()
• legpts()
• jacpts()
• radaupts()
• lobpts()

Bug in POLYFIT (2).

Column CHEBFUN with breakpoints : OK.
Row CHEBFUN without breakpoints : OK.

Row CHEBFUN wit breakpoints : NOT OK.

Error using zeros
NaN and Inf not allowed.

Error in chebfun/legpoly>legpolyPiecewise (line 55)
out = zeros(n+1, size(f, 2)); % Initialise storage.

Error in chebfun/legpoly (line 27)
out = legpolyPiecewise(f, varargin{:});

Error in chebfun/polyfit>continuousPolyfit (line 82)
cleg = legpoly(f, n).';

chebfuns and empty matrices

1. If F is a chebfun and x is an empty column matrix of any length, the call F(x) returns an empty 0-by-0 matrix (i.e. []) rather than an empty matrix of the same size. This is annoying because then the expression x + F(x) does not work; even though there are no numbers being calculated, MATLAB complains that the matrix dimensions don't agree.
2. If F is a chebfun and y is an empty row matrix of any length, the call F(y) results in an error.

On the other hand, MATLAB builtins like sin, abs, etc., always return a matrix of the same size as input.

Diary:

>> f = chebfun(@sin);
>> z = ones(1,0);
z =
   Empty matrix: 1-by-0
>> sin(z)
ans =
   Empty matrix: 1-by-0
>> f(z)
ans =
     []
>> z = ones(0,1);
>> sin(z)
ans =
   Empty matrix: 0-by-1
>> f(z)
Index exceeds matrix dimensions.
Error in chebfun/subsref (line 90)
            out = out(:, outCols(:), extraColons{:});

Augment assignColums() to allow assignment to empty chebfuns.

When reviewing the feature-chebfun-divide branch, Kuan Xu pointed out that the following does not work:

>> g = chebfun({@(x)sin(x) @(x)cos(x)}, [-1 0 1]);
>> f = chebfun;
>> h = assignColumns(f, 1, g);
Error using chebfun/assignColumns (line 63)
Index exceeds CHEBFUN dimensions.

The reason is that f is an empty chebfun, and so it has no columns that can be assigned. MATLAB, on the other hand, allows assignment for empty arrays:

>> A = []
A =
     []
>> A(:, 3) = [1 ; 2 ; 3]
A =
     0     0     1
     0     0     2
     0     0     3

To be in-line with MATLAB, we should enhance assignColumns() to work in this case as well.

Bug in POLYFIT.

In CONTINUOUSPOLYFIT(), line 75, when constructing a best L2 polynomial approximation of degree N to a given chebfun of length < N, 'Attempt to reference field of non-structure array'.
Replacing line 75 by:

if ( n > length(f) && numel(f.funs) == 1 )

makes the code work.

Hadrien

Constructing functions with simple poles

Both of these attempts at creating 1./x fail.

>> x = chebfun('x')
x = 
   chebfun column (1 smooth piece)
       interval       length   endpoint values  
[      -1,       1]        2        -1        1 
Epslevel = 6.492624e-16.  Vscale = 1.
>> 1./x
Error using  ~ 
NaN's cannot be converted to logicals.
Error in chebtech/compose (line 82)
if ( ~f.epslevel )
Error in chebtech2/compose (line 65)
f = compose@chebtech(f, op, g, pref);
Error in  ./  (line 58)
        f = compose(c, op, [], pref);
Error in  ./  (line 38)
    g.onefun = rdivide(f, g.onefun, varargin{:});
Error in chebfun/rdivide>columnRdivide (line 179)
        h.funs{k} = rdivide(f, g.funs{k});
Error in  ./  (line 95)
            h(k) = columnRdivide(f(k), g, pref); 

>> f = chebfun(@(x) 1./x, [-1 0 1], 'blowup', 'on')
Error using chebfun.constructor (line 89)
the number of the exponents is inappropriate.
Error in chebfun (line 167)
                [f.funs, f.domain] = chebfun.constructor(op, dom, pref); 

Logical operations for singfun.

singfun needs to support the following logical operations in the same way that chebtech does:

• any()
• and()
• logical()
• not()
• or()

Are we going to replace all bary with clenshaw in chebtech and smoothfun for function evaluation?

Now we're still using bary in:

@chebtech/prolong.m
@chebtech1/get.m
@smoothfun/smoothfun.m

Tests and documentation related to quasimatrices.

The following still need to be finished:

tests:

• subsasgn
• subsref
• vertcat

documentation:

• quasimatrix
• roots
• subsasgn
• subsref
• vertcat
• display

Tidy up PREF related documentation in @chebtech/@chebtech1/@chebtech2

Shall things like CHEBTECH.PREF be changed to CHEBTECH.TECHPREF?

A partial list using grep:

./@chebtech/chebtech.m:% CHEBTECH.PREF for details. The CHEBTECH class supports construction via
./@chebtech/chebtech.m:% p.gridType = 2; % See CHEBTECH.PREF.
./@chebtech/chebtech.m:% See also CHEBTECH.PREF, HAPPINESSCHECK, CHEBTECH1, CHEBTECH2.
./@chebtech/chebtech.m:% CHEBTECH.PREF().GRIDTYPE property, which should be set to either 1 or 2.
./@chebtech/chebtech.m:% EXTRAPOLATE preference is set to TRUE (See CHEBTECH.PREF), then the endpoint
./@chebtech/techPref.m:% default CHEBTECH preferences as field/value pairs. This structure may be

Merge funs over multiple sub-intervals.

Currently, chebfun.merge() only attempts to merge out one breakpoint at a time. Nick Hale suggests that it might be a better idea to first loop through all breakpoints and mark them as "mergeable" or "umergeable" and then try to take care of connected sequences of breakpoints in one go.

A bug in chebpoly@trunk?

I guess this is a bug.

t0 = chebpoly(0)

t0 =

chebfun column (1 smooth piece)
interval length endpoint values
[ -1, 1] 1 1 1
Epslevel = 2.220446e-16. Vscale = 1.

t1 = chebpoly(1)

t1 =

chebfun column (1 smooth piece)
interval length endpoint values
[ -1, 1] 1 1 1
Epslevel = 2.220446e-16. Vscale = 1.

isequal(t0, t1)

ans =

 1

---

I don't see a test for chebpoly@trunk, which is a bit surprising.

Ploting complex-valued chebfuns

This may have been fixed in development, but at least on my branch there is a bug in plotting complex-valued chebfuns:

r = chebfun( rand(10) + 1i*rand(10) );
plot(r)
Error using vertcat
Dimensions of matrices being concatenated are not consistent.

Error in chebfun/plotData (line 88)
data.xLine = [data.xLine ; NaN ; dataNew.xLine];

Error in chebfun/plot (line 116)
newData = plotData(f, interval);

Note that one is able to plot complex-valued, array-valued chebtech2 objects.

Wrong Default Tolerance in chebtech.simplify()

In chebtech.simplify(), we use the default value of pref.chebtech.eps as the default tolerance:

% Use the default tolerance if none was supplied:
if ( nargin < 2 )
    pref = chebtech.pref();
    tol = pref.chebtech.eps;
end

We should probably use the epslevel of the chebtech being simplified instead.

Problem with Constructing Array-Valued chebfuns with Jump Discontinuities

If we try to create an array-valued chebfun for [sin(x) sign(x)], we get

>> f = chebfun(@(x) [sin(x) sign(x)], [], 'splitting', 'on')
Operands to the || and && operators must be convertible to logical scalar
values.
Error in chebfun.detectEdge>findJump (line 206)
end
Error in chebfun.detectEdge>detectedgeMain (line 117)
        edge = findJump(op, ends(1) ,ends(2), hscale, vscale, derHandle);
Error in chebfun.detectEdge (line 62)
[edge, vscale] = detectedgeMain(op, domain, hscale, vscale, derHandle);
Error in chebfun.constructor (line 125)
    [edge, vscale] = chebfun.detectEdge(opk, [a b], vscale, hscale);
Error in chebfun (line 65)
                [f.funs, f.domain] = chebfun.constructor(op, dom, pref);

Upon changing sign() to abs(), the problem goes away:

>> f = chebfun(@(x) [sin(x) abs(x)], [], 'splitting', 'on')
f = 
   chebfun column (2 smooth pieces)
       interval       length   endpoint values
[      -1, 1.2e-17]       12    array-valued (2 pieces)
[ 1.2e-17,       1]       12    array-valued (2 pieces)
Epslevel = 6.492624e-16.  Vscale = 1.  Total length = 24.

NH notes that changing line172 in detectEdge() to include any(maxDer == inf) causes construction to proceed, but the jump isn't detected well:

>> f = chebfun(@(x) [sin(x) sign(x)], [], 'splitting', 'on')
f = 
   chebfun column (2 smooth pieces)
       interval       length   endpoint values
[      -1, 7.3e-09]       12    array-valued (2 pieces)
[ 7.3e-09,       1]       12    array-valued (2 pieces)
Epslevel = 6.492624e-16.  Vscale = 1.000000e+00.  Total length = 24.

What's going on here?