On Fri, Jun 14, 2019 at 9:27 AM Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
>
> Stephen J. Turnbull wrote:
> > Note that signal matrices will almost certainly be a completely
> > different type from signals, so as far as the compiler is concerned
> > there's no conflict between "@=" for signal injection and "@=" for
> > signal matrix multiplication.
>
> Except that if @= represents signal injection for individual signals,
> it could plausibly represent elementwise signal injection for matrices
> of signals, conflicting with in-place matrix multiplication of signal
> matrices.
>
> My solution to this would be not to use @ for matrix multiplication of
> signals at all, and represent it some other way. But it seems that
> Yanghao doesn't even want to compromise that far.
I could actually use @, @= operators, the problem is matrix dot
operation can result to a single value:
# In octave, try this:
dot([1 2 3], [1,2,3]) # ==> ans = 14
However we could also say the answer is a 1 x 1 matrix [14] (e.g. a
different type), The general problem is always we have to force end
user to think a general python numeric operator means something
completely different, and cause even more trouble if they have to use
@= as matrix operator in the same context as a DSL.
I just realized "L[:] = thing" can be properly executed as "L _space_
[:]= thing", causing the illusion that "[:]=" is an operator ;-) I am
thinking hard now if this can be a proper compromise (just one more
char to type than <==) .... There is a very common use case that a
signal, say 32bits, in HDL it is a very common operation to extract a
subset of bits (think about CPU decoding logic), and the normal
__getitem__(self, key) can be used for this. And here I can just
define: signal[:] means assignment to the whole signal (key ==
slice(None, None, None)). Such that only this slice(None, None, None)
case is re-interpreted and causing an assignment on signals, whereas
the usual signal slicing with concrete boundary/step parameters still
works. And when one wants to refer to the entire signal, just use the
signal without [:] (e.g. you cannot use signal[:] to refer to the
original signal, use signal instead).
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ONMCQXTYNRBTG2A64G36ENTRRQ4YPZTE/
Code of Conduct: http://python.org/psf/codeofconduct/
