switch to scientific notation when frequencies can't be displayed as decimals

[alexlancaster]

No description provided.

[sjmack]

Some of the examples have non-standard allele names, like 02:025 and 03:012. I think it would be used to use "real world" examples for tests like these to avoid confusion downstream, e.g., 02:125 and 03:212.

However, in general, this looks great. I doubt that we're going to see/need to care about anything with a frequency approaching X*10^-9 (unless you've really increased the 2N capacity), so this looks good.

[alexlancaster]

Some of the examples have non-standard allele names, like 02:025 and 03:012. I think it would be used to use "real world" examples for tests like these to avoid confusion downstream, e.g., 02:125 and 03:212.

I think most of those derive from the various original synthetic files you generated with the USAFEL and BIGDAWG prefixes. We could fix them by changing the specific alleles globally in the .pop and unit test output.

But functionally, they work. Except for the files that are "included" in the documentation and run as unit tests, they aren't really officially documented examples. But I take your point that it's a good idea for those examples to be real as possible, without being any actual individuals - and we do mention the availability of unit tests serving as templates, in our paper.

However, in general, this looks great. I doubt that we're going to see/need to care about anything with a frequency approaching X*10^-9 (unless you've really increased the 2N capacity), so this looks good.

Yes, and it would still handle that case. Could you click the "review" button on this PR, and "approve"? Then I can think about the merge timing.

[alexlancaster]

@sjmack do you think this is a big enough change to warrant making this next release a 1.1.0 (i.e. incrementing the "minor" version number), or could it be part of the next "patch" release 1.0.1?

I'm trying to follow "semantic versioning": https://semver.org/ which defines:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

I'm not 100% clear about whether this might be considered "bug fix" (incorrectly rounded ) or added functionality (more precision is now shown)? I'm leaning towards the patch (1.0.1) release.

[rsingle]

Given the 3 options I would say patch Rich

…

Sent from my iPhone On Feb 8, 2024, at 5:28 PM, Alex Lancaster ***@***.***> wrote:  @sjmack<https://github.com/sjmack> do you think this is a big enough change to warrant making this next release a 1.1.0 (i.e. incrementing the "minor" version number), or could it be part of the next "patch" release 1.0.1? I'm trying to follow "semantic versioning": https://semver.org/ which defines: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. I'm not 100% clear about whether this might be considered "bug fix" (incorrectly rounded ) or added functionality (more precision is now shown)? I'm leaning towards the patch (1.0.1) release. — Reply to this email directly, view it on GitHub<#192 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABLUS4WX7253DTCMVZYP4BDYSVGLNAVCNFSM6AAAAABC5MVDIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZVGAZTEMRUGE>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sjmack]

I agree. Seems like a minor change *at best*, but it is not particularly extensive.

…

On Feb 9, 2024, at 5:42 AM, rsingle ***@***.***> wrote: This Message Is From an External Sender This message came from outside your organization. Given the 3 options I would say patch Rich Sent from my iPhone On Feb 8, 2024, at 5:28 PM, Alex Lancaster ***@***.***> wrote:  @sjmack<https://github.com/sjmack> do you think this is a big enough change to warrant making this next release a 1.1.0 (i.e. incrementing the "minor" version number), or could it be part of the next "patch" release 1.0.1? I'm trying to follow "semantic versioning": https://semver.org/ which defines: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. I'm not 100% clear about whether this might be considered "bug fix" (incorrectly rounded ) or added functionality (more precision is now shown)? I'm leaning towards the patch (1.0.1) release. — Reply to this email directly, view it on GitHub<#192 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABLUS4WX7253DTCMVZYP4BDYSVGLNAVCNFSM6AAAAABC5MVDIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZVGAZTEMRUGE>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.