On Thu, Jul 2, 2009 at 11:48 AM, Vinzent
Steinbergvinzent.steinb...@googlemail.com wrote:
It should use mpf_mod (like the __add__ and __mul__ methods); faster,
and gets the precision right.
Fredrik
--~--~-~--~~~---~--~~
You received this message because you are
On Sun, May 17, 2009 at 12:25 PM, Vinzent Steinberg
vinzent.steinb...@googlemail.com wrote:
Yeah, this is what I changed in my patch. 0.001 was too small, but 0.01 did
the job. Shouldn't this be the default instead of 0.25?
There's a tradeoff, and there are examples where 0.01 fails too...
Do you think some of the functions should be rather implemented in mpmath?
which functions do you mean exactly? The jn_zeros? I don't mind. But
mpmath is sometimes very slow, e.g. I want to be able to use scipy
optionally. It can be in mpmath, I have no problems with that. But
then you
On Sat, May 16, 2009 at 11:56 AM, Ondrej Certik ond...@certik.cz wrote:
That'd be cool -- but it will still be slower than scipy -- sometimes
I just need it fast, but it's ok that maybe the 10th digit is wrong.
So I want to have both.
Some mpmath functions have turned out to be faster than
On Fri, Mar 13, 2009 at 9:53 AM, Fabian Seoane fab...@fseoane.net wrote:
Before of this patch, this calculation returned an AssertionError
(see issue #1051).
The new version is worse, IMO. Instead of just asking whether the
argument is negative, it now needs to worry about details about the
On Mon, Nov 24, 2008 at 8:47 AM, Mateusz Paprocki [EMAIL PROTECTED] wrote:
On Sun, Nov 23, 2008 at 09:27:05PM +0100, Fabian Seoane wrote:
The problem with factorization code is that it requires a lot of
CPU resources, so spending time on anything else that computing,
e.g. object creation,
On Tue, Nov 18, 2008 at 7:20 AM, Brian Granger [EMAIL PROTECTED] wrote:
2. The other option I can think of is to define a new object type
that has the __call__ logic (instead of putting into Basic). This
might look like this:
f = x*y
g = SympyCallable(f, (x,y))
g(2,3) # becomes
On Fri, Oct 17, 2008 at 11:36 AM, Ondrej Certik [EMAIL PROTECTED] wrote:
Yes, exactly. Let's just fix stuff like Integer(Integer(2)) and
Rational(1, Integer(2)), but let's not open the pandora box with
Rational(1, Symbol('n', integer=True).
Wouldn't it be easy to fix just doing this:
def
