This coding is not unique for certain elements. This will cause problems when decoding.

[sgbaird]

When using encode with "mod_pettifor", I'm getting:

2022-08-09 22:06:27.966 | WARNING | element_coder.data.coding_data:get_coding_dict:85 - This coding is not unique for certain elements. This will cause problems when decoding.

Hydrogen is listed as both 1 and 103 (Table 1 of https://dx.doi.org/10.1088/1367-2630/18/9/093011) (among other repeats), but that doesn't seem to be the case with ElMD's implementation (and by extension element-coder's version).

[kjappelbaum]

do you think we should add an encoding with these repeats?

[sgbaird]

Good question, but I'm not sure. I could see that causing many issues and making it less straightforward to use for many applications. I lean towards leaving it as-is currently implemented in element-coder, but maybe @SurgeArrester could comment on the design choice here and provide some insight. I also use essentially the same version as ElMD and element-coder in mat_discover for example.

[SurgeArrester]

Nice project!

I used H at the final index (as with D and T) for the ElMD work using the mod_petti scale. I like the continuity you get when wrapping the linear scale into a never ending cycle, but I think despite the similarities in atomic weight, H and He are dissimilar enough in substitutional feasibility that they can justifiably be placed far away from one another. I would agree with the previous comment, having two integer representations for the same element would probably create more problems than it solves