Am 28.01.2013 03:17, schrieb Allin Cottrell:
> On Mon, 28 Jan 2013, Pietro Battiston wrote:
>
>>>>
>>>> I'd be OK with 'language=numpy' if people think that's better,
>>>> although I'd say the _language_ is python.
>>>
>>> Sure, but Python doesn't speak arrays without numpy, so it's both
>>> together that form the numerical language. So "python-numpy"? (which is
>>> also the name of the debian package BTW).
>>
>> I personally do not agree. The language you will write is simply python,
>> which, for an implementational detail, uses numpy. I don't think the
>> user is even necessarily assumed to know this is happening, until she
>> just reads the docs. Unless there really are any reason why we should
>> want an additional python "flavour" supported, I think the simplest
>> alternative, "language=python", is the best.
>
> I'm with you on that, Pietro.
As I said, it's not a big thing, so go ahead, especially given the
solution chosen below, where the user must make her imports explicit.
Even though I do not agree (a language not only consists of syntax, but
of course of vocabulary as well, which is coming from numpy here), I
guess you can make the point that the Python spirit is always "import
this", and numpy is just one more (complex) module then.
>
> Here's what's in current CVS, following Sven's recent suggestions:
>
> 1) In the convenience python functions gretl_loadmat() and
> gretl_export() -- for shuttling matrices between gretl and python --
> we do this sort of thing:
>
> <python>
> def gretl_loadmat(fname):
> from numpy import loadtxt
> dname = gretl_dotdir()
> M = loadtxt(dname + fname, skiprows=1)
> return M
> </python>
>
> That is, we import locally the functionality we need from numpy.
>
> 2) We leave it up to the user to import from numpy and/or scipy,
> with the user's preferred namespace, for more general usage.
The scipy thing is actually also a good reason not to use numpy blindly,
because a user may want to work with stuff which is only in scipy.
>
> Point 1) means that gretl's python support depends on the user
> having numpy installed, but I suppose that really goes without
> saying: how could you do anything useful in terms of gretl/python
> interaction without numpy?
Yes; OTOH gretl could try to catch the resulting import error:
<python>
try:
def gretl_loadmat(fname):
from numpy import loadtxt
dname = gretl_dotdir()
M = loadtxt(dname + fname, skiprows=1)
return M
except ImportError:
<somehow signal the absence of numpy to gretl>
</python>
>
>> While I'm at it: I guess that now most of the work needed to also have a
>> python console running in gretl is done? Let me point out that if that
>> was the case, it would be great to be able to choose _which_ console to
>> use (for instance "ipython" instead than simple "python").
>
> Hmm. We currently have the ability to edit/run python scripts in the
> gretl gui (with appropriate syntax highlighting) in the same sort of
> way as we support Ox programs and R or Octave scripts. As for
> providing a "console" (by which I understand an interactive
> command-line interface), I'm not sure that is gretl's job.
I agree, or at least I don't see the use case.
thanks,
sven
