Nabble - Octave - Maintainers

Re: *.texi files not generated

2009-11-30T13:15:39Z

On 11/30/09 7:34 PM, John W. Eaton wrote:
> I checked in the following change. Does it fix the problem for you?
>
I will try whatever I find in the repository as soon as I can, but right
now the repository is down. Soon, I have to get ready for more travel...

Michael

Re: *.texi files not generated

2009-11-30T13:00:21Z

John W. Eaton wrote:

> On 30-Nov-2009, Rik wrote:
>
> | > I checked in the following change. Does it fix the problem for you?
> | >
> | > http://hg.savannah.gnu.org/hgweb/octave/rev/81c5ea6ddf81
> | >
> | May I substitute my patch for yours later today?
>
> Would you please post your proposed change first?
>

Attached is my proposed Makefile.am. It is easier to understand than

just seeing the diffs.
> | Mine handles the
> | missing *.texi files and in addition gets the distribution and cleanfile
> | targets correct.
>
> Doesn't mine also do that? When I tested it, it generated the .texi
> files. If there is a problem, what part is missing?
>
It generates the .texi files, but also distributes them. We don't want
to distribute them because they are not really primary sources and they
*do* require rebuilding on each host. I agree with your paragraph below.
> If we don't distribute conf.texi, but expect it to always be created
> at build time, then I don't see the point of distributing the
> generated .texi files. We might as well expect those to be generated
> at build time.
>
We don't distribute conf.texi because certain variables depend on the
libraries installed on the host. (See HAVE_QHULL for example)
> Yes, this goes against the coding standard that says it should not be
> necessary to have makeinfo/texinfo installed to build a package, but
> if we require that conf.texi to be generated, then I don't see any
> alternative.
>
> OTOH, if we decide that we don't need to build conf.texi, then we can
> just distribute all the .txi and generated .texi files.
>
Yes, that sums up the decision. Currently, we require texinfo to be
installed on the build host which isn't terrifically onerous, but we
could get rid of the requirement altogether if we choose to rewrite the
few texi files which actually depend on conf.texi.

--Rik

# Makefile for octave's doc/interpreter directory
#
# Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
# 2002, 2003, 2005, 2006, 2007, 2008, 2009 John W. Eaton
#
# This file is part of Octave.
#
# Octave is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
# Free Software Foundation; either version 3 of the License, or (at
# your option) any later version.
#
# Octave is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
# for more details.
#
# You should have received a copy of the GNU General Public License
# along with Octave; see the file COPYING. If not, see
# <http://www.gnu.org/licenses/>.

TOPDIR = ../..

include ../../common.mk

AM_MAKEINFOFLAGS = -I.. -I$(srcdir) -I$(srcdir)/..
AM_MAKEINFOHTMLFLAGS = -I.. -I$(srcdir) -I$(srcdir)/..

TEXINFO_TEX = ../texinfo.tex

TEXINPUTS := "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)$(TEXINPUTS)$(PATH_SEPARATOR)"
export TEXINPUTS

TEXMFCNF := "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)$(PATH_SEPARATOR)$(TEXMFCNF)$(PATH_SEPARATOR)"
export TEXMFCNF

dist_man1_MANS = \
mkoctfile.1 \
octave-bug.1 \
octave-config.1 \
octave.1

## The following example files are listed for dependencies.
## They should not be distributed from this directory.
EXAMPLE_FILES = \
$(top_srcdir)/examples/@polynomial/display.m \
$(top_srcdir)/examples/@polynomial/double.m \
$(top_srcdir)/examples/@polynomial/end.m \
$(top_srcdir)/examples/@polynomial/get.m \
$(top_srcdir)/examples/@polynomial/mtimes.m \
$(top_srcdir)/examples/@polynomial/plot.m \
$(top_srcdir)/examples/@polynomial/polynomial.m \
$(top_srcdir)/examples/@polynomial/polynomial_superiorto.m \
$(top_srcdir)/examples/@polynomial/polyval.m \
$(top_srcdir)/examples/@polynomial/set.m \
$(top_srcdir)/examples/@polynomial/subsasgn.m \
$(top_srcdir)/examples/@polynomial/subsref.m \
$(top_srcdir)/examples/addtwomatrices.cc \
$(top_srcdir)/examples/celldemo.cc \
$(top_srcdir)/examples/firstmexdemo.c \
$(top_srcdir)/examples/fortdemo.cc \
$(top_srcdir)/examples/fortsub.f \
$(top_srcdir)/examples/funcdemo.cc \
$(top_srcdir)/examples/globaldemo.cc \
$(top_srcdir)/examples/helloworld.cc \
$(top_srcdir)/examples/mycell.c \
$(top_srcdir)/examples/myfeval.c \
$(top_srcdir)/examples/myfunc.c \
$(top_srcdir)/examples/mypow2.c \
$(top_srcdir)/examples/mysparse.c \
$(top_srcdir)/examples/mystring.c \
$(top_srcdir)/examples/mystruct.c \
$(top_srcdir)/examples/paramdemo.cc \
$(top_srcdir)/examples/stringdemo.cc \
$(top_srcdir)/examples/structdemo.cc \
$(top_srcdir)/examples/unwinddemo.cc

include images.mk

.eps.pdf:
if [ -f $< ] ; then $(GHOSTSCRIPT) -dBATCH -dEPSCrop -dNOPAUSE -q -sDEVICE=pdfwrite -sOutputFile=$@ $< ; fi

IMAGES = $(IMAGES_EPS) $(IMAGES_PDF) $(IMAGES_PNG) $(IMAGES_TXT)

TXI_SRC = \
arith.txi \
audio.txi \
basics.txi \
bugs.txi \
container.txi \
contrib.txi \
cp-idx.txi \
data.txi \
debug.txi \
diffeq.txi \
diagperm.txi \
dynamic.txi \
emacs.txi \
errors.txi \
eval.txi \
expr.txi \
fn-idx.txi \
func.txi \
geometry.txi \
gpl.txi \
grammar.txi \
image.txi \
install.txi \
interp.txi \
intro.txi \
io.txi \
linalg.txi \
matrix.txi \
nonlin.txi \
numbers.txi \
oop.txi \
op-idx.txi \
optim.txi \
package.txi \
plot.txi \
poly.txi \
preface.txi \
quad.txi \
set.txi \
signal.txi \
sparse.txi \
stats.txi \
stmt.txi \
strings.txi \
system.txi \
testfun.txi \
tips.txi \
var.txi

MUNGED_TEXI_SRC = $(TXI_SRC:.txi=.texi)

info_TEXINFOS = octave.texi

nodist_octave_TEXINFOS = \
../conf.texi

octave_TEXINFOS = \
contributors.texi \
$(MUNGED_TEXI_SRC)

../conf.texi:
$(MAKE) -C .. conf.texi

octave.info octave.dvi octave.pdf octave.html: $(nodist_octave_TEXINFOS) $(octave_TEXINFOS) $(EXAMPLE_FILES)

octave.info: $(IMAGES_TXT)

octave.dvi octave.ps: $(IMAGES_EPS)

octave.pdf: $(IMAGES_PDF)

octave.html: $(IMAGES_PNG)

all-local: dvi html pdf ps doc-cache

# Install doc-cache of help files
install-data-local:
$(MKDIR_P) $(DESTDIR)$(octetcdir)
$(INSTALL_DATA) doc-cache $(DESTDIR)$(octetcdir)/doc-cache

uninstall-local:
rm -f $(DESTDIR)$(octetcdir)/doc-cache

DOCSTRING_FILES = $(TOPDIR)/src/DOCSTRINGS $(TOPDIR)/scripts/DOCSTRINGS

$(TOPDIR)/src/DOCSTRINGS:
$(MAKE) -C $(TOPDIR)/src DOCSTRINGS

$(TOPDIR)/scripts/DOCSTRINGS:
$(MAKE) -C $(TOPDIR)/scripts DOCSTRINGS

doc-cache: $(DOCSTRING_FILES) mk_doc_cache.m
$(TOPDIR)/run-octave -f -q -H $(srcdir)/mk_doc_cache.m doc-cache $(DOCSTRING_FILES) || { rm -f doc-cache; exit 1; }

$(MUNGED_TEXI_SRC): $(DOCSTRING_FILES) munge-texi$(BUILD_EXEEXT)

munge-texi$(BUILD_EXEEXT): munge-texi.cc
$(BUILD_CXX) $(BUILD_CXXFLAGS) -o $@ $^ $(BUILD_LDFLAGS)

.txi.texi:
./munge-texi $(DOCSTRING_FILES) < $< > $@-t
mv $@-t $@

contributors.texi: contributors.in
$(AWK) -f $(srcdir)/mkcontrib.awk $(srcdir)/contributors.in > $@-t
mv $@-t $@

../../INSTALL.OCTAVE: install.texi
rm -f INSTALL
-$(MAKEINFO) -D INSTALLONLY \
--no-validate --no-headers --no-split --output INSTALL \
-I.. -I$(srcdir) -I$(srcdir)/.. $<
mv INSTALL ../../INSTALL.OCTAVE

../../BUGS: bugs.texi
rm -f BUGS
-$(MAKEINFO) -D BUGSONLY \
--no-validate --no-headers --no-split --output BUGS \
-I.. -I$(srcdir) -I$(srcdir)/.. $<
mv BUGS ../../BUGS

EXTRA_DIST = \
config-images.sh \
contributors.in \
images \
images.mk \
mk_doc_cache.m \
mkcontrib.awk \
munge-texi.cc \
$(IMAGES) \
$(IMAGES_SRC) \
$(TXI_SRC)

DISTCLEANFILES = $(octave_TEXINFOS) doc-cache munge-texi$(BUILD_EXEEXT)

MAINTAINERCLEANFILES = $(IMAGES)

## .texi files are generated files, not primary sources, and should not
## be distributed. Automake, however, does not create rules to generate
## pdf and html documentation unless the info and texi files will be
## distributed. Various hacks, including using the nodist_ prefix and
## DISTCLEANFILES, do not work. The current solution is to build the texi
## files and create the correct Makefile rules and then use the dist-hook
## feature to remove the .texi files from the distribution just before it
## is archived in a tar file.
dist-hook:
( cd $(distdir) ; rm -f $(octave_TEXINFOS) ; )

.NOTPARALLEL:

Re: *.texi files not generated

2009-11-30T12:37:47Z

On 30-Nov-2009, Rik wrote:

| > I checked in the following change. Does it fix the problem for you?
| >
| > http://hg.savannah.gnu.org/hgweb/octave/rev/81c5ea6ddf81
| >
| May I substitute my patch for yours later today?

Would you please post your proposed change first?

| Mine handles the
| missing *.texi files and in addition gets the distribution and cleanfile
| targets correct.

Doesn't mine also do that? When I tested it, it generated the .texi
files. If there is a problem, what part is missing?

If we don't distribute conf.texi, but expect it to always be created
at build time, then I don't see the point of distributing the
generated .texi files. We might as well expect those to be generated
at build time.

Yes, this goes against the coding standard that says it should not be
necessary to have makeinfo/texinfo installed to build a package, but
if we require that conf.texi to be generated, then I don't see any
alternative.

OTOH, if we decide that we don't need to build conf.texi, then we can
just distribute all the .txi and generated .texi files.

jwe

Re: *.texi files not generated

2009-11-30T12:28:32Z

John W. Eaton wrote:

> On 28-Nov-2009, Michael D. Godfrey wrote:
>
> | On 11/28/09 5:19 PM, Rik wrote:
> | > The procedure I follow to verify my patches
> | > has been to clone a new tree from savannah, run autogen.sh, run
> | > configure, and then run make. This avoids any cruft that may have built
> | > up in the source tree.
> | >
> | This is what I did, and none of the .texi files got generated. but,
> | cd doc/interpreter; make xxx.texi would create the .txi. Also, I
> | found that if "old" .texi files were present the make updated them.
> | So, now my builds run fine -- until I do a new clone. For now,
> | I will save the old .texi files and copy them into a new clone.
>

Michael & John,

SHORT VERSION

I have been testing a patch since this morning which fixes the missing
.texi file problem. I'm a bit paranoid now so I'm testing it in
different build configurations to make sure it is rock solid. I will
check it in today.

LONG VERSION

We should think carefully about moving the documentation away from
dynamic sources to static sources. Autotools is geared towards
distributing .info and .texi files. Our .texi files are not static but
are generated at build time from .txi pre-cursors and conf.texi. Most
of the files are, in fact, static but there are a few decisions made
using @ifset and variables set in conf.texi by configure.

The idea behind distributing .info files is reasonably sensible because
it removes the requirement to have texinfo installed. A side effect of
the dependence on conf.texi is that all the .texi files and all the
documentation have to be re-made for every build host. Since texinfo is
now a requirement for building Octave we should at least not bother to
distribute the .texi files.

Unfortunately, this pattern is not common and autotools doesn't support
it well. The usual syntactic sugar, such as nodist_, does not work.
Also, globally turning off distribution of .info files turns off the
creation of build rules for pdf and html versions of the documentation.

The closest thing I have found to an explanation is a response in an
e-mail thread here:
http://www.mail-archive.com/bug-texinfo@.../msg04033.html. The
Automake developers are at least aware of the problem but the _TEXINFO
primary isn't as frequently used as the _SOURCES primary and I don't
expect resolution anytime soon.

My solution was to use as much of autotools as possible. I want
autoconfigure to choose a command to make pdfs, etc., rather than coding
it directly into Makefile.am. I then used a dist-hook clause to remove
.texi files before they are wrapped up in a tar archive for distribution.
> I checked in the following change. Does it fix the problem for you?
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/81c5ea6ddf81
>
May I substitute my patch for yours later today? Mine handles the
missing *.texi files and in addition gets the distribution and cleanfile
targets correct.

--Rik

FTP objects

2009-11-30T11:43:53Z

On 20-Nov-2009, David Bateman wrote:

| I have a fairly complete
| implementation of the FTP object type in the attached, though have
| several problems.

OK, I'm sorry I wasn't able to respond earlier.

| The first issue is that Octave currently doesn't have any code in the
| core using OOP and the matlab versions use OOP and so this is needed for
| compatibility. It appears that the new build process doesn't mind a
| scripts/@ftp. Is this the right place for it?

That seems OK to me.

| The next problem is that as this type wraps libcurl it has to be
| implemented at least partially in an oct-file. So the oct-files should
| live in the @ftp directory as well. One way should probably be like
|
| @ftp/{ftp.m, display.m, ...}
| @ftp/private/__ftp__.oct
| @ftp/private/PKG_ADD ## contains autoloads for the DEFUN_DLD functions
| in __ftp__.oct
|
| though this doesn't work as it appears that "autoload" doesn't work in
| either the private or class directories. In any case such a structure is
| against the separation of OS dependent and independent files, and I'm
| sure the debian packagers at least will complain as I remember well
| discussions about this when the pkg installation paths were being
| discussed.

Right, I don't think they would accept having architecture dependent
files in /usr/share.

| Then I suppose a better way to do it is to have two separate @ftp
| directories, one in
|
| ${fcnfiledir}/@ftp/{ftp.m,display.m,...}
| ${octfiledir}/@ftp/private/{__ftp__.oct,PKG_ADD}

If we do this, then maybe we should be doing some magic in the
load-path searching code so that the correspondence between the
${fcnfiledir}/@ftp and ${octfiledir}/@ftp is handled automatically?
Maybe there should be a directive that could appear in the
${fcnfiledir}/@ftp/PKG_ADD file that tells Octave to merge the
contents of the ${octfiledir}/@ftp with ${fcnfiledir}/@ftp? Or should
both directories should appear in the load-path?

| Having two separate @ftp directories works, but the autoloads in the
| private directory doesn't yet again. I'd suggest that the autoload issue
| in class and private directories should be fixed before going further
| with this direction.

How should it be fixed? Should we be searching for PKG_ADD files in
private directories? I guess that currently we are only looking for
PKG_ADD files in directories that actually appear in the load-path and
since private directories don't appear explicitly, we don't search for
PKG_ADD files there.

| As the oct-file basically does all of the work an alternative might be
| to have the OOP code in the oct-file itself and get rid of the mfiles.
| The mfiles in this changeset basically pass off all of the work to the
| underlying oct-file. However, I don't see how to do this within the
| build process. Ideas?

Does it work to create

${octfiledir}/@ftp/{__ftp__.oct,PKG_ADD}

and have the PKG_ADD file provide the autoloads for the individual
function names? Then we would still be relying on the user to
recognize that __ftp__ is an internal function instead of enforcing it
with the private directory structure.

Or are you asking how should the ${octfiledir}/@ftp subdirectory be
created within the current build scheme? I could help with that if we
decide that is needed.

| What I did in the attached package was to just make the oct-files
| callable anywhere even though they are only useful for the ftp objects
| and added the code to urlwrite.cc so that code might be shared with
| these functions. This avoids needing to fix the private directories with
| oct-files and autoloading, but adds yet more functions starting with __
| to the global function name space. The advantage for this is that
| nothing special needs to be done for the oct-file installation to put
| them in a different directory than normal. This is what this changeset
| implements

I think this is OK for now, but I would like to move the __x__
functions to private directories, so we need to discuss and decide how
best to handle private .oct files and also whether the .oct files
should be somehow grouped together with corresponding .m files (i.e.,
should we implement some kind of merged directories for the load-path
searching code so that we can keep architecture dependent and
independent files separate but have the load-path searching code see
certain directories as belonging together?).

| The next issue I have is how do I document an OOP class in the octave
| manual that overloads existing functions like cd, delete, close, mkdir,
| rmdir, etc? I can't use DOCSTRING on the OOP methods so basically all I
| can do is include the non overloaded functions and write a bit of text
| around those the explain the rest. Is there a better way? In any case
| there are a number of duplication errors signaled in the creation of the
| DOCSTRING file, but these don't stop the build itself.

How about the following change?

http://hg.savannah.gnu.org/hgweb/octave/rev/1506a17832c9

With it, you can use

@DOCSTRING(@ftp/ascii)

to reference the docstrings in the .txi files.

| Another question is should I store the password in the FTP object? If I
| want to be able to save the FTP objects to a file and have them work
| when reloaded, then this is needed. However, it can represent a security
| risk, though not much of a one as the password is stored in the octave
| history when the handle was first created. Should I care?

What does Matlab do? Should we try to make it possible for someone to
load an ftp object in Octave that was saved in a Matlab session?

| PS: I create the curl_handle class in __ftp__.cc such that it might be
| reused for urlread and urlwrite and reduce the code duplication between
| this existing code and the ftp objects and used this in the urlread and
| urlwrite functions.

OK. You know I am almost always in favor of eliminating duplicate
code...

Thanks,

jwe

Re: *.texi files not generated

2009-11-30T10:34:01Z

On 28-Nov-2009, Michael D. Godfrey wrote:

| On 11/28/09 5:19 PM, Rik wrote:
| > The procedure I follow to verify my patches
| > has been to clone a new tree from savannah, run autogen.sh, run
| > configure, and then run make. This avoids any cruft that may have built
| > up in the source tree.
| >
| This is what I did, and none of the .texi files got generated. but,
| cd doc/interpreter; make xxx.texi would create the .txi. Also, I
| found that if "old" .texi files were present the make updated them.
| So, now my builds run fine -- until I do a new clone. For now,
| I will save the old .texi files and copy them into a new clone.

I checked in the following change. Does it fix the problem for you?

http://hg.savannah.gnu.org/hgweb/octave/rev/81c5ea6ddf81

Thanks,

jwe

Little documentation bug

2009-11-30T10:33:05Z

On 29-Nov-2009, Eus wrote:

| Mind to check in the attached patch regarding a typo in inverse 2D FFT?

I fixed the ifft2 docstring.

Thanks,

jwe

Additional item in build /doc/interpreter problems

2009-11-30T10:31:11Z

On 30-Nov-2009, Michael Godfrey wrote:

| I have made the build run through, but there
| is a remaining error which I think is not part of
| the problem of building the *.texi files. The error
| message is:
| /home/godfrey/mdg/software/octave/devel/hg/octave/doc/interpreter//arith.texi:838:
| Cross reference to nonexistent node `doc-dot' (perhaps incorrect
| sectioning?).
| makeinfo: Removing output file
| `/home/godfrey/mdg/software/octave/devel/hg/octave/doc/interpreter/octave.htp/index.html'
| due to errors; use --force to preserve.
| make[3]: [octave.html] Error 1 (ignored)

The docstring for dot should be in the src/DOCSTRINGS file. Is it
there?

jwe

Add image support for fltk printing

2009-11-30T09:45:07Z

Hi

The attached changeset implements image printing using the fltk
backend (and as a bonus fixes a bug in the gl-renderer image support
that prevented display of images with width and/or height of 1). There
is some problem with how the gl2ps library decides if something
obscures an image so sometimes the axis background will obsecure the
image in ps file (i.e. the image won't be shown ...).
I do not know of an easy fix.

Also, images are stored in the ps file as uncompressed 24 bit per
pixel hex strings, so beware of printing large images (e.g. each image
megapixel will take 6MB in the ps file)

Shai

gl2ps_images.changeset (8K) Download Attachment

Additional item in build /doc/interpreter problems

2009-11-30T03:07:52Z

I have made the build run through, but there
is a remaining error which I think is not part of
the problem of building the *.texi files. The error
message is:
/home/godfrey/mdg/software/octave/devel/hg/octave/doc/interpreter//arith.texi:838:
Cross reference to nonexistent node `doc-dot' (perhaps incorrect
sectioning?).
makeinfo: Removing output file
`/home/godfrey/mdg/software/octave/devel/hg/octave/doc/interpreter/octave.htp/index.html'
due to errors; use --force to preserve.
make[3]: [octave.html] Error 1 (ignored)

Re: small graphics fixes

2009-11-29T12:06:46Z

On 11/29/09 8:22 PM, Shai Ayal wrote:
> Maybe it's the nx server? I don't have a clue.
> You say that previous builds work. Do they work now or did they work before?
> can you try glxgears to see if opengl is working?
>
glxgears works. And, the "old" build from 24 November works now and it
worked
when the current build was failing (See below!!). Also,
what I meant by "no plot" the frame came up (with A G along the
bottom), but the
data and axes were not drawn.

However, I have real news. Now it works. I really have no idea what fixed
it. I am running in the same NX session as before: I just disconnected and
reconnected -- this brings back exactly the state when I disconnected.
The only thing I did was run glxgears!!!

My experience with openGL is that it does lots of neat stuff, but it has
some
deep mysteries. Also, I have an application which causes openGL to
cause X11
to segfault -- end of X11. I documented this fully and sent it in, but
they just
decided it was too hard, or not worth fixing.

Back to Octave. If it fails again I will try to figure something out before
it starts working again. As I think of what could have gone wrong, I
suspect
X11 as much as openGL or Octave...
I looked around my server system: nothing obvious in system logs, etc.

Thanks again,
Michael

Re: Scale change for Plot Figures in the Manual

2009-11-29T11:56:00Z

On Nov 28, 2009, at 5:05 PM, Ben Abbott wrote:

>
> On Nov 28, 2009, at 4:27 PM, John W. Eaton wrote:
>
>> On 27-Nov-2009, Michael D. Godfrey wrote:
>>
>> | I looked at the current octave.pdf to see if my method
>> | of recovering from the doc/interpreter build problem had
>> | worked. This caused me to notice that the Figures in the
>> | Plotting Chapter are now about 1/5 intended size. I looked
>> | back at a Manual generated on 23 November. (Before the
>> | build problem.) It shows the same scale problem.
>> |
>> | I believe that the build script always uses octave -f, so
>> | the problem is probably not due to my having backend("fltk")
>> | in my .octaverc file.
>> |
>> | Is this problem happening to others?
>>
>> Yes, it seems that we are now using
>>
>> print -dpdf
>>
>> to create the PDF files and the resulting output is not cropped
>> tightly around teh bounding box of the figure.
>>
>> If that is what the -dpdf option is supposed to do, then I guess we
>> should probably just have the Makefile produce .eps files and then
>> convert them to formats we need instead of using Octave's print
>> function to generate the various formats.
>>
>> jwe
>
>
> "print -dpdf" should output the size of which is defined by the "pagesize" property.
>
> Seeing this reminded me that we'd discussed this some months ago. See the thread below.
>
> http://old.nabble.com/printing-figures-with-development-version-td22746152.html#a22835985
>
> The problem can be resolved by switching to eps. However, it is possible that the axes labels may be clipped. In that case, the pdf size may be specified by changing the defualtpapersize and defaultpaperposition prior to generating the pdfs.
>
> image_size = [6.4, 4.8]; % in inches
> border = 0;
> set (0, "defaultfigurepapertype", "<custom>")
> set (0, "defaultfigurepapersize", image_size + 2*border)
> set (0, "defaultfigurepaperposition", [border, border, image_size])
>
> If the axes labels for the pdf get cut off, the "border" may be increased.
>
> Ben

The changeset below looks like it was the result of the thread above.

http://hg.savannah.gnu.org/hgweb/octave/diff/77e71f3da3d6/doc/interpreter/plotimages.m

I'm unfamiliar with how the documentation is created, but It appears to me that the files below need to have similar changes.

http://hg.savannah.gnu.org/hgweb/octave/log/cddd5c3d5f04/doc/interpreter/geometryimages.m

http://hg.savannah.gnu.org/hgweb/octave/log/cddd5c3d5f04/doc/interpreter/interpimages.m

http://hg.savannah.gnu.org/hgweb/octave/log/cddd5c3d5f04/doc/interpreter/sparseimages.m

I'm presently unable to build the developers version of octave. Can someone tell me if the attached works?

Ben

changeset.patch (3K) Download Attachment

Re: small graphics fixes

2009-11-29T07:10:33Z

On Sun, Nov 29, 2009 at 5:08 PM, Michael D. Godfrey
<godfrey@...> wrote:

> On 11/27/09 9:21 PM, Shai Ayal wrote:
>>
>> I attach a changeset with 3 small changes:
>> 1. typo fix
>> 2. change rendering order in gl-renderer so that the list of children
>> is drawn from end to start -- the first child in the list should be
>> on top of the others
>> 3. change colorbar from an image to a surface. while using an image is
>> more concise, using a surface has the advantage of working with the
>> current gl-renderer, and with gl2ps, so that it will appear in the
>> postscript output.
>>
>
> In my previous email I meant to make clear that the above is the changeset
> that is
> suspicious for me.

It works fine for me.
what's your graphics setup? what is the output of
glxinfo | grep renderer

I have it working with both nvidia and Mesa X11
Shai

Re: small graphics fixes

2009-11-29T07:08:38Z

On 11/27/09 9:21 PM, Shai Ayal wrote:

In my previous email I meant to make clear that the above is the
changeset that is
suspicious for me.

Michael

Re: small graphics fixes

2009-11-29T06:36:23Z

Shai,

I am pretty sure that this is the changeset that has the effect,
for me, of producing a blank plot for:
plot([1:200])
xlabel("xxx label")

No contents appear. A build from 24 November works fine.

Sorry,
Michael

Little documentation bug

2009-11-29T03:01:33Z

HiHo!

Mind to check in the attached patch regarding a typo in inverse 2D FFT?

Thanks.

PS: Please put me in the CC when replying since I am not subscribed to
the mailing list.

--
Best regards,
Eus (FSF member #4445)

In this digital era, where computing technology is pervasive, your
freedom depends on the software controlling those computing devices.

Join free software movement today! It is free as in freedom, not as in
free beer!

Join: http://www.fsf.org/jf?referrer=4445

[patch]

diff -r cddd5c3d5f04 src/DLD-FUNCTIONS/fft2.cc --- a/src/DLD-FUNCTIONS/fft2.cc Sun Nov 29 07:51:15 2009 +0100 +++ b/src/DLD-FUNCTIONS/fft2.cc Sun Nov 29 11:53:26 2009 +0100 @@ -189,7 +189,7 @@ DEFUN_DLD (ifft2, args, , "-*- texinfo -*-\n\ -@deftypefn {Loadable Function} {} fft2 (@var{a}, @var{n}, @var{m})\n\ +@deftypefn {Loadable Function} {} ifft2 (@var{a}, @var{n}, @var{m})\n\ Compute the inverse two-dimensional FFT of @var{a} using subroutines from\n" FFTSRC ". The optional arguments @var{n} and @var{m} may be used specify the\n\

Re: Scale change for Plot Figures in the Manual

2009-11-28T14:05:45Z

On Nov 28, 2009, at 4:27 PM, John W. Eaton wrote:

> On 27-Nov-2009, Michael D. Godfrey wrote:
>
> | I looked at the current octave.pdf to see if my method
> | of recovering from the doc/interpreter build problem had
> | worked. This caused me to notice that the Figures in the
> | Plotting Chapter are now about 1/5 intended size. I looked
> | back at a Manual generated on 23 November. (Before the
> | build problem.) It shows the same scale problem.
> |
> | I believe that the build script always uses octave -f, so
> | the problem is probably not due to my having backend("fltk")
> | in my .octaverc file.
> |
> | Is this problem happening to others?
>
> Yes, it seems that we are now using
>
> print -dpdf
>
> to create the PDF files and the resulting output is not cropped
> tightly around teh bounding box of the figure.
>
> If that is what the -dpdf option is supposed to do, then I guess we
> should probably just have the Makefile produce .eps files and then
> convert them to formats we need instead of using Octave's print
> function to generate the various formats.
>
> jwe

"print -dpdf" should output the size of which is defined by the "pagesize" property.

Seeing this reminded me that we'd discussed this some months ago. See the thread below.

http://old.nabble.com/printing-figures-with-development-version-td22746152.html#a22835985

The problem can be resolved by switching to eps. However, it is possible that the axes labels may be clipped. In that case, the pdf size may be specified by changing the defualtpapersize and defaultpaperposition prior to generating the pdfs.

image_size = [6.4, 4.8]; % in inches
border = 0;
set (0, "defaultfigurepapertype", "<custom>")
set (0, "defaultfigurepapersize", image_size + 2*border)
set (0, "defaultfigurepaperposition", [border, border, image_size])

If the axes labels for the pdf get cut off, the "border" may be increased.

Ben

Scale change for Plot Figures in the Manual

2009-11-28T13:27:51Z

On 27-Nov-2009, Michael D. Godfrey wrote:

| I looked at the current octave.pdf to see if my method
| of recovering from the doc/interpreter build problem had
| worked. This caused me to notice that the Figures in the
| Plotting Chapter are now about 1/5 intended size. I looked
| back at a Manual generated on 23 November. (Before the
| build problem.) It shows the same scale problem.
|
| I believe that the build script always uses octave -f, so
| the problem is probably not due to my having backend("fltk")
| in my .octaverc file.
|
| Is this problem happening to others?

Yes, it seems that we are now using

print -dpdf

to create the PDF files and the resulting output is not cropped
tightly around teh bounding box of the figure.

If that is what the -dpdf option is supposed to do, then I guess we
should probably just have the Makefile produce .eps files and then
convert them to formats we need instead of using Octave's print
function to generate the various formats.

jwe

Re: new major release? (was: Re: 3.2.4 call for patches)

2009-11-28T13:16:20Z

On Nov 28, 2009, at 2:51 PM, John W. Eaton wrote:

> On 28-Nov-2009, Shai Ayal wrote:
>
> | On Wed, Nov 25, 2009 at 11:11 PM, John W. Eaton <jwe@...> wrote:
> | > There is also the
> | >
> | > addproperty: a `textlist' property already exists in the graphics object
> | >
> | > bug.
> | >
> | How do you reproduce this bug?
>
> Running
>
> demo clabel
>
> does it for me:
>
> octave:1> demo clabel
> clabel example 1:
> clf
> [c, h] = contour (peaks(), -4 : 6);
> clabel (c, h, -4 : 2 : 6, 'fontsize', 12);
>
> Press <enter> to continue:
> clabel example 2:
> clf
> [c, h] = contourf (peaks(), -7 : 6);
> clabel (c, h, -6 : 2 : 6, 'fontsize', 12);
>
> clabel example 2: failed
> addproperty: a `textlist' property already exists in the graphics object
>
> This is independent of which graphics backend is used.
>
> jwe

Soren noticed a similar (same?) bug some weeks ago.

http://old.nabble.com/%60__pixels_per_inch__%27-property-already-exists-p26049817.html

Ben

Re: small graphics fixes

2009-11-28T12:56:28Z

On 28-Nov-2009, Shai Ayal wrote:

| I attach another small changeset which implements indexed images. Like
| many other changes I submitted, this actually consisted of much
| planning, followed by a lot of browsing through code to see how to do
| it, and then finding out that Michael Goffioul already though of it
| and I just have to use his functions :)
| In this case, adding indexed image suppoert consisting of changing
| just one line (actually just one word: cdata -> color_data)

I applied this change.

Thanks,

jwe

small graphics fixes

2009-11-28T12:55:54Z

On 27-Nov-2009, Shai Ayal wrote:

| I attach a changeset with 3 small changes:
| 1. typo fix
| 2. change rendering order in gl-renderer so that the list of children
| is drawn from end to start -- the first child in the list should be
| on top of the others
| 3. change colorbar from an image to a surface. while using an image is
| more concise, using a surface has the advantage of working with the
| current gl-renderer, and with gl2ps, so that it will appear in the
| postscript output.
|
| I plan to begin indexed image support in the gl-renderer (but I'm
| afraid it will still have problems converting to postscript).
| Also, a lot of graphics scripts are not backend-agnostic and contain
| many gnuplot specifics -- most notably. print.m I think they should be
| seperated into backend specific and backend agnostic parts. I will try
| to do this myself, but any help would be appreciated.

I applied the patch to gl-render.h and graphics.cc, but not the change
to the colorbar function.

Switching the colorbar to a surface doesn't work for the gnuplot
backend (see the attached images). This may be a bug in the gnuplot
backend, but since the colorbar should be an image object for
compatibility with Matlab, I don't think we should change it to a
surface object in Octave.

jwe

before.png (14K) Download Attachment
after.png (14K) Download Attachment

Re: FYI: smarter indexing by logical masks

2009-11-28T11:55:51Z

On Sat, Nov 28, 2009 at 1:23 AM, Jaroslav Hajek <highegg@...> wrote:
> Not really. Let me explain how this works (not in 3.2.x though). When a
> matrix is first used in index expression, the internal conversion to
> index_vector is, if successful, cached for subsequent uses.

That is even better. I didn't pick up on octave caching the result in
your first email. Now I don't even have to do that manually anymore
which is also a huge deal! :) When you were reporting the two times in
your benchmark, I misunderstood and thought that was about filling the
CPU cache/conditioning along the lines of timeit.m
http://blogs.mathworks.com/steve/2008/02/29/timing-code-in-matlab/

find() returning doubles is yet another case of WWMWT that I hadn't
noticed. In a sane world index vectors would map immediately to one of
the integer array types based on the architecture. At least that's how
it works in IDL. But you're right, Matlab returns doubles. WITWWMWT D:

Great work!

--judd

Re: new major release? (was: Re: 3.2.4 call for patches)

2009-11-28T11:51:54Z

On 28-Nov-2009, Shai Ayal wrote:

| On Wed, Nov 25, 2009 at 11:11 PM, John W. Eaton <jwe@...> wrote:
| > There is also the
| >
| > addproperty: a `textlist' property already exists in the graphics object
| >
| > bug.
| >
| How do you reproduce this bug?

Running

demo clabel

does it for me:

octave:1> demo clabel
clabel example 1:
clf
[c, h] = contour (peaks(), -4 : 6);
clabel (c, h, -4 : 2 : 6, 'fontsize', 12);

Press <enter> to continue:
clabel example 2:
clf
[c, h] = contourf (peaks(), -7 : 6);
clabel (c, h, -6 : 2 : 6, 'fontsize', 12);

clabel example 2: failed
addproperty: a `textlist' property already exists in the graphics object

This is independent of which graphics backend is used.

jwe

Re: new major release? (was: Re: 3.2.4 call for patches)

2009-11-28T11:06:04Z

On Wed, Nov 25, 2009 at 11:11 PM, John W. Eaton <jwe@...> wrote:
> There is also the
>
> addproperty: a `textlist' property already exists in the graphics object
>
> bug.
>
How do you reproduce this bug?

Shai

Re: small graphics fixes

2009-11-28T09:18:49Z

On Fri, Nov 27, 2009 at 10:21 PM, Shai Ayal <shaiay@...> wrote:

> I attach a changeset with 3 small changes:
> 1. typo fix
> 2. change rendering order in gl-renderer so that the list of children
> is drawn from end to start -- the first child in the list should be
> on top of the others
> 3. change colorbar from an image to a surface. while using an image is
> more concise, using a surface has the advantage of working with the
> current gl-renderer, and with gl2ps, so that it will appear in the
> postscript output.
>
> I plan to begin indexed image support in the gl-renderer (but I'm
> afraid it will still have problems converting to postscript).
> Also, a lot of graphics scripts are not backend-agnostic and contain
> many gnuplot specifics -- most notably. print.m I think they should be
> seperated into backend specific and backend agnostic parts. I will try
> to do this myself, but any help would be appreciated.
>

I attach another small changeset which implements indexed images. Like

many other changes I submitted, this actually consisted of much
planning, followed by a lot of browsing through code to see how to do
it, and then finding out that Michael Goffioul already though of it
and I just have to use his functions :)
In this case, adding indexed image suppoert consisting of changing
just one line (actually just one word: cdata -> color_data)

Together with my previous changeset to colorbar, the colorbar demos
now work under fltk on-screen.

Shai

various_graphics.changeset (3K) Download Attachment
indexed_images.changeset (1K) Download Attachment

Re: *.texi files not generated

2009-11-28T08:42:06Z

On 11/28/09 5:19 PM, Rik wrote:
> The procedure I follow to verify my patches
> has been to clone a new tree from savannah, run autogen.sh, run
> configure, and then run make. This avoids any cruft that may have built
> up in the source tree.
>
This is what I did, and none of the .texi files got generated. but,
cd doc/interpreter; make xxx.texi would create the .txi. Also, I
found that if "old" .texi files were present the make updated them.
So, now my builds run fine -- until I do a new clone. For now,
I will save the old .texi files and copy them into a new clone.

Re: *.texi files not generated

2009-11-28T08:19:31Z

>
> ------------------------------------------------------------------------
>
> Subject:
> Re: *.texi files not generated
> From:
> "John W. Eaton" <jwe@...>
> Date:
> Fri, 27 Nov 2009 18:44:07 -0500
> To:
> "Michael D. Godfrey" <godfrey@...>
>
> To:
> "Michael D. Godfrey" <godfrey@...>
> CC:
> Rik <rdrider0-list@...>, octave maintainers mailing list
> <maintainers@...>
>
>
> On 27-Nov-2009, Michael D. Godfrey wrote:
>
> | On 11/27/09 5:29 PM, Ben Abbott wrote:
> | > "make -i" doesn't generate the texi files though,
> | True. I generated them by cd doc/interpreter, then "make xxx.texi"
> | would correctly generate a xxx.texi file. I just did this in order
> | to establish where to problem was.
> |
> | I hope we hear from Rik fairly soon.
>

My apologies. It was the Thanksgiving holiday here in the U.S. and I
have been away from my computer.

I'm hoping that this is merely a cruft issue. A number of the changes I
checked in touch the autotool files directly, such as Makefile.am.
There is a dependency mechanism that is supposed to recognize when a
configuration file has been changed and rebuild the Makefiles, but I
have found it to be weak. The procedure I follow to verify my patches
has been to clone a new tree from savannah, run autogen.sh, run
configure, and then run make. This avoids any cruft that may have built
up in the source tree.

Eventually, changes to the build environment will settle down and we can
stop using such extremely time-consuming build check procedures.
However, If you have a spare 45 minutes, I would ask you to try the
procedure above.

I'm currently trying a fresh compilation with a tip downloaded today of
9ed5f64e3959. I'll let you know.

> The problem is this change:
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/02d59b67632f
>
> which split the octave_TEXINFOS variable into nodist_octave_TEXINFOS
> and dist_octave_TEXINFOS. If I understand correctly, autoconf is
> supposed to recognize the dist and nodist prefixes and do some magic.
> But it is not working, because no overal octave_TEXINFOS variable is
> created, so in the lines
>
> $(srcdir)/octave.info: $(octave_TEXINFOS) $(IMAGES_TXT) $(EXAMPLE_FILES)
>
> octave.dvi octave.ps: $(octave_TEXINFOS) $(IMAGES_EPS) $(EXAMPLE_FILES)
>
> octave.pdf: $(octave_TEXINFOS) $(IMAGES_PDF) $(EXAMPLE_FILES)
>
> octave.html: $(octave_TEXINFOS) $(IMAGES_PNG) $(EXAMPLE_FILES)
>
> which are intended to add extra dependencies for these targets,
> $(octave_TEXINFOS) is empty, so there is no chain of dependencies that
> forces the .texi files to be created.
>
> Maybe this is not the right way to specify the extra dependencies when
> using autoconf. But if there is a proper way to do it, I don't see
> how. My guess is that I just don't understand the proper way to use
> autoconf, but it may also be a bug. Either way, I guess we probably
> need the help of an autoconf guru.
>

The issue is conf.texi which is a derived file and should not be
distributed. However, by listing it as a prerequisite for octave.info
file it looks like a source file to autotools and source files need to
be distributed. I worked around this by using the autotool specified
magic of dist_ and no_dist_. Perhaps there is not enough magic in these
constructs, but I'm still waiting on the results of my compilation this
morning.

--Rik

Re: FTP objects

2009-11-28T02:46:33Z

Ok, given no response to my questions of the way to have OOP code, I
merged this changeset

D.

Re: FYI: smarter indexing by logical masks

2009-11-27T22:23:58Z

On Sat, Nov 28, 2009 at 6:26 AM, Judd Storrs <storrsjm@...> wrote:

This is pretty cool!

Is it possible to somehow pre-compute/convert the mask? I've often
used find() to pre-convert a mask into index form because I think that
improves performance when the mask is used multiple times (but it may
have been a habit that I picked up when I was working primarily in IDL
where this is part of the collective folk wisdom). e.g. things along
these lines:

mask = find(a > 0) ;
a(mask) = b(mask) ;

Not really. Let me explain how this works (not in 3.2.x though). When a matrix is first used in index expression, the internal conversion to index_vector is, if successful, cached for subsequent uses. This optimizes usages like
c(mask) = a(mask) + b(mask)
because the conversion of mask has only to be done once. But beware that this is still evaluated by pieces, i.e.

aa = a(mask);
bb = b(mask);
cc = aa + bb;
c(mask) = cc;

This explains why find is *apparently* faster in your benchmark, because find creates the result with the index vector *already cached*. Try putting the first tic; prior to
mask = , and you will see. Also, in the last (full) section you've missed an assignment to mask:
"a > 0.0;" should be "mask = a > 0.0;"

Here's what I get with a corrected benchmark (the 4e7 case is too much for my home laptop):

n = 100000
sparse mask:        1st: 0.001931, 2nd: 0.000562
sparse mask(find): 1st: 0.001640, 2nd: 0.000611
sparse mask(where): 1st: 0.002379, 2nd: 0.000562
dense mask:         1st: 0.004646, 2nd: 0.003817
dense mask(find):   1st: 0.005676, 2nd: 0.003681
dense mask(where): 1st: 0.005042, 2nd: 0.003642
full mask:          1st: 0.002669, 2nd: 0.001587
full mask(find):    1st: 0.006236, 2nd: 0.004371
full mask(where):   1st: 0.005657, 2nd: 0.003588
n = 1000000
sparse mask:        1st: 0.017749, 2nd: 0.009287
sparse mask(find): 1st: 0.018799, 2nd: 0.008243
sparse mask(where): 1st: 0.016918, 2nd: 0.007967
dense mask:         1st: 0.044704, 2nd: 0.038776
dense mask(find):   1st: 0.058628, 2nd: 0.039231
dense mask(where): 1st: 0.054648, 2nd: 0.035887
full mask:          1st: 0.028402, 2nd: 0.017976
full mask(find):    1st: 0.057978, 2nd: 0.042992
full mask(where):   1st: 0.057311, 2nd: 0.038398
n = 10000000
sparse mask:        1st: 0.178092, 2nd: 0.092343
sparse mask(find): 1st: 0.182628, 2nd: 0.079860
sparse mask(where): 1st: 0.165752, 2nd: 0.079588
dense mask:         1st: 0.442568, 2nd: 0.392207
dense mask(find):   1st: 0.587378, 2nd: 0.398332
dense mask(where): 1st: 0.601536, 2nd: 0.397812
full mask:          1st: 0.256911, 2nd: 0.192204
full mask(find):    1st: 0.625493, 2nd: 0.435221
full mask(where):   1st: 0.639314, 2nd: 0.434564

so you can see find is actually slower. Not by much because the time is drowned in the other work; there's the mask creation, two index expressions, one addition and one indexed assignment. It's mainly visible in the dense and full mask cases. In fact, "find" not only *always* converts to index vector, it also creates a *double* array corresponding to the result (to form a valid octave_value). Hence, in development version, using raw logical masks is more efficient in (almost?) all cases.

I've been playing with the new code a bit and I think the find() trick
defeats the new optimization? I tried to create a simple where.oct
that converts its input into the new smart mask but I think I've
missed something

#include <octave/oct.h>

DEFUN_DLD(where, args, ,
"Convert mask to index")
{
idx_vector idx = args(0).index_vector() ;
return octave_value(idx);
}

Spoiler alert: something's wrong here because 'where' is slower than
using the raw boolean matrix. Here's the modified benchmark code I've
been using:

Yeah. Regarding this, I'm not yet fully sure. My rationale was that when you assign an index_vector to octave_value,
you expect to get a numeric array, not a logical one. So, if the idx_vector is actually a mask, it is converted to an index array. Hence, your where function actually simulates "find" (its simplest case). Giving it a second thought, maybe it should be possible to return a logical array with cached index; still, I believe one should never create a numeric array with a cached logical mask. That would be a bit weird. Hence, "find" will need to do the conversion.

here's the corrected benchmark:

for n = [1e5 1e6 1e7]
printf ("n = %d\n", n);
a = rand(n,1);
b = rand(n,1);
c = zeros(n,1);

tic; mask = a > 0.9;
c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("sparse mask:        1st: %f, 2nd: %f\n", t1, t2);
tic; mask = find(a > 0.9);
c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("sparse mask(find): 1st: %f, 2nd: %f\n", t1, t2);
tic; mask = where(a > 0.9);
c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("sparse mask(where): 1st: %f, 2nd: %f\n", t1, t2);

tic; mask = a > 0.1;
c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("dense mask:         1st: %f, 2nd: %f\n", t1, t2);
tic; mask = find(a > 0.1);
c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("dense mask(find):   1st: %f, 2nd: %f\n", t1, t2);
tic; mask = where(a > 0.1);
c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("dense mask(where): 1st: %f, 2nd: %f\n", t1, t2);

tic; mask = a > 0.0;
c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("full mask:          1st: %f, 2nd: %f\n", t1, t2);
tic; mask = find(a > 0.0);
c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("full mask(find):    1st: %f, 2nd: %f\n", t1, t2);
tic; mask = where(a > 0.0);
c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("full mask(where):   1st: %f, 2nd: %f\n", t1, t2);

endfor

best regards

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

Re: FYI: smarter indexing by logical masks

2009-11-27T21:26:39Z

This is pretty cool!

Is it possible to somehow pre-compute/convert the mask? I've often
used find() to pre-convert a mask into index form because I think that
improves performance when the mask is used multiple times (but it may
have been a habit that I picked up when I was working primarily in IDL
where this is part of the collective folk wisdom). e.g. things along
these lines:

mask = find(a > 0) ;
a(mask) = b(mask) ;

I've been playing with the new code a bit and I think the find() trick
defeats the new optimization? I tried to create a simple where.oct
that converts its input into the new smart mask but I think I've
missed something

#include <octave/oct.h>

DEFUN_DLD(where, args, ,
"Convert mask to index")
{
idx_vector idx = args(0).index_vector() ;
return octave_value(idx);
}

Spoiler alert: something's wrong here because 'where' is slower than
using the raw boolean matrix. Here's the modified benchmark code I've
been using:

for n = [1e5 1e6 1e7 4e7]
printf ("n = %d\n", n);
a = rand(n,1);
b = rand(n,1);
c = zeros(n,1);

mask = a > 0.9;
tic; c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("sparse mask: 1st: %f, 2nd: %f\n", t1, t2);
mask = find(a > 0.9);
tic; c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("sparse mask(find): 1st: %f, 2nd: %f\n", t1, t2);
mask = where(a > 0.9);
tic; c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("sparse mask(where): 1st: %f, 2nd: %f\n", t1, t2);

mask = a > 0.1;
tic; c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("dense mask: 1st: %f, 2nd: %f\n", t1, t2);
mask = find(a > 0.1);
tic; c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("dense mask(find): 1st: %f, 2nd: %f\n", t1, t2);
mask = where(a > 0.1);
tic; c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("dense mask(where): 1st: %f, 2nd: %f\n", t1, t2);

a > 0.0;
tic; c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("full mask: 1st: %f, 2nd: %f\n", t1, t2);
mask = find(a > 0.0);
tic; c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("full mask(find): 1st: %f, 2nd: %f\n", t1, t2);
mask = where(a > 0.0);
tic; c(mask) = a(mask) + b(mask); t1 = toc;
tic; c(mask) = a(mask) + b(mask); t2 = toc;
fprintf ("full mask(where): 1st: %f, 2nd: %f\n", t1, t2);

endfor

This is the output I get (core2 duo @ 1.80GHz).

n = 100000
sparse mask: 1st: 0.000999, 2nd: 0.000244
sparse mask(find): 1st: 0.000489, 2nd: 0.000264
sparse mask(where): 1st: 0.000327, 2nd: 0.000222
dense mask: 1st: 0.003210, 2nd: 0.004524
dense mask(find): 1st: 0.003246, 2nd: 0.002669
dense mask(where): 1st: 0.002386, 2nd: 0.002292
full mask: 1st: 0.002051, 2nd: 0.004716
full mask(find): 1st: 0.004231, 2nd: 0.003856
full mask(where): 1st: 0.004140, 2nd: 0.003120
n = 1000000
sparse mask: 1st: 0.012595, 2nd: 0.008671
sparse mask(find): 1st: 0.008518, 2nd: 0.008409
sparse mask(where): 1st: 0.007252, 2nd: 0.008931
dense mask: 1st: 0.040465, 2nd: 0.035385
dense mask(find): 1st: 0.038676, 2nd: 0.037124
dense mask(where): 1st: 0.036798, 2nd: 0.032833
full mask: 1st: 0.033531, 2nd: 0.035070
full mask(find): 1st: 0.041958, 2nd: 0.039313
full mask(where): 1st: 0.041469, 2nd: 0.038953
n = 10000000
sparse mask: 1st: 0.132680, 2nd: 0.086522
sparse mask(find): 1st: 0.087629, 2nd: 0.086389
sparse mask(where): 1st: 0.077222, 2nd: 0.074444
dense mask: 1st: 0.369931, 2nd: 0.350971
dense mask(find): 1st: 0.355203, 2nd: 0.367536
dense mask(where): 1st: 0.361620, 2nd: 0.361944
full mask: 1st: 0.355967, 2nd: 0.355466
full mask(find): 1st: 0.389125, 2nd: 0.391282
full mask(where): 1st: 0.388657, 2nd: 0.391113
n = 40000000
sparse mask: 1st: 0.524230, 2nd: 0.329079
sparse mask(find): 1st: 0.334702, 2nd: 0.334690
sparse mask(where): 1st: 0.318233, 2nd: 0.318034
dense mask: 1st: 1.391669, 2nd: 1.341700
dense mask(find): 1st: 1.350176, 2nd: 1.355216
dense mask(where): 1st: 1.359566, 2nd: 1.355399
full mask: 1st: 1.354963, 2nd: 1.353266
full mask(find): 1st: 1.482584, 2nd: 1.483595
full mask(where): 1st: 1.482001, 2nd: 1.483312

--judd

Re: *.texi files not generated

2009-11-27T15:44:07Z

On 27-Nov-2009, Michael D. Godfrey wrote:

| On 11/27/09 5:29 PM, Ben Abbott wrote:
| > "make -i" doesn't generate the texi files though,
| True. I generated them by cd doc/interpreter, then "make xxx.texi"
| would correctly generate a xxx.texi file. I just did this in order
| to establish where to problem was.
|
| I hope we hear from Rik fairly soon.

The problem is this change:

http://hg.savannah.gnu.org/hgweb/octave/rev/02d59b67632f

which split the octave_TEXINFOS variable into nodist_octave_TEXINFOS
and dist_octave_TEXINFOS. If I understand correctly, autoconf is
supposed to recognize the dist and nodist prefixes and do some magic.
But it is not working, because no overal octave_TEXINFOS variable is
created, so in the lines

$(srcdir)/octave.info: $(octave_TEXINFOS) $(IMAGES_TXT) $(EXAMPLE_FILES)

octave.dvi octave.ps: $(octave_TEXINFOS) $(IMAGES_EPS) $(EXAMPLE_FILES)

octave.pdf: $(octave_TEXINFOS) $(IMAGES_PDF) $(EXAMPLE_FILES)

octave.html: $(octave_TEXINFOS) $(IMAGES_PNG) $(EXAMPLE_FILES)

which are intended to add extra dependencies for these targets,
$(octave_TEXINFOS) is empty, so there is no chain of dependencies that
forces the .texi files to be created.

Maybe this is not the right way to specify the extra dependencies when
using autoconf. But if there is a proper way to do it, I don't see
how. My guess is that I just don't understand the proper way to use
autoconf, but it may also be a bug. Either way, I guess we probably
need the help of an autoconf guru.

jwe

Re: Re: [changeset] changet to acinclude.m4 for windows build

2009-11-27T15:17:56Z

Hello Jaroslav

In the mail in the past, I found
>Tatsuro, can you please adapt this to a patch against 3.2.x?

I do not have a account to update Mecurial archive on the web so that I ask you apply the changeset in
the previous mail.

http://old.nabble.com/Re:-Re:--changeset--changet-to-acinclude.m4-for-windows-build-p26530889.html

Regards

Tatsuro

--- Tatsuro MATSUOKA wrote:

> Hello Jaroslav Hajek
>
> I have remade the changeset for 3.2.x. and am attaching it with this mail.
>
> Regards
>
> Tatsuro
>
> --- Jaroslav Hajek wrote:
>
> > On Wed, Nov 25, 2009 at 9:18 PM, John W. Eaton <jwe@...> wrote:
> >
> > > On 24-Nov-2009, Tatsuro MATSUOKA wrote:
> > >
> > > | The previous patch is for 3.2.x. and the patch attached to this mail
> > > | is for the development branch.
> > >
> > > I checked in the following change:
> > >
> > > http://hg.savannah.gnu.org/hgweb/octave/rev/763906db555e
> > >
> > > Does that look OK?
> > >
> > > Thanks,
> > >
> > > jwe
> > >
> >
> > Tatsuro, can you please adapt this to a patch against 3.2.x?
> >
> >
> > --
> > RNDr. Jaroslav Hajek
> > computing expert & GNU Octave developer
> > Aeronautical Research and Test Institute (VZLU)
> > Prague, Czech Republic
> > url: www.highegg.matfyz.cz
> >
>
> --------------------------------------
> What is your No.1 Entertainment of 2009? -Yahoo! JAPAN Net BANZUKE 2009
> http://pr.mail.yahoo.co.jp/banzuke/

--------------------------------------
What is your No.1 Entertainment of 2009? -Yahoo! JAPAN Net BANZUKE 2009
http://pr.mail.yahoo.co.jp/banzuke/

Scale change for Plot Figures in the Manual

2009-11-27T13:23:28Z

I looked at the current octave.pdf to see if my method
of recovering from the doc/interpreter build problem had
worked. This caused me to notice that the Figures in the
Plotting Chapter are now about 1/5 intended size. I looked
back at a Manual generated on 23 November. (Before the
build problem.) It shows the same scale problem.

I believe that the build script always uses octave -f, so
the problem is probably not due to my having backend("fltk")
in my .octaverc file.

Is this problem happening to others?

Michael

Re: FYI: smarter indexing by logical masks

2009-11-27T13:10:27Z

On 11/27/09 9:44 PM, Jaroslav Hajek wrote:
> any comments?
This looks good. And, it reminds me that I have
intended to suggest that putting some
tic; toc; fprintf() sequences in appropriate function tests
might be interesting. The tests could contain some
"base" time value (maybe from the most recent major
release). Displayed timing could be in % of base time,
corrected for CPU performance which could be determined
by running some fixed sequence at the beginning of the
tests.

See what you get for doing all this good work?? :-)

Michael

FYI: smarter indexing by logical masks

2009-11-27T12:44:20Z

hi all,

the attached changeset implements further optimizations to the indexing machinery when dealing with logical masks:
http://hg.savannah.gnu.org/hgweb/octave/rev/034677ab6865

Rationale:
Up to now, Octave always converted logical masks to index vectors for indexing, via the octave_value::index_vector method. This allows efficient random access and is generally beneficial for masks where most elements are false.
However, when the mask is nearly full, the storage for index array is up to 4x or 8x (for 64-bit indexing) larger, hence incurring a significant penalty for memory traffic, as well as the penalty for the conversion itself.

With the new change, octave will convert the mask to index array only if at most 1/8 (or 1/16 for 64-bit indexing) of elements are true; i.e. if the index array takes at most half the memory of the mask.
The innermost loops are specialized for the mask case, and contiguous subrange cases are also detected.

This is beneficial for expressions like x(x != 0) in which you expect the condition to be true for most or all elements;

The following benchmark illustrates the improvements:
for n = [1e5 1e6 1e7 4e7]
printf ("n = %d\n", n);
a = rand (n, 1);
mask = a > 0.9;
tic; a(mask); t1 = toc;
tic; a(mask); t2 = toc;
fprintf ("sparse mask: 1st: %f, 2nd: %f\n", t1, t2);
mask = a > 0.1;
tic; a(mask); t1 = toc;
tic; a(mask); t2 = toc;
fprintf ("dense mask: 1st: %f, 2nd: %f\n", t1, t2);
mask = a > 0.0;
tic; a(mask); t1 = toc;
tic; a(mask); t2 = toc;
fprintf ("full mask: 1st: %f, 2nd: %f\n", t1, t2);
endfor

on a Core 2 Duo @ 1.83 GHz, I get with a recent tip:

n = 100000
sparse mask: 1st: 0.000928, 2nd: 0.000157
dense mask: 1st: 0.001803, 2nd: 0.001093
full mask: 1st: 0.001564, 2nd: 0.001318
n = 1000000
sparse mask: 1st: 0.008774, 2nd: 0.002222
dense mask: 1st: 0.020419, 2nd: 0.011310
full mask: 1st: 0.020780, 2nd: 0.012612
n = 10000000
sparse mask: 1st: 0.086547, 2nd: 0.022133
dense mask: 1st: 0.196409, 2nd: 0.107571
full mask: 1st: 0.203453, 2nd: 0.118685
n = 40000000
sparse mask: 1st: 0.366365, 2nd: 0.093962
dense mask: 1st: 0.790059, 2nd: 0.421204
full mask: 1st: 0.805457, 2nd: 0.466647

and with the new change:

n = 100000
sparse mask: 1st: 0.003601, 2nd: 0.000167
dense mask: 1st: 0.001102, 2nd: 0.001247
full mask: 1st: 0.000347, 2nd: 0.000013
n = 1000000
sparse mask: 1st: 0.007920, 2nd: 0.002377
dense mask: 1st: 0.013383, 2nd: 0.011627
full mask: 1st: 0.003406, 2nd: 0.000019
n = 10000000
sparse mask: 1st: 0.078718, 2nd: 0.023621
dense mask: 1st: 0.115947, 2nd: 0.108459
full mask: 1st: 0.031419, 2nd: 0.000039
n = 40000000
sparse mask: 1st: 0.325938, 2nd: 0.093050
dense mask: 1st: 0.462140, 2nd: 0.424088
full mask: 1st: 0.119612, 2nd: 0.000044

apparently, there is up to 70% speedup for the first indexing with dense masks, no penalty for subsequent ones.
for full masks, the speed-up is more than 6x (570%) because Octave detects that a shallow copy can be used.

any comments?

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