Rik | 1 Dec 01:05 2009

Re: *.texi files not generated

John W. Eaton wrote:
> On 30-Nov-2009, Rik wrote:
>
> | 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.
>
> I'm willing to consider not generating conf.texi, or generating it at
> configure time and only having it contain things like VERSION so that
> doesn't have to be changed by hand in the sources.  But I'm not sure
> how to correctly handle the conditional variables like HAVE_COLAMD.
>   
I'll think about this.  I don't know the best way to handle the
conditional variables either which is why I left it alone for the time
being.
> | octave.info octave.dvi octave.pdf octave.html: $(nodist_octave_TEXINFOS) $(octave_TEXINFOS) $(EXAMPLE_FILES)
>
> Shouldn't these also depend on octave.texi?
>   
These are covered by the default suffix rules.  The actual rule that
makes octave.pdf is of the form .pdf.texi so octave.texi is the default
dependency.  Only the extra dependencies need to be added.
> | MAINTAINERCLEANFILES = $(IMAGES)
>
> If we are requiring that the documentation be rebuilt, then we might
> as well also stop distributing the various image files, so maybe these
> should also go in DISTCLEANFILES and not be added to EXTRA_DIST?
> Likewise for the scripts/DOCSTRINGS and src/DOCSTRINGS files.
>   
(Continue reading)

Judd Storrs | 1 Dec 01:38 2009
Picon

Re: FTP objects

>> | 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?
>>
> I no longer have access to octave and so I don't know.. What does matlab
> give for
>
> fp = ftp('ftp.gnu.org');
> get(fp)

get(fp) doesn't work. I think matlab is storing the password (2007b)

I setup a local ftp server for testing (i.e. it will only work for me,
the firewalls won't let outsiders in).

hostname: cuneus.msbb.uc.edu
username: ftpuser
password: 12345

If I start matlab and run

fp = ftp('cuneus.msbb.uc.edu','ftpuser','12345') ;
save ftp.mat fp
dir(fp)

(Continue reading)

Judd Storrs | 1 Dec 01:58 2009
Picon

Re: FTP objects

| 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?

Another good option could be to let  <at> ftp objects fallback to the
.netrc file for missing credentials (i.e. blank usernames and
passwords). Then objects could be created without passwords in the
history or in stored objects. (I haven't actually used the new octave
 <at> ftp object so that may already work)

--judd

David Bateman | 1 Dec 02:03 2009

Re: FTP objects

Judd Storrs wrote:
>>> | Anothe
> I setup a local ftp server for testing (i.e. it will only work for me,
> the firewalls won't let outsiders in).
>
> hostname: cuneus.msbb.uc.edu
> username: ftpuser
> password: 12345
>
> If I start matlab and run
>
> fp = ftp('cuneus.msbb.uc.edu','ftpuser','12345') ;
> save ftp.mat fp
> dir(fp)
>
> I get the expected file listing. If I then quit matlab and restart
>
> load ftp.mat
> dir(fp)
>
> works and gives the same file listing.
>   
Ok that is pretty conclusive.

>   
>> I don't know if matlab provides the get accessor function for FTP
>> objects and so this might just fail. The only other way to see if matlab
>> stores the username/password is to read the ftp.m constructor and maybe
>> modify the display method.
>>     
(Continue reading)

David Bateman | 1 Dec 02:04 2009

Re: FTP objects

Judd Storrs wrote:
> | 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?
>
> Another good option could be to let  <at> ftp objects fallback to the
> .netrc file for missing credentials (i.e. blank usernames and
> passwords). Then objects could be created without passwords in the
> history or in stored objects. (I haven't actually used the new octave
>  <at> ftp object so that may already work
>   
It should work already as netrc is supported by CURL itself.

D.

--

-- 
David Bateman                                dbateman <at> dbateman.org
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

John W. Eaton | 1 Dec 03:04 2009

Re: FTP objects

On  1-Dec-2009, David Bateman wrote:

| Could I have a v6 version of this file.. The compression of a v7 format 
| makes the file difficult to read manually..  As for loading it into 
| Octave, I believe the only way to do it is to modify ls-mat5.cc so that 
| classes without constructors are treated as structures, or just disable 
| classes temporarily by setting "isclass=false" at the "case 
| MAT_FILE_STRUCT_CLASS" statement in the load function.

Or maybe it would be easier to save it in the v7.3 format so you can
examine the contents with h5dump?

jwe

Judd Storrs | 1 Dec 03:29 2009
Picon

Re: FTP objects

On Mon, Nov 30, 2009 at 9:04 PM, John W. Eaton <jwe <at> octave.org> wrote:
> On  1-Dec-2009, David Bateman wrote:
>
> | Could I have a v6 version of this file.. The compression of a v7 format
> | makes the file difficult to read manually..  As for loading it into
> | Octave, I believe the only way to do it is to modify ls-mat5.cc so that
> | classes without constructors are treated as structures, or just disable
> | classes temporarily by setting "isclass=false" at the "case
> | MAT_FILE_STRUCT_CLASS" statement in the load function.
>
> Or maybe it would be easier to save it in the v7.3 format so you can
> examine the contents with h5dump?

Here are v6 and v7.3 versions. The v6 refuses to load in octave, but
the v7.3 version loads somewhat octave as a struct with numeric ascii
vectors instead of strings.

char(fp.password)
char(fp.username)

seem to work for decoding them.

--judd
Attachment (ftpv6.mat): application/octet-stream, 1775 bytes
Attachment (ftpv73.mat): application/octet-stream, 37 KiB
Jaroslav Hajek | 1 Dec 07:44 2009
Picon

Re: Improved normest



On Sat, Nov 28, 2009 at 11:04 AM, David Bateman <dbateman <at> dbateman.org> wrote:
Jaroslav Hajek wrote:
I see, thanks. I randomized the guess again. My problem with the previous
code was that a priori forming A'*A is quite costly, especially if you want
just low precision and expect just a dozen iterations:

A = rand (1e3);
tic; [e,c] = normest (A); toc
tic; [e,c] = normest (A, 1e-1); toc

now:

Elapsed time is 0.0229969 seconds.
Elapsed time is 0.0183249 seconds.

previously:

Elapsed time is 0.220653 seconds.
Elapsed time is 0.210241 seconds.
 
Explicitly forming A'*A seemed the right thing to do for full matrices as it only needed to be done once. I suppose it only makes sense to do so in the case of difficult convergence..

Yes, I noticed that it starts to pay off in case the number of iterations gets comparable to the order of the matrix.
But then, normest times comparably to plain "norm". Besides, it's trivial to do `sqrt(normest(A'*A))', getting the speed-up back.
I suppose the timings used to be different, because prior to 3.2.x, A'*x was much slower, doing a physical matrix conjugate transpose.
 
In that case a similar issue probably exists in the code bicgstab where is two preconditioning matrices are given then

precon = <at> (x) M2 \ (M1 \ x);

if M1 and M2 are sparse or

M = M1 \ M2;
precon <at> (x) M \ x;

otherwise. Though bicgstab usually has many more iterations than a simple power method as in normest, so perhaps the existing code is the right ting to do..


It seems OK. Usually preconditioners are matrices with fast left division, so they're likely to be either sparse (permuted) triangular or diagonal matrices. Dense triangular preconditioners are unlikely. So, if M1 and M2 aren't both sparse, probably one is diagonal (or both are), in which case M1*M2 is efficient and does not adversely impact sparsity.

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

Re: FYI: smarter indexing by logical masks



On Sat, Nov 28, 2009 at 8:55 PM, Judd Storrs <storrsjm <at> email.uc.edu> wrote:
On Sat, Nov 28, 2009 at 1:23 AM, Jaroslav Hajek <highegg <at> gmail.com> 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!

I suppose it's a heritage from the old days when Matlab had no integers. Now this needs to be kept for backward compatibility. This issue is magnified by the fact that integers are "invasive", in the sense that they force integer results when mixed with reals. So, if "find" suddenly started to return integer results a lot of computations would break. Further, int64 arithmetic is not implemented in Matlab (at least in 2007 or so), so that would be problematic. double can be used to index up to 2^53 = 9e+15 elements, and that seems enough for decades to come. All in all, it wasn't really bad solution in that time, but I'm sure if they started over, they'd do things differently.
I even thought about creating a special type to hold just idx_vector and pretending to be a double matrix, postponing the conversion until needed. But that would need significant extensions to idx_vector, mimicking the capabilities of arrays (esp. indexing). Scanning real-life scripts, I didn't find enough justification for this change. The index vectors returned by "find" or "sort" are typically used in indexing, that's why they're created with pre-cached index vector, but they're also often employed in arithmetic.
All in all, the current solution seems like a good compromise to me.

best regards

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
Michael D. Godfrey | 1 Dec 18:14 2009
Picon

Re: *.texi files not generated

The latest changeset to fix the build in doc/interpreter
works well for me.  In fact, it works just a bit better
than yours;  octave.pdf in yours was missing the Operator
Index (the last thing).  The new changeset produces the
Operator Index as it should. I only noticed this when I went
to compare the outputs.

Michael


Gmane