octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getstruct, setstruct, etc.


From: Etienne Grossmann
Subject: Re: getstruct, setstruct, etc.
Date: Thu, 22 Jul 2004 18:32:48 -0400
User-agent: Mutt/1.4.2.1i

  Hi all,

I had fixed read_options.m some this a few weeks ago, but when I 

  cvs commit -m "list->cell and no more [sg]etfield" read_options.m

I get 

  Cannot access /cvsroot/octave/CVSROOT
  No such file or directory

  minimize.m should be simple to fix (there's a single getfield.m).

  In general, I guess [gs]etfields.cc would be just as good as
[gs]etfield. And it's easy to s/getfield/getfields/g in m-files.

  Cheers,

  Etienne

On Thu, Jul 22, 2004 at 05:24:21PM -0400, Paul Kienzle wrote:
# 
# On Jul 22, 2004, at 4:03 PM, Andy Adler wrote:
# 
# >>On Jul 21, 2004, at 4:21 PM, Andy Adler wrote:
# >>
# >>>QUESTION:
# >>>Is anyone feel strongly about changing the octave-forge functions
# >>>to be closer to Matlab?
# >>
# >>I would prefer it, but getfield/setfield are used elsewhere in
# >>octave-forge,
# >>so make sure they don't break.
# >>
# >>You should probably keep the old versions around but rename them
# >>to make it easier for those who depend on the existing  behaviour in
# >>their private scripts.
# >
# >The only parts of octave-forge that depend on this behaviour are:
# >
# >./main/miscellaneous/read_options.m
# >./main/optim/minimize.m
# >./main/struct/test_struct.m:     # this is obvious
# >./main/vrml/                     # many functions
# >
# >I can modify this. Any ideas on what to rename them to?
# 
# Since the existing functions allow get/set on multiple fields
# simultaneously, I suggest getfields and setfields.
# 
# Etienne, any comments?
# 
# >Here is my proposed fix. They're written as *.m files, but that
# >should be OK since this syntax is deprecated anyway.
# 
# Having to use eval is kind of ugly.  It seems like there should
# be a recursive solution like:
# 
#       getfield(s):
#               return s
#          getfield(s,idx,field,idx,...):
#               return getfield(s(idx).(field)(idx),...)
# 
# and
# 
#       setfield(s,v):
#               s = v
#               return s
#       setfield(s,idx,field,idx,...,v):
#               s(idx).(field)(idx) = setfield(s(idx).(field)(idx),...,v)
#               return s
# 
# I don't know that it would be any faster though.  And setfield
# will fail if field does not already exist.  So eval it is.
# 
# - Paul
# 

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne



reply via email to

[Prev in Thread] Current Thread [Next in Thread]