Thread Subject: Converting C code into matlab

How to convert 'C' language code into Matlab.

In article <g1jg4u$jr$1@fred.mathworks.com>,
jeya lakshmi <jeya_vedha@yahoo.co.in> wrote:
>How to convert 'C' language code into Matlab.

Is there a difference between your present query and your query
yesterday of nearly identical wording, which I answered with a couple
of paragraphs begining with "There is no tool available that can do that." ??


--
  "What is important, then, is not that the critic should possess a
  correct abstract definition of beauty for the intellect, but a
  certain kind of temperament, the power of being deeply moved by
  the presence of beautiful objects." -- Walter Pater

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in
message <g1jm42$rpj$1@canopus.cc.umanitoba.ca>...
> In article <g1jg4u$jr$1@fred.mathworks.com>,
> jeya lakshmi <jeya_vedha@yahoo.co.in> wrote:
> >How to convert 'C' language code into Matlab.
>
> Is there a difference between your present query and your
query
> yesterday of nearly identical wording, which I answered
with a couple
> of paragraphs begining with "There is no tool available
that can do that." ??
>
>
> --
> "What is important, then, is not that the critic should
possess a
> correct abstract definition of beauty for the
intellect, but a
> certain kind of temperament, the power of being deeply
moved by
> the presence of beautiful objects." -- Walter
Pater


there is no convertor from English to French, how do you
expect a convertor from C to Matlab.
You need a human translator.

In article <g1jscr$9lj$1@fred.mathworks.com>,
Rami AbouSleiman <rdabousl@oakland.edu> wrote:

>there is no convertor from English to French, how do you
>expect a convertor from C to Matlab.
>You need a human translator.

Natural languages have ambiguity in them, and puns, and mistaken
words that are recoverable from context, and so on. Natural language
processing is *hard*.

C does have -some- ambiguity in it, but it is well-defined what
sections are ambiguous (e.g., the specification deliberately
indicates that the result of overflowing a signed integer is undefined.)
There are languages which are easier to parse than C, but it is
not especially bad. C is -designed- for mechanical processing. As is
Matlab.

It is thus not unreasonable to hope that there might be a
C to Matlab compiler (e.g., there are a few different computer languages
that maple can parse and convert to maple or to other languages).
There just probably isn't one, due to the messiness of converting C
pointer operations into equivilent Matlab code.

--
  "Let me live in my house by the side of the road --
   It's here the race of men go by.
   They are good, they are bad, they are weak, they are strong
   Wise, foolish -- so am I;" -- Sam Walter Foss

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in
message <g1k0ib$djn$1@canopus.cc.umanitoba.ca>...
> In article <g1jscr$9lj$1@fred.mathworks.com>,
> Rami AbouSleiman <rdabousl@oakland.edu> wrote:
>
> >there is no convertor from English to French, how do you
> >expect a convertor from C to Matlab.
> >You need a human translator.
>
> Natural languages have ambiguity in them, and puns, and
mistaken
> words that are recoverable from context, and so on.
Natural language
> processing is *hard*.
>
> C does have -some- ambiguity in it, but it is well-
defined what
> sections are ambiguous (e.g., the specification
deliberately
> indicates that the result of overflowing a signed integer
is undefined.)
> There are languages which are easier to parse than C, but
it is
> not especially bad. C is -designed- for mechanical
processing. As is
> Matlab.
>
> It is thus not unreasonable to hope that there might be a
> C to Matlab compiler (e.g., there are a few different
computer languages
> that maple can parse and convert to maple or to other
languages).
> There just probably isn't one, due to the messiness of
converting C
> pointer operations into equivilent Matlab code.
>
> --
> "Let me live in my house by the side of the road --
> It's here the race of men go by.
> They are good, they are bad, they are weak, they are
strong
> Wise, foolish -- so am I;" -- Sam
Walter Foss

I guess this will be possible after series work from
mathworks, like how would you translate "extern" to Matlab
when some functions cannot read a variable from the
workspace.

In article <g1k4ja$odb$1@fred.mathworks.com>,
Rami AbouSleiman <rdabousl@oakland.edu> wrote:

>like how would you translate "extern" to Matlab
>when some functions cannot read a variable from the
>workspace.

"extern" is one of the easier ones: it mostly just translates to
"global".

--
  "The slogans of an inadequate criticism peddle ideas to fashion"
                                              -- Walter Benjamin

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in
message <g1k5kt$kiv$1@canopus.cc.umanitoba.ca>...
> In article <g1k4ja$odb$1@fred.mathworks.com>,
> Rami AbouSleiman <rdabousl@oakland.edu> wrote:
>
> >like how would you translate "extern" to Matlab
> >when some functions cannot read a variable from the
> >workspace.
>
> "extern" is one of the easier ones: it mostly just
translates to
> "global".
>
> --
> "The slogans of an inadequate criticism peddle ideas to
fashion"
> -- Walter
Benjamin

despite my great love for matlab, i think it still has
problems in variables declaration. A global in matlab is
like auto in C.
In C when i declare a global variable I can access it
anywhere anytime but in matlab I cannot.

"Rami AbouSleiman" <rdabousl@oakland.edu> wrote in message
news:g1k77l$f6$1@fred.mathworks.com...
> roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in
> message <g1k5kt$kiv$1@canopus.cc.umanitoba.ca>...
>> In article <g1k4ja$odb$1@fred.mathworks.com>,
>> Rami AbouSleiman <rdabousl@oakland.edu> wrote:
>>
>> >like how would you translate "extern" to Matlab
>> >when some functions cannot read a variable from the
>> >workspace.
>>
>> "extern" is one of the easier ones: it mostly just
> translates to
>> "global".
>>
>> --
>> "The slogans of an inadequate criticism peddle ideas to
> fashion"
>> -- Walter
> Benjamin
>
> despite my great love for matlab, i think it still has
> problems in variables declaration. A global in matlab is
> like auto in C.
> In C when i declare a global variable I can access it
> anywhere anytime but in matlab I cannot.

In MATLAB, you need to declare the variable as global _everywhere you want
to be able to access it from the global workspace_.

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/global.html

To the OP (original poster): instead of converting the C code into an
M-file, you might want to convert it into a MEX-file:

http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_external/f7667.html

or create an executable from the C file and call it using SYSTEM, ! (bang),
or LOADLIBRARY.

--
Steve Lord
slord@mathworks.com

In article <g1k77l$f6$1@fred.mathworks.com>,
Rami AbouSleiman <rdabousl@oakland.edu> wrote:

>despite my great love for matlab, i think it still has
>problems in variables declaration. A global in matlab is
>like auto in C.
>In C when i declare a global variable I can access it
>anywhere anytime but in matlab I cannot.

Incorrect. When you declare an object as extern in C, you can access
that object only within the scope of that declaration.

int foo(void) {
  { extern bar; bar = 5; } /* block one */
  { bar; printf("bar is currently \%d", bar); } /* block two */
}

The 'extern bar' inside block one has a scope only to the end of
block one. The unadorned reference to bar at the beginning of
block two is the equivilent of declaring an auto variable bar
with block scope and implicit type int; the bar in the printf then
refers to that auto variable... producing an undefined result as
the local bar is not initialized.


The key difference between C and Matlab in this respect is that
C permits extern references at the file scope level, thus establishing
a scope for the variable that extends to the end of the source file.
Not "anywhere anytime", just to the end of the file!.

Matlab's "global" is certainly not the equivilent of C's auto.
A variable declared global in any matlab routine declares a
persistent variable whose presence may be imported into any other function
by declaring it global in the second function. C's auto variables
are *always* scoped only in the block they are declared in, and
it is an error to refer to them outside that scope, even if you
passed out a pointer to them.

C's "static" has a lot more in common with Matlab's "extern" than
C's "auto" does! Even then the comparison is week: in C, you cannot
explicitly refer to a block-scoped static variable from outside
the block unless you have a pointer to that static area. The
comparison is strongest between C's extern and Matlab's global --
other than Matlab not offering a file scope to automatically
import the definition into all further routines in the source file.
--
  "What is important, then, is not that the critic should possess a
  correct abstract definition of beauty for the intellect, but a
  certain kind of temperament, the power of being deeply moved by
  the presence of beautiful objects." -- Walter Pater

Here is something more challenging to convert:

- setjmp and longjmp (ANSI-C)

Not sure whereas MATLAB has something equivalent.

I won't go into dirty C-programming such as using pointer
within a function to change itself (dirty but can be very
powerful).

Bruno

In article <g1kelq$cba$1@fred.mathworks.com>,
Bruno Luong <b.luong@fogale.fr> wrote:

>Here is something more challenging to convert:

>- setjmp and longjmp (ANSI-C)

>Not sure whereas MATLAB has something equivalent.

try/catch would be the closest in real functionality, but
setjmp / longjump has rather pathological cases as -possibilities-.

>I won't go into dirty C-programming such as using pointer
>within a function to change itself (dirty but can be very
>powerful).

Undefined by C itself; the only time you can dereference a pointer
to a function is for the purpose of calling the function.
C function pointers need not be the same length or address space
as data pointers -- for example, C can be implemented on Harvard
Architecture devices (seperate address spaces for instruction
and data.)

Implementations are permitted to assign meaning to converting
function pointers to integral values or to void*, but the C
standard doesn't even hint about what such things might mean.
--
  "When we all think alike no one is thinking very much."
                                              -- Walter Lippmann