Code covered by the BSD License

### Highlights from Table Breakpoint Optimization

4.33333
4.3 | 3 ratings Rate this file 23 Downloads (last 30 days) File Size: 605 KB File ID: #35194 Version: 1.7

# Table Breakpoint Optimization

### Tucker McClure (view profile)

04 Apr 2012 (Updated )

A set of tools for finding the best way to reduce the size of a table.

File Information
Description

These tools find the best way to reduce the size of a table, given either the desired number of points or the maximum tolerable error. The resulting table allows faster interpolation and requires less memory.

Specifically, given an input 1D, 2D, or n-D table and a desirable number of breakpoints (or allowable mean squared error), these functions will calculate the best placement of the breakpoints to fit the input table. The user can specify how the table values should be interpolated using linear, spline, nearest methods, etc. The breakpoints, new table, and mean squared error of the fit are returned.

The optimal placement of breakpoints is taken to be the placement resulting in the minimum mean squared error of the new table evaluated at the original table's breakpoints with the specified interpolation scheme. For regularly sampled input tables, this acts as an integral of error over the table's area. This allows irregular sampling of the original table to focus on critical (e.g., rapidly changing) areas of the table.

To get started, either load the app and click "Help", enter "TableOptimizerGui" at the command prompt, or see find_best_table_demo.pdf.

Requires the Optimization Toolbox(TM).
Supports (but does not require) the Parallel Computing Toolbox(TM).

Acknowledgements

Optimizing Breakpoints For Tables inspired this file.

Required Products Optimization Toolbox
MATLAB release MATLAB 8.0 (R2012b)
30 Oct 2015 Tucker McClure

### Tucker McClure (view profile)

Hi ths1104 Stenkhiste,

Good comments. However, note that each call to the "fit" function is an optimization problem where n_x is the number of parameters, and so running with n_x = length(x_0) for large datasets (and why would anyone use this if they didn't have a large dataset to compress?) would take very long. For this reason, we start small and double the number of points until we find a good option. You're right that this *could* result in a large n_x, but it won't actually do this in practice (except for specific pathological cases). Then, we use a binary search to narrow in on the best final number. This is much faster for the vast majority of data sets that make sense for compression because it never requires running with an absurdly large number of points. Make sense?

However, I agree that it would be a small improvement to limit n_x to the original data size, and I could put this into a future update.

Thanks for the critical feedback!

- Tucker

Comment only
18 Nov 2014 ing-electrica electrica

### ing-electrica electrica (view profile)

10 Jul 2014 Ameya Deoras

### Ameya Deoras (view profile)

Excellent! Works great for approximating a curve with piecewise linear functions

06 Dec 2013 ths1104 Stenkhiste

### ths1104 Stenkhiste (view profile)

Great code!

I am looking at find_best_table_1de. I have two comments:

(a) It seems there is a problem with max_iterations. Lets say we have length(x_0)=10. So max_iterations=10. In the first while loop, n_x could increase up to 3*2^10 = 3072. This is much higher than length(x_0)! The loop should stop when n_x>=length(x_0).

(b) Why dont you start directly the dichotomie using
n_x_left = 3;
n_x_right = length(x_0);
? This looks simpler because you can get ride of the first while loop.

25 Jun 2012 1.1

Tweak for improvements to stability in certain cases.

06 Aug 2012 1.4

Added ability to automatically find the smallest table satisfying a given mean squared error tolerance. Also added stability improvements.

20 Aug 2012 1.5