Re: JIT - automated mexing

[Jaroslav Hajek]

On Wed, Jul 28, 2010 at 11:05 AM, Alexander Barth
<address@hidden> wrote:
> 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;
>

Yes. Note that templates are by far the most tricky part of C++ compilers.

> 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.

The constant 5 is a double value in Octave. But what should happen if
A is 1+2i and B is 3?

> 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
>

It's real(sqrt(4)), actually. The automatic complex->real conversion
is one of the most convenient features of Octave/Matlab. Whether your
array is nonnegative, or complex/negative, sqrt does the right thing.

> 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
>

simpler cases exist, actually. For instance, some functions return []
as a special case, but often don't bother to cast it to correct type.

> 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.
>

To summarize the above:

1. only certain library funcs would be supported
2. code decorations are needed, i.e. code must be adjusted for compiling
3. compiling may slightly change code semantics, so extra conversions
may be needed - again adjusting code
4. it still may not compile, so you'd better keep the original code as well

Don't you feel it's just simpler to use the C++ API?

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz