Multiple toolboxes with lots of redundant features?

Note that this is not a question that needs to be answered, I would like to start a discussion on this. In recent years, mathworks has launched numerous new toolboxes, for example, on the large field of autonomous driving, the traditional computer vision toolbox, followed by the autonomous driving toolbox, navigation toolbox, sensor fusion and tracking toolbox, robotics toolbox, radar toolbox, and so on. Although nominally they have different applications and environments, there are too many common functions or functions that overlap, such as

1, quaternion / rotation matrix / Euler angle almost every toolbox above, even some names change a little, but still does not change the concept of quaternion.

2, Kalman filter series algorithm, particle filter algorithm, all kinds of linear nonlinear variants.

3, pose graph optimization algorithm, such as cv toolbox optimizePoses, navigation toolbox optimizePoseGraph essentially the same, the name is a little different.

4, probabilistic map / binary map construction, such as occupancyMap and other series of functions in the autopilot and navigation toolbox, etc. will appear.

5, path planning algorithms, A*, RRT will also appear in multiple toolboxes at the same time.

And so on too much, in this large functional board area can always find a function can be replaced or approximated by another toolbox of a function.

...

What I want to express is whether it is possible to try not to expand the number of toolboxes drastically, but to get as many function blocks under one toolbox as possible, so that their common base will remain unchanged. Just like Matlab is the base module of all toolboxes, the common functions should be ported to the "Scientific Engineering" base module (or other names). As an aside, I hope that mathworks is not trying to increase the number of "redundant functions" in the toolbox to earn more money, but rather to continue to provide quality common base modules to drive applications in various fields.

Answer 1

[Matt J]

The issue you've raised would only be a problematic one if it somehow forced people to buy more toolboxes than they should need. Having redundant functions normally helps to prevent that. For example, there is considerable overlap between functionality in the Curve Fitting toolbox and the Optimization Toolbox (e.g., fit() and lsqcurvefit()). If you were to remove fit from the Curve Fitting Toolbox in the interest of cutting down redundancy, then it would force people who only want to focus on curve fitting to buy both toolboxes.

[Stephen23]

"..then it would force people who only want to focus on curve fitting to buy both toolboxes"

The suggestion was that there would be "base module" which would support both/all toolboxes with any common functionalities. The number of toolboxes that the customer would need is not affected.

[Matt J]

Unless the "base module" here is the same as the current Matlab core product, it amounts to the same thing. Anyone who wanted to do curve fitting would need to buy 2 toolboxes, one containing the base fitting functions and one containing the specialized functions.

[Stephen23]

Although not stated explicitly, my interpretation is that the "base module" would be included at no extra cost along with any toolbox that needs it. As you state, two (or more, depending on how the Venn diagram of functionalites can be best divided) toolboxes would be installed, but the user would still only purchase the specialized toolbox, containing any high-level functions.

I guess there would be minor side-effects in terms of search path order and function version compatibility.

The problem occurs in many areas of computing: how to share resources effectively and efficiently. Duplication does not seem like the best approach, so the question is valid. Perhaps there is no optimal solution.

[xingxingcui]

Is it possible to imagine that each proprietary matlab toolbox is similar to the various package libraries in python, while the matlab base kernel section is similar to the basic syntax structure of python itself. python actually has many package libraries that do the same thing, and the difference between them is distinguished by import A. But in matlab it is not advisable to have multiple toolboxes If there are too many common parts, such as the quaternion I mentioned, they should be put in the Matlab base core section or a "scientific computing" base section.

[Matt J]

If there are too many common parts, such as the quaternion I mentioned, they should be put in the Matlab base core section or a "scientific computing" base section.

I believe they already are. The Curve Fitting Toolbox's fit function, to keep with my example, is calling the same underlying optimizer as lsqcurvefit() in the Optimization Toolbox.They may be wrapped by differently named functions in different toolboxes to suit the realm of application of the toolbox. Under the hood, however, they are calling the same base routines.

Contrast that wth Python which, for example, truly do have separate sin() and cos() implementations in numpy versus core Python.

[xingxingcui]

@Matt J What you say in this paragraph in this perspective case is correct, in some toolboxes can exist in the name of different, the underlying is the use of the same set of optimization algorithms. This is also for different areas of the toolbox to a more visual and intuitive name presented to the user, the purpose is to facilitate the use! But on the other hand, there are many toolboxes with exactly the same name and the same scenario, such as the quaternion I mentioned, and it is worthwhile for mathworks to consider whether it is appropriate to present them as separate toolboxes.

[Walter Roberson]

"The suggestion was that there would be "base module" which would support both/all toolboxes with any common functionalities."

That is already implemented for some pieces.

• Audio System and DSP share
• Some specific aspects of Fixed Point Toolbox are shared (in particular double precision and half precision)
• code generation is shared with a number of tools, such as deploying to Raspberry Pi and Arduino (at least from Simulink)