The function that I am using for solve_ivp is defined as:
def ydot(t,y,kappa4,kappa16):
Upon using solve_ivp as below:
sol=solve_ivp(ydot,[0,10],initial_condition(),args=(50,100))
I get the following error:
ydot() missing 2 required positional arguments: 'kappa4' and 'kappa16'
I am not able debug the code even though I have defined the function ydot the way scipy documentation for solve_ivp defines (https://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.solve_ivp.html)
There's even an example in the end of the documentation that demonstrates the passing of arguments implemented in the same way as I have done.
I believe the problem is somewhere in the two above pieces of the code I have provided from an otherwise long code.
I was able to replicate the error with scipy 1.1.0 .
Upgrading scipy to the latest version via cmd (pip install scipy==1.4.1) solved that error message for me.
Then the minimal reproducible example gave another error:
TypeError: ydot() argument after * must be an iterable, not int
Which was solved by the solution given by Tejas. The full working minimal script is hence:
from scipy.integrate import solve_ivp
def ydot(t,y,a): return -a*y
sol=solve_ivp(ydot,[0,10],[5],args=(8,))
print(sol.y)
I had faced the same issue recently.
But the great Warren Weckesser
helped me out.
Change
args=(10)
to
args=(10,)
and your MWE will work fine.
This happens because of tuples with a single element.
For reference see pg 30 of Python tutorial pdf (Release 3.5.1) on python.org
Related
My mediapipe version is 0.8.9.1
I have tried redownloading it on a lower version but it doesnt allow me to go past my version.
I am using "PoseModule" code from here: https://www.computervision.zone/lessons/code-files-15/
This is the error i get:
TypeError: create_bool(): incompatible function arguments. The following argument types are supported:
1. (arg0: bool) -> mediapipe.python._framework_bindings.packet.Packet
Invoked with: 0.5
Could anyone help me in fixing the code please?
Most answers i saw are regarding "self.mpHands.Hands".
I heard there is something wrong with the init within class poseDetector but I dont know how to rewrite tho code :/
I have a project with a couple thousand lines of code.
I'm getting this message when it runs:
(e.g. obj[:, None]) is deprecated and will be removed in a future version. Convert to a numpy array before indexing instead. y = y[:, np.newaxis]
The error message doesn't give me any line number to go look at and I have no idea what to look for to try to debug this.
Any suggestions would be appreciated.
One approach is to run Python with -Werror, i.e
python3 -Werror myproj.py
This will cause Python to exit with a full traceback when the warning is triggered.
The same effect can be achieved by setting the PYTHONWARNINGS environment variable to error.
I also encountered this problem when using Python's matplotlib.pyplot library, where I converted the input data from the plot() function to numpy Array, such a warning is not availabled, just for reference.
It seems as though some scipy modules are messing with my warning filters. Consider the following code. My understanding is that it should only throw one warning because of the "once" filter I supplied to my custom Warning class. However, the warning after the scipy import gets shown as well.
This is with python 3.7 and scipy 1.6.3.
import warnings
class W(DeprecationWarning): pass
warnings.simplefilter("once", W)
warnings.warn('warning!', W)
warnings.warn('warning!', W)
from scipy import interpolate
warnings.warn('warning!', W)
This only seems to happen when I import certain scipy modules. A generic "import scipy" doesn't do this.
I've narrowed it down to the filters set in scipy.special.sf_error.py and scipy.sparse.__init__.py. I don't see how that code would cause the problem, but it does. When I comment those filtersout, my code works as expected.
Am I misunderstanding something? Is there a work-around that that doesn't involved overwriting warnings.filterwarnings/warnings.simplefilters?
This an open Python bug: https://bugs.python.org/issue29672.
Note, in particular, the last part of the comment by Tom Aldcroft:
Even a documentation update would be useful. This could explain not only catch_warnings(), but in general the unexpected feature that if any package anywhere in the stack sets a warning filter, then that globally resets whether a warning has been seen before (via the call to _filters_mutated()).
The code in scipy/special/sf_error.py sets a warning filter, and that causes a global reset of which warnings have been seen before. (If you add another call of warnings.warn('warning!', W) to the end of your sample code, you should see that it does not raise a warning.)
I was trying to run the sample code found here:
https://pytorch.org/tutorials/intermediate/torchvision_tutorial.html
I get a crash in the class CocoEvaluator() constructor in coco_eval.py where the following line of code:
for iou_type in iou_types:
self.coco_eval[iou_type] = COCOeval(coco_gt, iouType=iou_type)
will crash with the warning "object of type class 'numpy.float64' cannot be safely interpreted as an integer."
iou_type is a string 'bbox'
COCOeval is a class from pycocotools (pycocotools.cocoeval.COCOeval)
coco_gt is the return value from get_coco_api_from_dataset(data_loader.dataset)
its not clear to me where the numpy.float64 value is being used here, or what I can change to fix this
The problem most likely lies in the numpy version. Numpy version 1.18.+ usually throws this error. However when changing to numpy 1.17.4 the problem is fixed.
as shown here
-> https://github.com/pytorch/vision/issues/1700
-> https://www.kaggle.com/questions-and-answers/90865
#check for version number
np.version.version
#downgrade version
!pip install numpy==1.17.4
This fixed it for me, hope it helps.
I just put together the following "minimum" repro case (minimum in quotes because I wanted to ensure pylint threw no other errors, warnings, hints, or suggestions - meaning there's a bit of boilerplate):
pylint_error.py:
"""
Docstring
"""
import numpy as np
def main():
"""
Main entrypoint
"""
test = np.array([1])
print(test.shape[0])
if __name__ == "__main__":
main()
When I run pylint on this code (pylint pylint_error.py) I get the following output:
$> pylint pylint_error.py
************* Module pylint_error
pylint_error.py:13:10: E1136: Value 'test.shape' is unsubscriptable (unsubscriptable-object)
------------------------------------------------------------------
Your code has been rated at 1.67/10 (previous run: 1.67/10, +0.00)
It claims that test.shape is not subscriptable, even though it quite clearly is. When I run the code it works just fine:
$> python pylint_error.py
1
So what's causing pylint to become confused, and how can I fix it?
Some additional notes:
If I declare test as np.arange(1) the error goes away
If I declare test as np.zeros(1), np.zeros((1)), np.ones(1), or np.ones((1)) the error does not go away
If I declare test as np.full((1), 1) the error goes away
Specifying the type (test: np.ndarray = np.array([1])) does not fix the error
Specifying a dtype (np.array([1], dtype=np.uint8)) does not fix the error
Taking a slice of test (test[:].shape) makes the error go away
My first instinct says that the inconsistent behavior with various NumPY methods (arange vs zeros vs full, etc) suggests it's just a bug in NumPY. However it's possible there's some underlying concept to NumPY that I'm misunderstanding. I'd like to be sure I'm not writing code with undefined behavior that's only working on accident.
I don't have enough reputation to comment, but it looks like this is an open issue: https://github.com/PyCQA/pylint/issues/3139
Until the issue is resolved on their end, I would just change the line to
print(test.shape[0]) # pylint: disable=E1136 # pylint/issues/3139
to my pylintrc file.
As of November 2019:
As mentioned by one of the users in the discussion on GitHub you could resolve the problem by downgrading both pylint and astroid, e.g. in requirements.txt
astroid>=2.0, <2.3
pylint>=2.3, <2.4
or
pip install astroid==2.2.5 & pip install pylint==2.3.1
This was finally fixed with the release of astroid 2.4.0 in May 2020.
https://github.com/PyCQA/pylint/issues/3139