On Thu, Mar 20, 2014 at 4:01 AM, Andrew Dalke da...@dalkescientific.com wrote:
My preference is for same-left. I rarely work with numpy, and it's more
likely that I'll see '@' used in a non-numpy context. That is, people
in general will see @ as a sort of free-for-all operator, to use and
On 20 Mar 2014 02:07, Sankarshan Mudkavi smudk...@uwaterloo.ca wrote:
I've written a rather rudimentary NEP, (lacking in technical details
which I will hopefully add after some further discussion and receiving
clarification/help on this thread).
Please let me know how to proceed and what you
On Mar 20, 2014, at 10:07 AM, Robert Kern wrote:
I think the operator-overload-as-DSL use cases actually argue somewhat
for right-associativity. ... Right-associativity adds some diversity
into the ecosystem and opens up some design space.
You say that like it's a good thing.
My argument is
On 03/19/2014 08:45 PM, josef.p...@gmail.com wrote:
On Wed, Mar 19, 2014 at 2:24 PM, Nathaniel Smith n...@pobox.com
mailto:n...@pobox.com wrote:
On Tue, Mar 18, 2014 at 9:14 AM, Robert Kern robert.k...@gmail.com
mailto:robert.k...@gmail.com wrote:
On Tue, Mar 18, 2014 at
On Thu, Mar 20, 2014 at 1:10 PM, Andrew Dalke da...@dalkescientific.com wrote:
On Mar 20, 2014, at 10:07 AM, Robert Kern wrote:
I think the operator-overload-as-DSL use cases actually argue somewhat
for right-associativity. ... Right-associativity adds some diversity
into the ecosystem and
On 03/20/2014 02:26 PM, Dag Sverre Seljebotn wrote:
On 03/19/2014 08:45 PM, josef.p...@gmail.com wrote:
On Wed, Mar 19, 2014 at 2:24 PM, Nathaniel Smith n...@pobox.com
mailto:n...@pobox.com wrote:
On Tue, Mar 18, 2014 at 9:14 AM, Robert Kern robert.k...@gmail.com
Hi Nathaniel,
It differs by allowing time zone info to be preserved if supplied. A naive
datetime64 would be unable to handle this, and would either have to ignore the
tzinfo or would have to throw up an exception. The current suggestion is very
similar to a naive datetime64 and only differs
On Thu, Mar 20, 2014 at 1:36 PM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 03/20/2014 02:26 PM, Dag Sverre Seljebotn wrote:
I'm positive to the chained @ idea, I think it's the answer to what we
really want.
Sorry, I totally misunderstood this. The question is of course how
On Thu, Mar 20, 2014 at 9:07 AM, Robert Kern robert.k...@gmail.com wrote:
I think the operator-overload-as-DSL use cases actually argue somewhat
for right-associativity. There is no lack of left-associative
operators for these use cases to choose from since they usually don't
have numeric or
Hi,
I plan to plot a sashimi plot to view the alternative splicing event of my
interested gene by using MISO.
After follow the following link,
http://genes.mit.edu/burgelab/miso/docs/and read through the forum.
Unfortunately, I still face some problems to run the complete set of MISO
successful.
On Wed, Mar 19, 2014 at 7:45 PM, Nathaniel Smith n...@pobox.com wrote:
Okay, I wrote a little script [1] to scan Python source files look for
things like 'dot(a, dot(b, c))' or 'dot(dot(a, b), c)', or the ndarray.dot
method equivalents. So what we get out is:
- a count of how many 'dot' calls
On Thu, Mar 20, 2014 at 1:36 PM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 03/20/2014 02:26 PM, Dag Sverre Seljebotn wrote:
Order-of-matrix-multiplication is literally my textbook example of a
dynamic programming problem with complexity O(n^2) where n is number of
terms (as in,
On Thu, Mar 20, 2014 at 1:25 PM, Nathaniel Smith n...@pobox.com wrote:
On Wed, Mar 19, 2014 at 7:45 PM, Nathaniel Smith n...@pobox.com wrote:
Okay, I wrote a little script [1] to scan Python source files look for
things like 'dot(a, dot(b, c))' or 'dot(dot(a, b), c)', or the ndarray.dot
On Thu, Mar 20, 2014 at 4:04 PM, Chia Jing Yi cjyxiao...@gmail.com wrote:
Hi,
I plan to plot a sashimi plot to view the alternative splicing event of my
interested gene by using MISO.
After follow the following link, http://genes.mit.edu/burgelab/miso/docs/and
read through the forum.
The Science Software Branch at the Space Telescope Science Institute is seeking
a developer that enjoys and is good at digging into and understanding the
details of Python internals and its libraries--particularly those related to
scientific computing--in order to support of our development of
On Mar 20, 2014, at 3:02 PM, Nathaniel Smith wrote:
- And anyway, my impression is that python-dev will give these other
possible uses ~zero weight anyway -- if they thought random DSL
operators were important for their own sake, they would have added @
long ago :-).
Unlike what you all seem
On Thu, Mar 20, 2014 at 8:38 PM, Andrew Dalke da...@dalkescientific.com wrote:
You say we've been asked to report back on what design of @ will
be best for the numeric community, since that's where we have special
expertise that python-dev lacks. I don't really think that goal
means you can
On Thu, Mar 20, 2014 at 9:10 AM, Andrew Dalke da...@dalkescientific.comwrote:
In DSL space, that means @ could be used as the inverse of ** by those
who want to discard any ties to its use in numerics. Considering it
now, I agree this would indeed open up some design space.
I don't see
On Thu, Mar 20, 2014 at 4:16 AM, Nathaniel Smith n...@pobox.com wrote:
Your NEP suggests making all datetime64s be in UTC, and treating string
representations from unknown timezones as UTC. How does this differ from,
and why is it superior to, making all datetime64s be naive?
This came up in
Hi Chris,
I think there are more or less three options:
1) a) don't have any timezone handling at all -- all datetime64s are UTC.
Always
b) don't have any timezone handling at all -- all datetime64s are
naive
(the only difference between these two is I/O of
On Mar 20, 2014, at 10:39 PM, Robert Kern wrote:
Sure, but that discussion will (and should) happen on python-ideas.
When Nathaniel says that we have been asked to answer this very
specific question, he means that literally.
Ah, now I understand.
Thanks!
On Thu, Mar 20, 2014 at 7:16 AM, Nathaniel Smith n...@pobox.com wrote:
Your NEP suggests making all datetime64s be in UTC, and treating string
representations from unknown timezones as UTC.
I recall that it was at some point suggested that epoch be part of dtype.
I was not able to find the
On Thu, Mar 20, 2014 at 9:39 AM, Sankarshan Mudkavi
smudk...@uwaterloo.cawrote:
A naive datetime64 would be unable to handle this, and would either have
to ignore the tzinfo or would have to throw up an exception.
This is not true. Python's own datetime has no problem handling this:
t1 =
Hi,
Thanks a lot for your email.
I will upload the full traceback soon.
Sorry for posting the same thread at scipy-user too.
I don't aware about that numpy and scipy user group is linked.
I apologize for my mistakes.
I will be more careful in future.
best regards
Edge
On Fri, Mar 21, 2014
On Thu, Mar 20, 2014 at 7:27 PM, Chris Barker chris.bar...@noaa.gov wrote:
On Thu, Mar 20, 2014 at 4:16 AM, Nathaniel Smith n...@pobox.com wrote:
Your NEP suggests making all datetime64s be in UTC, and treating string
representations from unknown timezones as UTC. How does this differ from,
25 matches
Mail list logo
