librelist archives

« back to archive

Intent of having two translation modules?

Intent of having two translation modules?

From:
Jon Riehl
Date:
2012-05-30 @ 19:17
Hi,

Just a quick warning: I'm about to start flooding this list with
development questions.  Smack me around if this isn't where we do
that.

So what is the intent of having "translate.py" and
"kerneltranslate.py", where "kerneltranslate.py" duplicates a lot of
the same code in the former?  I ask because I figured "translate" was
intended to be the main translation module (I'm rigging the decorators
to use it, for example), but "kerneltranslate" actually has the array
datatype defined in llvm-py.

Thanks,
-Jon

Re: [numba] Intent of having two translation modules?

From:
Travis Oliphant
Date:
2012-05-30 @ 20:32
Hey Jon,

The only point was to allow different classes to produce different 
decorators until their functionality could be merged into one.   It's 
purpose was to make it easier to move forward experimentally.

The make ufunc capability doesn't really need to know about arrays, but 
the kernel trsnsaltor does, for example. 

Travis 

--
Travis Oliphant
(on a mobile)
512-826-7480


On May 30, 2012, at 2:17 PM, Jon Riehl <jon.riehl@gmail.com> wrote:

> Hi,
> 
> Just a quick warning: I'm about to start flooding this list with
> development questions.  Smack me around if this isn't where we do
> that.
> 
> So what is the intent of having "translate.py" and
> "kerneltranslate.py", where "kerneltranslate.py" duplicates a lot of
> the same code in the former?  I ask because I figured "translate" was
> intended to be the main translation module (I'm rigging the decorators
> to use it, for example), but "kerneltranslate" actually has the array
> datatype defined in llvm-py.
> 
> Thanks,
> -Jon

Re: [numba] Intent of having two translation modules?

From:
Jon Riehl
Date:
2012-05-30 @ 20:45
Understandable.  For my own sanity, I'm going to try to work out of
the translate.py module for now, pulling in what I need from the other
module.  I assume we can add appropriate guards around make_ufunc at
some point to ensure it doesn't have unsuitable types.

Thanks,
-Jon

On Wed, May 30, 2012 at 3:32 PM, Travis Oliphant <travis@continuum.io> wrote:
> Hey Jon,
>
> The only point was to allow different classes to produce different 
decorators until their functionality could be merged into one.   It's 
purpose was to make it easier to move forward experimentally.
>
> The make ufunc capability doesn't really need to know about arrays, but 
the kernel trsnsaltor does, for example.
>
> Travis
>
> --
> Travis Oliphant
> (on a mobile)
> 512-826-7480
>
>
> On May 30, 2012, at 2:17 PM, Jon Riehl <jon.riehl@gmail.com> wrote:
>
>> Hi,
>>
>> Just a quick warning: I'm about to start flooding this list with
>> development questions.  Smack me around if this isn't where we do
>> that.
>>
>> So what is the intent of having "translate.py" and
>> "kerneltranslate.py", where "kerneltranslate.py" duplicates a lot of
>> the same code in the former?  I ask because I figured "translate" was
>> intended to be the main translation module (I'm rigging the decorators
>> to use it, for example), but "kerneltranslate" actually has the array
>> datatype defined in llvm-py.
>>
>> Thanks,
>> -Jon

Re: [numba] Intent of having two translation modules?

From:
Travis Oliphant
Date:
2012-06-01 @ 01:45
That's fine.   The kerneltranslate.py file had only the numpy interface 
work and little else of value --- some thought about improving the 
type-mapping from LLVM types to numpy dtypes.

-Travis

On May 30, 2012, at 3:45 PM, Jon Riehl wrote:

> Understandable.  For my own sanity, I'm going to try to work out of
> the translate.py module for now, pulling in what I need from the other
> module.  I assume we can add appropriate guards around make_ufunc at
> some point to ensure it doesn't have unsuitable types.
> 
> Thanks,
> -Jon
> 
> On Wed, May 30, 2012 at 3:32 PM, Travis Oliphant <travis@continuum.io> wrote:
>> Hey Jon,
>> 
>> The only point was to allow different classes to produce different 
decorators until their functionality could be merged into one.   It's 
purpose was to make it easier to move forward experimentally.
>> 
>> The make ufunc capability doesn't really need to know about arrays, but
the kernel trsnsaltor does, for example.
>> 
>> Travis
>> 
>> --
>> Travis Oliphant
>> (on a mobile)
>> 512-826-7480
>> 
>> 
>> On May 30, 2012, at 2:17 PM, Jon Riehl <jon.riehl@gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> Just a quick warning: I'm about to start flooding this list with
>>> development questions.  Smack me around if this isn't where we do
>>> that.
>>> 
>>> So what is the intent of having "translate.py" and
>>> "kerneltranslate.py", where "kerneltranslate.py" duplicates a lot of
>>> the same code in the former?  I ask because I figured "translate" was
>>> intended to be the main translation module (I'm rigging the decorators
>>> to use it, for example), but "kerneltranslate" actually has the array
>>> datatype defined in llvm-py.
>>> 
>>> Thanks,
>>> -Jon