On Sun, Aug 17, 2008 at 9:15 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 17, 2008 at 21:55, Anne Archibald <[EMAIL PROTECTED]>
> wrote:
> > 2008/8/17 Robert Kern <[EMAIL PROTECTED]>:
> >>
> >> I suggested that we move it to a branch for the time being so we can
> >> play with it and c
On Sun, Aug 17, 2008 at 21:55, Anne Archibald <[EMAIL PROTECTED]> wrote:
> 2008/8/17 Robert Kern <[EMAIL PROTECTED]>:
>>
>> I suggested that we move it to a branch for the time being so we can
>> play with it and come up with examples of its use. If you have
>> examples that you have already writte
2008/8/17 Robert Kern <[EMAIL PROTECTED]>:
>
> I suggested that we move it to a branch for the time being so we can
> play with it and come up with examples of its use. If you have
> examples that you have already written, I would love to see them. I,
> for one, am amenable to seeing this in 1.2.0,
On Sun, Aug 17, 2008 at 7:56 PM, Stéfan van der Walt <[EMAIL PROTECTED]>wrote:
> 2008/8/17 Robert Kern <[EMAIL PROTECTED]>:
> > I suggested that we move it to a branch for the time being so we can
> > play with it and come up with examples of its use.
>
> That branch is here:
>
> http://[EMAIL PRO
2008/8/17 Robert Kern <[EMAIL PROTECTED]>:
> I suggested that we move it to a branch for the time being so we can
> play with it and come up with examples of its use.
That branch is here:
http://[EMAIL PROTECTED]/svn/numpy/branches/gen_ufuncs
Stéfan
__
On Sun, Aug 17, 2008 at 6:13 PM, Engel, Hans-Andreas <
[EMAIL PROTECTED]> wrote:
> I am sorry that our submission
> http://projects.scipy.org/scipy/numpy/ticket/887 has created some
> annoyance; presumably we have taken the "Make contributions (e.g. code
> patches), (...) by submitting a 'ticket'
Hello,
Thanks to heroic efforts by Chris Galvan this weekend, and significant
efforts by the team that finalized ETS 3.0.0 this week, we've been able
to publish public beta releases of EPD with Py2.5 v4.0.30001 Beta1 for
Windows and Mac OS X today. I've uploaded them to the downloads website
and
On Sun, Aug 17, 2008 at 19:13, Engel, Hans-Andreas
<[EMAIL PROTECTED]> wrote:
> I am sorry that our submission
> http://projects.scipy.org/scipy/numpy/ticket/887 has created some
> annoyance; presumably we have taken the "Make contributions (e.g. code
> patches), (...) by submitting a 'ticket' on t
"Stéfan van der Walt" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL
PROTECTED]>...
Hi all,
I have moved the generalised ufuncs functionality off to a branch:
http://svn.scipy.org/svn/numpy/branches/gen_ufuncs
Please try it out and give us your feedback. We shall also pound on
it at the s
"Charles R Harris" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Hi All,
>
> I received an email from Hans Andreas -- the gen-ufuncs guy -- and he
is
> unable to post to the list even though subscribed. Anyone know what
might be
> the problem? Please cc [EMAIL PROTECTED] if yo
I am sorry that our submission
http://projects.scipy.org/scipy/numpy/ticket/887 has created some
annoyance; presumably we have taken the "Make contributions (e.g. code
patches), (...) by submitting a 'ticket' on the Trac pages linked below"
on http://scipy.org/Developer_Zone somewhat too literally.
Hi All,
I received an email from Hans Andreas -- the gen-ufuncs guy -- and he is
unable to post to the list even though subscribed. Anyone know what might be
the problem? Please cc [EMAIL PROTECTED] if you reply to this
post.
Chuck
___
Numpy-discussion
On Aug 18, 2008, at 12:00 AM, Ondrej Certik wrote:
> There is some inconsistency though, for example one can override A() +
> A(), but one cannot override 1 + 1. This could (should) be fixed
> somehow.
That will never, ever change in Python. There's no benefit
to being able to redefine int.__add_
> On Aug 17, 2008, at 10:35 PM, Christian Heimes wrote:
>> Andrew Dalke wrote:
>>> Or write B \circledast C ? (Or \oast?) Try using Google to search
>>> for that character.
>>
> unicodedata.lookup('CIRCLED ASTERISK OPERATOR')
>> '⊛'
>>
I mean, go to Google and search for "⊛".
It finds no h
On Sun, Aug 17, 2008 at 17:00, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> There is some inconsistency though, for example one can override A() +
> A(), but one cannot override 1 + 1. This could (should) be fixed
> somehow.
This is getting off-topic, but I really hope that never changes. The
differ
On Sun, Aug 17, 2008 at 7:03 AM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> [ please keep all replies to this only on the numpy list. I'm cc'ing
> the scipy ones to make others aware of the topic, but do NOT reply on
> those lists so we can have an organized thread for future referenc
Andrew Dalke wrote:
> Or write B \circledast C ? (Or \oast?) Try using Google to search
> for that character.
>>> unicodedata.lookup('CIRCLED ASTERISK OPERATOR')
'⊛'
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.o
Gael Varoquaux wrote:
> I am very much against unicode operators. I can see a huge
> amount of problems this will generate, for little gain.
I actually basically like PEP 225,
although I find @*, @+, etc more
readable, and to provide the right
visual emphasis. (Rather than ~*, ~+, etc.)
Additio
On Sun, Aug 17, 2008 at 1:58 PM, Andrew Dalke <[EMAIL PROTECTED]>wrote:
> On Aug 17, 2008, at 9:38 PM, Charles R Harris wrote:
>
> > And here is a bit of unicode just so we can see how it looks for
> > various folks.
> >
> > A = B⊛C
>
>
> Or write B \circledast C ? (Or \oast?) Try using Google t
On Aug 17, 2008, at 9:38 PM, Charles R Harris wrote:
> And here is a bit of unicode just so we can see how it looks for
> various folks.
>
> A = B⊛C
Or write B \circledast C ? (Or \oast?) Try using Google to search
for that character.
Andrew
On Sun, Aug 17, 2008 at 7:01 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> Aside from "more operators needed", is there a consensus
> view among the developers?
>
> Taking a user's perspective, I see a short run and a long
> run.
>
> SR: I am very comfortable with adding dot versions of operators.
On Sun, Aug 17, 2008 at 12:14 PM, Gael Varoquaux
<[EMAIL PROTECTED]> wrote:
> On Sun, Aug 17, 2008 at 11:10:11AM -0700, Fernando Perez wrote:
>> > LR: It would be great to use unicode math operators.
>> > On this issue, Fortress is being foresightful.
>> > Accepting the "times" symbol would be a fa
On Sun, Aug 17, 2008 at 09:33:33PM +0200, Andrew Dalke wrote:
> Gaël Varoquaux wrote:
> > Anybody care for '.*'?
> That's border-line case, and probably on the bad
> idea side because 1.*2 already means something in
> normal Python. If added there would be a difference
> between
>1.*2
> and
>
Gaël Varoquaux wrote:
> Anybody care for '.*'?
That's border-line case, and probably on the bad
idea side because 1.*2 already means something in
normal Python. If added there would be a difference
between
1.*2
and
1 .*2
This problem already exists. Consider
>>> 1 .__str__()
'1'
>>> 1.
On Sun, Aug 17, 2008 at 11:10:11AM -0700, Fernando Perez wrote:
> > LR: It would be great to use unicode math operators.
> > On this issue, Fortress is being foresightful.
> > Accepting the "times" symbol would be a fairly small move
> > for most users, since it is in the Latin 1 extension of
> > A
Fernando Perez wrote:
> For something as big as this, they would
> definitely want to work off a real pep.
What might be interesting, for those who want to experiment
with this syntax, is to take my Python parser for Python
(python4ply - http://www.dalkescientific.com/Python/python4ply.html )
and
Nadav Horesh wrote:
> But would it be not-trivial to enter times ans alike
> unicode symbols within "normal" text editors? Otherwise it
> is a compelling proposition at first glance.
First, what is a "normal" text editor?
Handling utf-8 seems pretty common these days.
http://en.wikipedia.org/
But would it be not-trivial to enter times ans alike unicode symbols within
"normal" text editors? Otherwise it is a compelling proposition at first glance.
Nadav.
-הודעה מקורית-
מאת: [EMAIL PROTECTED] בשם Alan G Isaac
נשלח: א 17-אוגוסט-08 16:01
אל: Discussion of Numerical Python
נושא
On Sun, Aug 17, 2008 at 6:01 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> Aside from "more operators needed", is there a consensus
> view among the developers?
I don't think so, but given that pep 225 exists and is fully fleshed
out, I guess it should be considered the starting point of the
discu
Aside from "more operators needed", is there a consensus
view among the developers?
Taking a user's perspective, I see a short run and a long
run.
SR: I am very comfortable with adding dot versions of operators.
I am not worried about reversing the Matlab/GAUSS meanings,
but if others are very wo
> David Cournapeau wrote:
>> Does that mean we will continue breaking the ABI from time to time
>> during the 1.* cycle ?
>
Jon Wright wrote:
> Can someone help me to understand me what is the compelling reason for
> this change? If it only means everyone recompiles, it is hard to see
> what we, a
On Sun, Aug 17, 2008 at 12:51 AM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
>
>
> I have nothing against extensions when they can be made to serve. If a
> dictionary gets added to ndarrays I hope it is done that way, likewise for
> generalized ufuncs.
But that's a totally different matter. You
2008/8/17 Charles R Harris <[EMAIL PROTECTED]>:
> I have nothing against extensions when they can be made to serve. If a
> dictionary gets added to ndarrays I hope it is done that way, likewise for
> generalized ufuncs. In the present case I think Travis wants to preserve the
> functionality while
33 matches
Mail list logo
