2

I am using python 3 and numpy and I am trying to compute an array with np.geomspace. My problem is that the array does not respect the boundaries I want.

For instance I have :

In  : np.geomspace(2.1951999999999994e-08, 1)[0]
Out : 2.1951999999999987e-08

The difference is really small, but I need this array to display an interpolated function, and it raises the error : "ValueError: A value in x_new is below the interpolation range.", because the geomspace array starts before the limit I asked.

This issue is the same when I use logspace :

In [243]: np.logspace(np.log10(2.1951999999999994e-08), 1)[0]
Out[243]: 2.1951999999999987e-08

I don't know if it is a problem of precision with python floats, and I tried to look for a solution without success.

Thanks for your help.

Edit :

Thank you for telling me it is a problem of definition of floats with computers.

But that does not really helps me, because in fact the number I showed as an example came from another computation with a python function, namely :

max(a[0], b[0])

where a and b are two float64 numpy arrays.

So when I do :

np.geomspace(max(a[0], b[0]), 1)[0]

the answer I have is smaller than max(a[0], b[0]). And this is a big issue for plotting my interpolation.

endolith
  • 25,479
  • 34
  • 128
  • 192
Louis
  • 43
  • 5
  • It's probably not obvious: The precision is lost when taking the logarithm. `np.log10(2.1951999999999994e-08)` and `np.log10(2.1951999999999987e-08)` give exactly the same result in 64 bit floating point. – MB-F May 23 '17 at 14:20
  • 1
    I think the fundamental question here is why `np.geomspace(a, b)[0]` is not, in general, identically equal to `a`. This behavior is not simply one of floating point imprecision that we all eventually learn more about than we wish we had to. `geomspace(a, b)`, at least for floating point inputs, *could* be implemented so that the endpoints of the result are always exactly `a` and `b`. That it is not is a numpy implementation detail. Maybe it isn't a bug, but it is a "wart", and a potential "gotcha" that @Louis has encountered. – Warren Weckesser May 23 '17 at 15:11
  • @Louis, it looks like you'll have to do something like `x = np.geomspace(a, b); x[0] = a` to fix your problem. – Warren Weckesser May 23 '17 at 15:24
  • Ok thank you for your help, I will post my question again with a more explicit exemple to ensure that people can see this (apparently my question redirect directly on the other question pointed by Toby Speight and Moses Koledoye). – Louis May 23 '17 at 15:58
  • There's no guarantee that a new question asking "Why does geomspace() act this way?" won't also be closed, because the answer might require reading the minds of the numpy developers. At best, the answer you get will point you to the [source code for `geomspace()`](https://github.com/numpy/numpy/blob/9aff656065f2749b83abf127472cafc28e235222/numpy/core/function_base.py#L230) to show how it does what it does. A better use of your time could be to create an issue over at [numpy's github repository](https://github.com/numpy/numpy). – Warren Weckesser May 23 '17 at 16:09
  • Yes, maybe you're right :) Thank you ! – Louis May 23 '17 at 16:15
  • @WarrenWeckesser "might require reading the minds of the numpy developers" [I wrote it](https://github.com/numpy/numpy/pull/7268) and the answer is "I didn't think of it". *Should* it special-case the first value to make it exactly equal to the input? I wanted to special-case it for integers, but other people disagreed. – endolith Jun 24 '17 at 03:58

0 Answers0