src/bernstein_approx/MultivariateBernAppr.m needs to be reviewed about scsynth

[arminalaghi]

All above is right.
Regarding the slowness for complex functions: one option is to use other methods of polynomial approximation (e.g. Taylor series), but then again as you mentioned, if the function is complicated enough that it requires a high polynomial degree, it is probably not a good idea to implement it via SC. (At least using ReSC/STRAUSS, because a clever simpler design might exist.)
Which reminds me: we have been working on a different synthesis tool: https://arxiv.org/abs/1810.04756

And thanks for the great suggestion! I'll add the note we discussed here to the README file.

[arminalaghi]

Your observation is correct. That line is trying to create a 3D grid to cover all the data points of the functions. You are basically asking it to have 100 points on each input, so you'll have 100^3 input combinations. This makes the program super slow.

Some points:

1. While this step is necessary, it does not have to have a high granularity. In this particular case, you can probably go with much lower granularity, e.g., [10 10 10]

2. STRAUSS and ReSC work by approximating data points in the function. By changing the granularity, you are selecting the number of points needed to represent the function. So high granularity means more data points. However, granularity should be selected based on the function you are representing. If the function is not a high frequency function (only slow changes with the input), you probably can get away with a handful of data points.
   Another thing to note is that ReSC and STRAUSS approximate functions by fitting polynomials on the data points. So if the degree of the target polynomial is 3, you should use high granularity.

3. I am not sure about the 'linear' vs. 'nearest' question, but regarding the solving question: we are solving the optimization problem of polynomial fitting. There are potentially other existing solutions to this problem that might be faster.

Let me know if these are helpful.

[danilo-bc]

These are very helpful, indeed.

So, a general rule of thumb is the higher the degree of the polynomial we're aiming, the higher the granularity needed to properly approximate it.

Are there some better guidelines that could be added to either Wiki or README?

If we're trying to apply simply algorithms such as edge 3x3 edge detection, where we get operations like (1*p1+2*p2+1*p3) I suppose we don't need either high granularity nor polynomial degrees. For this sample, I could simply use degrees=[1,1,1] and granularity=[10,10,10], if I understood correctly.

This does sound like the algorithm reaches a stalling point for complex functions, since both higher degree and higher granularity seem to heavily contribute in runtime. That said, SC isn't really fit for implementing complex operations, as far as I know, so the barrier should be more virtual than actual.

[danilo-bc]

Your remarks were very helpful on how to properly use working around the approximatioin bottleneck. Thank you for sharing your team's new approach to SC Synthesis. Are you planning to distribute that synthesizer somewhere? If so, under what regime (open source, freeware, proprietary, etc.)?

It's great to hear the area is still undergoing development. I checked your page and this repository some time ago and couldn't find any news.

[arminalaghi]

I need to check with the lead author on how he wants to proceed with the code. I assume it can be open sourced, but I am not sure. Either way, it should not be in this repo.

Sorry my page is really old. I need to update it more often.

[danilo-bc]

Thank you. It's good to hear the page is old probably because of more recent work!