Asked by Walter Roberson
on 18 May 2012

It is not uncommon for students to be assigned questions which they are required to complete "without using any built-in functions". There is not a great deal that can be programmed in MATLAB without using **any** built-in functions, but a *little* can be done -- but what, exactly **is** possible?

What a "built-in function" **is**, exactly, is open to interpretation. In the below, I refer instead to "publicly visible routines". Keywords (see below) are not publicly visible routines (they are "statements" or components of statements.) Any documented operation or call that invokes a MATLAB-supplied .m or .p or mex file or built-in library to do its work is a publicly visible routines. If you can use documented methods override the normal meaning of a statement or expression *in practice* by supplying alternate code, then the code probably involves publicly visible routines. If the language design is such that you could use documented methods to override the normal meaning of a statement or expression *in theory* (such as the behavior of adding two double, the code for which is in practice bundled into an internal MATLAB library), then I would still consider that a call to a publicly visible routine.

A MATLAB-supplied routine that is not documented, which is used for internal MATLAB purposes, could perhaps be held not to be a *publicly* visible routine, but it certainly would still be a "built-in function".

I exclude from the list any routine which there is no direct way to access, and is only used for internal purposes, such as the memory allocation routines.

This is what I have come up with:

- the names defined as "keywords" do not in themselves involve function calls to publicly visible routines. These keywords currently include 'break', 'case', 'catch', 'classdef', 'continue', 'else', 'elseif', 'end', 'for', 'function', 'global', 'if', 'otherwise', 'parfor', 'persistent', 'return', 'switch', 'try', 'while'. There is no functional form of any of these: for example, one cannot use global(s) to declare the name contained in the variable "s" to be global.
- scalar numeric double precision real-valued constants are handled at parse time, including unary plus and unary minus in front of them
- scalar numeric double precision constants followed immediately by "i" or "j" create a complex-value constant at parse time, including unary plus and unary minus in front of them
- whether a complete complex constant with real and imaginary part is handled at parse time is unknown
- literal character strings are handled at parse time
- in sufficiently new versions, int64() and uint64() around an integer constant is handled at parse time. This was a change from previous versions which handled it at run time (after the integer had been converted to double precision...)
- whether any other casts such as uint16() or logical() are now handled at parse time is unknown
- assignment of a compete variable (no indexing, no substructure references, etc.) to a plain variable (no indexing, no substructure references, etc.) does not involve any function calls to publicly visible routines (unless I have overlooked a case involving objects)
- "if" or "while" applied to a scalar logical constant or to a scalar logical variable does not involve any function calls to publicly visible routines. However, it is not known whether there is any method to construct a logical value without calling a MATLAB routine: "true" and "false" are MATLAB routines, not constants, and logical() of a numeric constant might be handled at run time
- "for" in which the range is named as a scalar constant or scalar variable do not involve any function calls to publicly visible routines; for example, "for K = 5"
- defining an anonymous function does not involve any function calls to publicly visible routines

I may have overlooked something due to shortage of chocolate in my bloodstream.

The language described above is **not** Turing complete, and is not "sufficiently powerful" for the purposes of the Church-Rosser Theorem of general-purpose computability. It is also not possible to do any arithmetic in it, as arithmetic must be reducible to the Peano Postulates, and those require at the very least the ability to compare a value for equality with 0, which in MATLAB would require a call to the MATLAB routine "eq".

*No products are associated with this question.*

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi test

Learn moreOpportunities for recent engineering grads.

Apply Today
## 6 Comments

## Daniel (view profile)

Direct link to this comment:http://uk.mathworks.com/matlabcentral/answers/38787#comment_80250

Does accessing the mex and java capabilities require any builtin functions?

## Walter Roberson (view profile)

Direct link to this comment:http://uk.mathworks.com/matlabcentral/answers/38787#comment_80255

Good question, Daniel. I would say "No" for "mex", and "I am not sure" for java. "import" does not.

I will add a clarification above as to what a "builtin function is" for the discussion.

## Walter Roberson (view profile)

Direct link to this comment:http://uk.mathworks.com/matlabcentral/answers/38787#comment_80257

I was wrong, import() is a real routine.

## Sean de Wolski (view profile)

Direct link to this comment:http://uk.mathworks.com/matlabcentral/answers/38787#comment_80259

Well if mex is okay, then I would say you can do a fair amount.

## Jan Simon (view profile)

Direct link to this comment:http://uk.mathworks.com/matlabcentral/answers/38787#comment_80346

Hey, what's up? I've written a lot functions without the built-in ANY command.

## per isakson (view profile)

Direct link to this comment:http://uk.mathworks.com/matlabcentral/answers/38787#comment_247920

Given this definition, isn't it impossible to write a bubble-sort routine without using any built-in function?