On Thu, 8 Oct 2020 at 22:10, Tim Peters wrote:
> Again, the concept of a _fixed_ (albeit user-settable) working
> precision is deep in the module's bones.
That is, for what I know, how also BigDecimal in Java works... and
float in any architecture.
___
Hello!
I want to discuss one feature for handful working with shapes of array-like
objects.
If we want to pass arrays to function we can declare their sizes directly with
argument declaration:
```
def foo(a[m, n], b[n]):
for i in range(m):
for j in range(n):
a[i, j] = b[
On Thu, Oct 8, 2020, at 16:07, Tim Peters wrote:
> See above. It's very much a feature of the IEEE 754/854 standards (of
> which family Python's decimal model is a part) that if an exact
> result is exactly representable, then that's the result you get.
My suggestion was for a way to make it so
[Random832 ]
> My suggestion was for a way to make it so that if an exact result is
> exactly representable at any precision you get that result, with
> rounding only applied for results that cannot be represented exactly
> regardless of precision.
That may have been the suggestion in your head ;-
On Thu, 8 Oct 2020 at 16:59, Random832 wrote:
>
> I was making a "convert Fraction to Decimal, exactly if possible" function
> and ran into a wall: it's not possible to do some of the necessary operations
> with exact precision in decimal:
>
> - multiplication
> - division where the result can b
On Fri, 9 Oct 2020 at 23:41, Tim Peters wrote:
> But the decimal spec takes a different approach, which Python's docs
> don't explain at all: the otherwise-mysterious ROUND_05UP rounding
> mode. Quoting from the spec:
>
> http://speleotrove.com/decimal/damodel.html
> ...
> The roundi
