Re: [sympy] New feature possibility

On Monday, May 13, 2024 at 4:56:30 p.m. UTC+2 henrique...@tecnico.ulisboa.pt wrote: Sorry for the late response, we've been busy with other subjects. What about time systems, included in the "Misc" section in the page mentioned on my first message? That page hasn't really been updated

Re: [sympy] Re: Enhancing the flexibility of MatchPy

Samith Kavishke wrote: >> >> >> >> I have attached the changed version of this project. Thank you! >> >> >> >> On Monday, April 1, 2024 at 2:43:25 PM UTC+5:30 Samith Kavishke wrote: >> >>> >> >>> I will go through it

Re: [sympy] New feature possibility

The class UnitSystem in SymPy defines the relations between units. In most cases, the Imperial Units follow the same relations as the SI unit system (maybe there are slight differences in fluid units between the UK and the US?). Anyways, creating an imperial unit system does not make any sense

Re: [sympy] Re: SymPy integration with LLM (generative AI)

On Sunday, April 14, 2024 at 5:30:25 a.m. UTC+2 Aaron Meurer wrote: I made a SymPy GPT for ChatGPT. Although ChatGPT will already use SymPy if you ask it to solve a math problem. The only difference is that this has access to the latest version of SymPy and the SymPy documentation. The

[sympy] Re: SymPy integration with LLM (generative AI)

On Friday, April 12, 2024 at 8:17:49 a.m. UTC+2 samithkar...@gmail.com wrote: Are there any plans from our side for the LLM that use Sympy? Not that I know. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop

[sympy] Re: SymPy integration with LLM (generative AI)

Their example jupyter notebook: https://github.com/langchain-ai/langchain/blob/master/cookbook/llm_symbolic_math.ipynb On Thursday, April 11, 2024 at 10:35:18 p.m. UTC+2 Francesco Bonazzi wrote: > It looks like someone is already trying to integrate LLM with SymPy: > &

[sympy] SymPy integration with LLM (generative AI)

It looks like someone is already trying to integrate LLM with SymPy: https://api.python.langchain.com/en/latest/llm_symbolic_math/langchain_experimental.llm_symbolic_math.base.LLMSymbolicMathChain.html -- You received this message because you are subscribed to the Google Groups "sympy" group.

Re: [sympy] Re: Enhancing the flexibility of MatchPy

 p.m. UTC+1 Francesco Bonazzi wrote: > The base idea is about modifying MatchPy in order to allow easy > integration of MatchPy into SymPy and into the python bindings of protosym. > Additional extensions to the project idea are welcome, provided there is > enough time to complete

Re: [sympy] Re: Enhancing the flexibility of MatchPy

; proposal. >> >> >> On Tuesday, March 19, 2024 at 8:15:07 PM UTC+5:30 Francesco Bonazzi wrote: >> >>> No, no parsers are needed. Just a tree traversal for-loop. It's already >>> implemented: >>> >>> >>>- iter

Re: [sympy] Re: Enhancing the flexibility of MatchPy

t; mean we have to use a parser to translate the sympy object type to matchpy > or are there any better way to handle the situation. > On Saturday, March 16, 2024 at 8:32:03 PM UTC+5:30 Francesco Bonazzi wrote: > >> I suggest to start the unit tests of MatchPy in debug mode and

Re: [sympy] Re: Enhancing the flexibility of MatchPy

capability of solving calculus, matrices and more advanced >problems. > > what are the other things that might affect if we add overridable method > to Expressions? any suggestions for me to refer. > On Wednesday, March 13, 2024 at 2:04:20 PM UTC+5:30 Francesco Bonazzi > w

Re: [sympy] Re: Enhancing the flexibility of MatchPy

On Wednesday, March 13, 2024 at 8:13:27 a.m. UTC+1 Aaron Meurer wrote: As far as we can tell, SymPy is the only thing that uses MatchPy, outside of the specific research software from that research group that it was developed for. Indeed, MatchPy is probably very underappreciated. Its

[sympy] Re: Enhancing the flexibility of MatchPy

On Wednesday, March 13, 2024 at 1:29:37 a.m. UTC+1 samithkar...@gmail.com wrote: Hi, If we are maintianing matchpy as our own repository, Is it okay for us to make the matchpy elements in more integrated way to sympy, or still we need to support the every functionalities that matchpy gave

Re: [sympy] In memory of Kalevi Suominen

This is a true loss for our community. May he rest in peace. I'll always remember interacting with him on several pull requests, especially receiving advice from him. His knowledge of mathematics was impressive. On Monday, March 11, 2024 at 9:21:08 p.m. UTC+1 abhinav@gmail.com wrote: > May

[sympy] Re: Enhancing the flexibility of MatchPy

ote: > Hi Francesco, > Thank you for the reply. How should I progress in this project? I have > several issues encountered when I am going through the matchpy repository, > where would I raise those issues. > > On Wednesday, March 6, 2024 at 3:49:09 PM UTC+5:30 Francesco Bonazzi wr

[sympy] Re: Enhancing the flexibility of MatchPy

ntroduce some methods to check whether it is a > instance of wildcard or an operation. > Through that we can change the tree traversal method without bothering > about the implementation of the Wild Card and Operations. > If Francesco Bonazzi, or any potential mentor can give thei

Re: [sympy] GSOC Application: Creating a Wolfram Mathematica Interpreter with Sympy

Technically we have a Wolfram Mathematica language parser that is able to get the abstract syntax tree from Wolfram Mathematica expressions. The hard task is the creation of the pattern matching engine, which is the reason why integrating MatchPy into SymPy is very important. On Tuesday, March

Re: [sympy] Re: ChatGPT and SymPy

me of >>> my weakest students. It does not seem to be able to use significant figures >>> in computations (also a problem for my weaker students). >>> >>> It seems to be improving rapidly. If it can get to reliably >>> differentiating between correct (

[sympy] Re: Article about Photomath and its own functional programming language

Note that there is a very powerful library to implement mathematical rules in Python that uses its own syntax: MatchPy We do have a way to connect SymPy to MatchPy

[sympy] Re: ChatGPT and SymPy

[image: chatgpt.sympy.matrix_diag.png] On Wednesday, December 14, 2022 at 11:26:37 p.m. UTC+1 Francesco Bonazzi wrote: > Not everything is perfect... ChatGPT misses the *convert_to( ... ) *function > in *sympy.physics.units*, furthermore, the given code does not work: >

[sympy] Re: ChatGPT and SymPy

Not everything is perfect... ChatGPT misses the *convert_to( ... ) *function in *sympy.physics.units*, furthermore, the given code does not work: [image: chatgpt.sympy.unit_conv.png] On Wednesday, December 14, 2022 at 11:24:29 p.m. UTC+1 Francesco Bonazzi wrote: > [im

[sympy] Re: ChatGPT and SymPy

[image: chatgpt.sympy.logical_inference.png] On Wednesday, December 14, 2022 at 11:23:43 p.m. UTC+1 Francesco Bonazzi wrote: > https://en.wikipedia.org/wiki/ChatGPT > > Some tested examples attached as pictures to this post. Quite impressive... > > -- You received this mess

Re: [sympy] Proof-of-concept: mathjax and graphviz side by side in Notebook

What about merging it as experimental API? In case you are not sure about the state of the current code, we have a "*sandbox*" module in SymPy for temporary experiments. On Monday, December 12, 2022 at 6:30:08 a.m. UTC+1 Aaron Meurer wrote: > You might also look at mermaid instead of graphviz.

Re: [sympy] Dependencies (mpmath and rubi/MatchPy)

I think there might be some issues with MatchPy when a constraint object is shared across patterns. Probably every pattern needs to have its own CustomConstraint objects even if they share the same constraints. How do you create a new repo? How do you split the subfolder a keep the git

Re: [sympy] SymPEP: make MatchPy a SymPy dependency

On Thursday, October 7, 2021 at 1:57:48 a.m. UTC+2 Oscar wrote: > > My approach would be to make a new library that redefines the core of > SymPy itself and that uses matchpy or equivalent. Then if that library > could be made compatible with SymPy through a mechanism like sympify then > it

Re: [sympy] SymPEP: make MatchPy a SymPy dependency

with SymEngine (one quick note, this module is still in its early stage). On Wednesday, October 6, 2021 at 10:50:32 p.m. UTC+2 asme...@gmail.com wrote: > On Wed, Oct 6, 2021 at 2:10 AM Francesco Bonazzi > wrote: > > > > > > > > On Wednesday, October 6, 2021 at 12:46:2

Re: [sympy] SymPEP: make MatchPy a SymPy dependency

On Tuesday, October 5, 2021 at 2:57:41 p.m. UTC+2 syle...@gmail.com wrote: > Although the matchpy gives of AC1-matching capability as far as I'm aware, > I just have a question that if is it really general enough. > I'm aware that general equational matching could be an undecidable > problem,

Re: [sympy] SymPEP: make MatchPy a SymPy dependency

On Wednesday, October 6, 2021 at 12:46:25 a.m. UTC+2 asme...@gmail.com wrote: > Since we are bringing up SymPEPs again, it would be helpful to agree > on the actual SymPEP process itself. There hasn't been much discussion > on https://github.com/sympy/SymPEPs/pull/2 for a while. > > I was

Re: [sympy] SymPEP: make MatchPy a SymPy dependency

On Tuesday, October 5, 2021 at 2:07:06 p.m. UTC+2 Oscar wrote: > > I agree that pattern matching is a crucial part of a CAS and should really > be the core of SymPy. If I was redesigning SymPy from scratch then > everything would be built on top of a pattern-matching engine and almost > all

[sympy] SymPEP: make MatchPy a SymPy dependency

Hi everyone, I have written a draft for a SymPEP (SymPy enhancement proposal) to include MatchPy as a dependency of SymPy. https://github.com/sympy/SymPEPs/pull/3 Once SymPy depends on the MatchPy library, the bindings to MatchPy can be moved into SymPy's core. MatchPy provides a much more

Re: [sympy] Re: tests for parsing Latex input to Sympy

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.

Re: [sympy] Re: Port MatchPy to C++20

On Friday, 27 March 2020 09:07:34 UTC+1, manik taneja wrote: > > Also if it’s not an issue could I seek more guidance on coroutines because > I’ve gone through a number of research papers that only highlight the > keyword features , videos and github repositories . I’ve seen the >

Re: [sympy] Re: Port MatchPy to C++20

On Thursday, 26 March 2020 08:26:37 UTC+1, manik taneja wrote: > > I am starting to get a hold of the porting technique and the logic shall I > start by working to port parts of expressions.py ( > https://github.com/HPAC/matchpy/blob/master/matchpy/expressions/expressions.py > ) > to c++20 ? >

[sympy] Re: GSoC 2020 Idea: Improving SymPy Units

On Friday, 27 March 2020 07:35:41 UTC+1, Anson Biggs wrote: > > Improving Units > > Idea > > I personally use SymPy for engineering and a great way to check myself for > mistakes is checking that the units for my equations are consistent and > compatible. I think that SymPy could greatly

[sympy] Re: Port MatchPy to C++20

OK, can you also post some code drafts? On Tuesday, 24 March 2020 21:40:52 UTC+1, manik taneja wrote: > > Hey , > taking into consideration the suggestion by Mr. Francesco ; porting > of Matchpy to C++ 20 is of utmost importance since C++20 has introduced > coroutines . > I am going

[sympy] Re: GSOC 2020 draft application

Hi Manik, The most urgent issue in MatchPy for C++ is to support C++20's coroutines. C++20 has introduced coroutines, which work approximately like Python's *yield* (i.e. the function returns a value without deallocating the function memory). MatchPy uses a lot of generators, MatchPyCpp

[sympy] Suggestion on Derivative and Expr._diff_wrt

It's suggest to subclass Derivative if this feature is needed. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this

Re: [sympy] Drop Python 2.7 and 3.4 support, add mypy to tests

On Tuesday, 24 December 2019 18:46:40 UTC+1, Aaron Meurer wrote: > > What sort of troubles? > > Aaron Meurer > > On Tue, Dec 24, 2019 at 5:44 AM Francesco Bonazzi > wrote: > >> It looks like the codegen module is really causing troubles to mypy. The >&g

Re: [sympy] Drop Python 2.7 and 3.4 support, add mypy to tests

> > is a big task. Perhaps this could be suggested as an idea for a GSOC > > proposal... > > > > On Sun, 22 Dec 2019 at 16:16, Francesco Bonazzi > wrote: > > > > > > Python 3.4 adds support for singledispatch > > > Python 3.5 adds support for typ

[sympy] Drop Python 2.7 and 3.4 support, add mypy to tests

- Python 3.4 adds support for singledispatch - Python 3.5 adds support for typing: https://docs.python.org/3.5/library/typing.html - Add mypy to Travis tests. The typing module adds support for type annotations of various kinds to Python. Using

[sympy] Re: SymPy 1.5 released

Great new! Are we going to drop Python 2.7 and 3.4 support? There are two nice things to have: 1. support for type annotations with enforcement in testing. 2. integration of MatchPy into SymPy (unfortunately this step requires to drop Python 3.5 support as well, as MatchPy is Python

Re: [sympy] What is the difference between Basic and Expr?

On Monday, 2 December 2019 05:25:54 UTC+1, JS S wrote: > > > Likewise, there exists no class such as 'NDimArrayAdd' class, making > NDimArray subclass of Basic only. > Technically there is *CodegenArrayElementwiseAdd *defined in *sympy.codegen.array_utils *which can be used to create an

[sympy] PROPOSAL: ban explicit class constructors in SymPy

Constructors are being overloaded many times in SymPy. The way a constructor is supposed to be written is quite standard, but there are so many ways they are being written and mis-written. Should we rather replace *__new__ *with something different (like, for example, *_eval_new*?)

[sympy] Re: Simple REST service around SymPy. Will it be useful?

On Friday, 8 November 2019 21:09:56 UTC+1, Roman Kuzmin wrote: > > > In our company we have developed a simple REST service around SymPy to > allow external tools using SymPy from languages other than python. > Well... REST sounds more like a WebApp project. There are many other ways to call

[sympy] Re: Symbolic integrator using a neural network

On Saturday, 28 September 2019 19:43:23 UTC+2, Gagandeep Singh (B17CS021) wrote: > > When I skimmed through the paper, I had the following queries: > > 1. Is integration really a tree to tree translation? Because, neural > network is predicting the resulting expression tree for the input

Re: [sympy] Symbolic integrator using a neural network

Their paper appears to be an attempt at using the transformer model for language translation to symbolic math. There is a Jupyter notebook with an example on how to create a translator from Portuguese to English using the transformer model:

[sympy] ANN: decision tree for RUBI integration rules

I have created a decision tree out of RUBI's (Rule-based integration) decision trees. You can find the code here: https://github.com/Upabjojr/rubi_generated The code misses some integrals and sometimes gives wrong results in a few cases, so futher work is needed. The current master branch of

[sympy] Re: local test_args failure with op_iter

Did you update MatchPy on pip? (MatchPy on Conda seems to be still the old version). On Wednesday, 17 April 2019 18:11:50 UTC+2, Chris Smith wrote: > > Does anyone know why I am getting the following error when testing > `test_args` locally? > > ``` > AttributeError: 'function' object has no

[sympy] Re: Interest in advanced physics libraries?

As another advice, I would suggest to focus more on pattern matching and rewriting rules. Implementing group theory and differential geometry in a rigorous manner might be very difficult, and often physicists are not even very precise with its usage. I recommend focusing on a good API (design

[sympy] Re: Interest in advanced physics libraries?

On Monday, 3 December 2018 00:00:39 UTC+1, Nicholas Ondo wrote: > > So I'm a former theoretical physicist, and I am interested in writing a > library that will implement important functionality needed for formal HEP > physics/gravitational physics research. There's loads of calculations I >

[sympy] ANN: NumFOCUS grant to port the code generator of MatchPy into C++

SymPy has been granted funds to port MatchPy's code generator into SymEngine. MatchPy is a pattern matching library with support for commutative and associative expressions, as well as matching rules similar to Wolfram Mathematica. The project will focus on the creation of decision trees in

Re: [sympy] 'get_indices' appears to return indices in a random order

Hi, I think that the module about indexed-objects needs to be modified so that all indices (even repeated ones) are free by default. I would recommend using summations for dummy indices (though I cannot guarantee that the code generation will work). On Monday, 11 June 2018 02:03:43 UTC+2,

[sympy] Re: Introduction

On Tuesday, 27 March 2018 14:30:37 UTC+2, Maxence Mayrand wrote: > > Not yet, but I plan to post them on my GitHub account in the next few days. > I wrote these codes mainly for my latest paper: > https://arxiv.org/abs/1709.09126 >

[sympy] Re: Introduction

On Tuesday, 27 March 2018 09:40:11 UTC+2, Maxence Mayrand wrote: > > One thing I would like to do is improve the liealgebras module, as this is > one of my area of expertise and I already coded many classes and functions > in python for Lie algebra computations. > That's interesting. Do you

[sympy] Re: Tensors and codegen for GSoC 2018

Hi, I would suggest not to confuse tensors with N-dim arrays. Tensors are objects in differential geometry that have covariant and contravariant components. On Wednesday, 21 February 2018 03:54:06 UTC+1, Benjamin Margolis wrote: > > Hi all, > > My name is Ben Margolis. I'm a second year PhD

[sympy] Re: failures in master at Travis

OK, let's try it: https://github.com/sympy/sympy/pull/14181 On Monday, 12 February 2018 17:40:27 UTC+1, Kalevi Suominen wrote: > > Maybe this would help. > > --- a/sympy/assumptions/handlers/ntheory.py > +++ b/sympy/assumptions/handlers/ntheory.py > @@ -136,7 +136,7 @@ def Mul(expr,

Re: [sympy] Re: GSoC 2018

Some ideas for the probability module: - hyperparameters - random matrices - stochastic processes (through indexed random variables) On Tuesday, 23 January 2018 12:03:33 UTC+1, Leonid Kovalev wrote: > > There is a discussion at https://github.com/sympy/sympy/pull/13943 but no >

Re: [sympy] API proposal: derivative by list

For those interested: https://github.com/sympy/sympy/pull/13655 On Thursday, 30 November 2017 09:49:16 UTC+1, Francesco Bonazzi wrote: > > > > On Monday, 27 November 2017 21:53:08 UTC+1, Aaron Meurer wrote: >> >> I think it would be better to explicitly require a Matrix ob

Re: [sympy] API proposal: derivative by list

On Monday, 27 November 2017 21:53:08 UTC+1, Aaron Meurer wrote: > > I think it would be better to explicitly require a Matrix object, although > lists could > potentially be useful for easier input. Matrix is always a two dimensioanl objects, even if they are row- or column- matrices. >

[sympy] Re: Sum of continuous random variables

On Sunday, 8 October 2017 01:10:14 UTC-4, Francesco Bonazzi wrote: > > This result is definitely wrong. > Sorry, ignore my previous answer, that result is correct. If you sum *n + n*, you are summing the same random value. To get the effect of summing two uniform distributions, ju

[sympy] Re: Sum of continuous random variables

This result is definitely wrong. I have opened an issue: https://github.com/sympy/sympy/issues/13417 On Saturday, 7 October 2017 20:46:34 UTC-4, EKW wrote: > > Consider: > > > ``` > > >>> from sympy import * > >>> from sympy.stats import * > >>> t = Symbol('t') > >>> n = Uniform('n', 0, 1) >

[sympy] Re: Status of Rubi implementation for SymPy?

On Saturday, 7 October 2017 12:30:16 UTC-4, Robert Dodier wrote: > > Hi Francesco, thanks for your response. The Rubi implementation looks very > interesting, also the paper about matching algorithms. I will definitely > take a close look at that. > Yes, the MatchPy authors have published a

[sympy] Re: Status of Rubi implementation for SymPy?

Hi, the code for RUBI is here: https://github.com/sympy/sympy/tree/master/sympy/integrals/rubi We have been using MatchPy: https://github.com/HPAC/matchpy MatchPy provides an associative-commutative pattern matcher. Unfortunately it only supports Python 3.6. We also have implementations for

[sympy] Re: Dealing with vectors (fields in particular)

On Thursday, 28 September 2017 08:34:20 UTC-4, Cavendish McKay wrote: > > > 3. use the vector module. In the 1.1.1 release, curvilinear coordinates > are not officially supported, but can be made to work using private methods > It's been a GSoC project this year. Actually the API is still to

Re: [sympy] Reasoning about free_symbols / .has( ) for non-Symbol symbols

On Tuesday, 26 September 2017 18:08:07 UTC-4, Aaron Meurer wrote: > > For free_symbols, I'm not so sure. It seems to me that the correct > free_symbols should be {A[i], i}. i is indeed free in the expression. https://github.com/sympy/sympy/pull/13360 > This is perhaps a bit confusing for

[sympy] Reasoning about free_symbols / .has( ) for non-Symbol symbols

In SymPy we have objects that are not Symbol(s) but should behave like symbols. Examples: Indexed, MatrixElement, sympy.physics.units.Quantity, RandomSymbol, etc... There are some issue related, for example: In [1]: A = IndexedBase("A") In [2]: Order(A[i]) Out[2]: O(A[i]; (A, i) → (0, 0))

[sympy] Doubts about extending the API of the vector module

As part of the GSoC 2017, the vector module (*sympy.vector*) is being extended to support any kind of coordinate system transformation that preserves the orthogonality of base vectors. The old code only supported rotations and translations. For example, to translate a coordinate system, there

[sympy] Re: User-defined Coordinate Transformation

Support for complex transformations is being added right now as part of the GSoC. In the latest master branch there is an experimental *_connect_to_standard_cartesian( )* function, but it's going to be removed and restructured. On Thursday, 10 August 2017 13:13:37 UTC-4, sar...@tcd.ie wrote:

Re: [sympy] A submodule on Quaternions

On Friday, 4 August 2017 19:16:04 UTC-4, Aaron Meurer wrote: > > > > On Fri, Aug 4, 2017 at 6:19 PM, Francesco Bonazzi <franz@gmail.com > > wrote: > >> >> >> On Friday, 4 August 2017 17:34:25 UTC-4, Aaron Meurer wrote: >>> >>>

Re: [sympy] A submodule on Quaternions

On Friday, 4 August 2017 17:34:25 UTC-4, Aaron Meurer wrote: > > You can try this, but I foresee problems reusing I=sqrt(-1) the complex > number as i the quaternion. Mathematically they aren't the same thing, but > even in terms of SymPy, ImaginaryUnit is burdened with things like >

Re: [sympy] A submodule on Quaternions

Also, consider that we don't have a class for complex numbers, we just define the imaginary unit and then complex numbers are managed by additions and multiplications. Maybe we should proceed by just adding *J* and *K* and defining their behavior. What do you think? -- You received this

Re: [sympy] A submodule on Quaternions

On Friday, 4 August 2017 15:06:30 UTC-4, Aaron Meurer wrote: > > What level of symbolics would you expect from the module? Would you expect > to be able to represent something like i*j unevaluated, > Let's make this simple: *Mul(i, j, evaluate=False)*, it's the same for the complex numbers:

Re: [sympy] sympy 1.1 performance

Try to add *return obj* after https://github.com/sympy/sympy/blob/a3389a25ec84d36f5cf04a4f2562d820f131db64/sympy/core/basic.py#L1636 (just to make sure that it's not *_exec_constructor_postprocessors* that's slowing down the code). On Thursday, 27 July 2017 15:08:42 UTC-4, Andrew Corrigan

Re: [sympy] sympy 1.1 performance

I hope it's not caused by the constructor post-processor. On Wednesday, 26 July 2017 08:19:19 UTC-4, Andrew Corrigan wrote: > > > > On Wednesday, July 26, 2017 at 3:36:29 AM UTC-4, Aaron Meurer wrote: >> >> Performance regressions are generally unintentional. Can you give us an >> idea of what

[sympy] Re: TensorIndexType.epsilon always returns None

https://github.com/sympy/sympy/pull/13053 On Wednesday, 26 July 2017 12:49:07 UTC-4, ric wrote: > > Dear developers of module tensor > > I have the impression that the method TensorIndexType.epsilon always > returns None (see EXAMPLE below) > > I guess that this misbehavior is due to the

Re: [sympy] Python 3.6 tests depending on external library

OK, shall we add some new Travis tests for this module only? How would you do that? -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [sympy] Python 3.6 tests depending on external library

On Saturday, 15 July 2017 10:29:23 UTC-4, Ondřej Čertík wrote: > > Hi Arihant, > > On Thu, Jul 13, 2017 at 10:52 AM, Arihant Parsoya > > If so, Then one option is to get your setup into Travis for Python 2, > and that way you have something that passes all SymPy tests in Python > 2 and

Re: [sympy] Python 3.6 tests depending on external library

I think that the current priority is to make the rules work. RUBI has a lot of utility functions that need to be translated. So far, it looks like the rules that have been ported are much slower than on Mathematica, but this is to be expected, as Mathematica is better optimized than Python.

Re: [sympy] Python 3.6 tests depending on external library

On Thursday, 13 July 2017 11:36:47 UTC-4, Francesco Bonazzi wrote: > > As a temporary workaround, we are generating > As a temporary workaround, we are generating the power set of all optional wildcards in a single rule, replacing them with the default matching value each time.

Re: [sympy] Python 3.6 tests depending on external library

pports all versions of > Python). But I also want Rubi to start getting into the main repo as > soon as possible. If it is far off, your method may be workable. But > I'd like to have it better at least by the time the code is released. > > Aaron Meurer > > On Thu, Jul 13,

[sympy] Python 3.6 tests depending on external library

Hi, As part of the Rubi GSoC project, the two students are importing the code from Mathematica using the MatchPy library, which provides support for Mathematica's associative and commutative pattern matchings. So far the code hasn't been merged into SymPy, given the dependence on MatchPy, and

[sympy] Re: Request for community input: removing versioned docs

I guess we should somehow make Google aware that we want the docs of the "latest" version of SymPy to be the default search results. A big warning will probably not solve this problem. I support a total removal and a permanent redirection to the latest version. On Thursday, 22 June 2017

[sympy] Re: Request for community input: removing versioned docs

https://en.wikipedia.org/wiki/HTTP_301 On Thursday, 22 June 2017 15:38:28 UTC-4, Aaron Meurer wrote: > > Hello all. > > I would like input from the broader SymPy community here. Right now, > at http://docs.sympy.org/ we have versioned docs for each version > going back to 0.6.7, e.g.,

[sympy] Re: sympy.tensor.tensor.tensor_indices : documentation inconsistent with the code

https://github.com/sympy/sympy/pull/12778 On Tuesday, 20 June 2017 11:30:42 UTC-4, Francesco Bonazzi wrote: > > Wrong description in the documentation. > > On Monday, 19 June 2017 12:27:28 UTC-4, ric wrote: >> >> Dear developers of module tensor >> >>

[sympy] Re: sympy.tensor.tensor.tensor_indices : documentation inconsistent with the code

Wrong description in the documentation. On Monday, 19 June 2017 12:27:28 UTC-4, ric wrote: > > Dear developers of module tensor > > the documentation of tensor_indices (in 1.00 as well as in dev) seems > inconsistent with the code: > > DOC string [1] states: > Returns list of tensor indices

[sympy] Re: PySDE, Solver for Stochastic Differential Equations

Looks nice. What is the license? It could potentially be merged into SymPy. On Friday, 5 May 2017 02:17:39 UTC+2, chu-ching huang wrote: > > the package is both for symbolic/numeric solver for SDE's and could run > within Jupyter notebook environment, > > https://github.com/cchuang2009/PySDE >

Re: [sympy] SymPy attributes

d not be necessary. > On Thu, Apr 20, 2017 at 4:37 PM, Francesco Bonazzi <franz@gmail.com > > wrote: > >> >> >> On Thursday, 20 April 2017 21:00:47 UTC+2, Aaron Meurer wrote: >>> >>> Why do they need to be set in a global dictionary? >>

Re: [sympy] Python magic to trigger post-constructors for Add, Mul, Pow?

On Thursday, 20 April 2017 21:23:54 UTC+2, Aaron Meurer wrote: > > > > On Thu, Apr 20, 2017 at 6:12 AM, Francesco Bonazzi <franz@gmail.com > > wrote: > > > > > > On Wednesday, 19 April 2017 21:51:08 UTC+2, Aaron Meurer wrote: > >> > >

Re: [sympy] SymPy attributes

On Thursday, 20 April 2017 21:00:47 UTC+2, Aaron Meurer wrote: > > Why do they need to be set in a global dictionary? > > You can already set whatever attributes you want on an atomic object. > So long as __eq__ checks against them it should work. I usually > recommend storing things in args

[sympy] SymPy attributes

Do you think it could make sense to have attributes for atoms in SymPy? Sometimes it could be convenient to store information on certain expressions, like SymPy atoms. It came into the discussion of: https://github.com/sympy/sympy/pull/12490 In this PR, *IndexedBase* is being loaded with more

Re: [sympy] Python magic to trigger post-constructors for Add, Mul, Pow?

nd such mechanism to functions as well. > Aaron Meurer > > On Wed, Apr 19, 2017 at 3:46 PM, Ronan Lamy <ronan...@gmail.com > > wrote: > > Le 19/04/17 à 19:00, Francesco Bonazzi a écrit : > >> > >> > >> > >> On Wednesday, 19 April 201

Re: [sympy] Python magic to trigger post-constructors for Add, Mul, Pow?

On Wednesday, 19 April 2017 17:05:08 UTC+2, Ronan Lamy wrote: > > Le 18/04/17 à 21:28, Francesco Bonazzi a écrit : > > I'm gonna merge this PR soon: > > > > https://github.com/sympy/sympy/pull/12508 > > Wow, that's horrifying! Good luck maintaining it! >

Re: [sympy] Python magic to trigger post-constructors for Add, Mul, Pow?

I'm gonna merge this PR soon: https://github.com/sympy/sympy/pull/12508 If anyone oppose merging the PR in its current state, please write it before it's too late. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and

Re: [sympy] Python magic to trigger post-constructors for Add, Mul, Pow?

https://github.com/sympy/sympy/pull/12508 Initial proposal. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group,

[sympy] Re: Implementation of a user-defined coordinate system

On Tuesday, 28 March 2017 22:06:41 UTC+2, Mikayla Z. Grace wrote: > Are you saying you think a single superclass is better than individual > classes? > A single class, not a superclass. -- You received this message because you are subscribed to the Google Groups "sympy" group. To

[sympy] Re: Implementation of a user-defined coordinate system

There should be one class for all coordinate systems because they are the same objects. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [sympy] GSoC: Assumptions Project

Hi, it's slightly out of topic, but SymPy is really missing the ability to define assumptions on sets (that is, that a variable belongs to a set, e.g. x in [1, 3]). There are some PR that could be continued: - https://github.com/sympy/sympy/pull/11615 -

[sympy] Merging the two units modules

I have modified the new units module (sympy.physics.unitsystems) in order to make it compatible with SymPy (it wasn't), then I added duplicates of the units definition to be compatible with the API of the old units module (sympy.physics.units). The old units module has been suppressed, its

[sympy] Re: Lots of problems with Stats module

On Monday, 27 March 2017 22:14:02 UTC+2, Vedarth Sharma wrote: > > Actually how should I begin my proposal and what all things to cover? > Just write a draft, we can then review it. By the way, what is your knowledge level of statistics and probability? Can you give us some more details? --

Re: [sympy] Re: GSoC 2017: Lie groups in SymPy

It would be nice to extend *sympy.diffeom* to support Lie groups. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this

  1   2   3   4   >