rik | 25 May 06:19 2015

Development branch ready for new code

5/24/15

All,

I have changed the development branch version to 4.1.0+ and removed all the
functions and features that were deprecated in 3.8 and scheduled for
removal in 4.2.  The development branch is now officially diverged from the
stable 4.0.X and ready for new code.

--Rik

rik | 24 May 16:52 2015

C++ coding style and in-place operators

5/24/15

All,

Do we have a preference for where in-place operators are used?  For
example, the following statement can be coded two ways.

a = a + 1;
a += 1;

In m-files there is a distinct preference for the in-place operator which
is faster as it doesn't allocate an intermediate variable.  In the C++
code, do we assume the compilers are smart enough these days to perform
that optimization?  And even if they are, do we like one style more than
the other?

Attached is a list in liboctave of opportunities to use in-place operators
that I quickly found using regular expressions.

--Rik
array/Array-util.cc:563:            idx = idx * dvx(i) + idxa(i)(0);
array/Array-util.cc:575:              start = start * dvx(i) + xstart;
array/Array-util.cc:576:              step = step * dvx(i) + xstep;
array/CNDArray.cc:897:    a = a * s;
array/MArray.cc:223:    a = a + s;
array/MArray.cc:234:    a = a - s;
array/MArray.cc:245:    a = a * s;
array/MArray.cc:256:    a = a / s;
(Continue reading)

rik | 24 May 16:01 2015

C++ vs m-file coding style

5/24/15

Carnë,

Using familiar function names, like numel, in the C++ is just one way of
trying make the code more recognizable.

I've also tried to implement the coding convention of cuddling the
parenthesis next to the variable when doing indexing and using a space when
it is a function call.

idx(3) = 5;
BUT
sort_idx (3);

I did this in a semi-automated way a long time ago using regular
expressions, but apparently I missed quite a few instances.

I just did a complete search and update for dim_vector objects across
liboctave/, libinterp/, and libgui/.  See
http://hg.savannah.gnu.org/hgweb/octave/rev/b2100e1659ac.

--Rik

Hydra Build Daemon | 23 May 10:09 2015
Picon
Picon

Success: Hydra job gnu:octave-default:tarball on x86_64-linux

Hi,

The status of Hydra job ‘gnu:octave-default:tarball’ (on x86_64-linux) has changed from "Failed
with output" to "Success".  For details, see

  http://hydra.nixos.org/build/22436492

This may be due to 8 commits by Eelco Dolstra <eelco.dolstra <at> logicblox.com>, Mike Miller
<mtmiller <at> octave.org> or Peter Simons <simons <at> cryp.to>.

Yay!

Regards,

The Hydra build daemon.

Rik | 23 May 05:00 2015

Re: acinclude.m4 patch

On 05/22/2015 06:20 PM, octave-maintainers-request <at> gnu.org wrote:
Subject:
[PATCH] acinclude.m4: Use pkg-config when available in OCTAVE_CHECK_LIB
From:
Jordi Gutiérrez Hermoso <jordigh <at> octave.org>
Date:
05/22/2015 02:06 PM
To:
maintainers <at> octave.org
List-Post:
<mailto:octave-maintainers <at> gnu.org>
Content-Transfer-Encoding:
base64
Precedence:
list
MIME-Version:
1.0
Message-ID:
<431f166a56cb347f8351.1432328792 <at> Iris>
Content-Type:
text/plain; charset="utf-8"
Message:
1

# HG changeset patch # User Jordi Gutiérrez Hermoso <jordigh <at> octave.org> # Date 1432328517 14400 # Fri May 22 17:01:57 2015 -0400 # Node ID 431f166a56cb347f8351950411f58f1b9c5f6621 # Parent 561af1ab60990a990c70c279475b621846639a83 acinclude.m4: Use pkg-config when available in OCTAVE_CHECK_LIB (Hi, I'm using the Mercurial patchbomb extension to email you a patch for code review.) The following patch uses pkg-config to add extra flags whenever possible. This was necessary for me in Debian in order to find the HDF5 libraries, and seems useful in general. Like it often happens with m4 and autoconf, I cargo-culted this code from existing checks for sndfile in configure.ac. It probably would make sense to move the original code into its own m4 macro, so we can have a little less code duplication in the autoconf files. Any comments if this is the best way to do this? It seems to have solved my immediate problem and now hdf5 is recognised on Debian without needing to pass extra flags to the configure script. diff --git a/m4/acinclude.m4 b/m4/acinclude.m4 --- a/m4/acinclude.m4 +++ b/m4/acinclude.m4 <at> <at> -598,6 +598,12 <at> <at> AC_DEFUN([OCTAVE_CHECK_LIB], [ ;; esac + PKG_CHECK_EXISTS([$1], [ + m4_toupper([$1])_CPPFLAGS="$($PKG_CONFIG --cflags-only-I $1) $m4_toupper([$1])_CPPFLAGS" + m4_toupper([$1])_LDFLAGS="$($PKG_CONFIG --libs-only-L $1) $m4_toupper([$1])_LDFLAGS" + m4_toupper([$1])_LIBS="$($PKG_CONFIG --libs-only-l $1) $m4_toupper([$1])_LIBS" + ]) + warn_$1="$3" m4_set_add([summary_warning_list], [warn_$1])

Looks okay.  Although, if the only package that is affected is hdf5 maybe it would be easier to set the flags like HDF5_CPPFLAGS in configure.ac.  The other libraries that use the macro OCTAVE_CHECK_LIB are things like amd, colamd, etc. which don't have pkg_config files.  At least on Ubuntu 12.04 I don't have a pkg-config file for HDF5 either.

--Rik

Jordi Gutiérrez Hermoso | 22 May 23:06 2015

[PATCH] acinclude.m4: Use pkg-config when available in OCTAVE_CHECK_LIB

# HG changeset patch
# User Jordi Gutiérrez Hermoso <jordigh <at> octave.org>
# Date 1432328517 14400
#      Fri May 22 17:01:57 2015 -0400
# Node ID 431f166a56cb347f8351950411f58f1b9c5f6621
# Parent  561af1ab60990a990c70c279475b621846639a83
acinclude.m4: Use pkg-config when available in OCTAVE_CHECK_LIB

(Hi, I'm using the Mercurial patchbomb extension to email you a patch
for code review.)

The following patch uses pkg-config to add extra flags whenever
possible. This was necessary for me in Debian in order to find the
HDF5 libraries, and seems useful in general.

Like it often happens with m4 and autoconf, I cargo-culted this code
from existing checks for sndfile in configure.ac. It probably would
make sense to move the original code into its own m4 macro, so we can
have a little less code duplication in the autoconf files.

Any comments if this is the best way to do this? It seems to have
solved my immediate problem and now hdf5 is recognised on Debian
without needing to pass extra flags to the configure script.

diff --git a/m4/acinclude.m4 b/m4/acinclude.m4
--- a/m4/acinclude.m4
+++ b/m4/acinclude.m4
 <at>  <at>  -598,6 +598,12  <at>  <at>  AC_DEFUN([OCTAVE_CHECK_LIB], [
     ;;
   esac

+  PKG_CHECK_EXISTS([$1], [
+    m4_toupper([$1])_CPPFLAGS="$($PKG_CONFIG --cflags-only-I $1) $m4_toupper([$1])_CPPFLAGS"
+    m4_toupper([$1])_LDFLAGS="$($PKG_CONFIG --libs-only-L $1) $m4_toupper([$1])_LDFLAGS"
+    m4_toupper([$1])_LIBS="$($PKG_CONFIG --libs-only-l $1) $m4_toupper([$1])_LIBS"
+  ])
+
   warn_$1="$3"
   m4_set_add([summary_warning_list], [warn_$1])

Rik | 22 May 20:21 2015

Re: X'*v in octave

On 05/22/2015 09:00 AM, octave-maintainers-request <at> gnu.org wrote:
Subject:
Re: X'*v in octave
From:
Jordi Gutiérrez Hermoso <jordigh <at> octave.org>
Date:
05/22/2015 07:11 AM
To:
Chih-Jen Lin <cjlin <at> csie.ntu.edu.tw>
CC:
jeremy89183 <at> gmail.com, b02902056 <at> ntu.edu.tw, octave-maintainers <at> gnu.org
List-Post:
<mailto:octave-maintainers <at> gnu.org>
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
References:
<4c5617lfxpv.fsf <at> linux15.csie.ntu.edu.tw>
In-Reply-To:
<4c5617lfxpv.fsf <at> linux15.csie.ntu.edu.tw>
Message-ID:
<1432303891.20198.12.camel <at> octave.org>
Content-Type:
text/plain; charset="UTF-8"
Message:
1

On Fri, 2015-05-22 at 05:05 +0800, Chih-Jen Lin wrote:
> Recently in an experiment I found that for sparse X'*v octave seems > to do X' first and then conduct the matrix vector product. This is > time consuming as this operation is simple a linear combination of > X's columns and X in Octave is stored in compressed column format.
I may be completely mistaken here, but I think that Octave is already doing what you suggest. If you attempt the following, x = sprand(1e5,1e5,0.0001); y = rand(1e4,1); then of the possible operations of interest, tic; x*y; toc tic; y'*x; toc tic; x'*y; toc the third one is the fastest. Are you seeing one of the two others as being faster? - Jordi G. H.

Results from testing with the Mercurial ID 561af1ab6099 on the development branch:

octave:11>     tic; x*y; toc
Elapsed time is 0.0312591 seconds.
octave:12>     tic; y'*x; toc
Elapsed time is 0.022948 seconds.
octave:13>     tic; x'*y; toc
Elapsed time is 0.0130401 seconds.

It appears that Jordi is right that this case is already significantly faster than straightforward multiplication of x*y.

--Rik

Carnë Draug | 22 May 18:36 2015

general package, inputParser, 4.0.0 release

Hi

the general package currently implements the inputParser class.  The upcoming
Octave release 4.0.0 also implements this class.  These implementations are
very similar but different enough that any of its use will require changes
to continue working.  Loading the general package will shadow the class but
Octave will not warn about it (seems like it only warns about shadowing
functions).

Currently, the best way to distinguish between the two is by checking the
path to the function like so:

    if (strfind (which ("inputParser"), [" <at> inputParser" filesep
"inputParser.m"]))
      ...
    else
      ...
    endfif

but we can't really expect users, in special new users that are not aware of
this history, to figure it out.

In addition, a few weeks ago [1] I expressed my wish of marking the general
package as an unmaintained package.  I didn't feel there was much of
opposition to that (but can also be because the email was a fairly long rant
that few read).

This said, I see two possible resolutions:

  1. make a new release of the general package without  <at> inputParser and
  dependent on (octave >= 4.0.0).

  2. make a new release of the general package, exactly the same as the
  last release, and dependent on (octave < 4.0.0).

Any of the two would prevent  <at> inputParser and classdef's inputParser to
co-exist.  I prefer the second option for the following reasons:

  * users that wrote code for the old version had his code dependent
    on general.  If it is used on the Octave 4.0.0 it will fail to load
    the general package forcing them to become aware of this difference.

  * users of old versions of Octave can still use the "latest" version
    of the package without having to dig on the old releases.

  * since we are "deprecating" the general package, we should make it easier
    for the people that will stay on the old versions of Octave, the ones
    released when it was "supported".

Unless someone opposes this, I will make a new release of general, still
with  <at> inputParser and dependent on (octave < 4.0.0), on Monday.

This would all be avoided if I hadn't implemented an incompatible version
of inputParser on the general package years ago.  Hopefully, I have learned
my lesson.

Carnë

[1] http://octave.1599824.n4.nabble.com/OF-and-packages-devs-please-read-tp4670263p4670295.html

Hydra Build Daemon | 22 May 17:12 2015
Picon
Picon

Failed with output: Hydra job gnu:octave-default:tarball on x86_64-linux

Hi,

The status of Hydra job ‘gnu:octave-default:tarball’ (on x86_64-linux) has changed from "Success"
to "Failed with output".  For details, see

  http://hydra.nixos.org/build/22422647

This may be due to 2 commits by Mike Miller <mtmiller <at> octave.org> or Rik <rik <at> octave.org>.

Go forth and fix it.

Regards,

The Hydra build daemon.

Rik | 22 May 16:50 2015

Re: X'*v in octave

On 05/22/2015 06:42 AM, octave-maintainers-request <at> gnu.org wrote:
Subject:
X'*v in octave
From:
Chih-Jen Lin <cjlin <at> csie.ntu.edu.tw>
Date:
05/21/2015 02:05 PM
To:
octave-maintainers <at> gnu.org
CC:
jeremy89183 <at> gmail.com, b02902056 <at> ntu.edu.tw
List-Post:
<mailto:octave-maintainers <at> gnu.org>
Precedence:
list
MIME-Version:
1.0
Message-ID:
<4c5617lfxpv.fsf <at> linux15.csie.ntu.edu.tw>
Content-Type:
text/plain
Message:
2

Dear Octave maintainers, Recently in an experiment I found that for sparse X'*v octave seems to do X' first and then conduct the matrix vector product. This is time consuming as this operation is simple a linear combination of X's columns and X in Octave is stored in compressed column format. May I suggest that you improve the setting in the near future? Thanks, Chih-Jen

For a full matrix this is already the case (in Octave 4.0 anyways).  That is, rather than perform a transpose in Octave followed by a multiplication using BLAS, we just forward the two matrices to BLAS for multiplication along with an indication that one of them is transposed.

The code to examine is in liboctave, either in the array/ directory where Sparse matrices are defined or in the operators/ directory where operations between various matrix types are declared.

--Rik
Chih-Jen Lin | 21 May 23:05 2015
Picon

X'*v in octave

Dear Octave maintainers,

Recently in an experiment I found that for sparse X'*v octave seems to do X' first and then conduct the matrix
vector product. This is time consuming as this operation is simple a linear combination of X's columns and
X in Octave is stored in compressed column format. May I suggest that you improve the setting in the near future?

Thanks,
Chih-Jen


Gmane