Re: make_lsq_spline and conversion to float
Thomas Hilger <[email protected]> Tue, 26 Oct 2021 16:09:48 +0200
| Newsgroups | gmane.comp.python.scientific.user |
|---|---|
| Message-ID | <CAOOOfF5_B=5zeEouPQxE7DUpAtPsef1g+DqiXrYtMc8hZNjPHw@mail.gmail.com> |
Thanks a lot for the explanation. With this information I am now wondering as well why it became so much slower. I can only guess it is because the problem is a bit nested (~500000 splines) and a lot of things happen in the surroundings. So the problem is somewhere else. Maybe the whole thing got a bit clumsy...and can be structured differently...time to re-think what actually needs to be done. Cheers, Thomas. Am Di., 26. Okt. 2021 um 15:25 Uhr schrieb Evgeni Burovski < [email protected]>: > Hi, > > Several reasons, in fact. First and foremost, linear algebra is > delegated to LAPACK, which only works in floating point. If you're > using integer values so large that the conversion to float64 is lossy, > essentially any integer arithmetics is nearly guaranteed to overflow. > So, the computations should stay in floating-point. There might be a > case for preserving float32 dtypes, but so far no use case was > reported, so it's separate. > > All in all, you're best off shifting and scaling the inputs yourself. > I'm actually surprised why this makes things slow : this is only O(N), > while the linear algebra part should definitely be more costly. > > Cheers, > > Evgeni > > On Tue, Oct 26, 2021 at 9:21 AM Thomas Hilger <[email protected]> > wrote: > > > > Hello, > > > > When using make_lsq_spline(x,y,t) with x being int64, I am running into > the issue that the x-array is internally converted to float. While on an > int64-level the input x-values are ordered, after the internal conversion > to float, an exception is raised, because as a result some of these values > are identical to each other. > > > > I was wondering about the reason for that internal conversion to float > (it seems to reside only in handling complex dtypes or is there some other > mechanism in Cox-de-Bor algorithm or Cholesky?). It is not obvious to me. > > > > Right now I can solve this problem by shifting the x-values, such that > the numbers are smaller and the conversion does not harm this way. However, > this makes things really slow or very unhandy codewise. > > > > Maybe it is feasible to modify _get_dtype a little? > > > > Thanks and cheers, > > Thomas. > > _______________________________________________ > > SciPy-User mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > https://mail.python.org/mailman3/lists/scipy-user.python.org/ > > Member address: [email protected] > _______________________________________________ > SciPy-User mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/scipy-user.python.org/ > Member address: [email protected] > _______________________________________________ SciPy-User mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/scipy-user.python.org/ Member address: [email protected]