Bug 379101 - custom fitting fails
Summary: custom fitting fails
Status: RESOLVED WORKSFORME
Alias: None
Product: LabPlot2
Classification: Applications
Component: general (show other bugs)
Version: 2.4.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Stefan Gerlach
URL:
Keywords: investigated, triaged
Depends on:
Blocks:
 
Reported: 2017-04-23 00:39 UTC by Uwe Stöhr
Modified: 2018-09-19 14:28 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
screenshot describing the axes and fit result error (98.16 KB, image/png)
2017-11-25 15:46 UTC, Uwe Stöhr
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Uwe Stöhr 2017-04-23 00:39:33 UTC
- install LP 2.4 under Windows
- create a new spreadsheet and fill 2 columns with row numbers
- create a worksheet
- create there an xy-plot
- add there a xy-curve
- use the menu Analysis -> Data fitting in the spreadsheet
- use a custom fit function, for example "exp(a*x)"

result: the "a" is not recognized as fit variable and does therefore not occur in the parameters list. There I see 2 variables named "c0" and "c1". So one has to add the "a" there manually and delete the "c" parameters. This is time-consuming and annoying. (MagicPlot and Origin recognizes the fit parameters automatically.)
However, 

- use for the parameter "a" as start value "1" and press recalculate

result: one gets this:

a = 1±nan (nan %)

but more severe is that the plot is overlayed with an empty fit. So fitting is just useless because I of course want to see the fit result I the plot.
Comment 1 Stefan Gerlach 2017-04-30 08:56:50 UTC
Finding the fit parameter automatically is not implemented yet. We will care about this.
A result like "1±nan (nan %)" usually means that the fit did not converge and the error could not be estimated. Probably the start value was not chosen well. Can you try a better start value? (I checked it and it works for me)
Please supply the data if it still doe not work.
Comment 2 Uwe Stöhr 2017-11-12 22:41:27 UTC
> the "a" is not recognized as fit variable

This works now in LP 2.5RC2.

> - use for the parameter "a" as start value "1" and press recalculate
> result: one gets this: a = 1±nan (nan %)

This is still the case.
It is clear that the fit did not converge and therefore I expect as user an information like:

"The fit did not converge. Please use a different start value for the parameter 'a'."
Comment 3 Uwe Stöhr 2017-11-25 15:46:14 UTC
Created attachment 109058 [details]
screenshot describing the axes and fit result error

Now the behavior of LabPlot is different. Nevertheless the user does not get the info that the fit did not converge and that he should use different start values.

Moreover, the fit plot is incorrect, see the axes in the attached screenshot.
Comment 4 Uwe Stöhr 2017-11-25 15:46:46 UTC
resetting bug status
Comment 5 Stefan Gerlach 2017-12-06 21:56:15 UTC
Hi,

i uploaded a new package including the latest fixes (also fixing a parser crash on my system) at
https://theorie.physik.uni-konstanz.de/gerlach/labplot/labplot-2.5.0rc3-64bit-setup.exe
There are two problems in your screenshot. The axes currently do not support values bigger than 1e+15. That's already on our TODO list. The second problem is the missing Unicode support in the fit result. I do not have this problem but i am no Windows expert to help here.
Comment 6 Uwe Stöhr 2017-12-08 01:31:38 UTC
> There are two problems in your screenshot. The axes currently do not support values bigger than 1e+15. 

In my opinion that is not a bug but that case that the y-axis has the auto fit option and as you can see this uses internally the values:
-4.30099e+42
3.11822e+43

for the axis min/max. To fix this, LabPlot should limit the max/min value to -1e+15/1e+15 of whatever is a sensible value.

> missing Unicode support in the fit result

Yes, this is only in my build and I haven't yet found out why.
Comment 7 Uwe Stöhr 2017-12-08 01:32:40 UTC
I see that you use Qt 5.9.2. Qt 5.9.3 is available.
Comment 8 Andrew Crouthamel 2018-09-19 14:28:19 UTC
This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change.