By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,908 Members | 1,751 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,908 IT Pros & Developers. It's quick & easy.

"bad argument type for built-in operation"

P: n/a
Hello,

I've got a nasty bug and no idea to deal with :

here is the method :
<method>
def denormer(self, var) :
" denorme un vecteur d'entree "
try:
#a = map(self.decerner, self.param, var)
#a = [self.decerner(x, y) for x, y in map(None,
self.param, var)]
a = []
print 'in', None, self.param, var, len(self.param),
len(var), str(self.decerner)
#return map(undoc, self.param, var)
print map(None, var)
print map(None, self.param)
#print zip(var, var)
#print zip(self.param, self.param)
#print map(lambda x, y: (x,y), self.param, var)
#print zip(self.param, var)
b = []
print '$',
ii = range(len(var))
print ii, '$',
for i in ii :
print '%',
b.append((self.param[i], var[i]))
print b, '/',
print '$',
print b
for x,y in b :
print x, y
z = undoc(x, y)
print z
a.append(z)
except TypeError, c :
print 'E', str(self.decerner), self.param, var
print 'E2', str(c)
raise
return a
</method>
in fact the method was initially reduce to
<method>
return map(self.decerner, self.param, var)
</method>
all the commented line produced the same exception raised

this method unnormalize an input vector (var)

and the trace
<trace>
in None [(-2.0, 2.0), (-2.0, 2.0)] [0.1385039192456847,
0.87787941093093491] 2 2 <function undo at 0x81ff94c>
[0.1385039192456847, 0.87787941093093491]
[(-2.0, 2.0), (-2.0, 2.0)]
$ [0, 1] $ % [((-2.0, 2.0), 0.1385039192456847)] / % [((-2.0,
2.0), 0.1385039192456847), ((-2.0, 2.0), 0.87787941093093491)] / $
[((-2.0, 2.0), 0.1385039192456847), ((-2.0, 2.0),
0.87787941093093491)]
(-2.0, 2.0) 0.138503919246
% 0.277007838491
(-2.0, 2.0) 0.877879410931
% 1.75575882186
in None [(-2.0, 2.0), (-2.0, 2.0)] [0.38111874838950943,
0.74880175070169164] 2
2 <function undo at 0x81ff94c>
[0.38111874838950943, 0.74880175070169164]
[(-2.0, 2.0), (-2.0, 2.0)]
$ [0, 1] $ % [((-2.0, 2.0), 0.38111874838950943)] / % [((-2.0,
2.0), 0.38111874838950943), ((-2.0, 2.0), 0.74880175070169164)] /
E <function undo at 0x81ff94c>
[(-2.0, 2.0), (-2.0, 2.0)] [0.38111874838950943, 0.74880175070169164]
E2 bad argument type for built-in operation

[...]
</trace>

the first call of the methode succeed
all following call failed.

I've got different scenario which call this low level methode,
many succeed, some failed this way.

what's happened ?
If someone got an idea ?
what can raise this exception ?

My program is written partially in python and partially in C.
the top level is in python which call a C optimisation routine
which use a callback (PyObject_CallMethod) to evaluate the cost in
python again.
Jul 18 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a

Gilles Arnaud wrote:
Hello,

I've got a nasty bug and no idea to deal with :

here is the method :
Big snip. The Python code is unlikely to be your problem.
and the trace
<trace>
in None [(-2.0, 2.0), (-2.0, 2.0)] [0.1385039192456847,
0.87787941093093491] 2 2 <function undo at 0x81ff94c>
[0.1385039192456847, 0.87787941093093491]
That's a very mangled trace!
the first call of the methode succeed
all following call failed.
So the first call is leaving a bomb behind.

I've got different scenario which call this low level methode,
many succeed, some failed this way.

what's happened ?
If someone got an idea ?
what can raise this exception ?
At this stage, without the benefit of look-ahead, one could only blame
gamma rays or pointy-eared aliens :-)

My program is written partially in python and partially in C.
the top level is in python which call a C optimisation routine
which use a callback (PyObject_CallMethod) to evaluate the cost in
python again.


Aha! *Now* you tell us. *You* have "denormalised" the stack. Read your
C code carefully. Use a debugger, or put some "printf()" in it. With
PyObject_CallMethod, do the format descriptors and the arguments match?
Are you testing the returned value for NULL and acting accordingly? Is
the called-from-C Python method ever executed? Try putting a print
statement (that shows the args) at the top. More generally, are you
testing the returned value from each and every C API call? Are you
testing for the correct error value (some return NULL, some -1, ...)?
Are you doing the right thing on error?

A catalogue of the different ways of messing things up using C would
take forever to write. If you can't find your problem, post the code,
either on the newsgroup or as a web page.

Hope this helps,
John

Jul 18 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.