> ∆y(P, H,L, E, I) := H * L^4 * P / (384 * E * I)
```python
Δy = lambda P, H, L, E, I: H * L**4 * P / (384 * E * I)
Δy
```
<function __main__.<lambda>(P, H, L, E, I)>
Is there a good way to redefine the '^' operator for {int, float, Decimal,
Fraction, numbers.Number}? Why would it be dangerous to monkey-patch global
types this way? Could a context manager redefine `float.__xor__ =
float.__pow_` for just that scope? Why or why not?
https://docs.python.org/3.4/library/operator.html#operator.__pow__
As far as syntactical preferences, LaTeX may be considered to be the
canonical non-executable syntax for mathematical expressions and equations.
SymPy can parse LaTeX into symbolic expressions.
Jupyter can render LaTeX embedded in Markdown.
SymPy displays expressions as LaTeX in Jupyter notebooks.
```python
from sympy import symbols
P, H, L, E, I = symbols('P, H, L, E, I')
Δy = H * L**4 * P / (384 * E * I)
Δy
```
$\frac{H L^{4} P}{384 E I}$
```python
import sympy
sympy.sympify("H*L^4*P/(384*E_*I_)")
```
$\frac{H L^{4} P}{384 E_{} I_{}}$
https://docs.sympy.org/latest/modules/core.html#sympy.core.sympify.sympify
calls parse_expr with `convert_xor=True`, by default.
https://docs.sympy.org/latest/modules/parsing.html#sympy.parsing.sympy_parser.convert_xor
:
> Treats XOR, ^, as exponentiation, **.
```python
from sympy.parsing.sympy_parser import parse_expr,
standard_transformations,\ convert_xor
trx = (standard_transformations +
(convert_xor,))
parse_expr("H*L^4*P/(384*E_*I_)", transformations=trx)
```
$\frac{H L^{4} P}{384 E_{} I_{}}$
https://docs.sympy.org/latest/modules/parsing.html#experimental-mathrm-latex-parsing
:
> LaTeX Parsing Caveats
> The current implementation is experimental. The behavior, parser backend
and API might change in the future. Unlike some of the other parsers, LATEX
is designed as a type-setting language, not a computer algebra system and
so can contain typographical conventions that might be interpreted multiple
ways
```python
from sympy.parsing.latex import parse_latex
#parse_latex(r'\frac{H L^{4} P}{384 E_{} I_{}}')
parse_latex(r'\frac{H L^{4} P}{384 E I}')
```
$\displaystyle \frac{H L^{4} P}{384 E I}$
SageMath defines ^ as operator.pow. CoCalc supports Sage notebooks as well
as Jupyter notebooks which import a CAS like SymPy, SymEngine, Diofant,
SageMath.
https://ask.sagemath.org/question/49127/what-is-sage-equivalent-to-pow-in-sympy/
...
https://www.lidavidm.me/blog/posts/2013-09-15-implicit-parsing-in-sympy.html
https://stackoverflow.com/questions/49284583/how-to-use-unicode-characters-as-variable-in-python-3/49284653
On Tue, Jun 23, 2020, 11:55 AM Ricky Teachey <ri...@teachey.org> wrote:
> On Tue, Jun 23, 2020 at 11:09 AM Rhodri James <rho...@kynesim.co.uk>
> wrote:
>
>> On 23/06/2020 15:12, Ricky Teachey wrote:
>> > On Tue, Jun 23, 2020 at 9:08 AM Mathew Elman <mathew.el...@ocado.com>
>> wrote:
>> >
>> >> Well there you go, good point.
>> >> I didn't really like it being an operator myself. But I can see having
>> a
>> >> math.tolerance class being useful.
>> >>
>> >> On Tue, 23 Jun 2020 at 13:53, Jonathan Goble <jcgob...@gmail.com>
>> wrote:
>> >>
>> >>> On Tue, Jun 23, 2020 at 8:44 AM Mathew Elman <mathew.el...@ocado.com>
>> >>> wrote:
>> >>>
>> >>>> Perhaps a more versatile operator would be to introduce a +- operator
>> >>>> that would return an object with an __eq__ method that checks for
>> equality
>> >>>> in the tolerance i.e
>> >>>>
>> >>>> a == b +- 0.5
>> >>>>
>> >>>
>> >>> This is already valid syntax, because unary minus is a thing. So this
>> is
>> >>> currently parsed as "a == b + (-0.5)".
>> >>>
>> >>> Reversing it to use -+ won't work because unary plus is also a thing.
>> >>>
>> >>
>> > A little bit out of the box, but what about:
>> >
>> > a == b +/- 0.5
>> >
>> > ...or even:
>> >
>> > a == b +or- 0.5
>>
>> Is "math.isclose(a, b, abs_tol=0.5)" really so hard to use?
>>
>
> TLDR:
>
> Of course it's not that hard to use. But the friction from "python code"
> to "mathematical calculations" is too large to make reaching for python as
> my go-to tool the first inclination. I'd really like to see this improved.
>
> I'm not strongly opinionated that this is a large, glaring need that
> simply *must* be rectified. Only that it would be VERY nice for those of us
> that use python primarily for mathematical calculations.
>
> BORING LONGER VERSION, BIT OF A RANT, SORRY:
>
> As a civil engineer, when I reach for a tool with which I am intending to
> do MATH, I generally do not reach for python right now-- even inside a
> Jupyter notebook. I reach for Mathcad or even Excel (blech).
>
> One of the biggest reasons is python code doesn't READ like real math in
> so many instances; this is a problem for me partly for my own reading, but
> also for my colleagues and clients. I would like to not have to spend a lot
> of time changing bits of the code to an output form for other
> non-programming people to read. My clients are not dumb, but if I were to
> print a jupyter notebook out and hand it to someone to read who doesn't
> know what python is, this:
>
> import math
> math.isclose(a, b, abs_tol=0.5)
>
> ...is just a step too far for them to read. So I have to use something
> else, or spend a lot of time massaging things to look more presentable.
>
> It would be nice-- for ME-- if there were ways to write functional code
> that looked more like calculations in python code. And something like +/-
> fits that bill.
>
> But I understand that not everyone-- perhaps not even close to significant
> % of people-- has the same needs I do, spending their days focused on
> producing, writing/reading mostly mathematical calculations with
> explanations. And that not everyone has the difficulty of having to present
> the math they are performing with their code to other people who are
> expecting to be reading calculations, not computer code.
>
> SIDEBAR
>
> Another BIG pain point for the "gee it would be nice if python code could
> look more like mathematical calculations" problem is the function writing
> syntax-- I love python, but sometimes I want to write a simple
> mathematical-looking structural engineering function:
>
> ∆y(P, H,L, E, I) = H * L^4 * P / (384 * E * I)
>
> ...and not:
>
> def ∆y(P, H,L, E, I):
> return H * L**4 * P / (384 * E * I)
>
> Boy would it be cool if we could use the walrus to write one-liner math
> functions!
>
> ∆y(P, H,L, E, I) := H * L^4 * P / (384 * E * I)
>
> THAT right there would change my life.
>
> ---
> Ricky.
>
> "I've never met a Kentucky man who wasn't either thinking about going home
> or actually going home." - Happy Chandler
>
>
> _______________________________________________
> 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/U4SDAOP36DV7MMPSMJOPQYVRPIMSDT5L/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
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/PX4X63GK7SXM6ZEXYXHN3RQ7FCEH4FTG/
Code of Conduct: http://python.org/psf/codeofconduct/
