### ODE how to?

2014-10-27 16:49:40 GMT

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion <at> scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

27 Oct 17:49 2014

Vincent Davis <vincent <at> vincentdavis.net>

2014-10-27 16:49:40 GMT

2014-10-27 16:49:40 GMT

It's been too long since I have done differential equations and I am not sure the best tools to solve this problem.

I am starting with a basic kinematic equation for the balance of forces.

P\v - ((A*Cw*Rho*v^2)/2 + m*g*Crl + m*g*slope) = m*a

P: power

x: position

v: velocity, x'

a: acceleration x"

(A*Cw*Rho*v^2)/2 : air resistance

m*g*Crl : rolling resistance

m*g*slope : potential energy (elevation)

I am modifying the above equation so that air velocity and slope are dependant on location x.

Vair = v + f(x) where f(x) is the weather component and a function of location x.

Same goes for slope, slope = g(x)

Power is a function I what to optimize/find to minimize time but at this time just simulate. maybe something like:

P = 2500/(v+1)

I will have restriction on P but not interested in that now.

The "course" I what to simulate therefore defines slope and wind speed. and is of a fixed distance.

I have played with some of the simple scipy.integrate.odeint examples. I get that I need to define a system of equations but am not really sure the rules for doing so. A little help would be greatly appreciated.

Vincent Davis

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion <at> scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

27 Oct 16:56 2014

Edison Gustavo Muenz <edisongustavo <at> gmail.com>

2014-10-27 15:56:26 GMT

2014-10-27 15:56:26 GMT

I’ve implemented support for numpy.arrays for the arguments of numpy.testing.assert_approx_equal() and have issued a pull-request on Github.

I don’t know if I should be sending the message to the list to notify about this, but since I’m new to the numpy-dev list I think it never hurts to say hi :)

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion <at> scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

27 Oct 16:06 2014

Glen Mabey <gmabey <at> swri.org>

2014-10-27 15:06:27 GMT

2014-10-27 15:06:27 GMT

Hello, I was very excited to learn about numpy.i for easy numpy+swigification of C code -- it's really handy. Knowing that swig wraps C code, I wasn't too surprised that there was the issue with complex data types (as described at http://docs.scipy.org/doc/numpy/reference/swig.interface-file.html#other-common-types-complex), but still it was pretty disappointing because most of my data is complex, and I'm invoking methods written to use C++'s std::complex class. After quite a bit of puzzling and not much help from previous mailing list posts, I created this very brief but very useful file, which I call numpy_std_complex.i -- /* -*- C -*- (not really, but good for syntax highlighting) */ #ifdef SWIGPYTHON %include "numpy.i" %include <std_complex.i> %numpy_typemaps(std::complex<float>, NPY_CFLOAT , int) %numpy_typemaps(std::complex<double>, NPY_CDOUBLE, int) #endif /* SWIGPYTHON */ I'd really like for this to be included alongside numpy.i -- but maybe I overestimate the number of numpy users who use complex data (let your voice be heard!) and who also end up using std::complex in C++ land. Or if anyone wants to improve upon this usage I would be very happy to hear about what I'm missing. I'm sure there's a documented way to submit this file to the git repo, but let me simultaneously ask whether list subscribers think this is worthwhile and ask someone to add+push it for me … Thanks, Glen Mabey

27 Oct 14:26 2014

D. Michael McFarland <dmmcf <at> dmmcf.net>

2014-10-27 13:26:58 GMT

2014-10-27 13:26:58 GMT

A recent post raised a question about differences in results obtained with numpy.linalg.eigh() and scipy.linalg.eigh(), documented at http://docs.scipy.org/doc/numpy/reference/generated/numpy.linalg.eigh.html#numpy.linalg.eigh and http://docs.scipy.org/doc/scipy/reference/generated/scipy.linalg.eigh.html#scipy.linalg.eigh, respectively. It is clear that these functions address different mathematical problems (among other things, the SciPy routine can solve the generalized as well as standard eigenproblems); I am not concerned here with numerical differences in the results for problems both should be able to solve (the author of the original post received useful replies in that thread). What I would like to ask about is the situation this illustrates, where both NumPy and SciPy provide similar functionality (sometimes identical, to judge by the documentation). Is there some guidance on which is to be preferred? I could argue that using only NumPy when possible avoids unnecessary dependence on SciPy in some code, or that using SciPy consistently makes for a single interface and so is less error prone. Is there a rule of thumb for cases where SciPy names shadow NumPy names? I've used Python for a long time, but have only recently returned to doing serious numerical work with it. The tools are very much improved, but sometimes, like now, I feel I'm missing the obvious. I would appreciate pointers to any relevant documentation, or just a summary of conventional wisdom on the topic. Regards, Michael

27 Oct 13:14 2014

Neal Becker <ndbecker2 <at> gmail.com>

2014-10-27 12:14:57 GMT

2014-10-27 12:14:57 GMT

The multi-dimensional c++ stuff is interesting (about time!) http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3851.pdf -- -- -- Those who don't understand recursion are doomed to repeat it

27 Oct 09:37 2014

Sunghwan Choi <sunghwanchoi91 <at> gmail.com>

2014-10-27 08:37:58 GMT

2014-10-27 08:37:58 GMT

Dear all,

I am now diagonalizing a 200-by-200 symmetric matrix. But the two methods, scipy.linalg.eigh and numpy.linalg.eigh give significantly different result. The results from two methods are different within 10^-4 order. One of them is inaccurate or both two of them are inaccurate within that range. Which one is more accurate? or Are there any ways to control the accuracy for diagonalization? If you have some idea please let me know.

Sunghwan Choi

Ph. D. candidator

Department of Chemistry

KAIST (South Korea)

26 Oct 19:40 2014

RayS <rays <at> blue-cove.com>

2014-10-26 18:40:52 GMT

2014-10-26 18:40:52 GMT

At 06:32 AM 10/26/2014, you wrote:

Seems to me that loadtxt()

http://docs.scipy.org/doc/numpy/reference/generated/numpy.loadtxt.html

should have an optional shape. I often know how many rows I have (# of samples of data) from other meta data.

Then:

- if the file is smaller for some reason (you're not sure and pad your estimate) it could do one of

- zero pad array

- raise()

- return truncated view

- if larger

- raise()

- return data read (this would act like fileObject.read( size ) )

- Ray S

On Sun, Oct 26, 2014 at 1:21 PM, Eelco Hoogendoorn

<hoogendoorn.eelco <at> gmail.com> wrote:

> Im not sure why the memory doubling is necessary. Isnt it possible to

> preallocate the arrays and write to them?

Not without reading the whole file first to know how many rows to preallocate

Seems to me that loadtxt()

http://docs.scipy.org/doc/numpy/reference/generated/numpy.loadtxt.html

should have an optional shape. I often know how many rows I have (# of samples of data) from other meta data.

Then:

- if the file is smaller for some reason (you're not sure and pad your estimate) it could do one of

- zero pad array

- raise()

- return truncated view

- if larger

- raise()

- return data read (this would act like fileObject.read( size ) )

- Ray S

26 Oct 18:13 2014

Julian Taylor <jtaylor.debian <at> googlemail.com>

2014-10-26 17:13:03 GMT

2014-10-26 17:13:03 GMT

Hi, We have finally finished the first release candidate of NumOy 1.9.1, sorry for the week delay. The 1.9.1 release will as usual be a bugfix only release to the 1.9.x series. The tarballs and win32 binaries are available on sourceforge: https://sourceforge.net/projects/numpy/files/NumPy/1.9.1rc1/ If no regressions show up the final release is planned next week. The upgrade is recommended for all users of the 1.9.x series. Following issues have been fixed: * gh-5184: restore linear edge behaviour of gradient to as it was in < 1.9. The second order behaviour is available via the `edge_order` keyword * gh-4007: workaround Accelerate sgemv crash on OSX 10.9 * gh-5100: restore object dtype inference from iterable objects without `len()` * gh-5163: avoid gcc-4.1.2 (red hat 5) miscompilation causing a crash * gh-5138: fix nanmedian on arrays containing inf * gh-5203: copy inherited masks in MaskedArray.__array_finalize__ * gh-2317: genfromtxt did not handle filling_values=0 correctly * gh-5067: restore api of npy_PyFile_DupClose in python2 * gh-5063: cannot convert invalid sequence index to tuple * gh-5082: Segmentation fault with argmin() on unicode arrays * gh-5095: don't propagate subtypes from np.where * gh-5104: np.inner segfaults with SciPy's sparse matrices * gh-5136: Import dummy_threading if importing threading fails * gh-5148: Make numpy import when run with Python flag '-OO' * gh-5147: Einsum double contraction in particular order causes ValueError * gh-479: Make f2py work with intent(in out) * gh-5170: Make python2 .npy files readable in python3 * gh-5027: Use 'll' as the default length specifier for long long * gh-4896: fix build error with MSVC 2013 caused by C99 complex support * gh-4465: Make PyArray_PutTo respect writeable flag * gh-5225: fix crash when using arange on datetime without dtype set * gh-5231: fix build in c99 mode Source tarballs, windows installers and release notes can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.9.1rc1/ Cheers, Julian Taylor

26 Oct 10:09 2014

Artur Bercik <vbubbly21 <at> gmail.com>

2014-10-26 09:09:32 GMT

2014-10-26 09:09:32 GMT

I have a rectangle with the following coordinates:

ulx,uly = (110, 60) ##uppper left lon, upper left lat

urx,ury = (120, 60) ##uppper right lon, upper right lat

lrx, lry = (120, 50) ##lower right lon, lower right lat

llx, lly = (110, 50) ##lower left lon, lower left lat

I want to divide that single rectangle into 100 regular grids inside that, and want to calculate the (ulx, uly), (urx,ury), (lrx, lry), and (llx, lly) for each grid separately:

lats = np.linspace(60, 50, 10)

lons = np.linspace(110, 120, 10)

lats = np.repeat(lats,10).reshape(10,10)

lons = np.tile(lons,10).reshape(10,10)

I could not imagine what to do then?

Is somebody familiar with such kind of problem?

import numpy as np

ulx,uly = (110, 60) ##uppper left lon, upper left lat

urx,ury = (120, 60) ##uppper right lon, upper right lat

lrx, lry = (120, 50) ##lower right lon, lower right lat

llx, lly = (110, 50) ##lower left lon, lower left lat

I want to divide that single rectangle into 100 regular grids inside that, and want to calculate the (ulx, uly), (urx,ury), (lrx, lry), and (llx, lly) for each grid separately:

lats = np.linspace(60, 50, 10)

lons = np.linspace(110, 120, 10)

lats = np.repeat(lats,10).reshape(10,10)

lons = np.tile(lons,10).reshape(10,10)

I could not imagine what to do then?

Is somebody familiar with such kind of problem?

26 Oct 09:46 2014

Saullo Castro <saullogiovani <at> gmail.com>

2014-10-26 08:46:48 GMT

2014-10-26 08:46:48 GMT

I would like to start working on a memory efficient alternative for np.loadtxt and np.genfromtxt that uses arrays instead of lists to store the data while the file iterator is exhausted.

The motivation came from this SO question:

where for huge arrays the current NumPy ASCII readers are really slow and require ~6 times more memory. This case I tested with Pandas' read_csv() and it required 2 times more memory.

I would be glad if you could share your experience on this matter.

Greetings,

Saullo

25 Oct 03:04 2014

Matthew Brett <matthew.brett <at> gmail.com>

2014-10-25 01:04:47 GMT

2014-10-25 01:04:47 GMT

Hi, We (dipy developers) have a hit a new problem trying to use the ``npy_log`` C function in our code. Specifically, on Linux, but not on Mac or Windows, we are getting errors of form: ImportError: /path/to/extension/distances.cpython-34m.so: undefined symbol: npy_log2 when compiling something like: <eg_log.pyx> import numpy as np cimport numpy as cnp cdef extern from "numpy/npy_math.h" nogil: double npy_log(double x) def use_log(double val): return npy_log(val) </eg_log.pyx> See : https://github.com/matthew-brett/mincy/tree/npy_log_example for a self-contained example that replicates the failure with ``make``. I guess this means that the code referred to by ``npy_log`` is not on the ordinary runtime path on Linux? What should I do next to debug? Thanks a lot, Matthew

Group

Advertisement

Project Web Page

Search Archive

Page

November 2014

Language

Options

Current view:
Threads only / Showing
whole messages /
Not hiding cited text.

Change to All messages, shortened messages, or hide cited text.

Post a message

NNTP Newsgroup

Classic Gmane web interface

RSS Feed

List Information

About Gmane

Change to All messages, shortened messages, or hide cited text.

Post a message

NNTP Newsgroup

Classic Gmane web interface

RSS Feed

List Information

About Gmane

Recent entries

ANN: Scipy 0.15.0 beta 1 release (24 Nov 00:13)

ANN: First release of combi, a combinatorics package for Python (22 Nov 20:39)

return type from ufuncs (20 Nov 18:47)

Problem with _dotblas.pyd when using Matplotlib for 3d plot (19 Nov 17:06)

Numpy 1.9.1, zeros and alignement (18 Nov 19:20)

Initializing array from buffer (16 Nov 18:42)

Fwd: numpy.i and std::complex (14 Nov 20:06)

#2522 numpy.diff fails on unsigned integers (13 Nov 08:10)

truthiness of object arrays (11 Nov 21:46)

Subscribing to mailinglist not possible / sites down (12 Nov 11:30)

FFT of 2D array along last axis (6 Nov 23:51)

median filtering a masked array (5 Nov 19:11)

#2522 numpy.diff fails on unsigned integers (4 Nov 14:50)

Guidance to start contribution to Numpy (2 Nov 19:21)

np.float64 * Python list vs np.float64 + Python list (1 Nov 19:28)

help using np.einsum for stacked matrix multiplication (29 Oct 10:39)

Deprecate pkgload, PackageLoader (29 Oct 05:30)

Why ndarray provides four ways to flatten? (28 Oct 17:58)

FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy funct (28 Oct 05:28)

Why ndarray provides four ways to flatten? (28 Oct 01:06)

ODE how to? (27 Oct 17:49)

ANN: First release of combi, a combinatorics package for Python (22 Nov 20:39)

return type from ufuncs (20 Nov 18:47)

Problem with _dotblas.pyd when using Matplotlib for 3d plot (19 Nov 17:06)

Numpy 1.9.1, zeros and alignement (18 Nov 19:20)

Initializing array from buffer (16 Nov 18:42)

Fwd: numpy.i and std::complex (14 Nov 20:06)

#2522 numpy.diff fails on unsigned integers (13 Nov 08:10)

truthiness of object arrays (11 Nov 21:46)

Subscribing to mailinglist not possible / sites down (12 Nov 11:30)

FFT of 2D array along last axis (6 Nov 23:51)

median filtering a masked array (5 Nov 19:11)

#2522 numpy.diff fails on unsigned integers (4 Nov 14:50)

Guidance to start contribution to Numpy (2 Nov 19:21)

np.float64 * Python list vs np.float64 + Python list (1 Nov 19:28)

help using np.einsum for stacked matrix multiplication (29 Oct 10:39)

Deprecate pkgload, PackageLoader (29 Oct 05:30)

Why ndarray provides four ways to flatten? (28 Oct 17:58)

FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy funct (28 Oct 05:28)

Why ndarray provides four ways to flatten? (28 Oct 01:06)

ODE how to? (27 Oct 17:49)

Archives

78 | |
---|---|

337 | |

229 | |

206 | |

435 | |

163 | |

117 | |

325 | |

484 | |

470 | |

273 | |

149 | |

183 | |

328 | |

318 | |

240 | |

269 | |

309 | |

325 | |

412 | |

346 | |

335 | |

402 | |

289 | |

313 | |

240 | |

302 | |

229 | |

444 | |

519 | |

570 | |

480 | |

455 | |

987 | |

366 | |

399 | |

258 | |

478 | |

282 | |

418 | |

540 | |

835 | |

372 | |

345 | |

732 | |

330 | |

360 | |

262 | |

467 | |

626 | |

505 | |

492 | |

796 | |

579 | |

447 | |

509 | |

646 | |

848 | |

458 | |

679 | |

745 | |

505 | |

913 | |

608 | |

594 | |

842 | |

590 | |

665 | |

897 | |

681 | |

587 | |

504 | |

532 | |

557 | |

778 | |

758 | |

1019 | |

620 | |

1244 | |

1110 | |

620 | |

551 | |

672 | |

317 | |

398 | |

391 | |

293 | |

319 | |

351 | |

282 | |

504 | |

617 | |

720 | |

435 | |

594 | |

361 | |

500 | |

873 | |

530 | |

636 | |

803 | |

664 | |

436 | |

543 | |

584 | |

673 | |

439 | |

61 | |

118 | |

145 | |

65 | |

56 | |

120 | |

58 | |

78 | |

205 | |

295 | |

318 | |

185 | |

60 | |

55 | |

131 | |

75 | |

84 | |

150 | |

149 | |

72 | |

49 | |

70 | |

75 | |

110 | |

71 | |

83 | |

61 | |

107 | |

24 | |

48 | |

12 | |

75 | |

6 | |

42 | |

72 | |

110 | |

104 | |

23 | |

36 | |

59 | |

34 | |

36 | |

123 | |

34 | |

62 | |

126 | |

37 | |

72 | |

54 | |

81 | |

33 | |

56 | |

92 | |

52 | |

33 | |

50 | |

67 | |

42 | |

54 | |

56 | |

24 | |

32 | |

60 | |

44 | |

16 | |

16 | |

28 | |

37 | |

28 | |

48 | |

49 | |

8 |

Design

Your Own Design

Paste the URL of your CSS below.
Download CSS template