|
| From: | Karthik Krishnan |
| Subject: | GSOC 2016,Matlab Compatible DAE solver |
| Date: | Sat, 5 Mar 2016 10:33:49 +0530 |
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 (Daniel J Sebald)
2. Re: gplot.txt (Daniel J Sebald)
3. octave forge package zeromq 1.1.0 released (JohnD)
4. Re: Gsoc 2016 (Satyam Pandey)
5. Gsoc 2016 (Satyam Pandey)
----------------------------------------------------------------------
Message: 1
Date: Fri, 04 Mar 2016 12:15:44 -0600
From: Daniel J Sebald <address@hidden>
To: Lachlan Andrew <address@hidden>
Cc: Rik <address@hidden>, Octave-Maintainers
<address@hidden>
Subject: Re: gplot.txt
Message-ID: <address@hidden>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 03/04/2016 12:26 AM, Lachlan Andrew wrote:
> On 4 March 2016 at 16:37, Daniel J Sebald<address@hidden> wrote:
>
>> 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
>> 2)
>> delete [] r;
>>
>> Now, the first line of code is more questionable. Typically one isn't
>> supposed to delete a NULL pointer.
>
> Good catch, but deleting NULL pointers is valid in all
> standards-compliant compilers, and some people advocate that rather
> than checking for NULL first. See the discussion at
>
> http://stackoverflow.com/questions/4190703/is-it-safe-to-delete-a-null-pointer#4190737
Yes, appears to be fine.
It turns out that ::change_length() is accessed much more than I
thought. It is used in the header in inline function
Sparse::change_capacity (octave_idx_type nz), and that routine is used
at least a half dozen times in the source file.
Anyway, so the path that "speye(10)" follows through the instantiation
(Sparse::Sparse) is
else if (a_scalar)
{
[snip]
else
{
idx_vector rr = r;
idx_vector cc = c;
const octave_idx_type *rd = rr.raw ();
const octave_idx_type *cd = cc.raw ();
I did a deeper dive on the code in that path, and I too find it to be
fine in terms of indexing. It is a bit tricky to follow because the
array length is one longer than the number of nc, but I can't find any
place where an index (of index) might be one index out of bounds.
The one thing that has me a bit confused is this raw() function:
const octave_idx_type *
idx_vector::raw (void)
{
if (rep->idx_class () != class_vector)
*this = idx_vector (as_array (), extent (0));
idx_vector_rep * r = dynamic_cast<idx_vector_rep *> (rep);
assert (r != 0);
return r->get_data ();
}
I verified that the reassignment of "this" takes place as a result of
the rr.raw () and cc.raw() calls. And here is the definition of idx_vector:
// Directly pass extent, no checking.
idx_vector (const Array<octave_idx_type>& inda, octave_idx_type ext)
: rep (new idx_vector_rep (inda, ext, DIRECT))
{ }
All this does basically--from the perspective of within raw()--is do
rep = new idx_vector_rep (inda, ext, DIRECT)
So, one question I have is what happens to the old/new contents of "rep"
if a new "rep" is being assigned? I printed out the value of rep coming
into raw() and got something non-zero:
octave:1> speye(10);
rep = 33754304
rep = 33753072
So, accessing rep->idx_class () should be valid, no matter the compiler.
(idx_class() is a virtual function, so maybe even if rep=0 the call
rep->idx_class() is fine). It seems there is a new rep in a new hunk of
memory created by calling the constructor idx_vector (,). And then
"*this =" simply means that the function takes on the identity of the
newly created object casting the new object's "rep" to get its data.
However, to me it seems like some type of new object was created that is
lost track of somehow. There is no type of delete within Sparse.c on
the cc or dd pointers.
Lachlan, does that idx_vector::raw (void) function make sense to you?
Dan
------------------------------
Message: 2
Date: Fri, 04 Mar 2016 12:52:35 -0600
From: Daniel J Sebald <address@hidden>
To: Lachlan Andrew <address@hidden>
Cc: Rik <address@hidden>, Octave-Maintainers
<address@hidden>
Subject: Re: gplot.txt
Message-ID: <address@hidden>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 03/04/2016 12:15 PM, Daniel J Sebald wrote:
> On 03/04/2016 12:26 AM, Lachlan Andrew wrote:
>> On 4 March 2016 at 16:37, Daniel J Sebald<address@hidden> wrote:
>>
>>> 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
>>> 2)
>>> delete [] r;
>>>
>>> Now, the first line of code is more questionable. Typically one isn't
>>> supposed to delete a NULL pointer.
>>
>> Good catch, but deleting NULL pointers is valid in all
>> standards-compliant compilers, and some people advocate that rather
>> than checking for NULL first. See the discussion at
>>
>> http://stackoverflow.com/questions/4190703/is-it-safe-to-delete-a-null-pointer#4190737
>>
>
> Yes, appears to be fine.
>
> It turns out that ::change_length() is accessed much more than I
> thought. It is used in the header in inline function
> Sparse::change_capacity (octave_idx_type nz), and that routine is used
> at least a half dozen times in the source file.
>
> Anyway, so the path that "speye(10)" follows through the instantiation
> (Sparse::Sparse) is
>
> else if (a_scalar)
> {
> [snip]
> else
> {
> idx_vector rr = r;
> idx_vector cc = c;
> const octave_idx_type *rd = rr.raw ();
> const octave_idx_type *cd = cc.raw ();
>
> I did a deeper dive on the code in that path, and I too find it to be
> fine in terms of indexing. It is a bit tricky to follow because the
> array length is one longer than the number of nc, but I can't find any
> place where an index (of index) might be one index out of bounds.
>
> The one thing that has me a bit confused is this raw() function:
>
> const octave_idx_type *
> idx_vector::raw (void)
> {
> if (rep->idx_class () != class_vector)
> *this = idx_vector (as_array (), extent (0));
>
> idx_vector_rep * r = dynamic_cast<idx_vector_rep *> (rep);
>
> assert (r != 0);
>
> return r->get_data ();
> }
Something else about the above routine is that a compiler has to be very
careful about optimization. In other words, the above construct is
something a compiler could have a bug with because it is tricky. This
"copy" operation
*this = idx_vector (as_array (), extent (0));
which I assume overwrites the existing memory for the "called" or
"acting upon" object is inherently changing the value of "rep" pointer.
So, by the time
dynamic_cast<idx_vector_rep *> (rep);
takes place, "rep" has a new value. But what if an optimizing compiler
doesn't understand that? The compiler might think "rep" is used here:
if (rep->idx_class () != class_vector)
and then a few instructions later rep is used here:
idx_vector_rep * r = dynamic_cast<idx_vector_rep *> (rep);
If the compiler were to keep "rep" local in some CPU register as a form
of optimization rather than reloading, then "rep" is the old rep
pointer, not the new rep pointer.
Dan
------------------------------
Message: 3
Date: Fri, 4 Mar 2016 16:54:00 -0500
From: "JohnD" <address@hidden>
To: "'Octave Maintainers List'" <address@hidden>,
<address@hidden>
Subject: octave forge package zeromq 1.1.0 released
Message-ID: <004d01d17660$5cbaf7b0$1630e710$@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Version 1.1.0 of the zeromq package [1] has been released.
The zeromq package provides Octave bindings to zeromq library. [2]
The ZeroMQ library provides fast distributed messaging options using
IPC, TCP, TIPC and multicasting and is available on most platforms.
This release increases the binding functionality by adding functions:
* zmq_errno
* zmq_unbind
Increased recognized values to zmq_getsockopt:
* ZMQ_TYPE
* ZMQ_EVENTS
It also updates the documentation and provides some example code files for use of the package.
When the package is loaded run 'help zeromq' for usage information.
The whole overview of changes is available in the news file [3]
[1] http://octave.sourceforge.net/zeromq/
[2] http://zeromq.org/
[3] http://octave.sourceforge.net/zeromq/NEWS.html
------------------------------
Message: 4
Date: Fri, 4 Mar 2016 23:29:21 +0530
From: Satyam Pandey <address@hidden>
To: address@hidden
Subject: Re: Gsoc 2016
Message-ID:
<CAFwxpy5yU085U1MBL9opC7zGFRZ7PjGngSA=L7VrHcLx=address@hidden>
Content-Type: text/plain; charset="utf-8"
Hello,
I am Satyam Pandey , a IInd year Undergraduate student at International
Institute of Information Technology,Hyderabad.
I am interested in some of the Octave's Project namely:
1.) Matlab Compatible DAE solver : I have deeply interested in
Mathematics and have basic knowledge of Differential Algebraic
2.) Improve logm, sqrtm, funm : I have worked a bit in MATLAB and I am
a Competitive Programmer thus ,I would like to implement the algorithms
for these Function
3.)Implement boolean operations on polygons : I have gone through
partial implementation and I think i can work on the subject
- I have deeply interested in Mathematics and have been selected for
National Level Olympiad quite a few times.
- I have Proficiency in C/C++ and decent experience in
Octave,Matlab,Python.
I have done Octave setup .Please guide me how
should I start contributing to projects
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/octave-maintainers/attachments/20160304/ec9ee6fe/attachment.html>
------------------------------
Message: 5
Date: Fri, 4 Mar 2016 23:25:42 +0530
From: Satyam Pandey <address@hidden>
To: address@hidden
Subject: Gsoc 2016
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Hello,
I am Satyam Pandey , a IInd year Undergraduate student at International
Institute of Information Technology,Hyderabad.
I am interested in some of the Octave's Project namely:
1.) Matlab Compatible DAE solver : I have deeply interested in
Mathematics and have basic knowledge of Differential Algebraic
2.) Improve logm, sqrtm, funm : I have worked a bit in MATLAB and I am
a Competitive Programmer thus ,I would like to implement the
algorithms
for these Function
3.)Implement boolean operations on polygons : I have gone through
partial implementation and I think i can work on the subject
- I have deeply interested in Mathematics and have been selected for
National Level Olympiad quite a few times.
- I have Proficiency in C/C++ and decent experience in
Octave,Matlab,Python.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/octave-maintainers/attachments/20160304/bff6a52d/attachment.html>
------------------------------
_______________________________________________
Octave-maintainers mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/octave-maintainers
End of Octave-maintainers Digest, Vol 120, Issue 16
***************************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |