2cmap file for specifying the correct
mapping. Read the code in numpy/f2py/capi_maps.py and you'll find that
inserting the following codelet to setup.py file might work (untested code):
from numpy.f2py.capi_maps import f2c_map
f2c_map['real'].update(sp='float', dp='dou
Hi Casey,
On Wed, Aug 12, 2015 at 11:46 PM, Casey Deen wrote:
> Hi Pearu-
>
>Thanks so much! This works! Can you point me to a reference for the
> format of the .pyf files? My ~day of searching found a few pages on the
> scipy website, but nothing which went into this a
intent(callback,hide) bambam
external bambam
end subroutine barney
Btw, instead of
f2py -c -m flintstone flintstone.pyf callback.f nocallback.f
use
f2py -c flintstone.pyf callback.f nocallback.f
because module name comes from the .pyf file.
HTH,
Pearu
On Wed, Aug 12, 2
FFLAGS in Makefile before executing make.
> 2. How can I use the library and my own Fortran source fileI( All.f90 )
> with the f2py command to generate the module I can use py Python
>
Try
f2py -c -m mylib All.f90 /path/to/kriginglib.a
python
>>> import mylib
>>
Studio specifics to suggest a more detailed
solution but after generating wrapper source files there is no f2py
specific way to build the extension module, in fact, `f2py -c` relies on
distutils compilation/linkage methods.
HTH,
Pearu
On Tue, Sep 30, 2014 at 4:15 PM, Bayard wrote:
> Hello to
the outcome (a working solution) in the following wikipage:
https://code.google.com/p/f2py/wiki/FAQ2ed
Just FYI,
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
can have allocatable arrays in module data block, for instance, where
they a global. f2py supports wrapping these allocatable arrays to python.
See, for example,
http://cens.ioc.ee/projects/f2py2e/usersguide/index.html#allocatable-arrays
Pearu
___
NumPy-Dis
rom numpy lapack_lite (which is
f2c code and could use also C-ordering, in principle),
F-contiguous arrays are actually returned.
Regards,
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
('header' for i in range(12))
> np.arange(100, dtype=np.uint).tofile(fhw)
>
> # use normal python io to determine of offset after 12 lines.
> with open('test.mm') as fhr:
> for i in range(12): fhr.readline()
> offset = fhr.tell()
I think that b
ibuteError: 'str' object has no attribute 'extra_f77_compile_args'
Reading the code, I don't see how this can happen. Very strange.
Anyway, I cleaned up build_clib to follow similar coding convention
as in build_ext. Could you try numpy head again?
Regards,
Pearu
__
extra_f77_compile_args and
extra_f90_compile_args
options that can be used in config.add_extension as well as in
config.add_library.
See
https://github.com/numpy/numpy/commit/43862759
So, with recent numpy the following will work
config.add_extension( 'my_extension', sources = my_sources,
l: _intel_fast_memset
>
>
> Can anyone suggest what this error message means and how I can overcome it,
> please?
Try
f2py -c -m sub sub.f90 --fcompiler=gnu95
HTH,
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
NPY_ULONG does not correspond to a 16 or 32
or 64 bit integer?
Or does this indicate a bug somewhere for this particular platform?
Thanks,
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy
s = self.swig_sources(sources, ext)
>> File
>>
>> "/home/bsesar/usr/pydebug/lib/python2.7/site-packages/numpy/distutils/command/build_src.py",
>>
>> line 646, in swig_sources
>> extension.swig_opts.remove('-c++')
>> AttributeError: 'str' object has
On Fri, May 27, 2011 at 7:39 AM, Matthew Brett wrote:
> Hi,
>
> On Thu, May 26, 2011 at 9:32 PM, Pearu Peterson
> wrote:
> > Hi,
> >
> > Would it be possible to setup a signing system where anyone who would
> like
> > to support Clint could sign and a
. Personally, I would be happy to sign to such a letter.
On the letter: the letter should also mention scipy community as they
benefit
most from the ATLAS speed.
Best regards,
Pearu
On Fri, May 27, 2011 at 12:03 AM, Matthew Brett wrote:
> Hi,
>
> On Wed, May 4, 2011 at 9:24 AM, Robert Ke
On Tue, May 17, 2011 at 8:05 AM, Pearu Peterson wrote:
>
>
> On Tue, May 17, 2011 at 12:04 AM, Nikolas Tautenhahn wrote:
>
>> Hi,
>>
>> > Here
>> >
>> >
>> http://code.google.com/p/pylibtiff/source/browse/#svn%2Ftrunk%2Flibtiff%2Fbitarr
:
>>> from libtiff import bitarray
>>> barr = bitarray.bitarray(0, 'little')
>>> barr.fromword(3,4)
>>> barr
bitarray('1100')
that will append 4 bits of the value 3 to the bitarray barr.
Also check out various bitarray `to*` and `from*` methods.
HTH,
P
Hi,
I have used bitarray for that
http://pypi.python.org/pypi/bitarray/
Here
http://code.google.com/p/pylibtiff/source/browse/#svn%2Ftrunk%2Flibtiff%2Fbitarray-0.3.5-numpy
you can find bitarray with numpy support.
HTH,
Pearu
On Mon, May 16, 2011 at 9:55 PM, Nikolas Tautenhahn wrote
y package, but how do you specify all these compiler flags?
>
>
It is possible. See numpy/distutils/tests for examples. To use gfortran, run
python setup.py build --fcompiler=gnu95
HTH,
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, May 7, 2011 at 12:00 AM, DJ Luscher wrote:
> Pearu Peterson gmail.com> writes:
> >
> > On Fri, May 6, 2011 at 10:18 PM, DJ Luscher lanl.gov> wrote:
> >
> > I have encountered another minor hangup. For assumed-shape array-valued
> > functions defi
t_in(vars[a]):
+add(var2fixfortran(vars,a,f90mode=f90mode))
+dumped_args.append(a)
+for a in args:
+if a in dumped_args: continue
add(var2fixfortran(vars,a,f90mode=f90mode))
-
+
add(l)
if need_interface:
to see if changing the order will fix the hang.
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, May 6, 2011 at 5:55 PM, DJ Luscher wrote:
> Pearu Peterson gmail.com> writes:
> >
> >
> > Thanks for the bug report!These issues are now fixed in:
> https://github.com/numpy/numpy/commit/f393b604 Ralf, feel free to apply
> this
> changeset to 1.6.x br
and I believe related) f2py can no longer compile source with assumed
> shape array valued functions within a module. Even though the python
> wrapped
> code did not function properly when called from python, it did work when
> called
> from other fort
lars are immutable. Hence the need to use `a =
foo(a)`.
HTH,
Pearu
On Tue, Apr 12, 2011 at 9:52 PM, Mathew Yeates wrote:
> bizarre
> I get
> =
> >>> hello.foo(a)
> Hello from Fortran!
> a= 1
> 2
> >>> a
> 1
> >
gt;> foo(a)
>
> and I want a's value to now be 2.
> How do I do this?
>
With
subroutine foo (a)
integer a
!f2py intent(in, out) a
print*, "Hello from Fortran!"
print*, "a=",a
a=2
end
you will have desired effect:
>>>
__ import division
>>> var1 = 10
>>> var2 = 100
>>> print var1/var2
0.1
HTH,
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Mar 31, 2011 at 1:00 PM, Scott Sinclair wrote:
> On 31 March 2011 11:37, Pearu Peterson wrote:
> >
> >
> > On Thu, Mar 31, 2011 at 12:19 PM, David Cournapeau
> > wrote:
> >>
> >> On Wed, Mar 30, 2011 at 7:22 AM, Russell E. Owen wrote:
&g
ly one seeing it ?
>
>
The test work here ok on Ubuntu 64 with numpy master. Could you try the
maintenance/1.6.x branch where the related bugs are fixed.
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Mar 29, 2011 at 11:03 AM, Dag Sverre Seljebotn <
d.s.seljeb...@astro.uio.no> wrote:
>
> I think it should be a(1:n*stride:stride) or something.
>
>
Yes, it was my typo and I assumed that n is the length of the original
array.
Pearu
___
On Tue, Mar 29, 2011 at 8:13 AM, Pearu Peterson wrote:
>
>
> On Mon, Mar 28, 2011 at 10:44 PM, Sturla Molden wrote:
>
>> Den 28.03.2011 19:12, skrev Pearu Peterson:
>> >
>> > FYI, f2py in numpy 1.6.x supports also assumed shape arrays.
>>
>> How
On Mon, Mar 28, 2011 at 10:44 PM, Sturla Molden wrote:
> Den 28.03.2011 19:12, skrev Pearu Peterson:
> >
> > FYI, f2py in numpy 1.6.x supports also assumed shape arrays.
>
> How did you do that? Chasm-interop, C bindings from F03, or marshalling
> through expli
ey are usually passed as a pointer to
> the first element. These are the only type of Fortran arrays f2py supports.
>
FYI, f2py in numpy 1.6.x supports also assumed shape arrays.
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http:/
On Fri, Mar 25, 2011 at 1:44 AM, Derek Homeier <
de...@astro.physik.uni-goettingen.de> wrote:
> On 24.03.2011, at 9:11AM, Pearu Peterson wrote:
> >
> > Intel-64bit:
> > ERROR: test_assumed_shape.TestAssu
On Thu, Mar 24, 2011 at 10:11 AM, Pearu Peterson
wrote:
>
> Regarding this test failure, could you hack the
> numpy/f2py/tests/test_kind.py script by adding the following code
>
> for i in range(20):
> print '%s -> %s, %s' % (i, selected_real_kind(i), selectedr
mp-/tmpfiy1jn/foo_free.f90',
> '/var/folders/DC/DC7g9UNr2RWkb++8ZSn1J+++0Dk/-Tmp-/tmpfiy1jn/foo_use.f90',
> '/var/folders/DC/DC7g9UNr2RWkb++8ZSn1J+++0Dk/-Tmp-/tmpfiy1jn/precision.f90']
>
Reading .f2py_f2cmap ...
Mapping "real(kind=rk)" to "double"
Hmm, this should not happen as real(kind=rk) should be mapped to "float".
It seems that you have .f2py_f2cmap file lying around. Could you remove it
and try again.
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
put in
> headers for several items that need a few lines in the notes, I hope
> this can be filled in by the authors of those features (Charles:
> Legendre polynomials, Pearu: assumed shape arrays, Mark: a bunch of
> stuff).
>
Done for assumed shape arrays and size fun
:
setup(...
libraries = [('foo', dict(sources=['qsnake/fmesh.f90']))],
ext_modules = [Extension("qsnake.cmesh",
sources =
["qsnake/cmesh.pyx"],
libraries = ['foo']
Thanks!
Pearu
On Thu, Dec 2, 2010 at 11:08 PM, Charles R Harris
wrote:
>
>
> On Thu, Dec 2, 2010 at 1:52 PM, Pearu Peterson
> wrote:
>>
>> Hi,
>>
>> I have followed Development workflow instructions in
>>
>> http://docs.scipy.org/doc/numpy/dev/g
emotes/origin/master
remotes/origin/ticket1679
remotes/upstream/maintenance/1.0.3.x
remotes/upstream/maintenance/1.1.x
remotes/upstream/maintenance/1.2.x
remotes/upstream/maintenance/1.3.x
remotes/upstream/maintenance/1.4.x
remotes/upstream/maintenance/1.5.x
remotes/upstream/master
. That said, I would try instructions from
http://www.scipy.org/Installing_SciPy/Linux#head-89e1f6afaa3314d98a22c79b063cceee2cc6313c
and may be using some older atlas version.
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ing the stout of 'python setup.py build_ext -i', in case it
> contains useful information.
>
> Would anybody have suggestions with regards to what I am doing wrong?
I could not read the stdout but perhaps you didn't build atlas with
complete lapack.
. I wonder whether this has converged to something that
could be used as reference for git beginners like me.
Thanks and sorry about messing up the history,
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mail
. I wonder whether this has converged to something that
could be used as reference for git beginners like me.
Thanks and sorry about messing up the history,
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mail
gnu95 build
will build a Fortran library flib.a and link it to
an extension module ctest.so. Use build_ext --inplace
if ctest.so should end up in current working directory.
Is that what you wanted to achieve?
HTH,
Pearu
On 10/09/2010 02:18 PM, Ioan Ferencik wrote:
> I would like to compile
are used by f2py.
So, try adding these lines to the Fortran code:
integer, intent(in) :: ts, n
real, dimension(n) :: a
HTH,
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi Mark,
On Mon, Jul 19, 2010 at 11:49 AM, Mark Bakker wrote:
> Thanks for fixing this, Pearu.
> Complex arrays with intent(inout) don't seem to work either.
> They compile, but a problem occurs when calling the routine.
What problem?
> Did you fix that as well?
I gu
ughts on what I am doing wrong?
compilation failed because of typos in the generated code. This is fixed
in svn revision 8478.
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
t with small operands this feature
may be unexpected.
For example, with the same rule the result of int64 + int should be
float64 while currently
it is int64.
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/li
Hi,
I just noticed some weird behavior in operations with uint64 and int,
heres an example:
>>> numpy.uint64(3)+1
4.0
>>> type(numpy.uint64(3)+1)
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail
(newshape)? For example, for resolving the original
problem, one could have
fp = numpy.memmap('test.dat', shape=(10,), mode='w+')
fp = fp.resized(11)
Regards,
Pearu
On Sun, Jun 6, 2010 at 10:19 PM, Pearu Peterson
wrote:
> Hi,
>
> I am creating a rather large file
izing memmap's _mmap attribute
directly:
>>> fp._mmap.resize(11)
>>> fp._mmap.size()
11
but the size of memmap instance remains unchanged:
>>> fp.size
10
Thanks,
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Try renaming GLMnet.f90 to GLMnet.f.
HTH,
Pearu
David Warde-Farley wrote:
> I decided to give wrapping this code a try:
>
> http://morrislab.med.utoronto.ca/~dwf/GLMnet.f90
>
> I'm afraid my Fortran skills are fairly limited, but I do know that
> gfortran compil
Hi,
You are running rather old numpy version (1.0.1).
Try upgrading numpy as at least recent numpy from svn detects
this compiler fine.
Regards,
Pearu
Peter Brady wrote:
> Hello all,
>
> The version of f2py that's installed on our system doesn't appear to
> handle ver
ret[1] = 100.0
return ret
...
>>> output = callbacktest(dV, arr)
in Python dV: V is: [ 2. 4. 6. 8.]
>>> output
array([ 2., 100.,6.,8.])
What problems do you have with implicit none? It works
fine here. Check the format of your source code,
if it is free then use
also returned by the wrapper)
before passing it to Fortran.
Regards,
Pearu
James McEnerney wrote:
> Pearu,
> Thanks. a follow question.
> Using fortran
>
> subroutine calc(j)
> Cf2py intent(callback) pycalc
> external pycalc
> Cf2py integer dimensio
Pearu Peterson wrote:
> Hmm, regarding `intent(in, out) j`, this should work. I'll check what
> is going on..
The `intent(in, out) j` works when pycalc is defined as subroutine:
call pycalc(i, j)
instead of
pyreturn = pycalc(i
`, this should work. I'll check what
is going on..
HTH,
Pearu
James McEnerney wrote:
> While using the call-back feature of f2py I stumbled across what appears
> to be a bug and I'm asking the community to look into this.
>
> Background: I'm in the middle of conver
y
> end subroutine testfun
..
> Is this expected behavior?
No. The bug is now fixed in numpy svn (rev 7712).
Thanks for pointing out this corner case.
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Original Message
Subject: [f2py] ANN: a journal paper about F2PY has been published
Date: Mon, 05 Oct 2009 11:52:20 +0300
From: Pearu Peterson
Reply-To: For users of the f2py program
To: For users of the f2py program
Hi,
A journal paper about F2PY has been published in
On Mon, March 16, 2009 4:05 pm, Sturla Molden wrote:
> On 3/16/2009 9:27 AM, Pearu Peterson wrote:
>
>> If a operation produces new array then the new array should have the
>> storage properties of the lhs operand.
>
> That would not be enough, as 1+a would behave d
der='F')
b = a + 1
instead of
a = zeros(, order='F')
b = a[:]
b += 1
to keep the storage properties in operations.
Regards,
Pearu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
quantity with undefined value. Closer
analysis of a particular case may reveal that it may be some finite number,
or an infinity with some direction, or be intrinsically undefined.
NaN is something that cannot be defined because its value is not unique.
Nothing would be the cont
---
$ f2py -c m.pyf foo.f
$ python
>>> import m
>>> m.foo(30)
---
Traceback (most recent call last)
/home/pearu/test/f2py/exc/ in ()
: a is gt 10
>>&g
as a rule these tasks do not take much of my time.
I have also rewritten f2py users guide
for numpy.f2py and submitted a paper on f2py. I'll make them
available when I get some more time..
Regards,
still-kicking-yoursly,
Pearu
On Thu, July 24, 2008 1:46 am, Fernando Perez wrote:
> Howdy,
&g
On Wed, July 2, 2008 8:25 pm, Robert Kern wrote:
> On Wed, Jul 2, 2008 at 09:01, Alan McIntyre <[EMAIL PROTECTED]>
> wrote:
>> On Wed, Jul 2, 2008 at 9:35 AM, Pearu Peterson <[EMAIL PROTECTED]>
>> wrote:
>>> Alan McIntyre wrote:
>>>> Some test f
estore_path() calls can be removed. (But please do not
remove them from scipy tests files, rebuilding scipy just
takes too much time and debugging subpackages globally would
be too painful).
Pearu
___
Numpy-discussion mailing list
Numpy-discus
ImportError: modulename.so: failed to map segment from shared
> object: Operation not permitted
>
> How can that be fixed ? Any suggestion ?
I don't have ideas what is causing this import error. Try
the instructions above, may be it is due to some compile object
conf
distutils). f2py_options can contain only f2py
specific options.
Hence you should try to modify sys.path
in the beggining of the setup.py file to specify the fortran
compiler options. For example, in setup.py file, insert:
import sys
sys.path.extend('config_fc --fcompiler=intel '.split()
there's still
>> complaints about Defined_Binary_Op not being implemented. If someone
>> more knowledgeable about that module could comment on that I'd
>> appreciate it.
>
> These files were for the in-development g3 version of f2py. That
> development has moved outside
On Tue, May 20, 2008 1:36 pm, Jarrod Millman wrote:
> On Mon, May 19, 2008 at 10:29 PM, Pearu Peterson <[EMAIL PROTECTED]>
> wrote:
>> On Tue, May 20, 2008 1:26 am, Robert Kern wrote:
>>> Is this an important bugfix? If not, can you hold off until 1.1.0 is
>>&g
.
This is nonsense, of course. I can find other similar examples
that have needed attention and changes to numpy.distutils and
numpy.f2py in past and I know that few are coming up.
Pearu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Tue, May 20, 2008 12:03 pm, David Cournapeau wrote:
> Pearu Peterson wrote:
>> f2py changes are never critical to numpy users who do not use f2py.
>>
> No, but they are to scipy users if f2py cannot build scipy.
Well, I know pretty well what f2py features scipy uses and
what
David Cournapeau wrote:
> Pearu Peterson wrote:
>> So I beg to be flexible with f2py related commits for now.
>
> Why not creating a branch for the those changes, and applying only
> critical bug fixes to the trunk ?
How do you define a critical bug? Critical to whom?
f2py
Stéfan van der Walt wrote:
> Hi Pearu
>
> 2008/5/20 Pearu Peterson <[EMAIL PROTECTED]>:
>> CC: numpy-discussion because of other reactions on the subject.
>>
>> On Tue, May 20, 2008 1:26 am, Robert Kern wrote:
>>> Is this an important bugfix? If not, ca
nd maintain it). If the release process
is going to take for weeks and is locking the trunk, may be the
release candidates should live in a separate branch?
Pearu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.
w, but I don't want to touch distutils without being sure it
> won't,
The change should not break anything that already works because
in distutils extension name is assumed to contain names joined with a dot.
If distutils works with / in extension name, then I think it is because
by an
t;
> So open the new branch already.
I am waiting it too. At least, give another time target for 1.1.0.
(ticket 752 has a patch ready and waiting for a commit,
if 1.1.0 is going to wait another few days, the commit to 1.1.0
should be safe).
Pearu
___
commit my work to 1.1.0 at this time, so I shall commit
when trunk is open as 1.1.1.
My question regarding branching: how the changes from 1.1.1 will end up
into 1.2 branch?
Thanks,
Pearu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http:/
r of core developers can be defined as a number of
developers who have ever been owners of numpy tickets.
It seems that the number is less than 10.
Note also that may be only few of them can work full time on numpy.
For adding new features, the patch review system can be reasonable
that f2py is doing (probably) bad
> things that trip these buffer overflow checks. IIRC, Pearu wasn't on
> the f2py mailing list at the time this came up; please try him again.
I was able to reproduce the bug on a debian system. The fix with
a comment on what was causing the bug, is in sv
t' objects
> zsh: exit 1 f2py -c -m hastings hastings.f90 --fcompiler=gnu95
...
> Have you got any clue to solve this pb ?
This issue is fixed in SVN. So, either use numpy from svn,
or wait a bit until numpy 1.0.5 is released, or change th
only give instructions how to do that. Doing the change
automatically requires testing the corresponding support code for many
different platforms and setups - this requires some effort and time..
and most importantly, some volunteers.
Pearu
Jarrod Millman wrote:
> On Wed, Apr 9, 2008 at 6:34 AM
, '')
>
> Should the test be cleaned up and moved into a seperate file in
> numpy/distutils/tests/ ?
Note that not all tests in exec_command.py are platform independent
(as it is the case with most distutils tools in general). So, be careful
when copying the tests to numpy/distutil
Register in the Login page).
Best regards,
Pearu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
g suggests that optional parameters seem otherwise OK.
Yes, f2py is not aware of the present function. Adding present awarness
support is not trivial as it may be compiler dependent (f2py would
need to know what is the value of an optional arguments such that
present wo
David Cournapeau wrote:
> - f2py has been almost entirely rewritten: it can now scan the
> module name automatically, and should be much more reliable.
What do you mean by ^^^? ;)
Pearu
___
Jarrod Millman wrote:
> Our version of split_quoted() was added several years ago and should
> I think be submitted for inclusion upstream. I know that distutils
> isn't exactly being maintained, but--Pearu--is it possible that we
> could get this upstream?
I looked into t
n to C/C++ converters, as well as
generating wrappers for other scripting languages. So, I think
this is something worth of keeping in mind indeed when developing g3
f2py. Although, I would need more support to take this task of
generalizing f2py to f2**.
Regards,
Pearu
___
wonder if a hosting could be provided for f2py? Say, in a
form of f2py.scipy.org or www.f2py.org? I am rather ignorant about these
matters, so any help will be appreciated.
Thanks,
Pearu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http:
On Wed, April 9, 2008 3:25 pm, Jarrod Millman wrote:
> On Wed, Apr 9, 2008 at 4:59 AM, Pearu Peterson <[EMAIL PROTECTED]> wrote:
>> I have fixed it in r4996.
>
> Thanks,
>
>> However, when trying to change the ticked status, I get forbidden
>> error:
>>
On Wed, April 9, 2008 2:13 pm, Jarrod Millman wrote:
> Hey Pearu,
>
> Could you take a quick look at this:
> http://projects.scipy.org/scipy/numpy/ticket/587
I have fixed it in r4996.
However, when trying to change the ticked status, I get forbidden error:
TICKET_APPEND privileges
On Thu, March 27, 2008 7:20 pm, Tom Loredo wrote:
>
> Pearu-
>
>> smll_offset = smll_offset
>> exec `smll_offset.__doc__`
>
> Thanks for the quick and helpful response! I'll give it
> a try. I don't grasp why it works, though. I suppose I don't
>
ut when
> I add them, they don't appear to be used.
This feature is still implemented only partially and not enabled.
When I get more time, I'll finish it..
HTH,
Pearu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
subroutine f1(fpy)
external fpy
call f2(fpy)
call f2(fpy)
end
subroutine f2(fpy)
external fpy
call fpy()
end
If this is something not suitable for your case, then there
exist ways to influence the generated wrapper codes from
signature files
available in
* http://code.google.com/p/sympycore/wiki/Performance
* http://code.google.com/p/sympycore/wiki/PerformanceHistory
and it is our aim to continue seeking for more efficient ways to
manipulate symbolic expressions:
http://cens.ioc.ee/~pearu/sympycore_bench/
Sympycore version
hout having to compile any fortran. I guess I could
> just invoke the linker directly in the case where there are no
> fortran files to compile but is nice being able to use distutils to
> get away from platform dependencies.
Hopefully the hint above works for you.
Pearu
_
gives an hint how to resolve this issue.
Try to use sys.setdlopenflags(...) before importing f2py generated
extension modules and then reset the state using sys.setdlopenflags(0).
See
http://docs.python.org/lib/module-sys.html
for more information how to find proper value for ...
HTH,
Pearu
_
> This works fine on Windows and Mac; the problem only seems to
> happen on Linux:
Can you import flib module directly? That is, what happens if you
execute
cd .../PyMC
PYTHONPATH=. python -c 'import flib'
?
Pearu
___
Numpy-disc
On Mon, February 4, 2008 4:39 pm, Lisandro Dalcin wrote:
> Pearu, now that f2py is part of numpy, I think it would be easier for
> you and also for users to post to the numpy list for f2py-related
> issues. What do you think?
Personaly, I don't have strong opinions on this.
O
1 - 100 of 152 matches
Mail list logo
