fix: addressed rounding logic to aligne with next network upgrade

[0xObsidian]

Description

• Updated rounding.py to handle integer prices differently from non-integer prices.
• Added test cases demonstrating the new behavior
• Added setup_testnet_account.py as a prerequisite setup script

Testing the introduced fix

clone this pr branch, and then:

1. install dependencies

make install

2. run the setup script:

python examples/setup_testnet_account.py

• Follow the instructions to get testnet funds
• Ant hen run with --verify flag to confirm funds received

python examples/setup_testnet_account.py --verify

3. Then run the updated example:

python examples/rounding.py

Previous behavior

• All prices were limited to 5 significant figures
• px = round(float(f"{px:.5g}"), 6)

New behavior

• Integer prices: allowed with any number of significant figures
• Non-integer prices: still limited to 5 significant figures
• Added integer check: if abs(round(px) - px) < 1e-10

[0xObsidian]

Hi @lilelrain and @traderben
This PR addresses ticket #74
Fell free to let me know if you have any question regarding this PR

[traderben]

There's no need for this additional setup_testnet_account script which seems unrelatedto the title of this PR. Also the rounding.py script was already updated to handle the change to allow integer prices. The comment at the top matches the gitbook. I think the original code was significantly clearer and I don't understand what this PR is trying to solve

[0xObsidian]

@traderben

There's no need for this additional setup_testnet_account script which seems unrelatedto the title of this PR. Also the rounding.py script was already updated to handle the change to allow integer prices. The comment at the top matches the gitbook. I think the original code was significantly clearer and I don't understand what this PR is trying to solve

Thanks you for your feedback. I can perhaps provide further clarification regarding this PR:

The original code had a special case for prices above 100k:

if px > 100_000:
    px = round(px)

According to the upgrade mentioned in #74, the tick formula has been updated to allow all integer prices regardless of their size or number of significant figures. This PR implements this by detecting if a price is effectively an integer (accounting for floating-point precision):

if abs(round(px) - px) < 1e-10:
    px = round(px)

And then also added explicit test cases in rounding.py to demonstrate and verify the new behavior:

print("\nTest Case 1: Integer price with more than 5 significant figures (now allowed)")
px1 = 123456  # 6 significant figures, integer
rounded_px1 = demonstrate_price_rounding(px1, coin, sz_decimals)

print("\nTest Case 2: Non-integer price with more than 5 significant figures (still not allowed)")
px2 = 12345.6  # 6 significant figures, non-integer
rounded_px2 = demonstrate_price_rounding(px2, coin, sz_decimals)

Basically these make it clear to users/devs that:

• Integer prices like 123456 are now valid (Test Case 1)
• Non-integer prices still follow the 5 significant figure rule (Test Case 2)

And regarding setup_testnet_account.py this was added to improve the developer experience when testing examples in examples/. Currently, to test any example that interacts with testnet (including rounding.py), devs need to:

• Manually figure out how to get testnet funds
• Verify they received the funds
• Then run the actual example

The setup_testnet_account script streamlines this process into clear steps:

python examples/setup_testnet_account.py           # Get funds
python examples/setup_testnet_account.py --verify  # Verify receipt
python examples/rounding.py                        # Run the example

Perhaps setup_testnet_account could have been a separate PR, but the reason why it been included here because testing the new rounding behavior requires a funded testnet account, and I wanted to make this testing process straightforward.

I appreciate your feedback, please feel free to let me know if you have any other questions, I'm happy to address any concerns or make any requested changes. Let me know

[traderben]

@traderben

There's no need for this additional setup_testnet_account script which seems unrelatedto the title of this PR. Also the rounding.py script was already updated to handle the change to allow integer prices. The comment at the top matches the gitbook. I think the original code was significantly clearer and I don't understand what this PR is trying to solve

Thanks you for your feedback. I can perhaps provide further clarification regarding this PR:

The original code had a special case for prices above 100k:

if px > 100_000:
    px = round(px)

According to the upgrade mentioned in #74, the tick formula has been updated to allow all integer prices regardless of their size or number of significant figures. This PR implements this by detecting if a price is effectively an integer (accounting for floating-point precision):

if abs(round(px) - px) < 1e-10:
    px = round(px)

And then also added explicit test cases in rounding.py to demonstrate and verify the new behavior:

print("\nTest Case 1: Integer price with more than 5 significant figures (now allowed)")
px1 = 123456  # 6 significant figures, integer
rounded_px1 = demonstrate_price_rounding(px1, coin, sz_decimals)

print("\nTest Case 2: Non-integer price with more than 5 significant figures (still not allowed)")
px2 = 12345.6  # 6 significant figures, non-integer
rounded_px2 = demonstrate_price_rounding(px2, coin, sz_decimals)

Basically these make it clear to users/devs that:

• Integer prices like 123456 are now valid (Test Case 1)
• Non-integer prices still follow the 5 significant figure rule (Test Case 2)

And regarding setup_testnet_account.py this was added to improve the developer experience when testing examples in examples/. Currently, to test any example that interacts with testnet (including rounding.py), devs need to:

• Manually figure out how to get testnet funds
• Verify they received the funds
• Then run the actual example

The setup_testnet_account script streamlines this process into clear steps:

python examples/setup_testnet_account.py           # Get funds
python examples/setup_testnet_account.py --verify  # Verify receipt
python examples/rounding.py                        # Run the example

Perhaps setup_testnet_account could have been a separate PR, but the reason why it been included here because testing the new rounding behavior requires a funded testnet account, and I wanted to make this testing process straightforward.

I appreciate your feedback, please feel free to let me know if you have any other questions, I'm happy to address any concerns or make any requested changes. Let me know

rounding.py was already updated in 2e7abba
The fact that all integer inputs are allows is only relevant for inputs above 100k because below that integers have 5 significant figures. There is no need to specifically check for numbers that are close to integers.

I disagree that the setup_testnet_account script makes set up simpler. It is likely easier to get started using the frontend and then export a private key from your wallet app instead of needing to import the generated key to use the drip page on the frontend. The existing setup utils already verify that funds have been received.

The goal of examples is to have simple code that is easy for users to understand. The example is not a test file designed for verifying behavior and I think adding additional test cases does not help with the demonstration

[0xObsidian]

@traderben

The goal of examples is to have simple code that is easy for users to understand. The example is not a test file designed for verifying behavior and I think adding additional test cases does not help with the demonstration

Got it, thanks for the feedback.
Side note:
I noticed that the repo doesn't currently have any GitHub workflow to check PRs.
Would you prefer that I write an issue detailing the implementation I'm planning to do or should I proceed with a PR directly that will introduce a workflow that will be checking each PR for:

• formatting
• testing
• type checking
• linting
• security scanning

The existing Makefile targets can be easily integrated into a CI workflow.

[traderben]

What problem are you trying to solve? Have we been merging in commits that are failing formatting, testing, type checking or linting? I believe github dependabot already sends warning about security issues. I'd rather not have to review code and maintain an additional workflow if there isn't a clear benefit

[0xObsidian]

Have we been merging in commits that are failing formatting

Yes, please see #79