Bug 120150 - Kalzium 'Plot Data' treats missing values as if equal to zero
Summary: Kalzium 'Plot Data' treats missing values as if equal to zero
Status: RESOLVED FIXED
Alias: None
Product: kalzium
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Kalzium Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-15 03:42 UTC by Vincent A. Patrick
Modified: 2008-12-20 13:39 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent A. Patrick 2006-01-15 03:42:57 UTC
Version:           1.4.2 (using KDE 3.5.0, Debian Package 4:3.5.0-3 (testing/unstable))
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.14-1-k7

The 'Plot Data' tool in Kalzium contains quite a few points which are zero. If this is because of a lack of information, it would be better to ignore the missing points, rather than plot them as zero. Here are some examples where the problem occurs: the densities of astatine and francium are given as zero; the boiling point of polonium is given as zero; the atomic radii of all elements from praseodymium to tungsten (and several others) are plotted as zero; the covalent radii of several elements are plotted as zero.

By the way, please accept a standing ovation for Kalzium!

- Vincent Patrick
Comment 1 Carsten Niehaus 2006-01-15 10:54:28 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...
Comment 2 Vincent A. Patrick 2006-01-15 13:38:47 UTC
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?
Comment 3 Carsten Niehaus 2006-01-15 14:28:31 UTC
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
Comment 4 Carsten Niehaus 2006-01-15 14:30:42 UTC
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.
Comment 5 Vincent A. Patrick 2006-01-15 17:00:21 UTC
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.
Comment 6 cniehaus 2006-01-15 17:19:23 UTC
> 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 ;-)
Comment 7 Vincent A. Patrick 2006-01-16 01:09:44 UTC
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.
Comment 8 Carsten Niehaus 2008-08-05 20:35:56 UTC
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)...
Comment 9 cniehaus 2008-12-20 13:39:18 UTC
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