In physics.mechanics, I actually tried to side-step this entire problem, by
just using .x, .y, and .z for the three directions. We also allowed for
users to define a custom string for an index, and access that direction via
a dictionary using the index they defined (['1'], ['2'], ['3'], or ['i'],
[
I personally think that 0 or 1, the most important thing is to be
consistent. Because the worst is switching between the two. So, since
the rest of Python and SymPy uses 0-based, I would use that. And
anyway, you will ultimately store things in a Python list, so it would
be awkward to always switch
On Fri, Nov 22, 2013 at 2:33 PM, F. B. wrote:
> Hi, I was recently facing a problem in Newtonian mechanics vs. special
> relativity: textbooks represent Newtonian objects as 1-offset
> vector/matrices/tensors, while in special relativity they are 0-offset ones,
> by the addition of a time-like dim
On Fri, Nov 22, 2013 at 12:05 PM, Aaron Meurer wrote:
> You can think of a pull request as just an issue with code attached to
> it. In fact, it's even possible to convert an issue into a pull
> request if you have push access to the repo (I'm not sure if
> downgrading a pull request to an issue i
Hi, I was recently facing a problem in Newtonian mechanics vs. special
relativity: textbooks represent Newtonian objects as 1-offset
vector/matrices/tensors, while in special relativity they are 0-offset
ones, by the addition of a time-like dimension.
I was drafting on my IPython notebook some
On Fri, Nov 22, 2013 at 12:05:07PM -0700, Aaron Meurer wrote:
> You can think of a pull request as just an issue with code attached to
> it. In fact, it's even possible to convert an issue into a pull
> request if you have push access to the repo (I'm not sure if
> downgrading a pull request to an
You can think of a pull request as just an issue with code attached to
it. In fact, it's even possible to convert an issue into a pull
request if you have push access to the repo (I'm not sure if
downgrading a pull request to an issue is possible; I'd have to
check). So closing the pull request and
On Fri, Nov 22, 2013 at 11:03 AM, Ondřej Čertík wrote:
> Hi,
>
> Currently the series are represented as a regular symbolic expression,
> with the Order() instance added to it.
>
> I think we should rather represent series as a Series class, roughly
> equivalent to SeriesData in Mathematica:
>
> h
Hi,
Currently the series are represented as a regular symbolic expression,
with the Order() instance added to it.
I think we should rather represent series as a Series class, roughly
equivalent to SeriesData in Mathematica:
http://reference.wolfram.com/mathematica/ref/SeriesData.html
The Series
On Fri, Nov 22, 2013 at 8:52 AM, Aaron Meurer wrote:
> If we move our issues to github, which I do still want to do, then wouldn't
> this be pointless since issues and pull requests are basically the same
> thing?
Except if you close it, then I think the corresponding issue is close as well.
My i
I think you can do it from the advanced search. I agree that it's not
ideal, though.
Aaron Meurer
> On Nov 22, 2013, at 9:31 AM, Sergey B Kirpichev wrote:
>
>> On Fri, Nov 22, 2013 at 09:24:14AM -0700, Aaron Meurer wrote:
>> Github has labels but only on the issues view. Can you create labels?
>
On Fri, Nov 22, 2013 at 09:24:14AM -0700, Aaron Meurer wrote:
> Github has labels but only on the issues view. Can you create labels?
Yes, I can.
But the problem is - probably, we want to mark stalled pr's,
to select after non-stalled ones. In the googlecode you can
**exclude** some label, but n
Usually the doit() method applies such rules.
Aaron Meurer
On Nov 22, 2013, at 9:07 AM, Matthew Rocklin wrote:
When used with explicitly defined Matrix objects, MatrixExpressions were
intended to be lazy by default. The idea here is that if you wanted
immediate evaluation you would have used
Github has labels but only on the issues view. Can you create labels?
Aaron Meurer
On Nov 22, 2013, at 9:08 AM, Sergey B Kirpichev wrote:
>> If we move our issues to github, which I do still want to do, then
>> wouldn't this be pointless since issues and pull requests are basically
>> the
When used with explicitly defined Matrix objects, MatrixExpressions were
intended to be lazy by default. The idea here is that if you wanted
immediate evaluation you would have used standard arithmetic operators
which would have pointed you to Matrix.__add__ etc. and forced immediate
evaluation.
>If we move our issues to github, which I do still want to do, then
>wouldn't this be pointless since issues and pull requests are basically
>the same thing?
Anyway, I think we want something like "stalled" label (to filter out
inactive PRs) for PRs like this (unfortunately, GitHub suc
Also regardless, I would like to very strongly suggest to people that
whenever possible, instead of just closing the pull request, to just fix
the issues yourself, and open a new pull request (or if the author is
active enough, send it to the original author's branch). Many pull requests
are stalle
If we move our issues to github, which I do still want to do, then wouldn't
this be pointless since issues and pull requests are basically the same
thing?
Aaron Meurer
On Nov 22, 2013, at 7:32 AM, Sergey Kirpichev wrote:
On Friday, August 9, 2013 7:40:50 PM UTC+4, Ondřej Čertík wrote:
>
> I pro
On Friday, August 9, 2013 7:40:50 PM UTC+4, Ondřej Čertík wrote:
>
> I propose to create an issue for old pull requests and close them with
> some kind words and encourage the author to reopen it if he or she
> starts working on it again.
>
Seems very reasonable and actual.
> Proposal for po
19 matches
Mail list logo
