Am 16.07.2015 um 05:32 schrieb Aaron Meurer:
Also, if you're a habitual rebaser and you have push access, you had better
have your origin remote set to read-only.
Very much agreed.
Maybe not just for habitual rebasers, merging with conflicts can go
wrong, too.
I hope to set up my own
Am 16.07.2015 um 18:21 schrieb Aaron Meurer:
OK, guys, this thread has reached its end.
Fully agreed.
With 20/20 hindsight, I'd say it did many messages ago.
I'm not going to take 100% responsibility for this, but enough that I
want to offer my apologies.
Regards,
Jo
--
You received this
Given the way Jason Moore has been acting towards me - some valid points
buried so deep in personal attacks that even talking to him has become
painful for me...
...and given that he's implying he's speaking for the project, which
would be bad if he does not and worse if he actually did...
...
The more you do this, the less
we like you.
Frankly, I do not care whether you like me. I care about code.
Also, I do not believe anybody gave you a mandate to tell me that they
don't like me anymore.
You accuse me of not helping moving stuff forward.
Ironically, you've been bogging this
Am 15.07.2015 um 20:23 schrieb Ondřej Čertík:
I agree with this --- many times there is just a few lines change,
that took 50 commits to get done, because the author was learning how
to make it work.
That too, yes.
For these cases I recommend to send a new PR with a polished (=rebased)
Am 15.07.2015 um 20:54 schrieb AMiT Kumar:
Well said, I think, this point won the argument!
Actually it didn't, each sentence is easily refuted:
Changing the history of your revisions is detrimental to the open
philosophy that you should have when developing in open source.
Open philosophy
Am 13.07.2015 um 23:58 schrieb Jason Moore:
Finally, if you would like to share an alternative solution to making it
simpler and easier for PRs to get merged then, by golly, please do so.
You've now written two long emails that do not come even close to offering
an alternative solution to the
Am 14.07.2015 um 16:39 schrieb Jason Moore:
It wasn't ignored, I just don't see it. All I see are detailed agreements
or counters to each point that has been mentioned to be negative about
rebasing.
Indeed, I misrepresented that a bit.
I can't hope to discuss solution details if we don't even
Am 14.07.2015 um 16:05 schrieb Jason Moore:
I want to discuss a comprehensive solution that
minimizes the git kung fu overhead for sympy contributors. If you have a
suggestion for that, please make it.
I did, but that got ignored.
--
You received this message because you are subscribed to the
Am 14.07.2015 um 18:10 schrieb Matthew Brett:
? I've certainly done PRs where I had a set of changes that I had to
rewrite completely on the basis of comments, so that the full history
would have been useless and distracting, and an interactive rebase was
obviously the best way to clean that
Am 13.07.2015 um 20:10 schrieb Aaron Meurer:
- Greatly increases the complexity of git for new users.
Agreed. I would recommend it only for people who are willing to write it.
- You can create commits that don't do what they say they do.
Yes for non-interactive rebases.
For an interactive
Am 13.07.2015 um 16:39 schrieb Jason Moore:
I apologize for insulting you.
Okay.
I have no intention of insulting you but I find that
the majority of your responses to emails/pr/issues are in essence nitpicks
or bikesheds.
Yeah... it's all things that one of the project leads or another
Am 12.07.2015 um 23:17 schrieb Jason Moore:
That is what I think, but I'm not asking you to shut up.
Rather, I'd like for you to raise legitimate concerns
Well, you're telling me I'm a master of bikeshedding, which is a
serious insult.
Plus you're dismissing arguments on an issue like git
Am 12.07.2015 um 00:17 schrieb Jason Moore:
FYI: We had a discussion at SymPy on how to synchronize with master and
decided that we no longer want to allow or encourage rebasing after a pull
request is made to the main SymPy repo.
I think that's overstated.
I see some reasons against merging:
Am 12.07.2015 um 16:36 schrieb Jason Moore:
Joachim,
Thanks for the start of the bike shedding, you are becoming a master at it.
Thanks.
If that's what you think, I'll simply shut up.
Jo
--
You received this message because you are subscribed to the Google Groups
sympy group.
To
Am 11.07.2015 um 09:02 schrieb Paul Royik:
But this can't be reproduced.
It is a bug from time to time.
How can this be possible?
Some non-deterministic code path, it seems.
Calls for a debugging session to find out what's happening.
--
You received this message because you are subscribed to
Am 12.07.2015 um 00:17 schrieb Jason Moore:
The development docs have been updated:
https://github.com/sympy/sympy/wiki/Development-workflow#synchronization-with-master-sympysympy
Where do I find the img/ subdirectory?
img/dev-guide-apitoken.png needs removing (the API token section in
Am 09.07.2015 um 12:45 schrieb AMiT Kumar:
On Thursday, July 9, 2015 at 1:59:01 AM UTC+5:30, Joachim Durchholz wrote:
Am 08.07.2015 um 21:59 schrieb Aaron Meurer:
Here is the video https://www.youtube.com/watch?v=RdFYj9NwD3g
That video is private, so outsiders can't see it.
Yesterday
Am 08.07.2015 um 21:59 schrieb Aaron Meurer:
Here is the video https://www.youtube.com/watch?v=RdFYj9NwD3g
That video is private, so outsiders can't see it.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop
Am 03.07.2015 um 14:48 schrieb Robert Pollak:
Hello,
I have got a newbie question: Does SymPy provide a way to deal with numbers
in different numeral systems and e.g. to convert them between different
systems? Or do I have to tell my students that they have to program this by
theirselves :) ?
(3) On my local machine. I go sage -ipython which launches a copy of
python with all the libraries that you could think of, certainly sympy and
matplotlib.
Again plot(x*x) and plot(x*x).show() fail to display anything.
I'm guessing in this case it's a (simple?) matter of telling sympy to talk
I just hit another situation where I would really have liked to use an
external (small) library that was packaging a huge amount of research
and knowledge in a relatively small but well-done codebase.
(See the end of this message for details.)
My realization is that the Python ecosystem has
(Replying instead of making this part of the initial post, to keep the
questions part separate from my and other people's answers.)
What are the problems?
Can we turn them into tasks?
How to we complete the tasks?
Here's my stab at this.
Fragile downloads
-
Problem:
Hi all,
I just set up a wiki page where we can collect which Python versions we
may want to support for how long. You can find it at
https://github.com/sympy/sympy/wiki/Python-Version
for viewing, corrections, and updates.
What's missing is Mac OS, but I know too little to retrieve useful
Am 23.06.2015 um 20:04 schrieb Peter Brady:
Python 3 is scheduled to be the default for Fedora
23 https://fedoraproject.org/wiki/Changes/Python_3_as_Default.
Ah... that's the first step of phasing out 2.7: Making it unneeded for
the distro itself.
Though that's not going to affect our
limit(sin(x)**15,x,0,'+') works
limit(sin(x)**15,x,0,'-') hangs
Actually, both are working. But the second limit is slow.
Confirming for Python 2.6.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving
Am 23.06.2015 um 22:37 schrieb Jason Moore:
Ubuntu 12.04 is crossed out in the page but it is supported until April
2017 (and is still the version Travis uses). We likely need to support
12.04 Python versions longer.
Ah right, I somehow picked the HWE date from the minor upgrade lines.
Fixed.
Thanks, I updated the table for RHEL6, which uses Python 2.6 and will
go out in 10-2020.
Mmm... it says Nov 2020.
But I guess that's accurate enough for now :-9
If Production Phase 3 is the relevant cutoff phase, I guess we'll need
to add 5 as well.
And 7 as it's current, too.
Are there any
Am 24.06.2015 um 03:32 schrieb Peter Brady:
Do pip or conda provide stats on which versions are downloaded?
I don't know, but I doubt that that's going to give very useful Python
version statistics.
I found
http://www.randalolson.com/2015/01/30/python-usage-survey-2014/
which is somewhat
Am 24.06.2015 um 01:24 schrieb Francesco Bonazzi:
I still use Python 2.7. Is there anyone else like me here?
I'm using 2.6, but that's so that I won't inadvertently use anything
that doesn't work in later Pythons.
--
You received this message because you are subscribed to the Google Groups
Am 21.06.2015 um 18:48 schrieb Francesco Bonazzi:
On Sunday, 21 June 2015 04:14:11 UTC+2, Aaron Meurer wrote:
We should probably remove the dev-py3k docs. I don't think they have
been updated in a long time.
Maybe it's better to put a 301 status code for a while, before removing
them. In
Am 21.06.2015 um 20:41 schrieb Aaron Meurer:
Links ought to point to the latest urls, which will always point to
the latest docs.
Both kinds of URLs have their uses.
Latest URLs are good for doing work with SymPy.
Version-specific URLs are good for finished work. Programs that are
coded
I'm talking about this:
http://docs.sympy.org/dev-py3k/tutorial/tutorial.en.html
It doesn't seem to get updated (it's still referencing SymPy 0.5.12 and
code.google.com), and I'm not finding sources for it anywhere.
--
You received this message because you are subscribed to the Google Groups
Am 11.06.2015 um 20:33 schrieb j.gonthie...@gmail.com:
I think this is actually the error we discussed about here:
https://groups.google.com/forum/#!searchin/sympy/gonthier/sympy/CxiRZWdW6KA/8pyTinsRWGgJ
Bummer, you're right.
Did you open an Issue for this? It's really annoying.
--
You
FYI, here's my interaction with them:
--
Hey Jo,
These are interesting ideas -- I can see how label permissions control
could be helpful in certain workflows. And adding label descriptions
makes sense. I can't make any promises, but I'll definitely pass your
ideas along to the team for
Am 06.06.2015 um 20:37 schrieb Robert Pollak:
as a SymPy newbie, do I do something wrong here?
In [1]: solve([x**2 * y**2 = x**2 * y, x**2 * y**2 x**2 * y])
I can't see anything wrong with that.
I'm not sure what that unexpected error thing is and why there's any
tokenization
Am 09.06.2015 um 23:39 schrieb Jason Moore:
Ondrej and I thought that we should ask Github to enable PR authors'
ability to modify labels on their own PRs. We should all put in a request
for that.
Once you put in a request, please post the link so we can add comments.
Thanks :-)
--
You
Am 10.06.2015 um 00:34 schrieb Ondřej Čertík:
We don't want ready to merge if Travis is okay to be settable by
everybody, we want to reserve that for those who can actually do a merge.
However, we want to allow the PR author and any reviewer to remove it.
First of all, we can trust the PR
Am 10.06.2015 um 00:37 schrieb Ondřej Čertík:
It's really about who's turn it is. So that both reviewers as well as
authors can see if they need to do anything.
Another potential approach is what needs to be done next?
The label set that came out of this thought was this:
Needs Evaluation:
I've added few labels related to PR:
PR: needs more work (author's turn)
PR: waiting for Travis to finish
and then we can use them in a query.
Only contributors (i.e. people with repository write access) can set or
remove these labels. I.e. most authors can't remove needs more work
when
Am 10.06.2015 um 00:22 schrieb Ondřej Čertík:
That way, each PR is in one (and only one) of the following stages:
* tests are in progress (the yellow status)
* labelled PR: needs more work (author's turn)
* labelled PR: in review
How about calling these:
PR: author's turn
PR: sympy's turn
Am 09.06.2015 um 23:55 schrieb Jason Moore:
I don't think Github cares how we manage our projects.
Sort of. There is a GitHub workflow, and not all git workflows are
easily mappable to it (git-flow, for example, won't - not easily anyway).
Though I agree that they probably don't care about
Am 09.06.2015 um 23:39 schrieb Jason Moore:
Ondrej and I thought that we should ask Github to enable PR authors'
ability to modify labels on their own PRs. We should all put in a request
for that.
Labels such as ready to merge if Travis is okay with it should not be
settable by the PR author,
I'm getting a failure for matplotlib when running the test suite
locally, but not on Travis. I'm not sure whether that's a bug in
implicit_plot, or in the test suite, or whether I'm just missing an
installation dependency.
Here's the trace:
$ bin/test test_plot_implicit -k test_matplotlib
It's not in the `sympy` namespace, but it is documented as a part of
`sympy.core.core` (not intentionally I suppose, it's just automatically
extracted).
I.e. the question is whether we guarantee a stable API for just the
`sympy` namespace, or for all submodules as well.
Motivation: I'm
Am 05.06.2015 um 20:02 schrieb Jason Moore:
I think we found out timeout issue but the warnings are still odd,
especially since we don't get them locally. That's be nice to fix too.
I suspect the Travis build is simply missing some packages that the
LaTex build needs.
I guess the best way to
Am 05.06.2015 um 21:54 schrieb Jason Moore:
All of the LaTeX warnings were causing Travis to truncate the log and
it took us a bit to find it.
It would be nice to get rid of these.
Not only can this throw off people who don't know that Travis truncates
logs with 10.000+ lines, the JS that
Am 31.05.2015 um 22:50 schrieb Aaron Meurer:
Perhaps we should make derivatives of booleans give TypeError. That
would make it much easier to see what is going on.
+1
Similarly, integer-valued functions should (probably?) emit a warning if
a derivative is taken. The derivative is technically
Good points.
So I conclude that it would be nice if somebody came up with a way to
allow user-defined attributes without running into namespace conflicts.
Oh, and the mechanism should be easy to use for the casual user. I have
some ideas in that direction, but I'd like to see what others think
Am 18.05.2015 um 15:56 schrieb Carsten Knoll:
I want to equip an Symbol with an additional attribute to store some
specific information right in place.
For 'normal' Python classes it is no problem to dynamically create an
additional attribute for an already existing instance.
However, for
Am 19.05.2015 um 00:44 schrieb Carsten Knoll:
That happens because we use __slots__ for performance reasons.
I was not aware of the __slots__ mechanism. Now I know.
However, storing attributes in that way is a bad idea in general,
because you risk name conflicts with future versions of
Am 15.05.2015 um 03:42 schrieb Duane Nykamp:
I don't think this is the desired behavior.
In [3]: a=Symbol('a')
In [4]: bool(And(2a, a2))
Out[4]: True
The `And` does not simplify, and the bool() conversion turns it into a
Pythonic `True`.
The former happens because assumptions don't know
I agree that `bool(And(a2, a3))` and `bool(a2)` should show analogous
behaviour.
At least that's what I'd assume from my current understanding of
assumptions and evaluation in SymPy. I'd like to defer to the real
experts on these components (I think that's @asmeurer and @certik).
--
You
On reconsideration, I recognize I may have been assuming too much.
My question now is: For the project that you have in mind, what would be
the task of the Java side? What kind of data would you want to exchange
between the Java and SymPy side?
I think that has a deep impact on what you
Am 08.05.2015 um 19:04 schrieb Raymond Gong:
I believe java wrapper
should be useful for many other people.
Important advice: Don't try to second-guess the needs of other people,
get your needs covered well. Making code more general is a lot of
additional work (Fred Brooks assumes a factor
Am 06.05.2015 um 23:01 schrieb Peter Brady:
Doesn't the test runner do a clear_cache before each test?
No. Just at the start of each file.
Ah, I missed that because I ran just a single test where I observed that.
I'm wondering whether we shouldn't do clear_cache() before each test. If
I
Am 08.05.2015 um 18:57 schrieb Raymond Gong:
from Java side, we are hoping just pass in the symbolic math expression
such as polynomials or whatever K12 math expression, the sympy will return
the result that java can consume. From java side, the expression is a java
string
we can construct the
Am 08.05.2015 um 19:50 schrieb Sudhanshu Mishra:
Creating a full featured wrapper for SymPy in Java is an amazing idea. It
will open a lot of opportunities and increase use cases of SymPy in the
Android community.
I'm very sceptical about that. Python's and Java's data model are
essentially
Am 07.05.2015 um 20:10 schrieb Raymond Gong:
Hey, this is the first time for me to be here, tried to search any examples
or comments or whatever information on usage of sympy in java project.
The standard Python interpreter is a standalone program, interacting
with that from Java is always
Am 07.05.2015 um 22:24 schrieb Ondřej Čertík:
On Thu, May 7, 2015 at 2:17 PM, Joachim Durchholz j...@durchholz.org wrote:
Am 07.05.2015 um 20:10 schrieb Raymond Gong:
Hey, this is the first time for me to be here, tried to search any
examples
or comments or whatever information on usage
Am 07.05.2015 um 22:29 schrieb Raymond Gong:
Hi Joachim,
Thanks a lot for your nice response. Actually I am doing this, I just
replied to Ondrej's message on this, but I didn't run Jython testing
against sympy, I even don't know how to do it,
could you provide some more information or link on
I'm currently tutoring PR #9376, which fixes a bug that happens only
when caching is turned off.
We're trying to figure out a way to write a regression test. Our test
suite is run with caching switched on, even on Travis, so we need a way
to make sure that this single test is running with
Am 06.05.2015 um 21:51 schrieb Aaron Meurer:
In my experience, you'll want to run the whole test suite without the
cache (I know it's slow).
Hm. Obviously nobody ever did this since 25 Jun 2014.
I.e.
- not ever locally for anybody
- not ever on Travis
- not during testing for two release
Am 06.05.2015 um 20:58 schrieb Peter Brady:
Absolutely. I was thinking that there was a decently sized set of tests
that were going to be run regularly without the cache in which case it
might make sense to introduce another mark/option but if it's only a few
than specifying them manually is
Am 07.05.2015 um 00:17 schrieb Aaron Meurer:
I've done it a few times (although admittedly not in a while), but
there have always been errors that have been too hard to fix, even
for a release.
Ah, I didn't know that.
In the light of this, do we even want to return SymPy to a state that
works
:04:07 PM UTC+3, Joachim Durchholz wrote:
Am 28.04.2015 um 12:42 schrieb Paul Royik:
How can I solve equation on the interval?
For example sin(x)=0, 2pi=x=4pi
Apply an assumption to x.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe
Am 28.04.2015 um 15:27 schrieb Tom Bachmann:
One last set of question here:
What was your overall strategy when choosing heuristics?
Was that strategy in some way derived from the SymPy's term sort order?
(If no, improvement and loss will tend to cancel each other out and I
can stop worrying
Am 28.04.2015 um 12:42 schrieb Paul Royik:
How can I solve equation on the interval?
For example sin(x)=0, 2pi=x=4pi
Apply an assumption to x.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails
Am 27.04.2015 um 00:09 schrieb j.gonthie...@gmail.com:
Sympy version 0.7.6-git, up-to-date with the current master on github.
Okay, so we're seeing the same failure as you do.
Note to maintainers: To reproduce the error, install matplotlib and run
bin/test plot_implicit
The plot_implicit
Am 26.04.2015 um 22:42 schrieb j.gonthie...@gmail.com:
File sympy/plotting/plot_implicit.py, line 81, in get_raster
temp = func(xinterval, yinterval)
File string, line 1, in lambda
NameError: global name 'Eq' is not defined
I can confirm that this error happens.
I had to `pip
Am 19.04.2015 um 15:31 schrieb Tom Bachmann:
The testing philosophy I went for with meijerint was to look at a lot of
common book integrals and make sure the algorithm can do them. What this
means may not be entirely clear. But certainly we want to have a definite
integral returned in elementary
Am 24.04.2015 um 00:02 schrieb Jason Moore:
That makes sense, but I'm not sure whether Garbage in - Garbage Out
should apply or whether SymPy should throw and error.
If something is invalid, the user needs to be notified.
General policy.
Otherwise, if the expressions become large, the user
Am 17.04.2015 um 23:11 schrieb James Crist:
That's just a name change for each label (one-to-one correspondance with
existing labels), which can be done easily later.
Grouping labels might make it easier to manipulate them using hooks.
But then it's probably better to change the names once
Am 18.04.2015 um 01:28 schrieb Aaron Meurer:
On Fri, Apr 17, 2015 at 2:05 PM, James Crist crist...@umn.edu wrote:
I have another label question:
- `Needs better patch`: could be useful to indicate PR status to devs, but
mostly I feel that it comes off as rude to the person making the PR. I'd
Am 17.04.2015 um 07:40 schrieb James Crist:
- Brief discussion on labeling system.
Actually I think what you're proposing is fine.
If it's found lacking, we can easily fix it.
- Help labeling.
I haven't found a way to enable tagging for people that do not have full
write access to the
One thing I saw proposed elsewhere is to group labels, by naming them
group:label.
Am 17.04.2015 um 07:40 schrieb James Crist:
*Submodule tags (html #FF, blue):*
Everything after `sympy.` for the specific submodule. Keep the naming and
casing consistent with the sympy namespace. If the
I roughly understand why assumptions are needed. In my mind: so that
sympy knows what the numerical values the symbol can assume. Is that a
right way of thinking about it?
It's one (correct) way of thinking about it.
Another way would be: The set of rules that restrict the values the
symbol
Am 14.04.2015 um 19:54 schrieb James Crist:
For example, say I make a tiny bug fix in function foo - I could also clean
up some of the code in foo. That way the last person to touch foo is not
someone who added a space between an operator, but someone who actually
changed the functionality of
Am 13.04.2015 um 07:13 schrieb Rathmann:
Just one data point that may be relevant -- blame shows the comment as
dating from 2012.
The code for multiset partitions has changed since then.
Ah thanks, I didn't notice that. Thanks for the pointer.
I'd still like to know what motivated that
Am 03.04.2015 um 11:58 schrieb Francesco Bonazzi:
I posted some month ago this link:
http://astrofrog.github.io/blog/2013/01/13/what-python-installations-are-scientists-using/
Apparently, in November 2012 the user share of Python 3.2 was negligible,
they were estimated to be less than Python
Am 03.04.2015 um 20:01 schrieb Aaron Meurer:
My understanding was that Debian was shipping 3.2,
That's indeed the case.
Jessie (the next release) will use 3.4.
More details on https://wiki.debian.org/Python .
and hence it would
be good for us to continue to support it.
Agreed.
--
You
Am 30.03.2015 um 21:33 schrieb Aaron Meurer:
I would definitely test the different alternatives for sympy.abc to
see what's faster.
I just ran bin/test with `a = Symbol('a')` etc.
Runtime went from 56:29 to 56:37, i.e. below the noise threshold.
That was with Python 2.7. I guess the Pyton
Am 02.04.2015 um 11:30 schrieb Christophe Bal:
Thanks for the answers.
Indeed I was hoping that git can manage multi pull requests. If it is not
case, Il will build a python scripts such to play with the git --stat
outputs.
Wait until you have seen some actual merge conflicts :-)
It's not
Am 02.04.2015 um 18:46 schrieb James Crist:
Performance:
Using symbols() in all contexts might have performance ramifications,
creating new Symbol() objects means more memory pressure than reusing
precreated symbols from sympy.abc (which happen 521 times in SymPy
itself, hopefully just in
Hi all,
I'm wondering about the section on creating symbols in
https://github.com/sympy/sympy/wiki/Idioms-and-Antipatterns#strings-as-input
.
It is mildly discouraging importing from sympy.abc because an accidental
from sympy.abc import * would clobber I and Q (and possibly others),
and
Am 30.03.2015 um 13:28 schrieb Francesco Bonazzi:
[with `symbols`,] it's easy to swap two
letters without noticing so you essentially get the equivalent of
p = Symbol('i')
i = Symbol('p')
with the devious consequence that everything would still work but any
outputs would be utterly
Am 30.03.2015 um 19:58 schrieb Aaron Meurer:
symbols() supports commas, so an easy thing to do here is to use the
form symbols(' t, w, x, y, z, n, k, m, p, i'), so that the left-hand
side of the assignment exactly matches the right-hand side.
Ah, I knew it could do commas but I didn't know
Am 30.03.2015 um 21:33 schrieb Aaron Meurer:
I would definitely test the different alternatives for sympy.abc to
see what's faster.
Also, I wonder what the effect of sympy.abc on the cache is. We have
an LRU cache, and assumedly importing it messes with that, at least
for a little bit.
Am 28.03.2015 um 21:35 schrieb Aaron Meurer:
Except in the tests you should use a more directed, efficient
simplification function than simplify(). cancel() should be sufficient
for this case.
That worked, thanks.
Is there a guideline which function to select for what kind of
normalization?
Am 28.03.2015 um 00:51 schrieb Aaron Meurer:
On Fri, Mar 27, 2015 at 5:26 PM, Joachim Durchholz j...@durchholz.org wrote:
The other approach would be to accept that some unit tests depend on sort
order in a superficial way, and to change the unit tests. (2)
The not-so-nice aspect about
I need to update a unit test where integrate now returns something that
contains 1/(2*(s+1)).
However, when I write that subexpression, SymPy gives me 1/(2*s + 2),
which compares unequal.
What would be the best way forward?
Alternatives that I can think of:
- have integrate() do whatever SymPy
Am 28.03.2015 um 00:51 schrieb Aaron Meurer:
On Fri, Mar 27, 2015 at 5:26 PM, Joachim Durchholz j...@durchholz.org wrote:
The other approach would be to accept that some unit tests depend on sort
order in a superficial way, and to change the unit tests. (2)
Is the result deterministic
Am 24.03.2015 um 22:29 schrieb Aaron Meurer:
On Tue, Mar 24, 2015 at 4:36 AM, Joachim Durchholz j...@durchholz.org wrote:
Is Meijer heuristic? In that case, I think variation due to changed sort
order would be expected.
Yes, it uses a lot of pattern matching, which is heuristic in nature.
I
Am 25.03.2015 um 20:11 schrieb Aaditya Nair:
Especially the
part about ManagedProperties.
Aside note: ManagedProperties might get split into two classes one of
these days (or weeks (or months, depending on how quickly I can get some
preliminaries out of the way)).
This isn't going to affect
Am 23.03.2015 um 22:39 schrieb Aaron Meurer:
On Mon, Mar 23, 2015 at 4:35 PM, Joachim Durchholz j...@durchholz.org wrote:
#2 Now this is asserting Eq(1/s,1) for old and Eq(s,1) for new. These
are semantically different for the case s=0 (i.e. integral of just sinh(x)):
Old sort order gives
Just a heads-up: I'm in a bit of a squeeze and won't be able to review
the application.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Am 23.03.2015 um 22:39 schrieb Aaron Meurer:
I would try to find some other example that this gives different
results for, or, preferably, get ahold of Tom Bachmann, and see if he
can shed any insight.
I can't find Tom via github, his account seems to be gone.
I tried contacting him via the
Am 23.03.2015 um 00:29 schrieb Aaron Meurer:
https://docs.python.org/3/reference/datamodel.html#object.__lt__. That
page in general is a good reference for all these sorts of things.
Aaah... I've been turning to the 2.7 docs so I don't accidentally do
anything 3.x, and the NotImplemented
Hi all,
this probably mostly goes to Tom Bachmann and Chris Smith, but maybe
others know a bit about Meijer integration.
I'm working on something that changes the internal ordering of terms a
bit, and Meijer seems to rely on the current ordering for some
vaguely-explained benefits; I need
Am 22.03.2015 um 22:23 schrieb Aaron Meurer:
Python operations fallback to the reverse operation when they are not
defined, so e.g., x + y does x.__add__(y) and if that returns
NotImplemented, it does y.__radd__(x). For the comparison operators,
it does the flipped operator, so this would be
1 - 100 of 782 matches
Mail list logo
