Re: gplot.txt

[Daniel J Sebald]

On 03/03/2016 05:48 AM, Ben Abbott wrote:
> > On Mar 3, 2016, at 02:00, Daniel J Sebald<address@hidden>  wrote:
> >
> > On 03/02/2016 09:07 PM, Ben Abbott wrote:
> > > > On Mar 2, 2016, at 9:41 PM, Daniel J Sebald<address@hidden>   wrote:
> > > >
> > > > On 03/02/2016 08:03 PM, Ben Abbott wrote:
> > > > > > On Mar 2, 2016, at 3:02 PM, Daniel J Sebald<address@hidden>    wrote:
> > > > [snip]
> > > > > > Or, there is a more elegant Mercurial feature that will display the log history 
> > > > > > for just a particular file.  In this case, try the Sparse.cc file:
> > > > > >
> > > > > > http://hg.savannah.gnu.org/hgweb/octave/log/40de9f8f23a6/liboctave/array/Sparse.cc
> > > > > >
> > > > > >  From the list one revision I would think to look at is this changeset:
> > > > > >
> > > > > > http://hg.savannah.gnu.org/hgweb/octave/rev/af8118df8292
> > > > >
> > > > > I’ve just reverted the changeset …
> > > > >
> > > > >     hg revert —all -r af8118df8292
> > > > >
> > > > > … and the problem persists.
> > > >
> > > > That revert may include the changeset itself.  You might need to revert to one 
> > > > of the changeset's parents or grandparents depending on how far back the 
> > > > related changes go.  Follow the link to the parent in the link listed above.
> > > >
> > > > Dan
> > >
> > > Ok. Meanwhile I reverted dd6345fd8a97 ...
> > >
> > >      hg revert --all -r dd6345fd8a97
> > >
> > > … the build still encounters seg-fauls, but speye() works.
> >
> > Ben,
> >
> > On the more recent versions that fail speye(10), does
> >
> > speye(10);
> >
> > with the semicolon seg-fault?
> >
> > Dan
>
> Yes

OK, that would suggest that the printing of the sparse matrix is not a 
problem.

Well, I looked through the Sparse.m data a bit.  It's not really that 
big, so I put a bunch of fprintf() in the code and found that the routine

Sparse<T>::SparseRep::change_length (octave_idx_type nz)
{

gets called upon instantiation.  So, change_length() is apparently used 
to assign memory even from the start--not a bad strategy.  However, at 
that point, the member pointers r and d are initialized as r(0) and 
d(0).  And there are these lines of code:

1)

      std::copy (r, r + min_nzmx, new_ridx);

If r is 0 and min_nzmx is 0, this line should not be a problem.  The 
std::copy innards do an "if (r != r + min_nzmx) {}" type of loop so that 
r isn't attempted access.

2)

      delete [] r;
      r = new_ridx;

Now, the first line of code is more questionable.  Typically one isn't 
supposed to delete a NULL pointer.  I'm not sure what the array [] 
prefix does, however.  Who knows, maybe linux is more forgiving about 
attempting to delete a NULL pointer while your Mac compiler isn't.

Attached is a simple patch for you to try.  See if it solves your 
speye() problem.

Dan

octave-mac_speye_fail-djs_2016mar03.patch
Description: Text Data