After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 616068 - Normality Plot
Normality Plot
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Charting
git master
Other Linux
: Normal normal
: ---
Assigned To: Jean Bréfort
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2010-04-18 05:59 UTC by Andreas J. Guelzow
Modified: 2010-04-23 11:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sample file (39.73 KB, application/x-gnumeric)
2010-04-18 05:59 UTC, Andreas J. Guelzow
  Details
Proposed patch (5.92 KB, patch)
2010-04-19 20:18 UTC, Jean Bréfort
committed Details | Review

Description Andreas J. Guelzow 2010-04-18 05:59:45 UTC
Created attachment 158996 [details]
sample file

In the attached sampole file we have an area of data A1:K9.

I performed an normality test on the data in that area (keeping the area as a single data set of 99 values.) TH etool also creates a normality plot. In that plot the series1 is A1to K9.

Problem: the normality only uses the data in A1:K1 ignoring most of it.
Comment 1 Jean Bréfort 2010-04-18 06:04:59 UTC
Gnumeric only accepts series consisting of just one column or one row. This is not specific to the normality plot.
Comment 2 Jean Bréfort 2010-04-18 06:29:07 UTC
I can think of two ways to fix that:
- extend GnmGODataVector so that it can accept rectangular ranges instead of just one row or one column
- create a new data type (GODataRange/GnmGODataRange or so).

The first option would allow all plots to use nxm data series, do we want that?
The second one actually creates another vector type, so it looks quite weird, imho.

Anyway, boxplots and histograms (if we implement histograms using raw data instead of populations, which I'm currently considering to implement) should accept n x m series as well.
Comment 3 Andreas J. Guelzow 2010-04-18 06:50:49 UTC
some plots use ordered data so a rectangular field may not be appropriate, others use unordered data where we definitely should allow for rectangular areas.

I thin kI would vote for the first option. Perhaps we could aloow for specification of using row or column major ordering if appropriate.
Comment 4 Jean Bréfort 2010-04-18 16:39:12 UTC
I have no idea how we might specify  the row/column priority. I think we'll have to rely on some automagic choice like the existing vec->as_col = (h > w).
It might be time to consider supporting multiple selection in graph vector data.
Comment 5 Jean Bréfort 2010-04-19 20:18:06 UTC
Created attachment 159109 [details] [review]
Proposed patch

Also implements multiple selection for vector data.
Comment 6 Jean Bréfort 2010-04-19 20:20:25 UTC
With the patch, ranges are scanned row by row since it uses sheet_foreach_cell_in_range.
Comment 7 Jean Bréfort 2010-04-23 11:28:08 UTC
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.