[sympy] Re: Discussion for introducing the hooks to core classes

[mcpl snu]

I found a typo in my original comment. in line 6, 'preprocessor' shoud be 
changed to 'postprocessor'.
Also, in line 7 I wrote that postprocessor is not applied when 
evaluate=False is passed, which is wrong. I will write an updated 
description.

>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/ba484333-3314-4974-abb7-be346a0e43b5%40googlegroups.com.

Re: [sympy] Re: Question on using Symbol as instance naming

[mcpl snu]

I agree with SYLee. All we need is just a wrapper of str. I doubt that 
anyone will need to manipulate with that.
SymPy doesn't need to support string manipulation indeed: That's why we 
don't have to implement those methods.

>
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/52db59e9-03da-4dfb-9396-ce0ab8663b95%40googlegroups.com.

Re: [sympy] Re: Question on using Symbol as instance naming

[mcpl snu]

I agree with SYLee. All we need is just a wrapper of str. I doubt that 
anyone will need to manipulate with that.
SymPy doesn't need to support string manipulation indeed: That's why we 
don't have to implement those methods.

2020년 5월 29일 금요일 오전 3시 48분 30초 UTC+9, Aaron Meurer 님의 말:
>
> One of the arguments I recall is that a String object would have lots 
> of string related methods. But string manipulation isn't really 
> something that SymPy as a symbolic system needs to support. 
>
> The codegen use-case was not imagined back then. I don't think the 
> codegen classes should be used outside of codegen. They are designed 
> to represent abstract programming language concepts for generating 
> code. 
>
> Aaron Meurer 
>
> On Thu, May 28, 2020 at 1:15 AM S.Y. Lee > 
> wrote: 
> > 
> > I haven't been part of the discussion back then. But I am also weighted 
> toward having a separate string classes because 
> > 
> > 1. Symbol is actually more heavier strings because assumptions are 
> stored and checked against. 
> > 
> > 2. I also see that atomic String class is implemented in codegen.ast 
> separately, so there were some other use cases. 
> > 
> > On Tuesday, May 26, 2020 at 5:34:43 PM UTC+9, mcpl snu wrote: 
> >> 
> >> Currently, many classes in SymPy include Symbol in args to provide the 
> names to their instances. An example for this is sympy.vector.CoordSys3D 
> class. 
> >> 
> >> Although this can be a clever way to do it, I think this is wierd - 
> perhaps it's an abuse of using Symbol. As far as I know, SymPy's Symbol is 
> a scalar whose operations, e.g. addition, integration, etc... are defined. 
> When we say "This 3D system's name is 'C'", we don't expect that this 'C' 
> can be substituted, divided, or subject to any other operation. Then why 
> use Symbol to denote it in the first place? 
> >> 
> >> Not only this design is unnecessary, it actually raises error. Please 
> refer to this issue page for example 
> >> 
> >> Although there can be many ways to circumvent this issue, I think the 
> most simple way is to introduce String class, which wraps str and is a 
> subclass of Atom. 
> >> 
> >> If there is any reason to use Symbol for this purpose that I 
> overlooked, please leave a comment here. Thank you. 
> > 
> > -- 
> > 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 sy...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/0ebe7487-2be3-4286-a824-4001bbbc0b40%40googlegroups.com.
>  
>
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/93dae711-2701-4333-9e26-d04a7b85ff0f%40googlegroups.com.

Re: [sympy] Question on using Symbol as instance naming

[mcpl snu]

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 time finding the discussions. 
>
> Aaron Meurer 
>
> On Tue, May 26, 2020 at 2:34 AM mcpl snu > 
> wrote: 
> > 
> > Currently, many classes in SymPy include Symbol in args to provide the 
> names to their instances. An example for this is sympy.vector.CoordSys3D 
> class. 
> > 
> > Although this can be a clever way to do it, I think this is wierd - 
> perhaps it's an abuse of using Symbol. As far as I know, SymPy's Symbol is 
> a scalar whose operations, e.g. addition, integration, etc... are defined. 
> When we say "This 3D system's name is 'C'", we don't expect that this 'C' 
> can be substituted, divided, or subject to any other operation. Then why 
> use Symbol to denote it in the first place? 
> > 
> > Not only this design is unnecessary, it actually raises error. Please 
> refer to this issue page for example 
> > 
> > Although there can be many ways to circumvent this issue, I think the 
> most simple way is to introduce String class, which wraps str and is a 
> subclass of Atom. 
> > 
> > If there is any reason to use Symbol for this purpose that I overlooked, 
> please leave a comment here. Thank you. 
> > 
> > -- 
> > 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 sy...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/1ce4ea17-af3e-4fc4-9870-013bf57a%40googlegroups.com.
>  
>
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/31ddf716-c96e-4e51-84ce-366a3a2bb5ee%40googlegroups.com.

[sympy] Question on using Symbol as instance naming

[mcpl snu]

Currently, many classes in SymPy include Symbol in args to provide the 
names to their instances. An example for this is sympy.vector.CoordSys3D 
class.

Although this can be a clever way to do it, I think this is wierd - perhaps 
it's an abuse of using Symbol. As far as I know, SymPy's Symbol is a scalar 
whose operations, e.g. addition, integration, etc... are defined. When we 
say *"This 3D system's name is 'C'"*, we don't expect that this 'C' can be 
substituted, divided, or subject to any other operation. Then why use Symbol 
to denote it in the first place?

Not only this design is unnecessary, it actually raises error. Please refer 
to this issue page  for example

Although there can be many ways to circumvent this issue, I think the most 
simple way is to introduce String class, which wraps str and is a subclass 
of Atom. 

If there is any reason to use Symbol for this purpose that I overlooked, 
please leave a comment here. Thank you.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/1ce4ea17-af3e-4fc4-9870-013bf57a%40googlegroups.com.

[sympy] Question on using Symbol as instance naming

[mcpl snu]

Currently, many classes in SymPy includes Symbol in args to provide the 
names to its each instance. An example for this is sympy.vector.CoordSys3D 
class.

Although this can be a clever way to do it, I think this is wierd - perhaps 
it's an abuse of using Symbol. As far as I know, SymPy's Symbol is a scalar 
whose operations, e.g. addition, integration, etc... are defined. When we 
say "This 3D system's name is 'C'", we don't expect that this 'C' can be 
substituted, divided, or subject to any other operation. Then why use Symbol 
to denote it in the first place?

Not only this design is unnecessary, it actually raises error. Please refer 
to this issue page  for example

Although there can be many ways to circumvent this issue, I think the most 
simple way is to introduce String class, which wraps str and is a subclass 
of Atom. 

If there is any reason to use Symbol that I overlooked, please leave a 
comment here. Thank you.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/9c5eb7f8-82c9-4bd7-8060-80cd7f243fad%40googlegroups.com.

[sympy] Re: Discussion for introducing the hooks to core classes

[mcpl snu]

I think I resolved this. Please refer to PR page 
.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/cce5897f-f21d-4c94-bb96-a9b2f42dd41f%40googlegroups.com.

Re: [sympy] Discussion for introducing the hooks to core classes

[mcpl snu]

Aaron Meurer,

Thanks for your opinion. I will try with 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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/25a72aea-3073-4f9e-a07b-4458d7a86606%40googlegroups.com.

[sympy] Discussion for introducing the hooks to core classes

[mcpl snu]

Discussion for introducing the hooks to core classes

This thread is related to issue #5040 
 and PR #18769 
.


*1. What is the problem?*

Currently, SymPy's Add and Mul are very complicated. There exist various 
type checkings in their flatten method to make them able to handle various 
objects. However, hard-coding like this can be troublesome when new classes 
are added. Not only these methods need to be added with more type 
checkings, it will make the code more and more jumbled.

To relieve this, 'postprocessor' is introduced to Add, Mul, Pow. When the 
instance of these classes is constructed, this 'preprocessor' hook is 
applied to it, transforming the result. (Currently, only matrix uses this 
hook.)
Although this can be used to reduce the complexity in the classes, still it 
has many problems. First, it is not applied when 'evaluate=False' option is 
passed. Second, it cannot take any keyword argument option. Third, the 
instance always needs to go through flatten method first, and only after 
then it is transformed. This is a waste if completely different flatten 
algorithm is to be applied by postprocessor. Finally, because of the same 
reason with third problem, the arguments must be made sure to pass flatten 
methods without raising any error, adding unnecessary restriction to class 
behaviors.


*2. How can we solve it?*

I believe we can solve it by introducing a hook, which is applied before 
any job is done, and also able to take keyword arguments.


*3. What is my proposal?*

My proposal in #18769  is to 
introduce a hook which is, unlike postprocessor, applied to the arguments 
before anything is done. It has these features:

1) Keyword arguments can be passed, allowing more flexibility.
2) Averts the arguments to be unnecessarily processed by flatten method.
3) By checking `_op_priority` of the arguments, determines which hook 
will be used.

The third feature is important. In current SymPy, `_op_priority` determines 
which operator methods will be used when operator (+, *, etc) is applied 
between two objects. This means, if A's _op_priority is 10 and B's is 11, 
then B.__radd__(A), instead of A.__add__(b), is called when A+B is 
executed. So I thought; "If `_op_priority` determines the behavior of 
'A+B', surely it could determine `Add(A, B)` as well!"

This is especially useful when argument of highest priority defines special 
classes, such as MatAdd and MatMul for matrix classes. Suppose we have 
three arguments A,B and C, with their priority A>> C_type_args = [i for i in args if isinstance(i, C)]
>>> other_args = [i for i in args if not isinstance(i, C.func)]
>>> other_args_added = Add(*other_args)
>>> return C_Add(C, other_args_added)

See? No type checking is needed.
With this, let's say someone want to add a new class D. `Add(A, B, C, D)` 
will return `C_Add(C, D_Add(A, B, D) )`. Doing this is simple indeed. Set 
D's `_op_priority` so that A>> D_type_args = [i for i in args if isinstance(i, D)]
>>> other_args = [i for i in args if not isinstance(i, D.func)]
>>> other_args_added = Add(*other_args)
>>> return D_Add(D, other_args_added)

Then, running `Add(A, B, C, D)` will call C's hook. Inside it, 
`Add(*other_args)` will call D's hook because it has the highest priority 
among A,B and D, assigning D_add(A, B, D) to `other_args_added`. 
Add.flatten is not called here.
This all works with full expandability, with minimum complexity and 
bypassing unnecessary steps.


*4. Please give your opinion*

My proposal will be one of the many ways to resolve current issue. I'd be 
grateful if you suggest any improvement to my work, or come up with better 
idea.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/fee15557-d98b-4512-9d26-92203c207cc3%40googlegroups.com.

Re: Re: [sympy] Suggestion on Derivative and Expr._diff_wrt

[mcpl snu]

Although using the rules of derivative is good idea, I'm not really sure 
that SymPy currently has the class for 'd' operator.

And, regarding to your second reply, df(t-1)/dt will be good for 
AppliedUndef classes. Written in SymPy code, it will be 
Subs(Derivative(f(t),t), (t,), (x+1)). Then, how about letting 
f(x).diff(x+1) result this?
Also, let's say if the expression is not AppliedUndef but other class, e.g. 
Add. For example, dx/d(x+1). In this case, substituting x+1 with t can 
evaluate this to 1, so I think x.diff(x+1) can return 1 as well.

Let me summarize:

- Differentiating AppliedUndef with x+1 results Subs(Derivative(f(t),t), 
(t,), (x+1)).
- Differentiating other classes, such as Add or Mul, results the evaluated 
value, if possible.

How do you think of it?



2020년 1월 5일 일요일 오전 2시 51분 8초 UTC+9, Vishesh Mangla 님의 말:
>
> Wrong if you want to use substitution then it should be df(t-1)/dt.
>
>  
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
>
>  
>
> *From: *David Bailey 
> *Sent: *04 January 2020 22:52
> *To: *sy...@googlegroups.com 
> *Subject: *Re: [sympy] Suggestion on Derivative and Expr._diff_wrt
>
>  
>
> On 04/01/2020 13:08, mcpl snu wrote:
>
> It's same as df(t)/dt, where t=x+1.
>
>  
>
> Thanks, and I suppose that also generalises to expressions such as 
> df(x)/d(sin(x))? 
>
> df(t)/dt where t=sin(x)
>
> Given how easy it is to mistype input to sympy, I don't think such an 
> extension is such a good idea.
>
> David
>
> -- 
> 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 sy...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/d517dc5a-3939-48dd-9d53-db458822ac11%40dbailey.co.uk
>  
> <https://groups.google.com/d/msgid/sympy/d517dc5a-3939-48dd-9d53-db458822ac11%40dbailey.co.uk?utm_medium=email&utm_source=footer>
> .
>
>  
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/ab7b7b8b-42e5-4435-bc28-5396aa872c9f%40googlegroups.com.

Re: [sympy] Suggestion on Derivative and Expr._diff_wrt

[mcpl snu]

I suppose that you mean df(sin(x))/d(sin(x)), and yes. 
``Derivative(f(sin(x)), sin(x))`` will be allowed. However, since 
``dx/d(sin(x)) != 1/(d(sin(x))/dx)``, evaluating this will result ``Subs`` 
instance, I guess.

Mistyping issue will be prevented by introducing 'rigorous' variable, as I 
mentioned above. And frankly speaking, it's user's fault if one mistypes 
the input.


2020년 1월 5일 일요일 오전 2시 22분 8초 UTC+9, David Bailey 님의 말:
>
> On 04/01/2020 13:08, mcpl snu wrote:
>
> It's same as df(t)/dt, where t=x+1.
>
> Thanks, and I suppose that also generalises to expressions such as 
> df(x)/d(sin(x))? 
>
> df(t)/dt where t=sin(x)
>
> Given how easy it is to mistype input to sympy, I don't think such an 
> extension is such a good idea.
>
> David
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/5010a095-39c3-41e2-b9de-a7ea3deb13b6%40googlegroups.com.

Re: Re: [sympy] Suggestion on Derivative and Expr._diff_wrt

[mcpl snu]

Your suggestion is true. However, using ``Derivative(f(x), x) * 
1/Derivative(x+1, x)`` explicitly every time is not very systematic 
approach.
If we know "Hey, df(x)/d(x+1) equals (df(x)/dx)/(d(x+1)/dx)!", then why 
don't we let SymPy know to automatically deal with this case with same 
approach?

Let me put this in another word. We know that ``dsin(x)/dx == cos(x)``. 
Then, how can we use this to evaluate ``expr = 1+Derivative(sin(x), x)``?
Although we can evaluate this by manually substituting like 
``expr.subs(Derivative(sin(x), 
x), cos(x))``, we let SymPy know that  ``dsin(x)/dx == cos(x)``, so that we 
can just use ``expr.doit()``.

My idea is same: ``f(x).diff(x+1)`` is better than ``(Derivative(f(x), x) * 
1/Derivative(x+1, x)).doit()``. If we can do something explicitly, then it 
would be better to do it implicitly.


2020년 1월 5일 일요일 오전 12시 27분 17초 UTC+9, Vishesh Mangla 님의 말:

> Why don’t you use the chain rule (d f(x) / dx) * (dx/d(x+1)). For first 
> order derivative you can use the reciprocal therefore dx/d(x+1) = 
> 1/(d(x+1)/dx).
>
>  
>
> Sent from Mail  for 
> Windows 10
>
>  
>
> *From: *David Bailey 
> *Sent: *04 January 2020 16:36
> *To: *sy...@googlegroups.com 
> *Subject: *Re: [sympy] Suggestion on Derivative and Expr._diff_wrt
>
>  
>
> On 04/01/2020 10:08, Francesco Bonazzi wrote:
>
> It's suggest to subclass Derivative if this feature is needed. 
>
>  
>
> I'd like to know what d f(x)/d(x+1) means exactly. It isn't too easy to 
> GOOGLE.
>
> David
>
>  
>
> -- 
> 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 sy...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/3ee75111-deca-b796-b400-79068e928745%40dbailey.co.uk
>  
> 
> .
>
>  
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/df0445ea-8997-490e-80f5-7b9cc57d64a7%40googlegroups.com.

Re: [sympy] Suggestion on Derivative and Expr._diff_wrt

[mcpl snu]

It's same as df(t)/dt, where t=x+1.


2020년 1월 4일 토요일 오후 8시 6분 55초 UTC+9, David Bailey 님의 말:
>
> On 04/01/2020 10:08, Francesco Bonazzi wrote:
>
> It's suggest to subclass Derivative if this feature is needed. 
>
>
> I'd like to know what d f(x)/d(x+1) means exactly. It isn't too easy to 
> GOOGLE.
>
> David
>
>
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/5b622855-66f5-44b3-a4cc-d2c9c303152c%40googlegroups.com.

[sympy] Re: Suggestion on Derivative and Expr._diff_wrt

[mcpl snu]

I have tried, and although it was working well, `diff()` method was 
unaffected since `Expr.diff()` method is connected to `Derivative`.
Since this feature will add no backward incompatibility, I think it would 
be better to modify `Derivative`.

2020년 1월 4일 토요일 오후 7시 8분 39초 UTC+9, Francesco Bonazzi 님의 말:
>
> 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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/86c7a273-413b-4695-83a8-8b2d170ea805%40googlegroups.com.

[sympy] Suggestion on Derivative and Expr._diff_wrt

[mcpl snu]

In current SymPy, derivative such as dx/d(x+1) is not allowed. Instead, one 
might use `Derivative(f(x)-1, f(x)).subs(f(x), x+1)`.
Although this is mathematically rigorous, the former expression is 
sometimes used as well, at least in the field of engineering.


Hence I carefully suggest; how about introducing a `rigorous` parameter to 
`Derivative`?

When `rigorous=True`, which is a default value, `Derivative` behaves as it 
does now. It does not allow dx/d(x+1).

When `rigorous=False`, user can have dx/d(x+1) and also evaluate it to 1. 
Similary, dx/df(x) = 1/(df(x)/dx) is allowed if `rigorous=False`.
User must be aware that this may lead to mathematically incorrect result, 
and use this feature at own risk.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/d7c0312e-491b-48fc-88f5-44b888301fbc%40googlegroups.com.

[sympy] Suggestion about Derivative and Expr._diff_wrt

[mcpl snu]

In current SymPy, derivative such as dx/d(x+1) is not allowed. Instead, one 
might use `Derivative(f(x)-1, f(x)).subs(f(x), x+1)`.
Although this is mathematically rigorous, the former expression is 
sometimes used as well, at least in the field of engineering.


Hence I carefully suggest; how about introducing a `rigorous` parameter to 
`Derivative`?

When `rigorous=True`, which is a default value, `Derivative` behaves as it 
does now. It does not allow dx/d(x+1).

When `rigorous=False`, user can have dx/d(x+1) and also evaluate it to 1. 
Similary, dx/df(x) = 1/(df(x)/dx) is allowed if `rigorous=False`.
User must be aware that this may lead to mathematically incorrect result, 
and use this feature at own risk.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/8f1de3aa-3d1e-4647-aef4-03ff2720d8fc%40googlegroups.com.

[sympy] Introduction to SymPy Community

[mcpl snu]

Hello. We are the researchers in Microfluidics and Coating Process 
Laboratory (MCPL) in Seoul National University, South Korea.

We have been developing a package for fluid mechanics for a year, which 
depends heavily on SymPy.

Our expertise is in fluid mechanics and chemical engineering, and education 
level varies from Ph.B to Ph.D.

Our interest is focused on enhancing the extendability of SymPy (which is 
already great!).

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sympy/ac9e92f0-1cc8-470a-9ebb-23c8b83dfcb3%40googlegroups.com.