Ok, I started a branch on my github fork (large_printing). I made
changes to LatexPrinter, StrPrinter, and PrettyPrinter's _print_Mul
and _print_Add methods.
My custom printer inherited those changes as well, and now with that
setting, print my large expressions quickly.
I also opened a pull reque
Just a heads up. I have been running into some problems in not having
html pages produced when using the coverage tool. The only workaround
I have found so far is to delete all the files in the covhtml before
running the tool. (win32, py27, cov35).
cf https://github.com/sympy/sympy/pull/532
--
Y
On Sat, Aug 20, 2011 at 3:37 PM, Aaron Meurer wrote:
> I don't know of any doctests in SymPy that do this. Why can't you put
> imports in each doctest? I'd highly recommend it.
The reason for not wanting to do the imports is as follows. We have a
class (Kane) that implements an algorithm, and
I don't know of any doctests in SymPy that do this. Why can't you put
imports in each doctest? I'd highly recommend it.
To see if this can be done, you'll probably have to do what I would
end up doing, which is to read the source. Look at
sympy/utilities/runtests.py and also the source for Pyth
Hello,
I would like to alter the execution context of some doctests so that
I don't have redundant import statements in every doctest. Python's
doctest.testmod() function allows one to do all the common import
statements in one place (at the bottom of your module), and pass those
names so that a
> What I wanted to do is to use type() to determine is an object is a sympy
> function.
This should do it, I think:
def is_sympy_func(f):
from sympy.core.function import UndefinedFunction
return f.is_Function and isinstance(f.func, UndefinedFunction)
--
You received this message becaus
On 08/20/2011 12:44 PM, Aaron Meurer wrote:
What Chris said is more or less true. There may be some SymPy objects
where obj.func != type(obj) (otherwise, we would have no need for the
func attribute). But the way it is now, for most objects they are the
same.
But the type of an object is relat
What Chris said is more or less true. There may be some SymPy objects
where obj.func != type(obj) (otherwise, we would have no need for the
func attribute). But the way it is now, for most objects they are the
same.
But the type of an object is related to how we implement the object,
and could c
You should click on the "Contact us" button at the bottom of the page
at GitHub and request this feature. Currently, they have labels for
issues, but they don't show up in the pull request view, so you can't
use them unless you have issues enabled.
Aaron Meurer
On Sat, Aug 20, 2011 at 6:32 AM, s
We already have function interfaces to all the printers. The str
printer is accessed via sstr(), for example, so for this case, it
would be an option to that function.
I think an unsorted option would be useful. Please also do it for the
other printers, and add a note do the docstring(s) noting
And as you suggest, you should try turning off caching and running the
timings again.
Aaron Meurer
On Sat, Aug 20, 2011 at 10:31 AM, Aaron Meurer wrote:
> You'll have to profile the code to discover the true reason, but to
> me, this has to be somewhere in sympify(). By the time that code
> rea
You'll have to profile the code to discover the true reason, but to
me, this has to be somewhere in sympify(). By the time that code
reaches Mul.flatten(), everything is sympified, so the second one and
third one should be equivalent at that point.
Aaron Meurer
On Fri, Aug 19, 2011 at 8:26 PM, s
On Sat, Aug 20, 2011 at 7:26 PM, Alan Bromborsky wrote:
from sympy import *
x = Symbol('x')
type(x)
>
f = Function('f')(*tuple((x,)))
f
> f(x)
type(f)
> f
>
> Why does the type of a function only return the name of the function?
>
Not positive but I think type() of
>>> from sympy import *
>>> x = Symbol('x')
>>> type(x)
>>> f = Function('f')(*tuple((x,)))
>>> f
f(x)
>>> type(f)
f
Why does the type of a function only return the name of the function?
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this
I wonder if categories/tabs for pull requests would make sense to help
people find something that they can review. We are hovering at about
50 requests. Some appear to be stalled. I went through and categorized
them. Perhaps if you are interested in a given category you could go
check out the pull
15 matches
Mail list logo
