On Wed, Feb 17, 2016 at 5:01 PM, Francesco Bonazzi
wrote:
>
>
> On Wednesday, 17 February 2016 22:33:18 UTC+1, Aaron Meurer wrote:
>>
>>
>> My idea is to have a BigNumber wrapper, which pulls assumptions from
>> its arguments automatically. BigNumber(10).is_positive would be True.
>> But importan
On Wednesday, 17 February 2016 22:33:18 UTC+1, Aaron Meurer wrote:
>
>
> My idea is to have a BigNumber wrapper, which pulls assumptions from
> its arguments automatically. BigNumber(10).is_positive would be True.
> But importantly, BigNumber(10).is_number would be False, and
> BigNumber(10).e
I think this object would be useful, but not necessarily for the sort
of things suggested in this thread.
This would be useful for most of the common use-cases today of people
using evaluate=False, which usually amounts to making an expression
look a specific way, or keeping some numbers from comb
As an example:
class Unevaluated(Expr):
def __new__(cls, wrapped_type, *args, **kwargs):
obj = Expr.__new__(cls, *args, **kwargs)
obj._wrapped_type = wrapped_type
kwargs["evaluate"] = False
obj._wrapped_object = wrapped_type(*
On Wednesday, 17 February 2016 19:45:57 UTC+1, Aaron Meurer wrote:
>
>
> But func isn't the only way an evaluation might happen. An algorithm
> might try to pull apart the expression and use the terms in different
> ways (for example, an algorithm that does the transformation a**x*a**y
> -> a*
On Wed, Feb 17, 2016 at 1:38 PM, Francesco Bonazzi
wrote:
>
>
> On Tuesday, 16 February 2016 23:59:56 UTC+1, Aaron Meurer wrote:
>>
>> Take for instance the googolplex, 10**10**100. You can represent this
>> already
>> using Pow(10, Pow(10, 100, evaluate=False), evaluate=False). But there
>> are t
On Tuesday, 16 February 2016 23:59:56 UTC+1, Aaron Meurer wrote:
>
> Take for instance the googolplex, 10**10**100. You can represent this
> already
> using Pow(10, Pow(10, 100, evaluate=False), evaluate=False). But there
> are two issues with this. First is that evaluate=False is very
> frag
On Tue, Feb 16, 2016 at 5:15 PM, Ondřej Čertík wrote:
> On Tue, Feb 16, 2016 at 12:39 PM, Aaron Meurer wrote:
>> The problem here isn't so much to do with trig identities as the big
>> numbers. The issue is that things like
>> factorial(847937526693730893984732849857349) and
>> 1342**(87236487262
On Tue, Feb 16, 2016 at 12:39 PM, Aaron Meurer wrote:
> The problem here isn't so much to do with trig identities as the big
> numbers. The issue is that things like
> factorial(847937526693730893984732849857349) and
> 1342**(87236487262873**(8732498237693269832+3)+5)-1) evaluate
> automatically,
I found the issue https://github.com/sympy/sympy/issues/6835.
Aaron Meurer
On Tue, Feb 16, 2016 at 2:39 PM, Aaron Meurer wrote:
> The problem here isn't so much to do with trig identities as the big
> numbers. The issue is that things like
> factorial(847937526693730893984732849857349) and
> 134
The problem here isn't so much to do with trig identities as the big
numbers. The issue is that things like
factorial(847937526693730893984732849857349) and
1342**(87236487262873**(8732498237693269832+3)+5)-1) evaluate
automatically, which causes Python to try to compute them until the
memory fills
Some trigonometric expressions can easily and quickly be simplified without
ever calculating some of the functions in it just by using the known
properties of the functions in the expression.
For example:
sin(2*pi)
is 0. So:
sin(pi*factorial(847937526693730893984732849857349))
is also 0. Thi
12 matches
Mail list logo
