Olaf Till wrote: > On Thu, May 06, 2010 at 01:35:31PM -0700, Søren Hauberg wrote: >> tor, 06 05 2010 kl. 22:24 +0200, skrev Alois Schlögl: >>> After looking further into the problem of converting octave code into >>> a >>> matlab compatible syntax, I concluded that in some cases it is >>> easiest >>> way to make the source code compatible. In some cases, there is just >>> no >>> way to make an automated conversion. E.g there is no good way to >>> convert >>> while (k++ == N) in a automated way. Converting the source code is >>> a >>> simpler and more straight forward way. >>> >>> The attached patch is doing this. The difficult cases like ++, --, >>> +=, >>> -=, /=, &=, *=, |=, and do-until are replaced. Most of the octave >>> specific syntax (like endfor, endwhile, ## comment, etc.) stays in >>> place. >>> >>> Are there are any objections on committing this patch ? >> In my opinion, this is a decision to be made by individual package >> maintainers. > > Søren, and Alois, I think such a decision can't be left only to the > individual package maintainers. Some packages (e.g. optim) have no > dedicated maintainer; in others the original author may be different > from the current maintainer; it's not guaranteed that the respective > authors attend to this list. These issues get weight especially since > such Octave->Matlab conversions are --- sorry for the hard word --- > anti-productive for the Octave community (IMO). They make the code > harder to read and more clumsy (there are cases where this is even > more obvious than in the proposed patch). They interfer with a widely > distributed Octave-mode of Emacs. They can introduce errors. > > For the latter point (errors), there are examples in the patch (I only > looked in optim and do not claim I've found all there), although the > changes were quite trivial in the case of this patch: > > while niter++ < something > > is not equivalent to > > while niter < something > niter = niter + 1; > > (in optim/inst/d2_min.m. niter is used after the while loop, so this > matters.) > > Similar with ninner in the same file. > > Olaf > > ------------------------------------------------------------------------------
Olaf, The two loops in d2_min are the only cases in optim, that are a little bit more difficult. Or do you see any other issues in optim? Concerning the inner loop maxinner = 30; ... ninner=0; while ninner++ < maxinner, ... if (c) break end; ... endwhile if ninner >= maxinner ... else ... If we apply this patch: - while ninner++ < maxinner + while ninner < maxinner + ninner = ninner + 1; There is no difference when the loop ends with the break, ninner is the same. Only when the while condition is false (that is when ninner = 30 or larger) the increment ninner++ is not applied. However, the subsequent check (ninner >= maxinner) is (30 >= 30) instead of (31>=30). So the overall outcome is the same. In case of the outer loop, the patch should be -while niter++ <= maxout && nev(1) < maxev +while niter <= maxout + niter = niter + 1; + if nev(1) < maxev, break; end; Thanks for pointing this out. I do not agree that reaching out for a larger audience can be detrimental to the Octave community. I think that a more widespread use of Octave functions will also increase the Octave community and improve Octave code. One of biggest selling points of Octave is that it is most compatible with Matlab, otherwise one could use freemat, scilab, python, R or whatever. Alois ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
