octave-maintainers
[Top][All Lists]
Advanced

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

Re: Compatability and an engineer's perspective


From: Daniel J Sebald
Subject: Re: Compatability and an engineer's perspective
Date: Sun, 15 Jul 2012 14:06:39 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 07/14/2012 11:17 PM, Jonathan Lister wrote:
Hello Octave Maintainers,

I am a Mechanical Engineer and I am interested in helping with Octave
Development.  I am fairly competent with MATLAB and I use it quite
frequently at work.  I also have done a lot of MATLAB deployable
applications with guis.

I've been watching Octave mature for some time now.  One concern that I
have is the trend to move away from compatibility with MATLAB.

From someone who's seen Octave over a period of ten to fifteen years, I actually think the trend has been in the other direction, HG being a prime example.


Allowing
endfunction, endfor, etc... makes sense for making Octave a nicer
language from a programmers point of view, but it does not help
engineers grab pieces of Octave code and use them in MATLAB.

Well, there are a couple perspectives on this. I don't think that the intention is to force users to put "endfunction" and similar syntax in their code. The end user writes code that will work in either Matlab or Octave.

On the other hand, for routines in Octave packages the intention (and I'm not sure as I can't recall any discussion on this); the intention appears to be to ensure (perhaps not that degree of strength, let's say discourage) what you are suggesting doesn't happen. I.e., that someone wants to use Matlab as a base and use Octave libraries/packages. I think it's best to generally avoid hybridized programs because of copyright issues and just the confusion of it all. For example, if a colleague tells me s/he used Octave or Matlab I know the quirks and limitations of both. But if the colleague tells me s/he used a hybrid of the two, it's rather shaky ground.


  (Key for
allowing a build up of confidence in the product)

Please explain this. To me, confidence is gained when the result of some computer computations agree with my understanding, my sample computations, my intuition. If you mean comparing results, that seems to happen all the time as regards the discussions and bug reports here.


I've adapted and can very quickly convert an Octave Toolbox to MATLAB,
but having a good automatic converter would be much better.

No one, and no license, is deeming such practice bad beyond perhaps discouragement. However, a couple comments:

1) The core of Octave, that is to say the portion of operation not using m-scripts (i.e., builtins), is rather compatible with Matlab. Anything built in gets an extra level of scrutiny because it is almost certain to pass top developers' eyes. So, there should be an extra level of confidence about the core of Octave. Octave may be slower in some circumstances because lack of resources means code optimization is lower priority, but the operation is rather solid.

2) That being said, if you have a client that demands using Matlab on company systems because that is the IT rule, then it is probably best to purchase packages for Matlab because the hybridized system with ported packages (given what I've said above) is more Octave than it is Matlab.


If you want to attract MATLAB users to switch to Octave you need to make
compatibility a top priority.  Our company researched what is the most
common language that Engineering students acquire through their studies
in American universities, the answer was MATLAB.

We've looked into alternatives such as Python, Scilab, R, and Octave.
  As Octave continues down the road of making its syntax more and more
distinct from MATLAB it becomes a less viable option.  In my
professional opinion if I had to learn a new language I would go for Python.

I'm not real familiar with Python, but my guess is that any decision as to the programming language depends on what the language is intended for. Matlab is popular with engineers because it quickly does things that engineers need to do in their practice.

However, one area I personally wouldn't use Matlab/Octave is for GUI's that need to be used in a product. For R&D, company department, the Matlab GUI is fine.


I'm not trying to put Octave down at all.  I only want to make sure that
everyone understands what this trend is leading to from an Engineer's
perspective.  Right now I cannot recommend Octave as a replacement due
to the differences in syntax, lack of handle graphics, no classdef, and
no IDE.

I know what you are saying, but I feel like that was the case maybe ten or fifteen years ago. I've made my opinion known in the past, and unpopular, that the IDE is the least significant barrier for scientists and engineers to use Octave. Plus, if there is to be an IDE, why limit to the look and feel of Matlab? Provide some features that really improve on already fairly convenient and flexible tools (e.g., command lines with tab completion, editors custom to what users are personally used to). I suspect this coming week we'll see and discuss these sorts of things at OctConf (plug!).

Dan


reply via email to

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