From serge.guelton at telecom-bretagne.eu  Wed Dec 21 02:49:46 2016
From: serge.guelton at telecom-bretagne.eu (serge guelton)
Date: Wed, 21 Dec 2016 08:49:46 +0100
Subject: [Python-compilers] Type inference and Python
Message-ID: <20161221074946.loiu22newebcaqzw@lakota>

Hi, Python compilers enthusiasts,

I recently implemented an (unsound) type inference algorithm for
Pythran, and documented it here:

    http://serge-sans-paille.github.io/pythran-stories/from-pythran-import-typing.html

Some of the ideas may be interesting for the community, so I'm sharing it!

From siu at continuum.io  Wed Dec 21 14:24:45 2016
From: siu at continuum.io (Siu Kwan Lam)
Date: Wed, 21 Dec 2016 19:24:45 +0000
Subject: [Python-compilers] Type inference and Python
In-Reply-To: <20161221074946.loiu22newebcaqzw@lakota>
References: <20161221074946.loiu22newebcaqzw@lakota>
Message-ID: <CAHjo7=Vcx6LNqAq7bLzfL4UuXgfpVm1AWVLpqyzFn5kWi_EoMA@mail.gmail.com>

Thanks for sharing.  The trick to get type promotion is interesting.  But,
it makes me wonder how you encode numpy casting rules like uint64 + int64
-> float64 if tog does not consider the signedness of int.  I found that
numpy casting rules can be weird sometimes that it needs many special cases.

On Wed, Dec 21, 2016 at 1:58 AM serge guelton <
serge.guelton at telecom-bretagne.eu> wrote:

> Hi, Python compilers enthusiasts,
>
> I recently implemented an (unsound) type inference algorithm for
> Pythran, and documented it here:
>
>
> http://serge-sans-paille.github.io/pythran-stories/from-pythran-import-typing.html
>
> Some of the ideas may be interesting for the community, so I'm sharing it!
> _______________________________________________
> Python-compilers mailing list
> Python-compilers at python.org
> https://mail.python.org/mailman/listinfo/python-compilers
>
-- 
Siu Kwan Lam
Software Engineer
Continuum Analytics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-compilers/attachments/20161221/c3df3ff9/attachment.html>

From serge.guelton at telecom-bretagne.eu  Thu Dec 22 08:51:39 2016
From: serge.guelton at telecom-bretagne.eu (serge guelton)
Date: Thu, 22 Dec 2016 14:51:39 +0100
Subject: [Python-compilers] Type inference and Python
In-Reply-To: <CAHjo7=Vcx6LNqAq7bLzfL4UuXgfpVm1AWVLpqyzFn5kWi_EoMA@mail.gmail.com>
References: <20161221074946.loiu22newebcaqzw@lakota>
 <CAHjo7=Vcx6LNqAq7bLzfL4UuXgfpVm1AWVLpqyzFn5kWi_EoMA@mail.gmail.com>
Message-ID: <20161222135139.pd4prfenqlskimto@lakota>

On Wed, Dec 21, 2016 at 07:24:45PM +0000, Siu Kwan Lam wrote:
> Thanks for sharing.  The trick to get type promotion is interesting.  But,
> it makes me wonder how you encode numpy casting rules like uint64 + int64
> -> float64 if tog does not consider the signedness of int.  I found that
> numpy casting rules can be weird sometimes that it needs many special cases.

In the case of tog, these rules are not taken in to account.

If I were to put uint64 and int64 into a list, it would turn into a list
of float64 according to the above rule (a strange but clever choice,
it's probably a good way to make the accuracy loss sparse). The current
type promotion trick would still work, with the according changes :

            float64     int64   uint64
  int64         any       yes      any
 uint64         any       any      yes

so the union of both would be (any, yes, yes) which is different from
(yes, any, any) but they are still compatible.

I didn't know about this conversion rule, thanks!