I agree with your assessment.
Here's my minimum working example where I don't use eval(str()) and get the
problem.
>>> import sys
>>> sys.version
'3.6.9 (default, Apr 18 2020, 01:56:04) \n[GCC 8.4.0]'
>>> import sympy
>>> sympy.__version__
'1.5.1'
>>> from sympy.physics.units import mass,
Why are you using eval(str(eq.lhs))? That should just give back eq.lhs.
Aaron Meurer
On Wed, May 27, 2020 at 6:35 PM Ben wrote:
>
> Thanks Aaron for your help.
>
> With your guidance, I solved my problem (though my use of eval() feels hacky).
>
> >>> import sympy
> >>> from sympy.physics.units
Thanks Aaron for your help.
With your guidance, I solved my problem (though my use of eval() feels
hacky).
>>> import sympy
>>> from sympy.physics.units import mass, length, time
>>> from sympy.physics.units.systems.si import dimsys_SI
>>> from sympy.parsing.latex import parse_latex
>>> eq =
You're right that you have to define the Python variable name to
access F like that. See
https://docs.sympy.org/latest/tutorial/gotchas.html.
You can get all the symbols in an expression with eq.free_symbols. Or
if you know the symbol is F you can just set
F = symbols('F')
since symbols with
I got that.
:members: only shows non private methods.
I got that when I read the document on autodoc again.
Is that right?
On Thursday, May 28, 2020 at 1:55:01 AM UTC+5:30, Mohit Shah wrote:
>
> [image: SympyAssumption2.PNG]
> It is something like this.
>
> But recently, I saw that I am getting
I got that.
:members: only shows non private methods.
I got that when I read the document on autodoc again.
Thanks.
On Thursday, May 28, 2020 at 1:55:01 AM UTC+5:30, Mohit Shah wrote:
>
> [image: SympyAssumption2.PNG]
> It is something like this.
>
> But recently, I saw that I am getting some
Yes, I tried that as well.
I don't know how but when I cloned the project again from github, It worked.
Thanks for the help.
On Wednesday, May 27, 2020 at 10:08:36 PM UTC+5:30, S.Y. Lee wrote:
>
> Have you tried
> sudo apt-get update
>
>
> On Tuesday, May 26, 2020 at 10:49:46 PM UTC+9, Mohit Shah
Hello,
I have a string written in Latex for which I know the dimensions of each
symbol. My goal is to validate the dimensional consistency of the
expression. I'm having trouble with substitution. For example,
>>> from sympy.physics.units import mass, length, time
>>> from
I think we can modify the backend, but we should be prepared as
mentors to do the programming work. Conversely, I don't know if it
would make sense to make any changes without feedback from a technical
writer if we are going to get one, so I don't know if it makes sense
to do anything like this
It just gives an another reason to hurry up setting up the static web
framework.
Unfortunately, I don't think that it is possible to edit sympy.org than
messing with html files, besides the translations, so it will not be easy
for technical writers.
On Tuesday, May 26, 2020 at 1:20:01 AM
I 100% agree with Jason here. In fact, I would say that the mentors
should help do any programming/tooling related fixes that are needed
to support the GSoD technical writers. This makes GSoD a harder
program to mentor than GSoC.
Aaron Meurer
On Wed, May 27, 2020 at 11:51 AM Jason Moore wrote:
I think a GSOD spot would be better spent on working on content, not
tooling and other things. Its a key distinction in the GSoC and GSoD
programs. The docs program is supposed to be suitable for people that don't
necessarily have programming know how.
Jason
moorepants.info
+01 530-601-9791
On
It is a possibility. It mainly depends on what we would gain from doing so.
I would add that, at least in my opinion, our website isn't in too bad
of a state, especially compared to the NumPy site as it was before the
refactor. As a reminder, this is what it used to look like
Have you tried
sudo apt-get update
On Tuesday, May 26, 2020 at 10:49:46 PM UTC+9, Mohit Shah wrote:
>
> I am getting the following error while I was following steps through sympy
> document. Please help to resolve this error.
> Thanks
>
> [image: SympyError.PNG]
>
>
--
You received this
On Wednesday, May 27, 2020 at 3:26:00 AM UTC-5, czgdp1807 wrote:
>
> Hi,
>
> Is https://github.com/sympy/sympy/issues/5031 related to your work?
>
Sort of. This https://github.com/sympy/sympy/pull/18174 and
https://github.com/sympy/sympy/issues/4986 (where Oscar Benjamin
Can you recall why it was rejected, please? I really would like to know.
2020년 5월 27일 수요일 오전 4시 51분 16초 UTC+9, Aaron Meurer 님의 말:
>
> I think this was discussed in the past and we decided we don't want a
> String object. Unfortunately GitHub's issue search is kind of bad so
> I'm having a hard
I see numpy.org is now using hugo.
We may have consider changing the static site generator like
https://github.com/numpy/numpy.org/issues/29
On Tuesday, May 26, 2020 at 1:20:01 AM UTC+9, Jason Moore wrote:
>
> I was admiring the new NumPy website: https://numpy.org/ and thinking how
> some of
Parsing a LaTeX expression should ideally return candidate SymPy
expressions with a matching probability. In case of unambiguous matching,
only one expression should have a high matching probability. In case of
ambiguous matching, two or more SymPy expressions should have high
probability.
Hi,
Is https://github.com/sympy/sympy/issues/5031 related to your work?
With Regards,
Gagandeep Singh
Github - https://github.com/czgdp1807
LinkedIn - https://www.linkedin.com/in/czgdp1807
On Wed, 27 May, 2020, 11:20 AM Jonathan Gutow, wrote:
> Dear SymPy Community,
>
> For use by my students
19 matches
Mail list logo
