|
From: | Daniel J Sebald |
Subject: | Re: Built-in base2dec and dec2base |
Date: | Mon, 20 Aug 2012 13:23:28 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 08/20/2012 12:42 PM, Rik wrote:
On 08/19/2012 10:41 PM, John W. Eaton wrote:On 19-Aug-2012, Daniel J Sebald wrote: | I've gone over the builtin base2dec/dec2base code and created a second | version of the patch file. I'm not sure that it is worth making these changes in core Octave. Yes, performance is improved, but at the cost of code that is more difficult to debug and maintain.8/20/12 Daniel, I will definitely take a look at your code, but I can only promise that I'll get to it before we make a new release. I'm busy with real life projects and my Octave time is currently going towards the build system and the directory structure.
Thanks. No rush. That's why I put the patch on Savannah. It's slightly too big to get to with limited time.
As a further datapoint in the discussion, the m-file code I wrote is very specifically oriented towards performance and is reasonably opaque (although short).
Well, it's fairly impressive actually. Efficiently compute from/to index sets for moving whitespaces to the left. Create a table to map anything other than the symbols and ' ' to NAN hinging on the fact that math with a NAN results in NAN. Nice.
BTW, looking at the code I have to think what is there is a wholesale rewrite, so that might warrant a change in the copyright notice.
The one issue with the m-script is that the cell version is so much slower. I'm looking into some cell issues right now, but that's not such straightforward code.
Something in C++ might actually be clearer and more straightforward since one can just use a loop where a loop makes sense instead of employing the contortions I did to eliminate them.
Yes, that was the point I was attempting to make. Dan
[Prev in Thread] | Current Thread | [Next in Thread] |