Ode techniques in octave

Dear all,
I am Karthik , I would like to know which all ODE techniques are presently there in octave.
Which all techniques are used presently and how??
I am looking forward to the reply .
Thank you

On 6 Mar 2016 08:26, <address@hidden> wrote:

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 (Daniel J Sebald)
2. Re: gplot.txt (Ben Abbott)
3. Re: gplot.txt (Ben Abbott)
4. Re: gplot.txt (Daniel J Sebald)
5. Re: noreturn for liboctave error handler function pointers
(Daniel J Sebald)

----------------------------------------------------------------------

Message: 1
Date: Sat, 05 Mar 2016 18:39:26 -0600
From: Daniel J Sebald <address@hidden>
To: Ben Abbott <address@hidden>, Rik <address@hidden>
Cc: Octave-Maintainers <address@hidden>
Subject: Re: gplot.txt
Message-ID: <address@hidden>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 03/05/2016 06:06 PM, Ben Abbott wrote:
>> On Mar 5, 2016, at 1:54 AM, Daniel J Sebald<address@hidden> wrote:
>>
>> On 03/04/2016 09:40 AM, Daniel J Sebald wrote:
>>> On 03/04/2016 07:44 AM, Ben Abbott wrote:
>> [snip]
>>>> Dan's patch didn't resolve the speye segfault. I'll move on to the
>>>> changesets isolated by bisecting.
>>>
>>> OK, thanks Ben. I will follow up with more. Go ahead with bisecting, and
>>> I'll approach just from looking at the code.
>>>
>>> Dan
>>
>> Ben,
>>
>> Here's another small patch for you to apply. It's meant to just hunt around for where the problem might be--prints out the value of the rep pointer before and after the object creation and copy. Here is what I see when running this:
>>
>> octave:1> speye(10);
>> Before object creation and copy: rep = 24093664
>> After object creation and copy: rep = 24099376
>> Before object creation and copy: rep = 24096528
>> After object creation and copy: rep = 24099808
>>
>> I'm curious how this action works with your compiler.
>>
>> Dan
>> <octave-mac_speye_fail-djs_2016mar04.diff>
>
> Sorry for the delay. Below is what I get ?
>
>>> speye(10)
> Before object creation and copy: rep = 140417476007088
> panic: Segmentation fault: 11 -- stopping myself...
> attempting to save variables to 'octave-workspace'...
> save to 'octave-workspace' complete
> Segmentation fault: 11

Exactly! That is what I had just wrote in response to your previous post.

Rik, the ball is in your court.

Dan

------------------------------

Message: 2
Date: Sat, 05 Mar 2016 19:46:28 -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=utf-8

> On Mar 5, 2016, at 7:35 PM, Daniel J Sebald <address@hidden> wrote:
>
> On 03/05/2016 05:08 PM, Ben Abbott wrote:
>>> On Mar 4, 2016, at 8:44 AM, Ben Abbott<address@hidden> wrote:
>>>
>>> On Mar 4, 2016, at 07:00, Ben Abbott<address@hidden> wrote:
>>>
>>>>> On Mar 4, 2016, at 1:26 AM, Lachlan Andrew<address@hidden> 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
>>>>>
>>>>> Cheers,
>>>>> Lachlan
>>>>
>>>> I tried bisecting again. The results I got is below. Many changes needed to be skipped because the default branch wouldn?t build on Mac OS X.
>>>>
>>>> Due to skipped revisions, the first bad revision could be any of:
>>>> changeset: 21210:4f7d3989c462
>>>> user: John W. Eaton<address@hidden>
>>>> date: Sat Feb 06 07:43:32 2016 -0500
>>>> summary: move UMFPACK_DNAME and UMFPACK_ZNAME macros to oct-sparse.h
>>>>
>>>> changeset: 21211:2cf8bc5c7017
>>>> user: John W. Eaton<address@hidden>
>>>> date: Sat Feb 06 08:48:47 2016 -0500
>>>> summary: use "#if defined (HAVE_FOO)" instead of "#if HAVE_FOO" for feature tests
>>>>
>>>> changeset: 21212:7eca4ba9bb6d
>>>> user: John W. Eaton<address@hidden>
>>>> date: Sat Feb 06 19:18:59 2016 -0500
>>>> summary: also distribute octave.css from source tree
>>>>
>>>> changeset: 21213:f7d1050b9b53
>>>> user: Rik<address@hidden>
>>>> date: Sat Feb 06 18:22:32 2016 -0800
>>>> summary: maint: Clean up various usages of #ifdef.
>>>>
>>>> changeset: 21214:7be1f58f9dd7
>>>> user: John W. Eaton<address@hidden>
>>>> date: Sun Feb 07 02:03:58 2016 -0500
>>>> summary: don't strip pipe character from command in drawnow function
>>>>
>>>> changeset: 21215:04866fac690a
>>>> user: Ben Abbott<address@hidden>
>>>> date: Sun Feb 07 02:21:37 2016 -0500
>>>> summary: use template keyword to handle dependent template names
>>>>
>>>> I?ll try Dan?s patch (since I?m using Apple?s clang, and they often don?t conform to other ?standards?. Then I?ll try backingout the above changes until I find the culprit.
>>>>
>>>> Ben
>>>
>>> Dan's patch didn't resolve the speye segfault. I'll move on to the changesets isolated by bisecting.
>>>
>>> Ben
>>
>> I was unable to confirm the bisecting results, so I went through the process again. This time, I single changeset was implicated. I haven?t had time to examine it yet.
>>
>> hg bisect --reset
>> hg bisect init
>> hg bisect --bad 67d2965af0b5
>> hg bisect --bad a223cce1daa4
>> hg bisect --bad 76e0ef020dae
>> hg bisect --good 53bded18aba6
>> hg bisect --good 2d7f658daa58
>> hg bisect --good f5b17eb2508b
>> hg bisect --good 54527108599a
>> hg bisect --good 7cac4e7458f2
>> hg bisect --bad 538b57866b90
>> hg bisect --bad 623fc7d08cc6
>> hg bisect --bad 623fc7d08cc6
>> The first bad revision is:
>> changeset: 21137:623fc7d08cc6
>> user: Rik<address@hidden>
>> date: Sat Jan 23 17:44:57 2016 -0800
>> summary: maint: Clean up compile warnings in liboctave from cset 7cac4e7458f2.
>
> Lot of work, Ben...
>
> OK, getting interesting. The changeset is here:
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/623fc7d08cc6
>
> The OCTAVE_NORETURN that Rik added is meant to suppress compiler warnings about the function not properly return when it is compiled. AND, maybe it does more substantive stuff like not set up something on the stack, who knows exactly?
>
> These functions:
>
> OCTAVE_NORETURN T range_error (const char *fcn, octave_idx_type n) const;
> OCTAVE_NORETURN T& range_error (const char *fcn, octave_idx_type n);
> OCTAVE_NORETURN T range_error (const char *fcn,
> OCTAVE_NORETURN T& range_error (const char *fcn,
> OCTAVE_NORETURN T range_error (const char *fcn,
> OCTAVE_NORETURN T& range_error (const char *fcn,
>
> are all error messages that don't return. Fine, plus they aren't being used in your case because there is no error--it's a proper speye(10).
>
> Similarly, these two in idx-vector.h don't return:
>
> OCTAVE_NORETURN virtual Array<octave_idx_type> as_array (void);
> OCTAVE_NORETURN idx_base_rep *sort_idx (Array<octave_idx_type>&);
>
> Here they are:
>
> Array<octave_idx_type>
> idx_vector::idx_base_rep::as_array (void)
> {
> (*current_liboctave_error_handler)
> ("internal error: as_array not allowed for this index class");
> }
>
> idx_vector::idx_base_rep *
> idx_vector::idx_colon_rep::sort_idx (Array<octave_idx_type>&)
> {
> (*current_liboctave_error_handler)
> ("internal error: idx_colon_rep::sort_idx");
> }
>
> I'm not sure what the problem is exactly, but notice that the "as_array" function plays a role in the code I sent a patch for yesterday. Here it is:
>
> const octave_idx_type *
> idx_vector::raw (void)
> {
> fprintf(stderr, "Before object creation and copy: rep = %ld\n", rep);
> if (rep->idx_class () != class_vector)
> *this = idx_vector (as_array (), extent (0));
> fprintf(stderr, "After object creation and copy: rep = %ld\n", rep);
>
> idx_vector_rep * r = dynamic_cast<idx_vector_rep *> (rep);
>
> assert (r != 0);
>
> return r->get_data ();
> }
>
> Notice that above between the two fprintf's is a call to as_array(). That makes me think if you were to run the patch I sent yesterday you would see the first fprintf() statement about the rep address just before the program crashes.
>
> So, I'm going to speculate here, and ask on Rik for input:
>
> 1) Could it be that __GNUC__ is not defined for Ben's compiler and as a result OCTAVE_NORETURN ends up being blank? Is that a problem?

I?m using Apple?s clang.

$ clang --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

Does this link help?

http://stackoverflow.com/questions/1617877/how-to-detect-llvm-and-its-version-through-define-directives

Ben

------------------------------

Message: 3
Date: Sat, 05 Mar 2016 20:02:45 -0500
From: Ben Abbott <address@hidden>
To: Daniel J Sebald <address@hidden>
Cc: Octave-Maintainers <address@hidden>
Subject: Re: gplot.txt
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8

> On Mar 5, 2016, at 7:06 PM, Ben Abbott <address@hidden> wrote:
>
>> On Mar 5, 2016, at 1:54 AM, Daniel J Sebald <address@hidden> wrote:
>>
>> On 03/04/2016 09:40 AM, Daniel J Sebald wrote:
>>> On 03/04/2016 07:44 AM, Ben Abbott wrote:
>> [snip]
>>>> Dan's patch didn't resolve the speye segfault. I'll move on to the
>>>> changesets isolated by bisecting.
>>>
>>> OK, thanks Ben. I will follow up with more. Go ahead with bisecting, and
>>> I'll approach just from looking at the code.
>>>
>>> Dan
>>
>> Ben,
>>
>> Here's another small patch for you to apply. It's meant to just hunt around for where the problem might be--prints out the value of the rep pointer before and after the object creation and copy. Here is what I see when running this:
>>
>> octave:1> speye(10);
>> Before object creation and copy: rep = 24093664
>> After object creation and copy: rep = 24099376
>> Before object creation and copy: rep = 24096528
>> After object creation and copy: rep = 24099808
>>
>> I'm curious how this action works with your compiler.
>>
>> Dan
>> <octave-mac_speye_fail-djs_2016mar04.diff>
>
> Sorry for the delay. Below is what I get ?
>
>>> speye(10)
> Before object creation and copy: rep = 140417476007088
> panic: Segmentation fault: 11 -- stopping myself...
> attempting to save variables to 'octave-workspace'...
> save to 'octave-workspace' complete
> Segmentation fault: 11
>
> Ben

Just in case the seg-fault?s I see while building the docs is related ...

GEN doc/interpreter/splinefit3.eps
Before object creation and copy: rep = 140389001213056
After object creation and copy: rep = 140389001213056
Before object creation and copy: rep = 140389005748384
After object creation and copy: rep = 140389005748384
Before object creation and copy: rep = 140389005748384
After object creation and copy: rep = 140389005748384
Before object creation and copy: rep = 140389005770816
After object creation and copy: rep = 140389005770816
Before object creation and copy: rep = 140389007043568
After object creation and copy: rep = 140389007043568
Before object creation and copy: rep = 140389007051872
After object creation and copy: rep = 140389007051872
Before object creation and copy: rep = 140389007043568
After object creation and copy: rep = 140389007043568
Before object creation and copy: rep = 140389007051872
After object creation and copy: rep = 140389007051872
panic: Segmentation fault: 11 -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11

Ben

------------------------------

Message: 4
Date: Sat, 05 Mar 2016 19:11:26 -0600
From: Daniel J Sebald <address@hidden>
To: Ben Abbott <address@hidden>
Cc: Octave-Maintainers <address@hidden>
Subject: Re: gplot.txt
Message-ID: <address@hidden>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 03/05/2016 07:02 PM, Ben Abbott wrote:
>
>> On Mar 5, 2016, at 7:06 PM, Ben Abbott<address@hidden> wrote:
>>
>>> On Mar 5, 2016, at 1:54 AM, Daniel J Sebald<address@hidden> wrote:
>>>
>>> On 03/04/2016 09:40 AM, Daniel J Sebald wrote:
>>>> On 03/04/2016 07:44 AM, Ben Abbott wrote:
>>> [snip]
>>>>> Dan's patch didn't resolve the speye segfault. I'll move on to the
>>>>> changesets isolated by bisecting.
>>>>
>>>> OK, thanks Ben. I will follow up with more. Go ahead with bisecting, and
>>>> I'll approach just from looking at the code.
>>>>
>>>> Dan
>>>
>>> Ben,
>>>
>>> Here's another small patch for you to apply. It's meant to just hunt around for where the problem might be--prints out the value of the rep pointer before and after the object creation and copy. Here is what I see when running this:
>>>
>>> octave:1> speye(10);
>>> Before object creation and copy: rep = 24093664
>>> After object creation and copy: rep = 24099376
>>> Before object creation and copy: rep = 24096528
>>> After object creation and copy: rep = 24099808
>>>
>>> I'm curious how this action works with your compiler.
>>>
>>> Dan
>>> <octave-mac_speye_fail-djs_2016mar04.diff>
>>
>> Sorry for the delay. Below is what I get ?
>>
>>>> speye(10)
>> Before object creation and copy: rep = 140417476007088
>> panic: Segmentation fault: 11 -- stopping myself...
>> attempting to save variables to 'octave-workspace'...
>> save to 'octave-workspace' complete
>> Segmentation fault: 11
>>
>> Ben
>
> Just in case the seg-fault?s I see while building the docs is related ...
>
> GEN doc/interpreter/splinefit3.eps
> Before object creation and copy: rep = 140389001213056
> After object creation and copy: rep = 140389001213056
> Before object creation and copy: rep = 140389005748384
> After object creation and copy: rep = 140389005748384
> Before object creation and copy: rep = 140389005748384
> After object creation and copy: rep = 140389005748384
> Before object creation and copy: rep = 140389005770816
> After object creation and copy: rep = 140389005770816
> Before object creation and copy: rep = 140389007043568
> After object creation and copy: rep = 140389007043568
> Before object creation and copy: rep = 140389007051872
> After object creation and copy: rep = 140389007051872
> Before object creation and copy: rep = 140389007043568
> After object creation and copy: rep = 140389007043568
> Before object creation and copy: rep = 140389007051872
> After object creation and copy: rep = 140389007051872
> panic: Segmentation fault: 11 -- stopping myself...
> attempting to save variables to 'octave-workspace'...
> save to 'octave-workspace' complete
> octave exited with signal 11
>
> Ben

I would conclude that the problem above isn't because of the as_array()
function in this case. I say that because all the index code above has
an "After" after the "Before". Also notice that the addresses are the
same before and after in all cases. For the speye(10) example, I found
that the address Before and After change. In other words, for all the
cases above, this test fails:

if (rep->idx_class () != class_vector)
*this = idx_vector (as_array (), extent (0));

and the idx_vector() function is not called.

So your second example here is a different issue, but it may be the same
kind of issue. Rik will know how extensive this type of OCTAVE_NORETURN
discrepancy between base class and inheriting classes is.

Dan

------------------------------

Message: 5
Date: Sat, 05 Mar 2016 20:55:37 -0600
From: Daniel J Sebald <address@hidden>
To: Octave Maintainers List <address@hidden>
Subject: Re: noreturn for liboctave error handler function pointers
Message-ID: <address@hidden>
Content-Type: text/plain; charset=UTF-8; format=flowed

I searched for NORETURN in my email threads and found this as the last
entry, so I'll continue with this thread...

Ben has run across an issue at least associated with the OCTAVE_NORETURN
definition in the case where the base class has a virtual function that
jumps to an error (i.e., OCTAVE_NORETURN) but the derived classes do not
go that path. I'm wondering how necessary the OCTAVE_NORETURN
clarification is. Might there really only need to be one routine that
doesn't return, i.e., prints a message and then jumps somewhere?

One question I have with the many new jumps in program flow is how
dynamic data management is to be done. If the error routine stops
program flow and jumps somewhere else, is the stack unwound? How about
something like:

xyz *myfunc(args) {
xyz *retval;

retval = new xyz();

// Do some stuff, and then find dimensions don't agree
error_message_and_jump_somewhere("Dimension mismatch");

return xyz;
}

If the programmer isn't careful, they could write something like the
above for which the malloced memory (via new) is not yet kept track of
globally. Changing program flow would leak that memory.

Perhaps what is needed is to rewrite the global "new" and "delete" operator:

http://en.cppreference.com/w/cpp/memory/new/operator_new

so that the interpreter could keep track of all the dynamic memory that
has been allocated between returns to the command line, or at least when
it's a good point to clean up the "octave intra-command memory table".
So the new "new" operator would do the allocation, but also keep a
linked-list of pointers to the memory it has allocated. The new
"delete" would look to the linked list and remove the memory address
before freeing the memory. If there is an error that redirects program
flow, then free everything in that table (and unwind the stack). Any
object that has been associated with another container during processing
(e.g., stored in global variable table) would need to be removed from
the "intra-command memory table" so that it isn't cleared if an error
occurs.

Dan

On 01/01/2016 11:31 PM, Rik wrote:
> On 12/31/2015 02:40 PM, John W. Eaton wrote:
>> Rik:
>>
>> I agree that tagging the liboctave error handlers with "noreturn" is the
>> right thing to do, but in the past they did return (or at least the ones
>> we defined in Octave did return).
>>
>> I suppose it's possible that someone provided their own versions of these
>> functions if they were using liboctave in their own program that also
>> returned after printing a message.
>>
>> I guess as things are, liboctave functions can still work properly if the
>> function called through the liboctave_error_handler pointer returns
>> because that's the way things have always worked up until now. But
>> things will break if we start modifying liboctave in the same way as we
>> have modified the libinterp sources.
>>
>> Should we care? Maybe just document the change in NEWS?
>
> I imagine the number of people who have overridden the default error
> handling routines is vanishingly small. But we can document it just in
> case. I added this note to the NEWS file:
>
> ** The default error handlers in liboctave have been updated to use
> exceptions. After displaying an error message they no longer return
> control to the calling program. The error handler function can be
> customized through the global variables "current_liboctave_error_handler"
> and "current_liboctave_error_with_id_handler". If a programmer has
> installed their own custom error handling routines when directly linking
> with liboctave then these must be updated to throw an exception and
> not return to the calling program.
>
> --Rik
>
>
>

--

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

------------------------------

_______________________________________________
Octave-maintainers mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/octave-maintainers

End of Octave-maintainers Digest, Vol 120, Issue 20
***************************************************

From:	Karthik Krishnan
Subject:	Ode techniques in octave
Date:	Sun, 6 Mar 2016 10:32:30 +0530