Depreciated Functions

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Depreciated Functions

Bill Denney
Here is a large patch that fixes the problem of depreciated functions
being called.  It does not change all of them (I didn't have access to CVS
because I was just using my laptop not connected to the net), but it does
these:

isstr     ischar
is_struct isstruct
setstr    char
is_vector isvector

I created a script to do the changes for me (massedit.sh), and I've
attached it.  It's just a simple grep and sed deal.

One minor change that was unintentional, but I thought made sense to leave
is that in hist.m, it changed arg_is_vector to arg_isvector.  I also made
an unintentional change of isstruct to ischaruct, but that was fixed
before making the diff that is attached.

If you would like for me to go and do the other depreciated functions, let
me know, but I don't want to go to the work unless you want it.

Also, it seems that it would be a good idea to make depreciated functions
give a warning that they are depreciated to encourage people to change
their scripts and functions.

Bill

--
Moneybelt: "When you wear it, feeling a street urchin's hand in your
pocket becomes just one more interesting cultural experience."
   -- http://travelstore.ricksteves.com/

massedit.sh (286 bytes) Download Attachment
depreciated-patch.diff (59K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Depreciated Functions

John W. Eaton-6
On  7-Sep-2005, Bill Denney wrote:

| Here is a large patch that fixes the problem of depreciated functions
| being called.

I applied this patch.

| If you would like for me to go and do the other depreciated functions, let
| me know, but I don't want to go to the work unless you want it.

Yes, I think Octave should avoid using the deprecated functions
internally.

Thanks,

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Depreciated Functions

Paul Kienzle
Careful with that one.  In octave-forge I had instances of isstruct
turning into ischaruct when I applied the transformation blindly.  I
haven't checked his patch.

Please let me know about other simple decrufting I can do for
octave-forge.

Thanks,

- Paul

On Sep 7, 2005, at 9:40 PM, John W. Eaton wrote:

> On  7-Sep-2005, Bill Denney wrote:
>
> | Here is a large patch that fixes the problem of depreciated functions
> | being called.
>
> I applied this patch.
>
> | If you would like for me to go and do the other depreciated
> functions, let
> | me know, but I don't want to go to the work unless you want it.
>
> Yes, I think Octave should avoid using the deprecated functions
> internally.
>
> Thanks,
>
> jwe
>

Reply | Threaded
Open this post in threaded view
|

Re: Depreciated Functions

Bill Denney
On Wed, 7 Sep 2005, Paul Kienzle wrote:

> Careful with that one.  In octave-forge I had instances of isstruct
> turning into ischaruct when I applied the transformation blindly.  I
> haven't checked his patch.

I noticed that while I was working on it and I fixed it before submitting
the bug.  I checked over everything, and the only odd thing that I left in
there was that arg_is_vector in hist.m became arg_isvector.

> Please let me know about other simple decrufting I can do for
> octave-forge.

I'll go through octave-forge after I get done with regular octave.  One
question for you about that.  In CVS, there are lots more depreciated
functions than there are in 2.1.71-- do you want me to just do the 2.1.71
functions for octave-forge or do you want me to do all of them?

Bill

--
"It was 1996. A year of many unexplained phenomena. The Macarena.
Tickle-Me-Elmo. Beavis and Butthead."
   -- Doug Worgul, The Kansas City Star, Sep 6, 2003

Reply | Threaded
Open this post in threaded view
|

Re: Depreciated Functions

Paul Kienzle
I would like octave-forge to be cruft free for the 3.0 release, so it
should depend on functions and syntax in 2.9.x.

There is a lot of cruft in the C++ functions for supporting older
versions of octave.  Basically anything in #if is suspicious.

- Paul

On Sep 8, 2005, at 7:32 AM, Bill Denney wrote:

> On Wed, 7 Sep 2005, Paul Kienzle wrote:
>
>> Careful with that one.  In octave-forge I had instances of isstruct
>> turning into ischaruct when I applied the transformation blindly.  I
>> haven't checked his patch.
>
> I noticed that while I was working on it and I fixed it before
> submitting the bug.  I checked over everything, and the only odd thing
> that I left in there was that arg_is_vector in hist.m became
> arg_isvector.
>
>> Please let me know about other simple decrufting I can do for
>> octave-forge.
>
> I'll go through octave-forge after I get done with regular octave.  
> One question for you about that.  In CVS, there are lots more
> depreciated functions than there are in 2.1.71-- do you want me to
> just do the 2.1.71 functions for octave-forge or do you want me to do
> all of them?
>
> Bill
>
> --
> "It was 1996. A year of many unexplained phenomena. The Macarena.
> Tickle-Me-Elmo. Beavis and Butthead."
>   -- Doug Worgul, The Kansas City Star, Sep 6, 2003
>

Reply | Threaded
Open this post in threaded view
|

Re: Depreciated Functions

Quentin Spencer
Paul Kienzle wrote:

> I would like octave-forge to be cruft free for the 3.0 release, so it
> should depend on functions and syntax in 2.9.x.
>
> There is a lot of cruft in the C++ functions for supporting older
> versions of octave.  Basically anything in #if is suspicious.


There was a discussion a while back on the Octave-forge list about
branching Octave forge so that the main CVS could follow 2.9.x and
prepare for 3.0. I have only a minimum knowledge of using CVS--has this
been done, or how does one go about doing it? If some of us were to
begin making 2.9.x changes could someone go back and branch from an
older release? As far as I'm concerned, octave-forge is functional
enough on 2.1.71--I suggest we move ahead and only make bug fixes for
2.1.x if something critical comes up.

-Quentin

Reply | Threaded
Open this post in threaded view
|

Re: Depreciated Functions

Paul Kienzle
On http://www.psc.edu/~semke/cvs_branches.html it says:

        To create a branch from a tagged revision of my_module, use the command

        cvs rtag -r Tagname -b Branchname my_module

So using the latest release tag R2005-06-13 we can at any point create
a 2.1.xx maintenance branch for octave-forge.

- Paul

On Sep 9, 2005, at 11:49 AM, Quentin Spencer wrote:

> Paul Kienzle wrote:
>
>> I would like octave-forge to be cruft free for the 3.0 release, so it
>> should depend on functions and syntax in 2.9.x.
>>
>> There is a lot of cruft in the C++ functions for supporting older
>> versions of octave.  Basically anything in #if is suspicious.
>
>
> There was a discussion a while back on the Octave-forge list about
> branching Octave forge so that the main CVS could follow 2.9.x and
> prepare for 3.0. I have only a minimum knowledge of using CVS--has
> this been done, or how does one go about doing it? If some of us were
> to begin making 2.9.x changes could someone go back and branch from an
> older release? As far as I'm concerned, octave-forge is functional
> enough on 2.1.71--I suggest we move ahead and only make bug fixes for
> 2.1.x if something critical comes up.
>
> -Quentin
>

Reply | Threaded
Open this post in threaded view
|

Re: Depreciated Functions

Bill Denney
In reply to this post by John W. Eaton-6
On Wed, 7 Sep 2005, John W. Eaton wrote:

> Yes, I think Octave should avoid using the deprecated functions
> internally.

I was looking through the other depreciated functions, and one that is not
depreciated, but that does not fit with the naming of other functions is
stdnormal_* (* = cdf, inv, pdf, rnd).  Would you like to change the naming
to stdnorm* instead and move the stdnormal_* versions to depreciated?

Also, can someone explain what the difference between a standard normal
and just a normal distribution are (it may be good to update the docs for
that)?

Bill

--
"Nothing is more terrible than ignorance in action."
   -- Johann Wolfgang von Goethe

Reply | Threaded
Open this post in threaded view
|

Re: Depreciated Functions

David Bateman-3
In reply to this post by Quentin Spencer
Quentin Spencer a écrit :

> Paul Kienzle wrote:
>
>> I would like octave-forge to be cruft free for the 3.0 release, so it
>> should depend on functions and syntax in 2.9.x.
>>
>> There is a lot of cruft in the C++ functions for supporting older
>> versions of octave.  Basically anything in #if is suspicious.
>
>
>
> There was a discussion a while back on the Octave-forge list about
> branching Octave forge so that the main CVS could follow 2.9.x and
> prepare for 3.0. I have only a minimum knowledge of using CVS--has
> this been done, or how does one go about doing it? If some of us were
> to begin making 2.9.x changes could someone go back and branch from an
> older release? As far as I'm concerned, octave-forge is functional
> enough on 2.1.71--I suggest we move ahead and only make bug fixes for
> 2.1.x if something critical comes up.
>
> -Quentin

Should Soren's packaging system be taken into account in any clean-up of
octave-forge. What I'd like to see is perhaps one last monolithic
release for 3.0 and then everything cut up CPAN style...

Cheers
David

Reply | Threaded
Open this post in threaded view
|

Re: Depreciated Functions

John W. Eaton-6
In reply to this post by Bill Denney
On  9-Sep-2005, Bill Denney wrote:

| On Wed, 7 Sep 2005, John W. Eaton wrote:
|
| > Yes, I think Octave should avoid using the deprecated functions
| > internally.
|
| I was looking through the other depreciated functions, and one that is not
| depreciated, but that does not fit with the naming of other functions is
| stdnormal_* (* = cdf, inv, pdf, rnd).  Would you like to change the naming
| to stdnorm* instead and move the stdnormal_* versions to depreciated?

The reason for changing the names of these functions was to improve
compatibility.  There doesn't seem to be a stdnorm function in Matlab,
so I'm not sure why we should change the name of the stdnormal_*
functions.  See the following thread:

  http://www.octave.org/octave-lists/archive/bug-octave.2005/msg00845.html

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Depreciated Functions

James R. Phillips-2
--- "John W. Eaton"  wrote:

> The reason for changing the names of these functions was to improve
> compatibility.  There doesn't seem to be a stdnorm function in Matlab,
> so I'm not sure why we should change the name of the stdnormal_*
> functions.  See the following thread:
>
>   http://www.octave.org/octave-lists/archive/bug-octave.2005/msg00845.html
>
> jwe
>
>

As far as Matlab goes, the functions you are looking for are in the statistics
toolbox, not part of Matlab base.  I note the following three functions in
Matlab 7.01:

>> which normpdf
C:\MATLAB701\toolbox\stats\normpdf.m  
>> which normcdf
C:\MATLAB701\toolbox\stats\normcdf.m  
>> which norminv
C:\MATLAB701\toolbox\stats\norminv.m  
>>


Reply | Threaded
Open this post in threaded view
|

Re: Depreciated Functions

Bill Denney
In reply to this post by John W. Eaton-6
On Mon, 19 Sep 2005, John W. Eaton wrote:

> On  9-Sep-2005, Bill Denney wrote:
>
> | I was looking through the other depreciated functions, and one that is
> | not depreciated, but that does not fit with the naming of other
> | functions is stdnormal_* (* = cdf, inv, pdf, rnd).  Would you like to
> | change the naming to stdnorm* instead and move the stdnormal_*
> | versions to depreciated?
>
> The reason for changing the names of these functions was to improve
> compatibility.  There doesn't seem to be a stdnorm function in Matlab,
> so I'm not sure why we should change the name of the stdnormal_*
> functions.  See the following thread:
>
>  http://www.octave.org/octave-lists/archive/bug-octave.2005/msg00845.html

I was just thinking that stdnorm* fit with the rest of the naming
convention of norm*, etc without the "_" and the longer name.  I.e. if I
knew that norm* existed, I wouldn't look for stdnormal_*, I would look for
stdnorm*.

Let me know if you do want to keep it, and I'll make the depreciated
changes patch and send it through.

Bill

--
"Kill two birds with one stone. Feed the homeless to the hungry."
   -- unknown