Re: indexing expression performance

[Jaroslav Hajek]

On Fri, Jan 16, 2009 at 10:47 AM, Thomas Weber
<address@hidden> wrote:
> Am Freitag, den 16.01.2009, 10:01 +0100 schrieb Jaroslav Hajek:
>> >> The dense indexing improvements started with
>> >> http://hg.savannah.gnu.org/hgweb/octave/rev/7cbe01c21986
>> >> dated 20th October and lots of bugfixes afterwards. I don't think this
>> >> was in the 3.1.51 snapshot which I think was done in late July. There
>> >> was no 3.1.52 so far. So, if you want these, development sources are
>> >> your only resort.
>> >
>> > I'd vote for a new snapshot. Or, if you can give me a mercurial id where
>> > sources are in a reasonable[1] shape, we can use that for a new snapshot
>> > package in Debian.
>> >
>> > [1]  Reasonable by whatever metric you choose.
>> >
>> >        Thomas
>> >
>>
>> A very loose metric is as follows:
>> Checkout a current tip, and wait a whole day for possible patches
>> coined like "omission from last patch" etc.
>> If no such patch appears, you have a reasonable shape.
>>
>> But, given that there were rumors about making 3.1.52 testing
>> snapshot, perhaps you'll want to wait for that?
>
> How about a snapshot _now_? I mean, it's a snapshot, it's expected to
> contain bugs.
>
>> My opinion for the best way to proceed is to fork 3-2-x branch at a
>> suitable time (maybe now) and then make testing and later stable
>> releases from it, but I think John has a different idea.
>>
>> Btw., I see Debian has a pretty complete octave3.0 package.
>> How hard would be packaging the qrupdate library for Debian?
>> (https://sourceforge.net/projects/qrupdate).
>
> Good question. I don't have much experience with packaging libraries.
> The biggest problem are incompatible changes to the library's interface,
> which means a proper SONAME.
>
> It's somewhat complicated by the fact that the library uses Fortran. For
> C/C++, you have knowledgable people at every corner. How much do you
> expect the library to change in the future?
>

I will probably add more routines. The current set for QR & Cholesky
is fairly complete, but there are other factorizations left - QRZ, LU,
SVD... I guess adding a routine does not mean an incompatible change,
right? In that sense, I will aim for minimal changes.
Fortran is used for various reasons. My choices have only been C or
Fortran, because I want the lib to be easily usable from Fortran
programs - we here at VZLU Prague make fairly good use of Fortran for
in-house codes. As usually, Fortran won on its native support for
matrices, which need to be simulated by ugly macro tricks in C, or
simply coded in all-linear-arrays style. Also, Fortran doesn't tend to
be slower than C, sometimes even faster.
I think gfortran is generally regarded mature (at least w.r.t. F90
support) since gcc 4.2, so you can say Fortran is well supported on
free platforms.

regards

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz