On Tuesday 16 May 2006 03:12, Dr. Richard Boulanger wrote:

> YOU TOLD US THAT THERE IS A SPEED INCREASE BY USING POWERS OF 2

I definitely did not say this, and there is no real evidence or
explanation why this would be true in general.

> as well as satisfying my current developmental need.

And being a waste in the 99% of other cases when more than 24
arguments are not needed, just to allow for the 1% to be done in
a more elegant way.

> I need more than 24 - that's it.  And I don't want a special version  
> of the program.

You do not need a special version. You can already pass 64, 100, 1000,
or whatever number of values you want with the stack opcodes; in
addition, this method also allows for string arguments, and is not
limited to user defined opcodes (subinstruments are still useful
because of the possibility of calling by a number which can be
calculated at run-time).
I am also looking at ways to allow the user defined opcodes to take
very large number of arguments and more types (e.g. S or f), while
remaining lean and efficient in the previously already supported cases.
However, it remains to be seen if this is really worth the effort, or
the stack opcodes are good enough (with support for f-signals hopefully
added in 5.03), even if not the most elegant.

> here when I say to you Istvan - CUT THE FUCKING SHIT

Well, I can take this polite advice and stop bothering with the user
defined opcodes that I originally implemented. Definitely more
convenient than spending my time trying to fix bugs or add new
features.