[Numpy-discussion] SVG Logo of NumPy

[Christophe Bal]

Hello,
is there a SVG version of the NumPy logo ? This would be to be used on my
website.

Christophe BAL
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] SVG Logo of NumPy

[Christophe Bal]

Sorry for my no-brain question. ;-)

Thanks for the link.


2014-03-10 10:46 GMT+01:00 Pierre Haessig :

> Le 10/03/2014 10:38, Christophe Bal a écrit :
> > is there a SVG version of the NumPy logo ? This would be to be used on
> > my website.
> Could it be one of those
> https://github.com/numpy/numpy/tree/master/branding/icons ?
> (don't know if it's up to date though)
>
> best,
> Pierre
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] It looks like Py 3.5 will include a dedicated infix matrix multiply operator

[Christophe Bal]

This id good for Numpyists but this will be another operator that good also
help in another contexts.

As a math user, I was first very skeptical but finally this is a good news
for non Numpyists too.

Christophe BAL
Le 15 mars 2014 02:01, "Frédéric Bastien"  a écrit :

> This is great news. Excellent work Nathaniel and all others!
>
> Frédéric
>
> On Fri, Mar 14, 2014 at 8:57 PM, Aron Ahmadia  wrote:
> > That's the best news I've had all week.
> >
> > Thanks for all your work on this Nathan.
> >
> > -A
> >
> >
> > On Fri, Mar 14, 2014 at 8:51 PM, Nathaniel Smith  wrote:
> >>
> >> Well, that was fast. Guido says he'll accept the addition of '@' as an
> >> infix operator for matrix multiplication, once some details are ironed
> >> out:
> >>   https://mail.python.org/pipermail/python-ideas/2014-March/027109.html
> >>   http://legacy.python.org/dev/peps/pep-0465/
> >>
> >> Specifically, we need to figure out whether we want to make an
> >> argument for a matrix power operator ("@@"), and what
> >> precedence/associativity we want '@' to have. I'll post two separate
> >> threads to get feedback on those in an organized way -- this is just a
> >> heads-up.
> >>
> >> -n
> >>
> >> --
> >> Nathaniel J. Smith
> >> Postdoctoral researcher - Informatics - University of Edinburgh
> >> http://vorpus.org
> >> ___
> >> NumPy-Discussion mailing list
> >> NumPy-Discussion@scipy.org
> >> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >
> >
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [RFC] should we argue for a matrix power operator, @@?

[Christophe Bal]

Hello.

Maybe a solution would be to not see @ and @@ only from the matrix point of
view.

Why ? The philosophy of Python is to give total control of the infix
operators +, * and ** for example via the magic methods. So it can be also
the case for @ and @@ that could be use for something else
that @@.

So what we can expect from A@@B@@C. I will say that is the same as a**b**c
because a human goes from top to down (but this is not a general convention
in CAS).

Ok guy but what can we do for . Just raises an
error. The programmer has the possibility to use @@ as ** but it has to
take care of the meaning regarding to the types of the objects. This is for
example what we expect for @@pi even if we mathematically can give
a meaning to that for some matrices.

Do not forget also that a direct computation of the inverse of a matrice is
a complicated things, and that integer power of matrices have to be
cleverly build, but I'm sure that everyones here know that.

*So standard Python can...*

   - only proposes multiplication of matrices,
   - and for the power of matrices, just indicates that there is a magic
   method associated to @@ and explains that regarding to the complexity of
   this problem, it will be the job of the programmer to implement it.


I think the problem from Guido's point of view is the asymmetrical type
domain for operations. All the numeric operators are from *
to .

Hoping that my frenchy english is clear enough.
Chrisopthe BAL


PS: maybe a good question for Python would be to see if other operators
could be useful. For CAS, I would like to have the possibility to use f°g
for composition, even if it is more for pedagogical reason, and f°°n for
dynamical systems. But this is just a dream...


2014-03-15 6:39 GMT+01:00 Jaime Fernández del Río :

> On Fri, Mar 14, 2014 at 9:32 PM, Nathaniel Smith  wrote:
>
>>
>> Here are the interesting use cases for @@ that I can think of:
>> - 'vector @@ 2' gives the squared Euclidean length (because it's the
>> same as vector @ vector). Kind of handy.
>> - 'matrix @@ n' of course gives the matrix power, which is of marginal
>> use but does come in handy sometimes, e.g., when looking at graph
>> connectivity.
>> - 'matrix @@ -1' provides a very transparent notation for translating
>> textbook formulas (with all their inverses) into code. It's a bit
>> unhelpful in practice, because (a) usually you should use solve(), and
>> (b) 'matrix @@ -1' is actually more characters than 'inv(matrix)'. But
>> sometimes transparent notation may be important. (And in some cases,
>> like using numba or theano or whatever, 'matrix @@ -1 @ foo' could be
>> compiled into a call to solve() anyway.)
>>
>> (Did I miss any?)
>>
>
> I'm not really arguing for it, and I am not sure how, or even if, it fits
> in the general scheme. But for completeness sake, 'e @@ Matrix' is used in
> some treatments of linear systems of differential equations, where:
>
> d/dt =  @ 
>
> would have solution
>
>  = e @@ ( * t) @ 
>
> I don't think it makes any sense to use it as such in the context of
> numpy, as I think it would make broadcasting undecidable. But there may be
> parallel universes where having n @@  and  @@ n both with
> well defined, yet different meanings may make sense. It is my impression
> that in this entirely made up scenario you would want e @@ A @@ 3 to be
> evaluated as (e @@ A) @@ 3. Which probably has more to do with the fact
> that the two @@ mean different things, than with the associativity that
> repeated calls to the same @@ should have.
>
> Personally I couldn't care less, and if I had a vote I would let @@ rest
> for now, until we see how @ plays out.
>
> Jaime
>
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

Hello,
and what about something like that ?

a @ b @ c  ->  (a @ b) @ c
a * b @ c  ->  (a * b) @ c
a @ b * c  ->  a @ (b * c)

Easy to remember. The *-product has priority to @-product, and then we just
to @-product from left to right.

An advantage of this is that parsers do job from left to right so I realy
think that is a better choice than the weak-right.

Christophe BAL



2014-03-17 21:37 GMT+01:00 Russell E. Owen :

> In article
> ,
>  Nathaniel Smith  wrote:
>
> > OPTION 1 FOR @:
> > Precedence: same as *
> > Associativity: left
> > My shorthand name for it: "same-left" (yes, very creative)
> >
> > This means that if you don't use parentheses, you get:
> >a @ b @ c  ->  (a @ b) @ c
> >a * b @ c  ->  (a * b) @ c
> >a @ b * c  ->  (a @ b) * c
> >
> > OPTION 2 FOR @:
> > Precedence: more-weakly-binding than *
> > Associativity: right
> > My shorthand name for it: "weak-right"
> >
> > This means that if you don't use parentheses, you get:
> >a @ b @ c  ->  a @ (b @ c)
> >a * b @ c  ->  (a * b) @ c
> >a @ b * c  ->  a @ (b * c)
> >
> > OPTION 3 FOR @:
> > Precedence: more-tightly-binding than *
> > Associativity: right
> > My shorthand name for it: "tight-right"
> >
> > This means that if you don't use parentheses, you get:
> >a @ b @ c  ->  a @ (b @ c)
> >a * b @ c  ->  a * (b @ c)
> >a @ b * c  ->  (a @ b) * c
> >
> > We need to pick which of which options we think is best, based on
> whatever
> > reasons we can think of, ideally more than "hmm, weak-right gives me warm
> > fuzzy feelings" ;-). (In principle the other 2 possible options are
> > tight-left and weak-left, but there doesn't seem to be any argument in
> > favor of either, so we'll leave them out of the discussion.)
>
> After seeing all the traffic on this thread, I am in favor of
> "same-left" because it is easiest to remember:
> - It introduces no new rules.
> - It is unambiguous. If we pick option 2 or 3 we have no strong reason
> to favor one over the other, leaving users to guess.
>
> To my mind, being able to easily reason about code you are reading is
> more important that hoping to increase efficiency for one common case
> when not using parenthesis.
>
> It also has the advantage that it needs the least justification.
>
> -- Russell
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

Sorry for all the misspellings...


2014-03-17 22:32 GMT+01:00 Christophe Bal :

> Hello,
> and what about something like that ?
>
> a @ b @ c  ->  (a @ b) @ c
> a * b @ c  ->  (a * b) @ c
> a @ b * c  ->  a @ (b * c)
>
> Easy to remember. The *-product has priority to @-product, and then we
> just to @-product from left to right.
>
> An advantage of this is that parsers do job from left to right so I realy
> think that is a better choice than the weak-right.
>
> Christophe BAL
>
>
>
> 2014-03-17 21:37 GMT+01:00 Russell E. Owen :
>
> In article
>> ,
>>  Nathaniel Smith  wrote:
>>
>> > OPTION 1 FOR @:
>> > Precedence: same as *
>> > Associativity: left
>> > My shorthand name for it: "same-left" (yes, very creative)
>> >
>> > This means that if you don't use parentheses, you get:
>> >a @ b @ c  ->  (a @ b) @ c
>> >a * b @ c  ->  (a * b) @ c
>> >a @ b * c  ->  (a @ b) * c
>> >
>> > OPTION 2 FOR @:
>> > Precedence: more-weakly-binding than *
>> > Associativity: right
>> > My shorthand name for it: "weak-right"
>> >
>> > This means that if you don't use parentheses, you get:
>> >a @ b @ c  ->  a @ (b @ c)
>> >a * b @ c  ->  (a * b) @ c
>> >a @ b * c  ->  a @ (b * c)
>> >
>> > OPTION 3 FOR @:
>> > Precedence: more-tightly-binding than *
>> > Associativity: right
>> > My shorthand name for it: "tight-right"
>> >
>> > This means that if you don't use parentheses, you get:
>> >a @ b @ c  ->  a @ (b @ c)
>> >a * b @ c  ->  a * (b @ c)
>> >a @ b * c  ->  (a @ b) * c
>> >
>> > We need to pick which of which options we think is best, based on
>> whatever
>> > reasons we can think of, ideally more than "hmm, weak-right gives me
>> warm
>> > fuzzy feelings" ;-). (In principle the other 2 possible options are
>> > tight-left and weak-left, but there doesn't seem to be any argument in
>> > favor of either, so we'll leave them out of the discussion.)
>>
>> After seeing all the traffic on this thread, I am in favor of
>> "same-left" because it is easiest to remember:
>> - It introduces no new rules.
>> - It is unambiguous. If we pick option 2 or 3 we have no strong reason
>> to favor one over the other, leaving users to guess.
>>
>> To my mind, being able to easily reason about code you are reading is
>> more important that hoping to increase efficiency for one common case
>> when not using parenthesis.
>>
>> It also has the advantage that it needs the least justification.
>>
>> -- Russell
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

Here is the translation. ;-)

Hello,
and what about something like that ?

*a @ b @ c  ->  (a @ b) @ c*
*a * b @ c  ->  (a * b) @ c*
*a @ b * c  ->  a @ (b * c)*

Easy to remember: the *-product has priority regarding to the @-product,
and we just do @-product from left to right.

An advantage of this is that most parsers do analyze from left to right.

So I really think that it is a better choice than the weak-right one.

Christophe BAL


2014-03-17 22:34 GMT+01:00 Christophe Bal :

> Sorry for all the misspellings...
>
>
> 2014-03-17 22:32 GMT+01:00 Christophe Bal :
>
> Hello,
>> and what about something like that ?
>>
>> a @ b @ c  ->  (a @ b) @ c
>> a * b @ c  ->  (a * b) @ c
>> a @ b * c  ->  a @ (b * c)
>>
>> Easy to remember. The *-product has priority to @-product, and then we
>> just to @-product from left to right.
>>
>> An advantage of this is that parsers do job from left to right so I realy
>> think that is a better choice than the weak-right.
>>
>> Christophe BAL
>>
>>
>>
>> 2014-03-17 21:37 GMT+01:00 Russell E. Owen :
>>
>> In article
>>> ,
>>>  Nathaniel Smith  wrote:
>>>
>>> > OPTION 1 FOR @:
>>> > Precedence: same as *
>>> > Associativity: left
>>> > My shorthand name for it: "same-left" (yes, very creative)
>>> >
>>> > This means that if you don't use parentheses, you get:
>>> >a @ b @ c  ->  (a @ b) @ c
>>> >a * b @ c  ->  (a * b) @ c
>>> >a @ b * c  ->  (a @ b) * c
>>> >
>>> > OPTION 2 FOR @:
>>> > Precedence: more-weakly-binding than *
>>> > Associativity: right
>>> > My shorthand name for it: "weak-right"
>>> >
>>> > This means that if you don't use parentheses, you get:
>>> >a @ b @ c  ->  a @ (b @ c)
>>> >a * b @ c  ->  (a * b) @ c
>>> >a @ b * c  ->  a @ (b * c)
>>> >
>>> > OPTION 3 FOR @:
>>> > Precedence: more-tightly-binding than *
>>> > Associativity: right
>>> > My shorthand name for it: "tight-right"
>>> >
>>> > This means that if you don't use parentheses, you get:
>>> >a @ b @ c  ->  a @ (b @ c)
>>> >a * b @ c  ->  a * (b @ c)
>>> >a @ b * c  ->  (a @ b) * c
>>> >
>>> > We need to pick which of which options we think is best, based on
>>> whatever
>>> > reasons we can think of, ideally more than "hmm, weak-right gives me
>>> warm
>>> > fuzzy feelings" ;-). (In principle the other 2 possible options are
>>> > tight-left and weak-left, but there doesn't seem to be any argument in
>>> > favor of either, so we'll leave them out of the discussion.)
>>>
>>> After seeing all the traffic on this thread, I am in favor of
>>> "same-left" because it is easiest to remember:
>>> - It introduces no new rules.
>>> - It is unambiguous. If we pick option 2 or 3 we have no strong reason
>>> to favor one over the other, leaving users to guess.
>>>
>>> To my mind, being able to easily reason about code you are reading is
>>> more important that hoping to increase efficiency for one common case
>>> when not using parenthesis.
>>>
>>> It also has the advantage that it needs the least justification.
>>>
>>> -- Russell
>>>
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>
>>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

I think that weak-left is a little strange, just think a little of the
operators used by mathematicians that always follow a hierarchy.

A parser is mostly done using grammars : see
http://docs.python.org/3.1/reference/grammar.html.

Defining *-product to have stronger priority than the @-product, and this
last having stronger priority than +, will make the changes in the grammar
easier.

I'm now convinced of the usefulness of @ and @@ too but I also think that
you must think of other uses than only for numpy. In other words, numpy is
a the good argument for this new operators, but this can also open new
perspectives for other uses.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

First of all I'm must be very tired because I've written *"I think that
weak-left is a little strange..."* instead of *"I think that same-left is a
little strange..."*. It is the night in french... ;-)

So I'm definitely for the weak-left !

Here is my answer to Alexander Belopolsky.

You are right from a grammar point of view but for a human this looks too
weird because * and @ are of different kinds contrary to * and / for
example.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

If you see the operators as following a hierarchy, the answer is simply yes.


2014-03-18 0:16 GMT+01:00 Bago :

>
>> I'm now convinced of the usefulness of @ and @@ too but I also think that
>> you must think of other uses than only for numpy. In other words, numpy is
>> a the good argument for this new operators, but this can also open new
>> perspectives for other uses.
>>
>>
> Speaking of `@@`, would the relative precedence of @ vs * be the same as
> @@ vs **?
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

>>> This follows the principle that it's better to be great
>>> at some things than to be mediocre at everything.

You're right.


>>> >>> I think that weak-left is a little strange, just think
>>> >>> a little of the operators used by mathematicians that
>>> >>> always follow a hierarchy.

>>> Not sure what you mean -- I don't think most mathematicians
>>> think that scalar and matrix multiplication are above or below
>>> each other in precedence, for example.

You're right but on the other hand, I've never seen mixed use of matrix and
scalar products without parenthesis... Indeed in math, we can use < Au , Bv
> for the scalar product of two matrix-vector products.

But here, I think that the situation is different because we are talking
about operators from arrays to array : mainly @ , * and + (elementwise for
the two last). Whereas in the preceding example, the scalar product is from
arrays to scalar.

As a math user, I think at this point that the arrays-to-array operators
must follows a hierarchy.

Who is the guy who have asked such a complicated question about precedence
? :-)



2014-03-18 0:30 GMT+01:00 Nathaniel Smith :

> On Mon, Mar 17, 2014 at 10:33 PM, Christophe Bal 
> wrote:
> > I think that weak-left is a little strange, just think a little of the
> > operators used by mathematicians that always follow a hierarchy.
>
> Not sure what you mean -- I don't think most mathematicians think that
> scalar and matrix multiplication are above or below each other in
> precedence, for example. (Well, it's a strange question because scalar
> multiplication commutes, but even so, people often forget that these
> are even different operations.)
>
> > A parser is mostly done using grammars : see
> > http://docs.python.org/3.1/reference/grammar.html.
> >
> > Defining *-product to have stronger priority than the @-product, and this
> > last having stronger priority than +, will make the changes in the
> grammar
> > easier.
> >
> > I'm now convinced of the usefulness of @ and @@ too but I also think that
> > you must think of other uses than only for numpy. In other words, numpy
> is a
> > the good argument for this new operators, but this can also open new
> > perspectives for other uses.
>
> No, that's not how this game is played :-). The way it works is, we
> figure out the best possible way to handle the use case that we've
> demonstrated a need for (matrix multiplication), and then once we've
> done that someone might or might not find some other uses too. If they
> do then cool, if not then too bad. This follows the principle that
> it's better to be great at some things than to be mediocre at
> everything.
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

*About weak-left.* You need to define a priority of @ the matrix product
regarding to * the elementwise product because (A*B)@C <> A*(B@C) : see the
example above. I say that also from a mathematical point of view.

Using mathematical like notations, Matrix1 * Matrix2 * 3 can be written
because (Matrix1 * Matrix2) * 3 = Matrix1 * (Matrix2 * 3).

That's why I think that the weak-left is the better choice.

*About group implementation.* I think the idea of calculating A@B@C as
__atmul__([A,B,C]) is a very good idea because this allows efficient
implementations.

*-*
*[1 2]*
*A = [3 4]*

*[5 6]*
*B = [7 8]*

*[a d]*
*C = [b c]*

*-*
*(A*B)@C*
*=*
*[5  12]   [a d]*
*[21 32] @ [b c]*
*=*
*[5a+12b  5d+12c ]*
*[21a+32b 21d+32c]*

*-*
*A*(B@C)*
*=*
*[1 2]   [5a+6b 5d+6c]*
*[3 4] * [7a+8b 7d+8c]*
*=*
*[5a+6b   10d+12c]*
*[21a+24b 28d+32c]*



2014-03-18 10:50 GMT+01:00 Eelco Hoogendoorn :

> To elaborate a little on such a more general and explicit method of
> specifying linear operations (perhaps 'expressions with named axes' is a
> good nomer to cover this topic).
>
> I think indexing rather than calling is preferable. I worried at first
> about the performance overhead of checking for strings at every indexing
> op, but get ndarray__getitem__ is already quite a complex beast anyway, and
> adding (yet another) type test on its args isn't a significant difference.
> For those who disagree; we could also approach strings with a 'forgiveness
> is better then permission' attitude.
>
> The general rules could be: if no string args, everything works as normal.
> In case of string args, we may think of the effect of __getitem__ as
> indexing with strings replaced by colons first, and then creating a
> NamedAxisIndexExpression (NAIE), associating the given string label with
> each corresponding axis. Thus, we can write things like A[0:3,'i']
>
> As some additional rules; string arguments can be 'expanded', the string
> is split on commas if present, and otherwise split into characters, which
> are then the axis labels.
>
> In expressions, all non-labeled axes are treated in sequential order,
> similar to the ... construct, and have standard numpy broadcasting
> semantics.
>
> The only problem with [] notation is field name lookup; though I have
> always felt that tables with named columns should be an ndarray subtype,
> given their fundamentally different indexing semantics.
>
> Realizing the full potential of such an approach would be a complex
> undertaking, but to start with, a more elegant interface to np.einsum would
> be rather easy to implement.
>
>
> On Tue, Mar 18, 2014 at 9:46 AM, Sebastian Haase wrote:
>
>> Just add one vote:  I am for
>> * right association *
>> because  1) I'm thinking of matrix multiplication more like operators,
>> which I also learned to work from right to left and because 2) I would
>> put a vector to the right, which would result in better performance.
>>
>> I don't have an opinion on tight/same/ or weak (maybe that means
>> then 'same' because it's easier to remember !?)
>>
>> My two cents,
>> Sebastian Haase
>>
>>
>> On Tue, Mar 18, 2014 at 7:13 AM, Eelco Hoogendoorn
>>  wrote:
>> >
>> >
>> > Perhaps this a bit of a thread hyjack; but this discussion got me
>> thinking
>> > about how to arrive
>> >
>> > at a more vectorized/tensorified way of specifying linear algebra
>> > operations, in an elegant manner.
>> >
>> > I probably got a little carried away, but what about this syntax?
>> >
>> > indexing/calling an ndarray with a string returns a TensorExpression
>> object
>> > these TensorExpression objects can be combined into a graph using
>> operator
>> > overloads
>> > and these graphs are translated to calls to BLAS or einsum, as is
>> > appropriate
>> >
>> >
>> > #declare some symbols
>> > i,j,ij,k = 'i','j','ij','k'
>> > #we may force evaluation of a (sub) TensorExpression by calling it
>> > #this is trivial to translate to call to einsum
>> > #but such special cases could be dispatched to BLAS as well
>> > b = (A(ij) * x(j)) (i)
>> > #alternatively, we can predeclare a LHS which is automatically sized
>> later
>> > #note that this translates into the same call as the above; just some
>> > syntactic sugar
>> > b = np.empty(())
>> > b[i] = A(ij) * x(j)
>> > #more complex TensorExpression graphs of this form are trivial to
>> translate
>> > to a call to einsum as well
>> > a(i)*b(j)*c(k)
>> > #conceptually, there is no need to limit this scheme to multiplications
>> > only!
>> > #although such generalizations would require a more complex execution
>> engine
>> > #however, the revamped nditer should make this quite managable to
>> implement
>> > a(i)*b(j) + c(k)
>> > #if axes strings are omitted, standard numpy broadcasting rules are
>> applied
>> > to the expressiongraph created
>> > #this is identical to a*b+c; except that we have the opportunity to
>> > eliminate temporaries
>> > a()*b()+c()
>> >
>> >
>> > 

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

Strange, Gmail has cut my example.

Here it is normally.

*[1 2]*
*A = [3 4]*

*[5 6]*
*B = [7 8]*

*[a d]*
*C = [b c]*

*(A*B)@C*
*=*
*[5  12]   [a d]*
*[21 32] @ [b c]*
*=*
*[5a+12b  5d+12c ]*
*[21a+32b 21d+32c]*

*A*(B@C)*
*=*
*[1 2]   [5a+6b 5d+6c]*
*[3 4] * [7a+8b 7d+8c]*
*=*
*[5a+6b   10d+12c]*
*[21a+24b 28d+32c]*


2014-03-18 16:29 GMT+01:00 Robert Kern :

> On Tue, Mar 18, 2014 at 3:22 PM, Christophe Bal 
> wrote:
> > About weak-left. You need to define a priority of @ the matrix product
> > regarding to * the elementwise product because (A*B)@C <> A*(B@C) : see
> the
> > example above. I say that also from a mathematical point of view.
>
> What example above?
>
> > Using mathematical like notations, Matrix1 * Matrix2 * 3 can be written
> > because (Matrix1 * Matrix2) * 3 = Matrix1 * (Matrix2 * 3).
>
> This seems to argue against what you just said.
>
> > That's why I think that the weak-left is the better choice.
>
> But this is true as well:
>
>   3 * Matrix1 * Matrix2 = (3 * Matrix1) * Matrix2 = 3 * (Matrix1 * Matrix2)
>
> Does that expression argue for tight-left?
>
> --
> Robert Kern
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

When I write "using mathematical like notations...", Matrix1 * Matrix2 is a
matrix multiplication.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

This is a different situation because / is indeed an hidden multiplication
: a/b = a*inv(b). The same is true for + and - : a-b=a+opp(b). What I'm
saying is that these operations * and / are indeed of the very same j-kind.

This is not the same for * and @.


2014-03-18 17:53 GMT+01:00 Nathaniel Smith :

> On Tue, Mar 18, 2014 at 3:22 PM, Christophe Bal 
> wrote:
> > About weak-left. You need to define a priority of @ the matrix product
> > regarding to * the elementwise product because (A*B)@C <> A*(B@C)
>
> This doesn't follow.  (a / b) * c != a / (b * c), but / and * in
> Python have the same priority.
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

I think that there is very big misunderstanding. My point of view is both a
mathematical and a programmagical one.
Le 18 mars 2014 20:20, "Nathaniel Smith"  a écrit :

> On 18 Mar 2014 17:32, "Christophe Bal"  wrote:
> >
> > This is a different situation because / is indeed an hidden
> multiplication : a/b = a*inv(b). The same is true for + and - :
> a-b=a+opp(b). What I'm saying is that these operations * and / are indeed
> of the very same j-kind.
> >
> > This is not the same for * and @.
>
> // (floordiv) isn't equivalent to a multiplication, but it is also at the
> same level. << and >> aren't inverses, but they are at the same level. 'in'
> and 'is' are not even the same type (they have totally different
> requirements on their right argument) but they are at the same level.
> Whatever choice we make needs to be something we can justify, and our
> justification should probably not imply that all of python's other
> operators are wrong ;-).
>
> -n
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [help needed] associativity and precedence of '@'

[Christophe Bal]

I'm not saying that Python choices are wrong, I'm just saying that if * is
elementwise product, then (A*B)@C <> A*(B@C) should imply to choose
different levels fro * and @.

By choosing A*B@C = (A*B)@C, that is a convention, we just say that a human
who want to calculate something like A*B@C*D@E@G*H*K will have to start
first with the elementwise products and then finish by the matrix product
that is to say this human will evaluate (A*B)@(C*D)@E@(G*H*K).

Maybe you should argue to calculate first the @-products but this will not
be a good choice if * is the product of a scalar with a matrix like in 2*A@3
*B.

*On the other hand, if you calculate from left to right, there will be a
lot of isolate @-products to do instead of doing a single one. This will
not allow to use the very good group technic you have proposed.*

1) If A*B@C*D@E@G*H*K = (A*B)@(C*D)@E@(G*H*K), you quickly evaluate
first X = A*B, Y = C*D and Z = G*H*K, and then you can do an efficient
@-product of X, Y and Z.

2) If you calculate from left to right, you will do three @-products on
couple without having the possibility to choose the more efficient way to
evaluate the @-products.

Christophe BAL


PS1: // is an approximate calculation of the exact mathematical inversion,
so it is not really a counter example.


PS2: here is a second time my example showing that (A*B)@C <> A*(B@C).

*[1 2]*
*A = [3 4]*

*[5 6]*
*B = [7 8]*

*[a d]*
*C = [b c]*

*(A*B)@C*
*=*
*[5  12]   [a d]*
*[21 32] @ [b c]*
*=*
*[5a+12b  5d+12c ]*
*[21a+32b 21d+32c]*

*A*(B@C)*
*=*
*[1 2]   [5a+6b 5d+6c]*
*[3 4] * [7a+8b 7d+8c]*
*=*
*[5a+6b   10d+12c]*
*[21a+24b 28d+32c]*
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Resolving the associativity/precedence debate for @

[Christophe Bal]

The left associativity should be the less disturbing choice.

Using parenthesis to force right associativity will be not too painful. How
many matrices in long product are involved concretely in Numpy projects ?

On the other hand, Nathaniel proposed a new way to evaluate associative
operators, and I really think that would be the best way to manage products
of matrices. The idea is fir example to see A@B@C@D as __atmul__(A, B, C,
D).

Christophe BAL
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] PEP 465 has been accepted / volunteers needed

[Christophe Bal]

Hello,
I really think that add a new operator @  is not a good thing.

Sorry I just want to make a joke... ;-)

Christophe BAL


2014-04-10 15:11 GMT+02:00 :

> On Thu, Apr 10, 2014 at 4:43 AM, Francesc Alted  wrote:
> > On 4/9/14, 10:46 PM, Chris Barker wrote:
> >> On Tue, Apr 8, 2014 at 11:14 AM, Nathaniel Smith  >> <mailto:n...@pobox.com>> wrote:
> >>
> >> Thank you! Though I suspect that the most important part of my
> >> contribution may have just been my high tolerance for writing emails
> >> ;-).
> >>
> >>
> >> no -- it's your high tolerance for _reading_ emails...
> >>
> >> Far too many of us have a high tolerance for writing them!
> >
> > Ha ha, very true!
>
> I'm trying, but it's hard.
> Sometimes avoiding the `send` button helps. I still have a collection
> of draft replies.
>
> Josef
> "I'm not going to send this reply" -- oops, did it again
>
> >
> > --
> > Francesc Alted
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Christophe Bal]

Hello.

Can you give an example where GOTO is useful ?
Le 24 sept. 2015 07:24, "Charles R Harris"  a
écrit :

> At last, goto for python !
>
> Usage:
>
> from goto import with_goto
>
> @with_goto
> def range(start, stop):
> i = start
> result = []
>
> label .begin
> if i == stop:
> goto .end
>
> result.append(i)
> i += 1
> goto .begin
>
> label .end
> return result
>
>
> HT: LWN
>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Christophe Bal]

To be honest, I am not very conviced. Does someone can give a pseudo
example ?
Le 24 sept. 2015 20:50, "Benjamin Root"  a écrit :

> Most of the time when I wanted to use goto in my early days, I found that
> breaks and continues were better and easier to understand. I will admit
> that there are occasional nested if/elif/else code that get messy without a
> goto. But which smells worse? A "goto" package or a complex if/elif/else?
>
> Ben Root
>
> On Thu, Sep 24, 2015 at 2:41 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak 
>> wrote:
>>
>>>
>>>
>>> On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
>>> alex.eberspaec...@gmail.com> wrote:
>>>
>>>> On 24.09.2015 13:25, Christophe Bal wrote:
>>>>
>>>> > Can you give an example where GOTO is useful ?
>>>>
>>>> I think those pieces of code are best understood with some humour..
>>>>
>>>> However, basically I can think two main causes for using goto:
>>>>
>>>> 1. Stop whatever your code is doing and jump towards the end of the
>>>> program. However, this is mainly something useful for languages without
>>>> exception handling and garbage collection.
>>>>
>>>> 2. Get out of something deeply nested. Also, this probably isn't very
>>>> useful in Python as there's exception handling.
>>>>
>>>
>>> I think there are more valid uses - I've read that "goto" basically is
>>> what a state machine does.
>>> Have a read of the brief implementation notes for "goto" in golang, for
>>> example.  Goto may not be unreasonable to use, just most people would
>>> abuse.  Sort of like "everyone shouldn't write assembly, but if you
>>> understand the machine, you can make good things happen".  Without
>>> compiler/interpreter checks, more responsibility rests on the coder to keep
>>> out of trouble.
>>>
>>
>> I would agree about state machines. When implemented using the standard
>> control flow constructs they always look a bit artificial.
>>
>> Chuck
>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Christophe Bal]

By pseudo example, I mean pseudo code.
Le 24 sept. 2015 20:56, "Christophe Bal"  a écrit :

> To be honest, I am not very conviced. Does someone can give a pseudo
> example ?
> Le 24 sept. 2015 20:50, "Benjamin Root"  a écrit :
>
>> Most of the time when I wanted to use goto in my early days, I found that
>> breaks and continues were better and easier to understand. I will admit
>> that there are occasional nested if/elif/else code that get messy without a
>> goto. But which smells worse? A "goto" package or a complex if/elif/else?
>>
>> Ben Root
>>
>> On Thu, Sep 24, 2015 at 2:41 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
>>>> alex.eberspaec...@gmail.com> wrote:
>>>>
>>>>> On 24.09.2015 13:25, Christophe Bal wrote:
>>>>>
>>>>> > Can you give an example where GOTO is useful ?
>>>>>
>>>>> I think those pieces of code are best understood with some humour..
>>>>>
>>>>> However, basically I can think two main causes for using goto:
>>>>>
>>>>> 1. Stop whatever your code is doing and jump towards the end of the
>>>>> program. However, this is mainly something useful for languages without
>>>>> exception handling and garbage collection.
>>>>>
>>>>> 2. Get out of something deeply nested. Also, this probably isn't very
>>>>> useful in Python as there's exception handling.
>>>>>
>>>>
>>>> I think there are more valid uses - I've read that "goto" basically is
>>>> what a state machine does.
>>>> Have a read of the brief implementation notes for "goto" in golang, for
>>>> example.  Goto may not be unreasonable to use, just most people would
>>>> abuse.  Sort of like "everyone shouldn't write assembly, but if you
>>>> understand the machine, you can make good things happen".  Without
>>>> compiler/interpreter checks, more responsibility rests on the coder to keep
>>>> out of trouble.
>>>>
>>>
>>> I would agree about state machines. When implemented using the standard
>>> control flow constructs they always look a bit artificial.
>>>
>>> Chuck
>>>
>>>
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Christophe Bal]

Very funny !  😂
Le 25 sept. 2015 07:53, "Alexander Eberspächer" 
a écrit :

> On 24.09.2015 21:12, Charles R Harris wrote:
>
> > I find Cleve Moler's old Fortran version of Brent's zero finding
> > algorithm using gotos clearer than the structured versions you can find
> > in Numerical Recipes. The operation of the algorithm is easiest to
> > describe as a finite state machine.
>
> I need to look into that piece of Fortran code. I've never (knowingly)
> implemented a state-machine myself. However I can say that specifically
> Fortran has named loops, which probably helps to avoid many uses of goto.
>
> > However, the post was for laughs, I didn't expect serious discussion.
>
> Well, then let me fill in the missing piece - the obligatory XKCD strip:
>
> https://www.xkcd.com/292/
>
> Alex
>
>
>
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion