This list is closed, nobody may subscribe to it.
2000 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(10) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
(4) |
Mar
|
Apr
(3) |
May
(13) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(2) |
Oct
(5) |
Nov
(8) |
Dec
|
2002 |
Jan
|
Feb
|
Mar
(19) |
Apr
(8) |
May
(8) |
Jun
(8) |
Jul
(4) |
Aug
(8) |
Sep
(19) |
Oct
(13) |
Nov
(37) |
Dec
(2) |
2003 |
Jan
(7) |
Feb
(23) |
Mar
(16) |
Apr
(4) |
May
(18) |
Jun
(9) |
Jul
(7) |
Aug
(6) |
Sep
(7) |
Oct
|
Nov
(39) |
Dec
(57) |
2004 |
Jan
(21) |
Feb
(15) |
Mar
(17) |
Apr
(9) |
May
(17) |
Jun
(65) |
Jul
(33) |
Aug
(48) |
Sep
(93) |
Oct
(35) |
Nov
(18) |
Dec
(4) |
2005 |
Jan
(20) |
Feb
(59) |
Mar
(17) |
Apr
(59) |
May
(77) |
Jun
(32) |
Jul
(34) |
Aug
(8) |
Sep
(34) |
Oct
(26) |
Nov
(65) |
Dec
(66) |
2006 |
Jan
(45) |
Feb
(37) |
Mar
(50) |
Apr
(32) |
May
(48) |
Jun
(42) |
Jul
(12) |
Aug
(53) |
Sep
(51) |
Oct
(79) |
Nov
(46) |
Dec
(25) |
2007 |
Jan
(120) |
Feb
(78) |
Mar
(45) |
Apr
(91) |
May
(155) |
Jun
(66) |
Jul
(96) |
Aug
(110) |
Sep
(145) |
Oct
(189) |
Nov
(68) |
Dec
(160) |
2008 |
Jan
(163) |
Feb
(212) |
Mar
(209) |
Apr
(157) |
May
(216) |
Jun
(120) |
Jul
(80) |
Aug
(83) |
Sep
(98) |
Oct
(120) |
Nov
(80) |
Dec
(129) |
2009 |
Jan
(45) |
Feb
(80) |
Mar
(174) |
Apr
(142) |
May
(133) |
Jun
(191) |
Jul
(183) |
Aug
(138) |
Sep
(77) |
Oct
(141) |
Nov
(209) |
Dec
(131) |
2010 |
Jan
(85) |
Feb
(213) |
Mar
(245) |
Apr
(222) |
May
(168) |
Jun
(82) |
Jul
(50) |
Aug
(144) |
Sep
(92) |
Oct
(80) |
Nov
(64) |
Dec
(78) |
2011 |
Jan
(58) |
Feb
(98) |
Mar
(112) |
Apr
(98) |
May
(64) |
Jun
(150) |
Jul
(126) |
Aug
(59) |
Sep
(271) |
Oct
(154) |
Nov
(321) |
Dec
(183) |
2012 |
Jan
(146) |
Feb
(217) |
Mar
(426) |
Apr
(208) |
May
(206) |
Jun
(230) |
Jul
(158) |
Aug
(170) |
Sep
(237) |
Oct
(260) |
Nov
(178) |
Dec
|
From: David B. <Dav...@mo...> - 2006-03-29 14:36:55
|
Paul Kienzle wrote: > > Prettty was there because disp didn't return a value. I believe the > current version does and pretty is no longer needed. > Yes the current disp returns a string if given an output arg. So pretty.cc goes.. > > You are correct that this patch is old and irrelevant at this point. > Also I never completed it --- I have no interest in maintaining a > fork of octave. I still believe it would be nice to write, e.g., > (A - mean(A))./std(A) > > Perhaps a better alternative is to leave matrices as they are, but > provide full numerical support for cell arrays. That would allow the > different data sets to have different lengths rather than relying on > NaN and missing data functions. I think that although the patch itself is now useless due to age, the ideas encapsulated in it should be kept somewhere for future reference. If the PROJECTS file is converted to an issues database based then ideally this patch would form part of that. > > I've been living with the current octave-mod. So the octave-mod in extras/patches goes.. > >> For FIXES, the problem files are >> >> fsolve.cc: I've already attacked this one with the inclusion of the >> function handles and inline functions. The multiple arguments accepted >> by the o-f version might be easier enough to include in octave. > > > This has been refused in the past. I agree with John that it is > an ugly hack, and with anonymous functions supported in both Octave > and matlab, we can ask users to convert their code. What I propose if just the additional arguments bits, not the anonymous function handles and inline functions that cause all of the mess. > >> grid.m: This is a compatibility extension of grid.m to allow 1) >> recovering the previous state with the gget function and toggling grid >> state if no input arguments are used. It also supports minor tics if you >> have an argument like "x#y#z#" where # is a digit. This is not >> texinfo-fied, so based on a very old octave version of grid.m, it used >> gget which I don't see ever going into octave as it has some possibly >> nasty race conditions on temporary files. Perhaps with gnuplot 4.1 >> something similar might be implemented with a pipe and be accepted in >> octave. So in its current implementation I don't see this code being >> accepted. That being the case, the minor tick stuff might be included, >> just not the probing of the existing settings. > > > Rather than querying we could try keeping track of state on the > octave side. I suppose if there is a "PKG_ADD grid('off')" command in grid.m and a persistent variable tracking its state this would make sense. Easy enough to propose a patch. > > The syntax for minor tics is a bit hackish and may be rejected. John what do you want to do about the minors tics in o-f's grid.m? > >> hankel.m, triu.m, tril.m, toeplitz.m: The versions in o-f trade speed >> for memory usage. The o-f versions also have the advantage that they >> work for user types (eg galois fields) as they don't use zeros(m,n) to >> create the initial matrix. There's a thread about this about a year ago >> between Paul and myself on the maintainers list. I don't think John is >> concerned about the speed issue, but the compatibility with user types >> is a real problem for me. In the octave versions of tril.m and triu.m >> what is currently done is >> >> if (isa (x, "sparse")) >> retval = sparse (nr, nc); >> else >> retval = zeros (nr, nc, class (x)); >> endif >> >> however, this can't be done with the galois of fixed types, and there is >> additional information that is not contained in the class. > > > Rather than building up from zeros, can you chop down from a full > matrix. E.g., triu > > for i = 1:columns(x) > x(i+1:end,i) = 0; > end Yes but which value of "0"? In the implementation of galois field the above makes sense and there is only one field for the entire matrix. However, for the fixed-point type it does as each element of the matrix can have a different fixed point representation. > > Preserving the old random number generator seems crufty. Could it > be made into an external package that the few people who care > about it can download it separately? > John's stated he want to keep the capability to generate the same sequences as the old generators. That being the case I don't see a way around having both. > That is not to say we shouldn't support different random > number generators. GSL supports several. However, a > "seed" vs. "state" selector seems like the wrong way to do it. That is the way Matlab does it, so it made sense in a compatibility way. > >> tf2zp.m, zp2tf.m: These are marked as bug fixes in o-f, and if so the >> bug should be fixed in octave. Paul what is the reason for these? > > > I will have to dig through the mailing list to find the cases > where octave's functions fail. Ok. > >> Everything else in FIXES can be removed without question, including the >> sort code, the mu2lin, lin2mu function the poly*.m functions > > > Because octave now includes these functions? Yes D. -- David Bateman Dav...@mo... Motorola Labs - Paris +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob) 91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax) The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
From: Quentin S. <qsp...@ie...> - 2006-03-29 14:10:42
|
I've started the process by removing the following files that are either conditionally compiled or now found in octave: main/audio/wavread.m main/audio/wavwrite.m main/cell/cell2mat.m.in main/cell/cellfun.cc main/cell/Makefile main/cell/.cvsignore main/general/bitand.cc main/general/bitcmp.m.in main/general/bitget.m.in main/general/bitset.m.in main/general/bitshift.m.in main/general/blkdiag.m.in main/general/isequal.m.in main/general/sortrows.m.in main/miscellaneous/dispatch.cc main/miscellaneous/dispatch.m.in main/miscellaneous/inline.m main/plot/clf.m main/plot/orient.m main/plot/print.m.in main/set/.cvsignore main/set/Makefile main/set/unique.m.in main/set/setdiff.m.in main/set/ismember.m.in main/strings/regexp.cc main/strings/str2double.m.in main/strings/strcmpi.m.in main/strings/strmatch.m.in main/strings/strfind.m main/strings/strncmpi.m main/time/Makefile main/time/calender.m main/time/datenum.m.in main/time/datestr.m main/time/datevec.m main/time/eomday.m main/time/now.m main/time/weekday.m I have edited the following to reflect the above deletions: main/miscellaneous/Makefile main/miscellaneous/.cvsignore main/string/Makefile main/string/.cvsignore main/general/Makefile main/general/.cvsignore main/plot/Makefile I'll start into the sparse stuff and the other files that David pointed out next time I have time to work on this. -Quentin |
From: Quentin S. <qsp...@ie...> - 2006-03-29 14:08:50
|
Bill Denney wrote: > Since (IIRC) the current o-f tree is supposed to be heading to > 2.9.x/3.0, I'd very much like for this to happen. One other thing > that I'd really like is for the functions that are going to move to > octave to move (I think that there are some functions that are to be > permanent o-f fixtures). > > I know at one point a list was made of functions that were to be moved > over-- is there a current version of this list? It strikes me as > something that would be good to have on the wiki. I don't think the list was updated. Seems like someone sent it to one of the octave mailing lists. I agree it would be nice to put it on the wiki and update it during the conversion process. -Quentin |
From: Paul K. <pki...@us...> - 2006-03-29 12:59:47
|
On Mar 29, 2006, at 4:53 AM, David Bateman wrote: > Quentin Spencer wrote: > >> Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there >> are incompatibilities, as recently pointed out with the system >> function (should be fixed in CVS now), so I think we should make >> another release for 2.9.5+ soon. I'm willing to spend a little time >> doing some de-crufting, but I just wanted to ask first if there is >> anything I shouldn't touch. The obvious stuff is all of the Makefiles >> and .m.in files for things that are now in octave, but even that is >> incomplete (most of the stuff in the main/time directory appears to be >> in octave now, and there are probably more examples). I also was >> inclined to just remove the whole sparse directory, but I thought >> David said we needed to keep the superLU stuff. Any objections? >> >> -Quentin >> > A lot of stuff is conditionally built, and that can be removed. Also > for > the sparse stuff the iteration stuff should be kept for 2.9, but not > the > rest. That is the pcg.m and pcr.m functions, but nothing else. You can > also remove the extra/test directory completely but move the pretty.cc > function somewhere else unless Paul wants to drop it. Prettty was there because disp didn't return a value. I believe the current version does and pretty is no longer needed. > I'd also like to > eventually see the FIXES and extra/patches directories completely gone > and anything in these should either be in octave or dropped. Though we > can't do that completely until certain code is ported to octave. So > there are several files in these two directories that must be treated > before being dropped. In extra/patches these are > > M-v-ops-2.1.31.patch: This allows things like rand(3).*[1:3] to make > sense and be allowed, however there is a fundamental question of > whether > we want this, given the other products behavior, regardless of how > attractive this is and further more the ages of the patch means that > its > more of an idea of what needs to be done rather than a working patch > against a current version of octave. If we had an issues database, this > should go there but for now keep it in o-f You are correct that this patch is old and irrelevant at this point. Also I never completed it --- I have no interest in maintaining a fork of octave. I still believe it would be nice to write, e.g., (A - mean(A))./std(A) Perhaps a better alternative is to leave matrices as they are, but provide full numerical support for cell arrays. That would allow the different data sets to have different lengths rather than relying on NaN and missing data functions. > octave-mod-2.1.31.patch: I'm not sure the octave emacs mode has been > updated to handle the test/assert stuff. Now that this is in octave > itself, if it doesn't it should be adapted and included in octave. I > think Paul has to make a call on this one. In any case the current > patch > needs serious updating as it doesn't apply at all to the current CVS. I've been living with the current octave-mod. > For FIXES, the problem files are > > fsolve.cc: I've already attacked this one with the inclusion of the > function handles and inline functions. The multiple arguments accepted > by the o-f version might be easier enough to include in octave. This has been refused in the past. I agree with John that it is an ugly hack, and with anonymous functions supported in both Octave and matlab, we can ask users to convert their code. > grid.m: This is a compatibility extension of grid.m to allow 1) > recovering the previous state with the gget function and toggling grid > state if no input arguments are used. It also supports minor tics if > you > have an argument like "x#y#z#" where # is a digit. This is not > texinfo-fied, so based on a very old octave version of grid.m, it used > gget which I don't see ever going into octave as it has some possibly > nasty race conditions on temporary files. Perhaps with gnuplot 4.1 > something similar might be implemented with a pipe and be accepted in > octave. So in its current implementation I don't see this code being > accepted. That being the case, the minor tick stuff might be included, > just not the probing of the existing settings. Rather than querying we could try keeping track of state on the octave side. The syntax for minor tics is a bit hackish and may be rejected. > hankel.m, triu.m, tril.m, toeplitz.m: The versions in o-f trade speed > for memory usage. The o-f versions also have the advantage that they > work for user types (eg galois fields) as they don't use zeros(m,n) to > create the initial matrix. There's a thread about this about a year ago > between Paul and myself on the maintainers list. I don't think John is > concerned about the speed issue, but the compatibility with user types > is a real problem for me. In the octave versions of tril.m and triu.m > what is currently done is > > if (isa (x, "sparse")) > retval = sparse (nr, nc); > else > retval = zeros (nr, nc, class (x)); > endif > > however, this can't be done with the galois of fixed types, and there > is > additional information that is not contained in the class. Rather than building up from zeros, can you chop down from a full matrix. E.g., triu for i = 1:columns(x) x(i+1:end,i) = 0; end A resize function will still be needed to grow the matrix. > rand*: These need to be included in octave, though the question of > allowing the old sequences to be generated needs to be addressed. I > believe the way to handle this is to keep the old generators in octave, > include the new ones, and if the keyword "seed" is used the old > generators will be used to maintain the old sequences for people who > force the seed of the generator, otherwise the new generators will be > used. Also the octave statistic functions should be updated to use > these > functions Preserving the old random number generator seems crufty. Could it be made into an external package that the few people who care about it can download it separately? That is not to say we shouldn't support different random number generators. GSL supports several. However, a "seed" vs. "state" selector seems like the wrong way to do it. > tf2zp.m, zp2tf.m: These are marked as bug fixes in o-f, and if so the > bug should be fixed in octave. Paul what is the reason for these? I will have to dig through the mailing list to find the cases where octave's functions fail. > Everything else in FIXES can be removed without question, including the > sort code, the mu2lin, lin2mu function the poly*.m functions Because octave now includes these functions? > Cleaning up the above and getting what should be in octave sent to John > is on my TODO list, but relatively low priority :-). So if you want to > at least get rid of the stuff I marked above that would be a good > start. - Paul |
From: David B. <Dav...@mo...> - 2006-03-29 09:53:30
|
Quentin Spencer wrote: > Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there > are incompatibilities, as recently pointed out with the system > function (should be fixed in CVS now), so I think we should make > another release for 2.9.5+ soon. I'm willing to spend a little time > doing some de-crufting, but I just wanted to ask first if there is > anything I shouldn't touch. The obvious stuff is all of the Makefiles > and .m.in files for things that are now in octave, but even that is > incomplete (most of the stuff in the main/time directory appears to be > in octave now, and there are probably more examples). I also was > inclined to just remove the whole sparse directory, but I thought > David said we needed to keep the superLU stuff. Any objections? > > -Quentin > A lot of stuff is conditionally built, and that can be removed. Also for the sparse stuff the iteration stuff should be kept for 2.9, but not the rest. That is the pcg.m and pcr.m functions, but nothing else. You can also remove the extra/test directory completely but move the pretty.cc function somewhere else unless Paul wants to drop it. I'd also like to eventually see the FIXES and extra/patches directories completely gone and anything in these should either be in octave or dropped. Though we can't do that completely until certain code is ported to octave. So there are several files in these two directories that must be treated before being dropped. In extra/patches these are M-v-ops-2.1.31.patch: This allows things like rand(3).*[1:3] to make sense and be allowed, however there is a fundamental question of whether we want this, given the other products behavior, regardless of how attractive this is and further more the ages of the patch means that its more of an idea of what needs to be done rather than a working patch against a current version of octave. If we had an issues database, this should go there but for now keep it in o-f octave-mod-2.1.31.patch: I'm not sure the octave emacs mode has been updated to handle the test/assert stuff. Now that this is in octave itself, if it doesn't it should be adapted and included in octave. I think Paul has to make a call on this one. In any case the current patch needs serious updating as it doesn't apply at all to the current CVS. For FIXES, the problem files are fsolve.cc: I've already attacked this one with the inclusion of the function handles and inline functions. The multiple arguments accepted by the o-f version might be easier enough to include in octave. grid.m: This is a compatibility extension of grid.m to allow 1) recovering the previous state with the gget function and toggling grid state if no input arguments are used. It also supports minor tics if you have an argument like "x#y#z#" where # is a digit. This is not texinfo-fied, so based on a very old octave version of grid.m, it used gget which I don't see ever going into octave as it has some possibly nasty race conditions on temporary files. Perhaps with gnuplot 4.1 something similar might be implemented with a pipe and be accepted in octave. So in its current implementation I don't see this code being accepted. That being the case, the minor tick stuff might be included, just not the probing of the existing settings. hankel.m, triu.m, tril.m, toeplitz.m: The versions in o-f trade speed for memory usage. The o-f versions also have the advantage that they work for user types (eg galois fields) as they don't use zeros(m,n) to create the initial matrix. There's a thread about this about a year ago between Paul and myself on the maintainers list. I don't think John is concerned about the speed issue, but the compatibility with user types is a real problem for me. In the octave versions of tril.m and triu.m what is currently done is if (isa (x, "sparse")) retval = sparse (nr, nc); else retval = zeros (nr, nc, class (x)); endif however, this can't be done with the galois of fixed types, and there is additional information that is not contained in the class. That is the primitive polynomial, etc for galois fields. If we created a new type for every primitive polynomial, then the number of user types would explode, which is why its done in this manner. Thinking about it further what I propose is to create a helper function, like DEFUN (resize, args, , "-*- texinfo -*-\n\ @deftypefn {Built-in Function} {} resize (@var{x}, @var{m})\n\ @deftypefnx {Built-in Function} {} resize (@var{x}, @var{m}, @var{n})\n\ Resize @var{x} to be dimension @var{m}-by-@var{n} where @var{m}\n\ and @var{n} are scalar. If @var{n} is not supplied, then resize @var{x}\n\ to be dimension @var{m}-by-@var{m} if @var{m} is scalar, or if\n\ @var{m} is a vector, then the values of this vector respresent the\n\ dimensions of the resized matrix.\n\ @end deftypefn") { octave_value retval; int nargin = args.length (); if (nargin == 2) { Array<double> vec = args(1).vector_value (); int ndim = vec.length (); if (ndim == 1) { octave_idx_type m = static_cast<octave_idx_type> (vec(0)); retval = args (0). resize (dim_vector (m, m)); } else { dim_vector dv (ndim); for (int i = 0; i < ndim; i++) { dv(i) = static_cast<octave_idx_type> (vec(i)); retval = args (0). resize (dv); } } else if (nargin == 3) { octave_idx_type m = args(1).scalar_value(); octave_idx_type n = args(2).scalar_value(); if (!error_state) retval = args (0).resize (dim_vector (m, n)) } else print_usage (resize); return retval; } which I wrote straight into the mailer and so is untested. Then if (isa (x, "sparse")) retval = sparse (nr, nc); else retval = zeros (nr, nc, class (x)); endif can be written as retval = resize (resize (x, 0), nr, nc); and the o-f functions can be dropped. rand*: These need to be included in octave, though the question of allowing the old sequences to be generated needs to be addressed. I believe the way to handle this is to keep the old generators in octave, include the new ones, and if the keyword "seed" is used the old generators will be used to maintain the old sequences for people who force the seed of the generator, otherwise the new generators will be used. Also the octave statistic functions should be updated to use these functions tf2zp.m, zp2tf.m: These are marked as bug fixes in o-f, and if so the bug should be fixed in octave. Paul what is the reason for these? Everything else in FIXES can be removed without question, including the sort code, the mu2lin, lin2mu function the poly*.m functions Cleaning up the above and getting what should be in octave sent to John is on my TODO list, but relatively low priority :-). So if you want to at least get rid of the stuff I marked above that would be a good start. Regards David -- David Bateman Dav...@mo... Motorola Labs - Paris +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob) 91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax) The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
From: Paul K. <pki...@us...> - 2006-03-29 00:21:13
|
On Mar 28, 2006, at 1:00 PM, Quentin Spencer wrote: > Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there > are incompatibilities, as recently pointed out with the system > function (should be fixed in CVS now), so I think we should make > another release for 2.9.5+ soon. I'm willing to spend a little time > doing some de-crufting, but I just wanted to ask first if there is > anything I shouldn't touch. The obvious stuff is all of the Makefiles > and .m.in files for things that are now in octave, but even that is > incomplete (most of the stuff in the main/time directory appears to be > in octave now, and there are probably more examples). I also was > inclined to just remove the whole sparse directory, but I thought > David said we needed to keep the superLU stuff. Any objections? No objections from me. - Paul |
From: Bill D. <de...@se...> - 2006-03-28 19:08:58
|
Since (IIRC) the current o-f tree is supposed to be heading to 2.9.x/3.0, I'd very much like for this to happen. One other thing that I'd really like is for the functions that are going to move to octave to move (I think that there are some functions that are to be permanent o-f fixtures). I know at one point a list was made of functions that were to be moved over-- is there a current version of this list? It strikes me as something that would be good to have on the wiki. Bill On Tue, 28 Mar 2006, Quentin Spencer wrote: > Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there > are incompatibilities, as recently pointed out with the system function > (should be fixed in CVS now), so I think we should make another release > for 2.9.5+ soon. I'm willing to spend a little time doing some > de-crufting, but I just wanted to ask first if there is anything I > shouldn't touch. The obvious stuff is all of the Makefiles and .m.in > files for things that are now in octave, but even that is incomplete > (most of the stuff in the main/time directory appears to be in octave > now, and there are probably more examples). I also was inclined to just > remove the whole sparse directory, but I thought David said we needed to > keep the superLU stuff. Any objections? > > -Quentin > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev > -- From Dumblaws.com: In Guelph, Ontario, Canada, the city is classified as a no-pee zone. |
From: Quentin S. <qsp...@ie...> - 2006-03-28 18:02:13
|
Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there are incompatibilities, as recently pointed out with the system function (should be fixed in CVS now), so I think we should make another release for 2.9.5+ soon. I'm willing to spend a little time doing some de-crufting, but I just wanted to ask first if there is anything I shouldn't touch. The obvious stuff is all of the Makefiles and .m.in files for things that are now in octave, but even that is incomplete (most of the stuff in the main/time directory appears to be in octave now, and there are probably more examples). I also was inclined to just remove the whole sparse directory, but I thought David said we needed to keep the superLU stuff. Any objections? -Quentin |
From: William P. Y. H <wil...@ya...> - 2006-03-27 14:34:26
|
They were accidentally sent. Sorry, please ignore them. William Poetra Yoga Hadisoeseno __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Michael C. <mic...@ua...> - 2006-03-23 14:36:25
|
There is a new version with the stepsize, numeric gradient, and finite difference code integrated into bfgsmin.cc. This simplifies the code, eliminates redundant error checking, and leads to about 15% better performance. There should be no numeric differences in results comparing to the previous version. The example file bfgsmin_example.m has also been updated. Please let me know if any problems are seen. Michael |
From: David B. <Dav...@mo...> - 2006-03-22 20:12:38
|
Quentin Spencer wrote: > Etienne Grossmann wrote: > >> On Fri, Mar 10, 2006 at 12:20:20PM -0600, Quentin Spencer wrote: >> # A while ago I reported an incompatibility with Matlab in the order >> of # outputs of the "system" function. John made changes in CVS >> yesterday to # fix this. I looked through octave-forge CVS and found >> several instances # where "system" is used that will also need to be >> changed. Should I check # these changes in now, or wait until a new >> octave is released? I'm # assuming we're now breaking compatibility >> with 2.1.x. >> # # -Quentin >> [snip] >> >> >> Iigc, this is both the two-output system call, for which >> [msg,status]=system should become [status,msg]=system and the >> single-uutput, for which msg=system should become >> [dummyname,msg]=system. >> >> Seems feasible semi-automatically. >> >> The cases I find in OF are the following. Do you find the same? >> >> ====================================================================== >> ./extra/Windows/dos.m: [text, status] = system(['cmd /c ',cmd]); >> ./main/audio/sound.m: host = system("uname -n"); >> ./main/comm/comms.m: showfile = system(["find '", >> infopath(1:len-1), "' -name ", ... >> ./main/comm/comms.m: showfile = system(["find '", infopath, >> "' -name ", infofile, ... >> ./main/comm/comms.m: [testout, testret] = system(["'", >> INFO_PROGRAM, "' --version"]); >> ./main/comm/comms.m: [testout, testret] = system("info --version"); >> ./main/fixed/fixedpoint.m: showfile = system(["find '", >> infopath(1:len-1), "' -name ", ... >> ./main/fixed/fixedpoint.m: showfile = system(["find '", >> infopath, "' -name ", infofile, ... >> ./main/fixed/fixedpoint.m: [testout, testret] = system(["'", >> INFO_PROGRAM, "' --version"]); >> ./main/fixed/fixedpoint.m: [testout, testret] = system("info >> --version"); >> ./main/general/unix.m: [text, status] = system (cmd); >> ./main/image/imginfo.m:[res,status] = system(sprintf("convert >> -verbose '%s' /dev/null",fn),1); >> ./main/image/imwrite.m: [jnk,retcode] = system(cmd); >> ./main/image/myimage.m: [o,s] = system ("feh tmp.pgm"); >> ./main/image/myimage.m: [o,s] = system ("feh tmp.ppm"); >> ./main/miscellaneous/edit.m: host = system("uname -n"); >> ./main/miscellaneous/slurp_file.m:s = system (sprintf ("cat '%s'",f), >> 1); >> ./main/plot/print.m: [output, errcode] = system (command); >> ./main/vrml/select_3D_points.m:res = system (cmd, 1); >> ./main/vrml/vrml_browse.m: [dum,status]=system (sprintf ("kill -CONT >> %d &> /dev/null",vrml_b_pid)); >> ./main/vrml/vrml_browse.m:[dum,status] = system (["test -e ",b_temp]); >> ./main/vrml/vrml_browse.m: [out, status] = system (cmd = >> [vrml_b_name," ",b_opt," ",b_temp], 1); >> ./main/vrml/vrml_browse.m: [dum,status]=system (sprintf ("kill -USR1 >> %d &> /dev/null",vrml_b_pid)); >> ====================================================================== >> >> >> > > This list is pretty close to mine, although I found a couple of > others. I'll check in the changes soon, but we'll need to be aware of > this after 2.9.5 is released and make sure there isn't anything I missed. > > -Quentin If this is purely a 2.9.5 change then I'd suggest that the comm and fixedpoint system calls that call info might be replaced with the doc.m function, and so it might be better to eliminate these than convert them.. D. |
From: Quentin S. <qsp...@ie...> - 2006-03-22 17:43:49
|
Etienne Grossmann wrote: >On Fri, Mar 10, 2006 at 12:20:20PM -0600, Quentin Spencer wrote: ># A while ago I reported an incompatibility with Matlab in the order of ># outputs of the "system" function. John made changes in CVS yesterday to ># fix this. I looked through octave-forge CVS and found several instances ># where "system" is used that will also need to be changed. Should I check ># these changes in now, or wait until a new octave is released? I'm ># assuming we're now breaking compatibility with 2.1.x. ># ># -Quentin >[snip] > > >Iigc, this is both the two-output system call, for which >[msg,status]=system should become [status,msg]=system and the >single-uutput, for which msg=system should become >[dummyname,msg]=system. > > Seems feasible semi-automatically. > > The cases I find in OF are the following. Do you find the same? > >====================================================================== >./extra/Windows/dos.m: [text, status] = system(['cmd /c ',cmd]); >./main/audio/sound.m: host = system("uname -n"); >./main/comm/comms.m: showfile = system(["find '", infopath(1:len-1), "' -name ", ... >./main/comm/comms.m: showfile = system(["find '", infopath, "' -name ", infofile, ... >./main/comm/comms.m: [testout, testret] = system(["'", INFO_PROGRAM, "' --version"]); >./main/comm/comms.m: [testout, testret] = system("info --version"); >./main/fixed/fixedpoint.m: showfile = system(["find '", infopath(1:len-1), "' -name ", ... >./main/fixed/fixedpoint.m: showfile = system(["find '", infopath, "' -name ", infofile, ... >./main/fixed/fixedpoint.m: [testout, testret] = system(["'", INFO_PROGRAM, "' --version"]); >./main/fixed/fixedpoint.m: [testout, testret] = system("info --version"); >./main/general/unix.m: [text, status] = system (cmd); >./main/image/imginfo.m:[res,status] = system(sprintf("convert -verbose '%s' /dev/null",fn),1); >./main/image/imwrite.m: [jnk,retcode] = system(cmd); >./main/image/myimage.m: [o,s] = system ("feh tmp.pgm"); >./main/image/myimage.m: [o,s] = system ("feh tmp.ppm"); >./main/miscellaneous/edit.m: host = system("uname -n"); >./main/miscellaneous/slurp_file.m:s = system (sprintf ("cat '%s'",f), 1); >./main/plot/print.m: [output, errcode] = system (command); >./main/vrml/select_3D_points.m:res = system (cmd, 1); >./main/vrml/vrml_browse.m: [dum,status]=system (sprintf ("kill -CONT %d &> /dev/null",vrml_b_pid)); >./main/vrml/vrml_browse.m:[dum,status] = system (["test -e ",b_temp]); >./main/vrml/vrml_browse.m: [out, status] = system (cmd = [vrml_b_name," ",b_opt," ",b_temp], 1); >./main/vrml/vrml_browse.m: [dum,status]=system (sprintf ("kill -USR1 %d &> /dev/null",vrml_b_pid)); >====================================================================== > > > This list is pretty close to mine, although I found a couple of others. I'll check in the changes soon, but we'll need to be aware of this after 2.9.5 is released and make sure there isn't anything I missed. -Quentin |
From: Michael C. <mic...@ua...> - 2006-03-22 13:47:22
|
Etienne Grossmann wrote: > Hi All, > > On Wed, Mar 22, 2006 at 07:52:28AM -0500, Bill Denney wrote: > # On Wed, 22 Mar 2006, Michael Creel wrote: > # > # >Hello all, > # >I'm planning on converting the existing bfgsmin (source bfgsmin.cc) to a > # >new function __bfgsmin (source __bfgsmin.cc), and writing a user frontend > # >bfgsmin.m. A couple of questions > # > # What is the benefit of doing this? > > my guess: > > 1) Having a user-friendly func (.m) where the user-friendliness is > written in Octave (ez on the developer). This is what I was thinking about. > > 2) Having a low-overhead func (__.cc) that you may use to do N>>1 > times almost the same thing, without paying N*overhead. This is > only useful if you can actually determine the params for __.cc > (perhaps if bfgs.m has a "show_me_how_to_do_it" options that > returns the args it passes to __bfgs.cc). This is something that I hadn't thought about, but may be a benefit, Now when bfgsmin calls newtonstep, about a zillion times during the course of minimization, the arguments are checked each time. How important the arg checking overhead is, I have no idea. But it can be eliminated with or without going the .m file frontend route, just by incorporating the stepsize algorithm into bfgsmin.cc. Actually, now that I think about it, I can incorporate a copy of the numeric gradient code into bfgsmin, too. There's no need to make them disappear as separate genrally available functions, the same functions will just have different names internally to bfgsmin.cc. This will get rid of a lot of overhead and will achieve the benefit of a single pass though argument checking for all functions. For a first step, I'm going to try that and do some benchmarking. The issue of a m-file frontend can wait or be forgotten. Thanks, M |
From: Michael C. <Mic...@ua...> - 2006-03-22 13:23:05
|
Bill Denney wrote: > On Wed, 22 Mar 2006, Michael Creel wrote: > >> Hello all, >> I'm planning on converting the existing bfgsmin (source bfgsmin.cc) to >> a new function __bfgsmin (source __bfgsmin.cc), and writing a user >> frontend bfgsmin.m. A couple of questions > > > What is the benefit of doing this? Simplicity and code re-use: All the C functions would have their arguments checked in the same place. As it is, there's more scope for programmer error since there are multiple copies of essentially the same argument checks. Extendability: Someone writing a different frontend to __bfgsmin (for example, a general minimization routine that allows the method to be user selected) would have intelligible Octave expressions for argument checks to use as an example, rather than the less user friendly C argument checks. > >> 1) All input checking will be in the .m file frontend. Thus, it will >> be possible to crash octave by directly calling __bfgsmin with bad >> arguments. Is that acceptable? > > > My personal opinion is that every function should do full error checking > of its arguements. I know that people are writing web front-ends to > octave, and that could lead to dangerous code. > > The way that I view this is that some day, someone will call __bfgsmin > and get an error and complain about it. Then we'll have to add the > arguement checking anyway, so it should just be added from the beginning. Well, that's the way it is now, so if this is not a well-received idea, the course of action is clear :-) Thanks for the input. M. |
From: Etienne G. <et...@cs...> - 2006-03-22 13:19:33
|
Hi All, On Wed, Mar 22, 2006 at 07:52:28AM -0500, Bill Denney wrote: # On Wed, 22 Mar 2006, Michael Creel wrote: # # >Hello all, # >I'm planning on converting the existing bfgsmin (source bfgsmin.cc) to a # >new function __bfgsmin (source __bfgsmin.cc), and writing a user frontend # >bfgsmin.m. A couple of questions # # What is the benefit of doing this? my guess: 1) Having a user-friendly func (.m) where the user-friendliness is written in Octave (ez on the developer). 2) Having a low-overhead func (__.cc) that you may use to do N>>1 times almost the same thing, without paying N*overhead. This is only useful if you can actually determine the params for __.cc (perhaps if bfgs.m has a "show_me_how_to_do_it" options that returns the args it passes to __bfgs.cc). Is my guess close? Etienne # >1) All input checking will be in the .m file frontend. Thus, it will be # >possible to crash octave by directly calling __bfgsmin with bad # >arguments. Is that acceptable? # # My personal opinion is that every function should do full error checking # of its arguements. I know that people are writing web front-ends to # octave, and that could lead to dangerous code. # # The way that I view this is that some day, someone will call __bfgsmin and # get an error and complain about it. Then we'll have to add the arguement # checking anyway, so it should just be added from the beginning. # # Bill # # -- # "The history of liberty is a history of the limitation of government # power, not the increase of it." # -- Woodrow Wilson # # # # ------------------------------------------------------- # This SF.Net email is sponsored by xPML, a groundbreaking scripting language # that extends applications into web and mobile media. Attend the live webcast # and join the prime developer group breaking into this new coding territory! # http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 # _______________________________________________ # Octave-dev mailing list # Oct...@li... # https://lists.sourceforge.net/lists/listinfo/octave-dev -- Etienne Grossmann ------ http://www.cs.uky.edu/~etienne |
From: Bill D. <de...@se...> - 2006-03-22 12:52:34
|
On Wed, 22 Mar 2006, Michael Creel wrote: > Hello all, > I'm planning on converting the existing bfgsmin (source bfgsmin.cc) to a new > function __bfgsmin (source __bfgsmin.cc), and writing a user frontend > bfgsmin.m. A couple of questions What is the benefit of doing this? > 1) All input checking will be in the .m file frontend. Thus, it will be > possible to crash octave by directly calling __bfgsmin with bad > arguments. Is that acceptable? My personal opinion is that every function should do full error checking of its arguements. I know that people are writing web front-ends to octave, and that could lead to dangerous code. The way that I view this is that some day, someone will call __bfgsmin and get an error and complain about it. Then we'll have to add the arguement checking anyway, so it should just be added from the beginning. Bill -- "The history of liberty is a history of the limitation of government power, not the increase of it." -- Woodrow Wilson |
From: Michael C. <mic...@ua...> - 2006-03-22 10:19:16
|
Hello all, I'm planning on converting the existing bfgsmin (source bfgsmin.cc) to a new function __bfgsmin (source __bfgsmin.cc), and writing a user frontend bfgsmin.m. A couple of questions 1) All input checking will be in the .m file frontend. Thus, it will be possible to crash octave by directly calling __bfgsmin with bad arguments. Is that acceptable? 2) bfgsmin.cc currently uses newtonstep.cc which sometimes calls bisectionstep.cc. I wrote the two stepsize algorithms as separate functions since they could be of use by other minimization algorithms. But I'm not aware of any such use, so I'm thinking of incorporating them into __bfgsmin.cc, so that they would benefit from the argument checking in the new bfgsmin.m. Does anyone object to the two stepsize functions disappearing from general availability? 3) bfgsmin.cc currently has stuff like (line 391) g = tempmatrix.row((octave_idx_type)0).transpose(); in it which prevent it from compiling using "mkoctfile bfgsmin.cc" I understand this is for 64 bit compatibility. This is no big deal for me, I'm ok using octave-forge. But is it possible to get 32 and 64 bit compatibility and still compile using plain mkoctfile? 4) I'm planning similar changes for numgradient and numhessian, and the disappearance of finitedifference. Comments welcome. Thanks, Michael |
From: Rafael L. <rla...@us...> - 2006-03-22 09:48:48
|
* David Bateman <Dav...@mo...> [2006-03-22 10:43]: > Thomas Weber wrote: > >If it helps, a build log of a failed build with gcc-4.1 is available at > >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357651 > > I believe Paul fixed this, which was one of the motivating factors for > the 2006-03-16 release... Indeed, the bug report above regards version 2006.01.28. -- Rafael |
From: David B. <Dav...@mo...> - 2006-03-22 09:43:47
|
Thomas Weber wrote: >Hi David, > >Am Samstag, den 04.02.2006, 20:36 +0100 schrieb David Bateman: > > >>I don't curently have a machine with g++ 4.1 installed, so I can't fix >>this. However, I'd like to see it fixed, so if you can supply me with >>the compile logs giving the errors off-line I'll attempt a fix... >> >> > >If it helps, a build log of a failed build with gcc-4.1 is available at >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357651 > > >Regards > Thomas > > Thomas, I believe Paul fixed this, which was one of the motivating factors for the 2006-03-16 release... Regards David -- David Bateman Dav...@mo... Motorola Labs - Paris +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob) 91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax) The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
From: Thomas W. <tho...@gm...> - 2006-03-22 08:35:50
|
Hi David, Am Samstag, den 04.02.2006, 20:36 +0100 schrieb David Bateman: > I don't curently have a machine with g++ 4.1 installed, so I can't fix > this. However, I'd like to see it fixed, so if you can supply me with > the compile logs giving the errors off-line I'll attempt a fix... If it helps, a build log of a failed build with gcc-4.1 is available at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357651 Regards Thomas |
From: James R. P. <ant...@ya...> - 2006-03-21 17:01:26
|
INFO ==== The Cygwin octave-forge package has been updated to release 2006.03.17-1. This is the first Cygwin release to incorporate D. Bateman's fixed-point package, useful for designing testing fixed-point signal processing applications. Changes (from release notes): 2006-03-16 == * statistics/regress: new function 2006-01-28 == * audio/waveread: big-endian fix; 2-channel file fix * comm/galois: fix rank calculation for galois array * general/interp2: cubic interpolation * image/: return MxNx3 matrices of appropriate numeric class * io/textread: faster * io/dlmwrite: control precision and line separator; allow append * miscellaneous/mfilename: compatibility function * miscellaneous/listen: subnet patterns; loopback support * NaN/xcovf: missing data xcorr * octcdf/: support for netcdf files * optim/wpolyfit: return row vector; allow centering and scaling * plot/legend: fix error on first call * plot/print: add PDF option * signal/residued,residuez: partial fraction expansion of filters * signal/qp_kaiser: PPN filter bank coefficients * statistics/histfit: allow negative data * statistics/mvnpdf,mvnrnd: multivariate normal distribution * tsa/: improved speed, style and docs * tsa/amarma: adaptive mean ARMA modeling * tsa/y2res: add entropy estimation; add equidistant quantisation * tsa/mvfreqz: add PDCF * support for 2.9.4 * support for 64-bit indexing * support for MinGW build The octave-forge project contains over 500 contributed functions for GNU Octave which are not in the main distribution. These functions are grouped according to the following subdirectories: audio, comm, control, general, geometry, fixed, ident, image, io, linear-algebra, miscellaneous, optim, path, plot, set,signal, sparse, specfun, special-matrix, splines, statistics, strings, struct, symbolic, time. The Cygwin distribution of octave-forge also incorporates m-files from the octave-ci collection. octave-forge home page: http://octave.sourceforge.net octave-ci collection: ftp://ftp.ci.tuwien.ac.at/pub/octave/octave-ci.tar.gz UPDATE ====== To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'octave-forge' from the 'Math' category. Then click on the 'skip' field next to 'octave-forge' until '2006.03.17' is displayed. DOWNLOAD: ========= Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: ========== If you want to make a point or ask a question the Cygwin mailing list cy...@cy... is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: ================================= To unsubscribe to the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-YOU=YOU...@cy... If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. MAINTAINER ========== James R. Phillips |
From: Bill D. <de...@se...> - 2006-03-21 02:57:28
|
I noticed a directory that appears to be created by the=20 octave-forge-windows installer that probably shouldn't be: c:\Documents=20 and Settings\Agust=EDn Bart=F3 directory (or at least that's the only way I= =20 can imagine that it would have been created). Also, if it is created=20 there, the directory is not removed on uninstallation. Bill --=20 "Wanted: Hardworking moronic drone to assist insane genius. High school diploma...not required?" -- Bernard, DoTT |
From: Paul K. <pki...@us...> - 2006-03-19 20:29:21
|
I ran the following cvs command on the R2006-03-17 release: cvs tag -b R2-1-x That means we now have a branch for 2.1.x. Any fixes against the 2.1.x octave can be applied to there. I used the following command to check out the branch: cvs -d :ext:pki...@cv...:/cvsroot/octave co -doctave-forge-21 -r R2-1-x octave-forge I then modified the Makefile to note that it was in the 2.1.x branch, and indeed the changes did not get copied to the trunk. I have no intention of making any more 2.1.x releases, but should some be needed, release.sh could be modified to accept a tag parameter when downloading the archive. All pre-2.9.5 cruft can now be purged. I would like to see a new 'octave-forge/package' tree. Directories in this tree should install using the octave-2.9.x packaging system. Packages in main, extra and non-free should eventually move to package. We should not need any toplevel configure script---if the octave packaging system doesn't do what we need it to, then extend the packaging system. octave-forge is dead! Long live octave-forge. Given the problems with cvs on sourceforge lately, we might consider moving to e.g., savannah and subversion. At a minimum we could move to subversion on sourceforge. The subversion page on sourceforge says that it is slower than CVS, but I understand that it will feel faster because more operations are done locally. The main argument for moving to subversion, though, is that we can move packages from main to package without losing history. Anyone care to do the work, and tell the rest of us what we need to do that is different? - Paul On Mar 10, 2006, at 1:20 PM, Quentin Spencer wrote: > A while ago I reported an incompatibility with Matlab in the order of > outputs of the "system" function. John made changes in CVS yesterday > to fix this. I looked through octave-forge CVS and found several > instances where "system" is used that will also need to be changed. > Should I check these changes in now, or wait until a new octave is > released? I'm assuming we're now breaking compatibility with 2.1.x. > > -Quentin |
From: Etienne G. <et...@cs...> - 2006-03-19 19:21:44
|
On Fri, Mar 10, 2006 at 12:20:20PM -0600, Quentin Spencer wrote: # A while ago I reported an incompatibility with Matlab in the order of # outputs of the "system" function. John made changes in CVS yesterday to # fix this. I looked through octave-forge CVS and found several instances # where "system" is used that will also need to be changed. Should I check # these changes in now, or wait until a new octave is released? I'm # assuming we're now breaking compatibility with 2.1.x. # # -Quentin [snip] Iigc, this is both the two-output system call, for which [msg,status]=system should become [status,msg]=system and the single-uutput, for which msg=system should become [dummyname,msg]=system. Seems feasible semi-automatically. The cases I find in OF are the following. Do you find the same? ====================================================================== ./extra/Windows/dos.m: [text, status] = system(['cmd /c ',cmd]); ./main/audio/sound.m: host = system("uname -n"); ./main/comm/comms.m: showfile = system(["find '", infopath(1:len-1), "' -name ", ... ./main/comm/comms.m: showfile = system(["find '", infopath, "' -name ", infofile, ... ./main/comm/comms.m: [testout, testret] = system(["'", INFO_PROGRAM, "' --version"]); ./main/comm/comms.m: [testout, testret] = system("info --version"); ./main/fixed/fixedpoint.m: showfile = system(["find '", infopath(1:len-1), "' -name ", ... ./main/fixed/fixedpoint.m: showfile = system(["find '", infopath, "' -name ", infofile, ... ./main/fixed/fixedpoint.m: [testout, testret] = system(["'", INFO_PROGRAM, "' --version"]); ./main/fixed/fixedpoint.m: [testout, testret] = system("info --version"); ./main/general/unix.m: [text, status] = system (cmd); ./main/image/imginfo.m:[res,status] = system(sprintf("convert -verbose '%s' /dev/null",fn),1); ./main/image/imwrite.m: [jnk,retcode] = system(cmd); ./main/image/myimage.m: [o,s] = system ("feh tmp.pgm"); ./main/image/myimage.m: [o,s] = system ("feh tmp.ppm"); ./main/miscellaneous/edit.m: host = system("uname -n"); ./main/miscellaneous/slurp_file.m:s = system (sprintf ("cat '%s'",f), 1); ./main/plot/print.m: [output, errcode] = system (command); ./main/vrml/select_3D_points.m:res = system (cmd, 1); ./main/vrml/vrml_browse.m: [dum,status]=system (sprintf ("kill -CONT %d &> /dev/null",vrml_b_pid)); ./main/vrml/vrml_browse.m:[dum,status] = system (["test -e ",b_temp]); ./main/vrml/vrml_browse.m: [out, status] = system (cmd = [vrml_b_name," ",b_opt," ",b_temp], 1); ./main/vrml/vrml_browse.m: [dum,status]=system (sprintf ("kill -USR1 %d &> /dev/null",vrml_b_pid)); ====================================================================== -- Etienne Grossmann ------ http://www.cs.uky.edu/~etienne |
From: Quentin S. <qsp...@ie...> - 2006-03-19 05:04:58
|
A while ago I reported an incompatibility with Matlab in the order of outputs of the "system" function. John made changes in CVS yesterday to fix this. I looked through octave-forge CVS and found several instances where "system" is used that will also need to be changed. Should I check these changes in now, or wait until a new octave is released? I'm assuming we're now breaking compatibility with 2.1.x. -Quentin |