|
| From: | Karthik Krishnan |
| Subject: | GSOC 16, Improvements to sqrtm,logm and funm. |
| Date: | Thu, 3 Mar 2016 09:27:58 +0530 |
Send Octave-maintainers mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/octave-maintainers
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Octave-maintainers digest..."
Today's Topics:
1. Re: gplot.txt (Lachlan Andrew)
2. GSOC 16, Improvements to N-dimensional image processing
(Muhammad Omer Saeed)
3. Re: gplot.txt (Ben Abbott)
4. Re: gplot.txt (Daniel J Sebald)
5. Re: gplot.txt (Ben Abbott)
6. Re: gplot.txt (Lachlan Andrew)
----------------------------------------------------------------------
Message: 1
Date: Thu, 3 Mar 2016 10:00:03 +1100
From: Lachlan Andrew <address@hidden>
To: Daniel J Sebald <address@hidden>
Cc: Rik <address@hidden>, Octave-Maintainers
<address@hidden>
Subject: Re: gplot.txt
Message-ID:
<CAGt6uZ_4MCrvJL-VBA4oQ8Wa4=bu-P54-6RzJw4_oa4=address@hidden>
Content-Type: text/plain; charset=UTF-8
On 3 March 2016 at 07:02, Daniel J Sebald <address@hidden> wrote:
> The mod has to do with indexing, which is typically a source of seg-fault
> problems. In particular, the following is the sort of thing that would fall
> into question:
>
> octave_idx_type i_old_rm = static_cast<octave_idx_type> (-old_nr);
>
> I don't know if that is a problem, but the casting of a negative value might
> be different between compilers.
>
> I just don't want to dig into the code right now, so maybe Lachlan could
> have a brief look at the above changeset and determine if there might be a
> problem.
OK, I'll take a look. (A faster alternative than bisection, is just
to check all the patches I have submitted... I think over half of
them introduce bugs ):
Cheers,
Lachlan
------------------------------
Message: 2
Date: Thu, 3 Mar 2016 01:39:40 +0100
From: Muhammad Omer Saeed <address@hidden>
To: address@hidden
Subject: GSOC 16, Improvements to N-dimensional image processing
Message-ID:
<CAE_4zar_anouYRZ-GDt-_J2s09y-n2L7O=nesGe==address@hidden>
Content-Type: text/plain; charset="utf-8"
Dear All,
My name is Muhammad Omer Saeed and I am a masters student at the University
of Bonn in Germany, specializing in computer vision and graphics. I have
been using Octave (and MATLAB) for the last 3 years for my various
University projects in numerical computing, image processing and computer
graphics (implementing different algorithms and rendering). I am quite
interested in the project idea 'Improvements to N-dimensional image
processing' for GSOC 16 particularly because it relates closely to my field.
I wanted to ask what should be my steps for becoming a successful candidate
for this project idea in GSOC 16? Are there any bugs that I should try to
fix to show my understanding in m-files and C++? What should be the content
of a successful proposal for this project idea? I am looking forward to a
reply. Thank you.
Best Regards,
Muhammad Omer Saeed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/octave-maintainers/attachments/20160303/15fab8ee/attachment.html>
------------------------------
Message: 3
Date: Wed, 02 Mar 2016 21:03:45 -0500
From: Ben Abbott <address@hidden>
To: Daniel J Sebald <address@hidden>
Cc: Rik <address@hidden>, Octave-Maintainers
<address@hidden>, Lachlan Andrew <address@hidden>
Subject: Re: gplot.txt
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252
> On Mar 2, 2016, at 3:02 PM, Daniel J Sebald <address@hidden> wrote:
>
> On 03/02/2016 12:37 PM, Rik wrote:
>> On 03/01/2016 05:12 PM, Ben Abbott wrote:
>>>> On Mar 1, 2016, at 3:07 PM, Ben Abbott<address@hidden> wrote:
>>>>
>>>> On Mar 1, 2016, at 15:04, Ben Abbott<address@hidden> wrote:
>>>>
>>>>>> On Mar 1, 2016, at 11:02, Rik<address@hidden> wrote:
>>>>>>
>>>>>> 3/1/16
>>>>>>
>>>>>> Ben,
>>>>>>
>>>>>> Things can get weird when tinkering with the build system, and jwe has been
>>>>>> doing a lot recently to improve it. One way to test things cleanly is to
>>>>>> get rid of all the cruft in your source tree and try a fresh build.
>>>>>>
>>>>>> I do
>>>>>>
>>>>>> make maintainer-clean
>>>>>> hg stat -u -i> unknown.list
>>>>>> #look through unknown.list and delete things you don't need like leftover
>>>>>> .o object files.
>>>>>> bootstrap
>>>>>> configure
>>>>>> make
>>>>>>
>>>>>> However, a quicker test is to update your source repository and then clone
>>>>>> it to a new directory. That will get you only the files under version
>>>>>> control, and skip all the cruft.
>>>>>>
>>>>>> cd octave-src
>>>>>> hg pull
>>>>>> hg update
>>>>>> cd ..
>>>>>> hg clone octave-src octave-tmp
>>>>>> cd octave-tmp
>>>>>> bootstrap
>>>>>> configure
>>>>>> make
>>>>>>
>>>>>> --Rik
>>>>> Good idea. I tried the first approach, but the problems persist. I'll try a fresh archive next (just to be sure)
>>>>>
>>>>> Ben
>>>> Oops, I spoke too soon. The gui runs for me now! :-)
>>>>
>>>> Ben
>>> Building default still runs into trouble in doc/interpreter. The first seg-fault occurs for gplot.txt. It tracked the problem to speye().
>>>
>>> speye(10)
>>> panic: Segmentation fault: 11 -- stopping myself...
>>> attempting to save variables to 'octave-workspace'...
>>> save to 'octave-workspace' complete
>>> Segmentation fault: 11
>> Ugh. So is the code to create the problem as simple as this?
>>
>> make
>> ./run-octave
>> speye (10)
>>
>> If so, I'm going to have to suggest bisecting. You know the tip is broken,
>> I would try going back to 623fc7d08cc6 as the first possible working
>> revision. jwe has done a lot in liboctave recently to revamp the
>> factorization classes and there have necessarily been some changes to
>> sparse matrices.
>>
>> --Rik
>
> There has been discussion about speeding compilation by avoiding multiple compilation of code in header files. My general feeling is that re-compiling Octave is too slow for development. To make a minor change takes on the order of a minute or more to recompile. This wasn't always the case--maybe a couple years ago this became the norm.
>
> I wonder, is there some type of optimization now that slows things down? Is it the way that file dates are checked by the make facility? Is there a way to have a development build configuration which is faster and a release build that is slower with optimizations?
>
> Anyway, the slow recompile makes bisecting slow. As an alternative, I typically first search through the changesets that might have caused the problem. One can simplify this process by identifying which file it might be where the problem lies, i.e., some file that would have to be altered if it were related to the function. To do this, go to the mercurial log of the project and navigate to the file of interest using the "browse" link. From the file, click on the "changeset" link to see the difference from the parent. If nothing looks problematic, follow the link backward and select the parent. Click "changeset" again, etc. Do that until roughly the date you think the problem might have occurred.
>
> 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.
Ben
------------------------------
Message: 4
Date: Wed, 02 Mar 2016 20:41:52 -0600
From: Daniel J Sebald <address@hidden>
To: Ben Abbott <address@hidden>
Cc: Rik <address@hidden>, Octave-Maintainers
<address@hidden>, Lachlan Andrew <address@hidden>
Subject: Re: gplot.txt
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252; format=flowed
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
------------------------------
Message: 5
Date: Wed, 02 Mar 2016 22:07:53 -0500
From: Ben Abbott <address@hidden>
To: Daniel J Sebald <address@hidden>
Cc: Rik <address@hidden>, Octave-Maintainers
<address@hidden>, Lachlan Andrew <address@hidden>
Subject: Re: gplot.txt
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252
> 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
------------------------------
Message: 6
Date: Thu, 3 Mar 2016 14:17:44 +1100
From: Lachlan Andrew <address@hidden>
To: Daniel J Sebald <address@hidden>
Cc: Rik <address@hidden>, Octave-Maintainers
<address@hidden>
Subject: Re: gplot.txt
Message-ID:
<CAGt6uZ83QWs=aw74u_Lx-=kK3GmT+P-MYoqAsFdhhkPV=br=address@hidden>
Content-Type: text/plain; charset=UTF-8
On 3 March 2016 at 13:41, Daniel J Sebald <address@hidden> wrote:
> On 03/02/2016 08:03 PM, Ben Abbott wrote:
>>
>> 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.
I've had a quick look at that changeset, and at speye. I don't see
how the code to reshape or resize sparse arrays can be called from
speye. It is hard to debug on my system, because it doesn't give an
error.
Note also that Sparse.cc isn't the only place to look for sparse
matrix code. I gather that other files called by speye include
libinterp/core/sparse.cc
liboctave/array/Sparse-d.cc
liboctave/array/dSparse.cc
liboctave/array/MSparse.cc
plus associated header files (which contain surprisingly much actual code).
------------------------------
_______________________________________________
Octave-maintainers mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/octave-maintainers
End of Octave-maintainers Digest, Vol 120, Issue 9
**************************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |