Fixes issue whereby scale 29 is required however is optimized away #619
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #618
Fixes an issue during add/subtract with a small number with scale 29. Effectively, what happened is that the number was able to be "aligned" within a 32 bit boundary however because it used scale 29 it was "optimized" away when reconstructing the decimal.
Scale 30, even though invalid, was ok since it continued scaling back until it reached a scale of 28. Scale 29 however effectively stopped scaling and was forced to 28 during reconstruction. This fix forces scale 29 to also be scaled down to scale 28 before reconstruction. The alternative solution would be to retain a scale of 29 however that could lead to subtly incorrect values (i.e.
-0.09999999999999999999999999990
with the trailing zero). Since the decimal library constrains scale to 0 to 28 in most cases (rescaling is the exception) it makes sense to continue scaling to 28 during these calculations.