| Summary: | Kalzium 'Plot Data' treats missing values as if equal to zero | ||
|---|---|---|---|
| Product: | [Applications] kalzium | Reporter: | Vincent A. Patrick <vap> |
| Component: | general | Assignee: | Kalzium Developers <kalzium> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Vincent A. Patrick
2006-01-15 03:42:57 UTC
Thanks Vincent for the ovations :) The question which comes to my mind here is whether the line (if you connect the points) should - just stop and skip the missing value (this would create a gap) or - connect the elements left and right of the missing value. From a programmers point of view the second solution should be easier to do but from a users point of view I think the first is better... Either approach is better than the current plot. As you say, skipping the missing value would be the ideal. Some of the data points will probably never be obtained satisfactorily, such as the density of francium. This makes me wonder whether it might be worthwhile to place in *estimates* as points of a different colour/shape. For example, an approximation of the density for francium is 2.0 g.cm-3, and an approximation for the density of astatine is 7.5 g.cm-3. Incidentally, the boiling point of polonium appears to be 1235 K. Would it be any help if I looked up some of the other values such as atomic radii in various reference books, or is that being taken care of? About looking up data: Please check if the data is in http://www.blueobelisk.org/repos/blueobelisk/ (for density, in density.txt and so on). Kalzium in trunk (KDE4) switched to BlueObelisk as datarepository. And of course every new dataset it really welcome! If you give me a dataset/value please also give me the reference About the approximation: I doubt this will work. Not even the atomic mass is incresing with each element (for example between element 18 and 19 it is reduced by ~1g). Furthermore there are certain borders after which things change (half full orbits, full orbits and so on) so that there are "jumps" in the values. Hi Carsten, Thanks for the information about the BlueObelisk repository. I will have a look in the next few days and see if I can provide some additional information. About the estimates, if the programming were not too difficult to include a second type of data point, then it would be useful to include the points for completeness and as a learning aid. There are periodic trends which allow a reasonable prediction of many properties, at least within broad bounds. If you don't like the idea, that's fine by me, too. > About the estimates, if the programming were not too difficult to > include a second type of data point, then it would be useful to include > the points for completeness and as a learning aid. Sorry, what do you mean by "second type of date point"? In Kalzium4, we will also have the errormargin (weight of Element Foo = 1234.5u +/- 0.04u and so on). Like that? > There are periodic > trends which allow a reasonable prediction of many properties, at least > within broad bounds. If you don't like the idea, that's fine by me, too. Well, if you tell me how and if possible also give me the code ;-) Error margins in the future too - wow! By a 'second type of data point' I meant a different coloured point which indicated data that had not been actually measured, but was a broad estimate based on periodic trends. I was not suggesting that Kalzium use mathematically derived estimates for unknown data, but that it could use human-derived expectations for each unknown data point. For example, Kalzium might indicate 7.5 (or perhaps 7.0) as the predicted density for astatine. Sometimes unmeasured estimates are available on the web, or a chemist can make a predicted estimate. On the other hand, please disregard this notion if it is too messy or time consuming to place separate, visually distinct, points on the graph in this way. I am still not sure how to handle this "issue"... The problem is that I cannot simple skip all elements with a value of 0.0 because 0.0 can be a valid value (like for EN)... SVN commit 899243 by cniehaus: Fixing bug 120150. Now the plotting widget doesn't show unknown values as valid values. No string changes, but for KDE 4.3 the handbook should tell the user about this. Patch by Kashyap Puranik and Vinayi Hegde. Thanks! BUG:120150 M +69 -29 elementdataviewer.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=899243 |