What can be programmed "without any built-in functions" ?
158 views (last 30 days)
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', 'spmd', '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. (However, you can define an "end" method; https://www.mathworks.com/help/matlab/matlab_oop/object-end-indexing.html )
- 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 vectors and string objects 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".