Re: [OT?] Matlab usage, when, where, why?


Brad Phelan wrote:
> > Polymorphism is where the true power of object oriented
> > programming comes in, and is where the real savings in code
> > development and maintenance are realized. Of course, that requires
> > the programming language to be strongly typed in the first place,
> > which Matlab, whatever virtues it otherwise might have, is not.
>
> I think you mean overloading not polymorphism.

Maybe I do. What I have done, is to define a virtual class as basic
interface
for the user. The user needs to decide if he wants a lowpass, highpass,

bandpass or bandstop filter, and set the parameters in an instance
of the appropriate LP/HP/BP/BSSpecificationClass. The user then
sets up an instance of a FilterClass where the coefficients will be
stored, and then calls an instance of the XXXXFilterGeneratorClass for
whatever filter type he wants (XXXX=Butterworth, Cheb 1/2,...).

Internally to the FilterGenerator virtual base class, type checking on
the
filter specification instance decides what computational routines will
be
used, i.e.

void compute(LPSpecificationClass*);
void compute(HPSpecificationClass*);
void compute(BPSpecificationClass*);
void compute(BSSpecificationClass*);

are available methods, and whichever is used is determined by the
exact type of CurrentSpecification in the call

this->compute(CurrentSpecification);

Some of the detailed computations on the lowpass prototypes are
delegated to the classes derived from the virtual class
FilterGenerator.

I don't know if this is overloading or polymorphism. What I do know, is
that
the testing and imlementation of new filters takes no work at all, once

the main framework is up and running. Once the virtual base classes
work, adding a new type of filters amounts to deriving a new class
from the virtual base class, and reimplementing the virtual functions.
Everything is taken care of at compile/link time, no extra overhead
at run-time.

> Overloading requires ( maybe ) a statically typed language such as
> Java or C++ to dispatch method calls to similarly named methods with
> different method type signatures. The language can be either strongly
> or weakly typed. C++ and Java allow overloading but Matlab does not.

OK, you obviously know more about the programming terminology
than me. We do agree that the type specification in the method calls
is what makes C++ handle this style of programming, and is the
reason why Matlab does not support it.

> Weak typing and strong typing refer to whether type violations are
> checked before executing commands. Strongly typed languages have an
> explicit type-violation mechanism such as the Java, "Class Cast
> Exception". C and C++ just do random undetermined things if you get
> your class casting wrong and thus they are weakly-typed.

Ah, now I understand the terms "weakly typed" and "strongly typed".
I did discover, the hard way, a need for checking the arguments through

a "dynamic_cast<T>" type of statement at the beginning of each of
my type-dependent methods...

> Polymorphism is not a feature of strong typing or weak typing. Matlab
> is polymorphic. Matlab OOPs allows you to define the same named
> methods on a base class with different implementations for child
> classes. For example most OOPs objects are defined with a display
> method and most people implement subsref and subsasgn for indexing
> like behaviour.
>
> C & C++ - weakly typed - statically typed
> Java - strongly typed - statically typed
> Matlab - strongly typed - dynamically typed
> Python - strongly typed - dynamically typed

Thanks for the summary. It seems "statically/dynamically typed" are
the terms I ought to use. I haven't noticed them before.

My own dislike of dynamically typed languages comes from trying to
understand/modify/debug/maintain ancient FORTRAN code of
unknown origin with absent documentation. While the FORTRAN
language does require memory to be allocated, say n(100) is an
array named n with 100 elements, it does not require the data type
to be explicitly specified. Knowing whether the array n contains
integers,
floats or complex numbers could make a big difference in understanding
what its purpose is inside the program.

Actually declaring the variable somewhere, like (C/C++ this time)

float n[100];

not only makes the type explicit, it also provides a point in the code
where it is reasonable to insert a comment about what the purpose
of the variable is,

float n[100]; //!< Refraction index in medium

Once you have a commented declaration, it literally takes a
fraction of a second to insert the extra "!<" code so that, say,
Doxygen can generate a HTML documentation page from the code.

To me, statically typed languages are necessary pre-requisites
to make decently documented programs. No programmer I know
is diciplined enough to consitently document the work he does
in a dynamically typed language. Few programmers do, even in
statically typed languages. But statically typed languages
provide -- require, even -- a few basic hooks where it is very
reasonable to insert some basic comments. Once such basic
documentation is enforced, it costs next to nothing to insert the
extra voodoo needed to generate online or printed documentation.

Rune

.

Loading