On Thursday, April 14, 2022 at 10:04:28 PM UTC+5:30 Oscar wrote:

> On Tue, 12 Apr 2022 at 19:26, Matthias Köppe <[email protected]> 
> wrote: 
> > 
> > Hi Aaron, 
> > 
> > On Tuesday, April 12, 2022 at 5:17:22 AM UTC-7 [email protected] wrote: 
> >> 
> >> On Sun, Apr 10, 2022 at 7:44 PM Matthias Köppe <[email protected]> 
> wrote: 
> >> > We are in the early stages of planning an online SageDays event (
> https://wiki.sagemath.org/days112.358). Wondering if some SymPy 
> developers would be interested in presenting? I think there's a lot of 
> potential for synergy between the projects. 
> >> 
> >> What sort of presentation would you like to see from SymPy? 
> > 
> > I'd be interested in: 
>
> I would be interested in coming along and can present on at least some 
> of these things. 
>
> > - General overview of recent-ish features of SymPy 
> > - status and plans regarding use of FLINT - the Sage interface to it 
> misses many of the more recent developments in the FLINT 2.x series (
> https://trac.sagemath.org/ticket/31408), so there's a potential for 
> synergy here 
>
> It would definitely be good to work together on this if possible. Does 
> SAGE use its own bindings for flint? I've been working a little on 
> python_flint e.g.: 
> https://github.com/fredrik-johansson/python-flint/pull/20 
>
> The python_flint bindings still miss a lot of the newer features from 
> flint, arb etc. A primary goal though is just to make it more easily 
> installable. 
>
> > - status and plans regarding SymEngine 
>
> I don't know about the status of SymEngine. I can't say that I can see 
> any significant work happening on the SymPy side to integrate 
> SymEngine any further with SymPy. My personal view is that for faster 
> symbolics a different approach is needed in general but SymEngine 
> seems to have the same design flaws as SymPy itself in that respect.


Hi, as someone who is relatively new to the SymPy + SymEngine project, and 
wants to work on SymEngine as a part of their GSoC, I would appreciate it 
if you could elaborate a bit on what design flaws you are referring to. I 
have been going through the SymEngine repository, and the main thing that 
sticks out to me is the lack of useful documentation. For example, what 
exactly is ATan2's is_canonical() 
<https://symengine.org/symengine/classSymEngine_1_1ATan2.html#a70edcb86917de5053687e686738c555d>
 
function supposed to do, and why? From a cursory glance at the code, we 
know that the code deems something in a non-canonical form if the numerator 
is equal to the denominator, but why?

Moreover, the design principles page 
<https://symengine.org/design/design.html> says that the repository uses 
the visitor and double dispatch design pattern, but how exactly, and to do 
what?

>From my perspective, it looks like we can do a lot to make SymEngine more 
beginner-friendly. I had a much easier time starting with SymPy than I did 
with SymEngine.

>
>
> > - status and plans regarding solveset for several variables 
>
> There are no immediate plans for a solveset for several variables 
> beyond nonlinsolve. There was recent discussion about this on the 
> mailing list here though: 
> https://groups.google.com/g/sympy/c/v_YLkX4QuRY 
>
> > - status and plans regarding the assumptions facility 
>
> I think much like solveset etc there needs to be more organisation 
> among sympy developers to define what the plans for things like this 
> should be going forwards. These are the kinds of things that GSOC 
> should really be used for rather than adding peripheral features. We 
> need to make that clearer to GSOC applicants though. 
>
> -- 
> Oscar 
>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/68fd8363-6370-425d-844f-d958a8488068n%40googlegroups.com.

Reply via email to