On Thu, Jan 6, 2022 at 4:43 PM <alejandro.giacometti@gmail.com> wrote:
Thanks for your answer.
I think i understand it - is it that `f64_info.max - f64_info.min` does not fit in float64? because it approximates `2 * f64_info.max`?
Well, it "fits" into a float64 by becoming `inf`, which is a valid float64 value, just one that has particular consequences. In that case, I agree with Klaus, linspace should be able to handle this?
I don't particularly agree that linspace() ought to add special-case logic to handle this. It would be difficult to write logic that reliably recognizes all the ways that something like this is actually the case and then does something sensible to recover from it. Lev showed how you can manually do something sorta reasonable for `np.linspace(f64_info.min, f64_info.max, num)` because the endpoints are symmetric around 0, but there is nothing that can really be done for the asymmetric case. Floating point arithmetic has its limits, and playing with values near the boundaries is going to make you run into those limits. I would rather have linspace() do something consistent that gives non-useful results in these boundary edge cases than try to do a bunch of different logic in these outer limits. The utility of getting "sensible" results for the extreme results is fairly limited (not least because any downstream computation will also be very likely to generate NaNs and infs), so I would happily trade that to have a more consistent mental model about what linspace() does. -- Robert Kern