Re: JIT - automated mexing

[Alexander Barth]

On Mon, Jul 26, 2010 at 7:53 PM, Jaroslav Hajek <address@hidden> wrote:
> On Mon, Jul 26, 2010 at 5:54 PM, Judd Storrs <address@hidden> wrote:
>> On Mon, Jul 26, 2010 at 11:42 AM, Alexander Barth
>> <address@hidden> wrote:
>>>
>>> function x = foo(a,b)
>>> %oct-type a,x double
>>> %oct-type b int
>>> x = a+b
>>
>> But return types in octave are very unruly. For example how would you
>> declare the return type of sort()?
>> Also, none come immediately to mind but can't functions return different
>> types based on the number of input and output arguments that are used?
>>
>
>
> Definitely, yes. log2, for instance. Another thing is functions like
> sqrt() which can return double or complex results depending on the
> input.
> Most importantly, many m-functions are designed to be type-generic,
> i.e. they will compute in double if passed double inputs, single with
> single inputs, integers, complex, characters etc. How would you
> reflect that with declarations?
>

Well the idea is that only a subset of the language would be supported
(for the code translation) and all types have to be known at the time
you write the code. Basically one could only use language features
what you could use in C++ (or any strongly typed language). In those
languages you would need to declare something like this for log2:

function [double R] = log2(double X);
function [double F, int E] = log2(double X);

With this information, I think that the code translation could know
the type of the return values based on the number of in-/output
arguments and argument types at the calling level.

For type generic function, one could imagine something vaguely
equivalent of C++ function templates:

function [type S] = sum_of_two_values(type A, type B)
S = A + B;

If this function is called for example with two doubles, the result
would be a double. Also for the case when A=3.5 and B=2.5, I think
that the results should be considered as double, although 5 can be
represented as an integer. For the same reason, I think it would be
simpler to assume that the result of sqrt is always of complex type
(despite the fact that it could be represented as double when the
argument is positive). At the caller level, one can always cast the
result to a double:

x = double(sqrt(4))

An error would be generated if the cast is not possible:

x = double(sqrt(-4))  % error

However, there might be still cases when the return type can only be
detected by running the function. Here is a (quite strange) example:

function r = foo(a)
if a < 0
   r = 'negative';
else
   r = a;
endif

One could just simply say that this function cannot be used in code
than need to be translated (it would only be interpreted) or
translated to C++ by using the generic octave_value type. Operations
using this return value would thus be slow, but all other statements
using variables of known types could benefit from the performance
increase.

But I know that this is a HUGE task to implement....

Cheers,
Alex