Re: Handle graphics plotting functions

>> Unfortunately, the same calmness happened over my C++ implementation of the
>> histogram routine, which is more than 25x faster than the current hist.m.
>> See the thread "Re: fast hist() / histogram() implementation in C++" here
>>         http://www.octave.org/mailing-lists/help-octave/2004/
>> 
> Writing octave core functions in C++ must be highly justified, and speed is 
> not the only criteria, I myself have had an improved triu/tril function in 
> C++ knocked back. Concretely the above thread showed upto 50 times speed 
> improvement. But the current m-file on a test image took only 1 second. So 
> does even a 50 times speed improvement justify the issue of making code 
> maintaince much harder with the addition of C++ code..

Try it on an image of 512x512, 1024x1024 or larger. It takes dozens of 
seconds by the .m code, and that's why the C++ improvement is a must.

>> I would recommend that you contribute them to octave-forge,
>> probably in the main/general directory.
> Are you a member of octave-forge. "Us" I'm afraid includes "you", and if you 
> want code included, you must take ownership of the code right to its logical 
> conclusion of supporting its inclusion in octave-forge.

No, I'm not on the list.

I don't have and won't have time to maintain gnuplot subsystem in Octave, 
sorry. But that project would need someone to check/update the code for 
gnuplot 4.0 features, and it was what I have asked in my earlier mails. 
That person can get support from gnuplot developers from this or from 
gnuplot-beta mailing list.

---
Petr Mikulik