@isuruf Why does

`numer_denom.cpp`

use `Ptr<RCP<const Basic>>`

? Couldn’t the same functionality be achieved by just using `RCP<const Basic>&`

?
If calculus module is needed in symengine, I would like to work on it and can use some help https://groups.google.com/forum/m/#!topic/symengine/BOamOmtPqoQ

@isuruf @certik I read up on Polynomiial factoring algorithms and finally have two of them in mind - Berkelamp’s Algorithm and Cantor - zassenhaus algorithm. Sympy has both of these implemented with an option to switch between them but I am initially thinking of implementing only one of them and do the other if time permits. Which one would you prefer being implemented? I’d myself prefer to do Cantor-Zassenhaus first since its faster. But there is always a trade off.

A fundamental difference between the two algorithms is that the Berlekamp algorithm is deterministic. This means that given any polynomial it will provide the unique factorization eventually, regardless of how many steps it takes. The CZ algorithm on the other hand is probabilistic, in that it can effectively fail to factor a polynomial completely. The tradeoff is that probabilistic factoring algorithms tend to utilize tricks that enable them to perform tasks quicker if they do succeed.

What does SymPy use by default?

@CodeMaxx, btw, you should ask @Sumith1896, it's his idea

@isuruf Sympy uses Cantor-Zassenhaus by default.

Okay then, start with Cantor-Zassenhaus

@isuruf btw I took a look at Pynac’s

Just wanted to ask if you have any other ideas or views regarding this?

`Infinity`

class as well. Its pretty interesting. I’m thinking of following it rather than sympy for this.Just wanted to ask if you have any other ideas or views regarding this?

@abhinavagarwal07, what do you mean by, some of functions are relatively easy to implement (like trig integration) ?

@CodeMaxx actually Sage has two implementations, an

`InfinityRing`

and infinity with directions inside Pynac:

- https://github.com/sagemath/sage/blob/master/src/sage/rings/infinity.py
- https://github.com/pynac/pynac/blob/master/ginac/infinity.h
- https://github.com/pynac/pynac/blob/master/ginac/infinity.cpp

all by Volker Braun. I later limited the latter to three directions but it's reversible and maybe will be reverted at some later time.

@rwst What do you mean by “limited” to three direction? Doesn’t `positive`

= +1, `negative`

= -1 and `complex`

= 0 cover all we need?

@CodeMaxx, there are other directions, like

`(1+I)/sqrt(2)`

Oh! For complex space…I see. I think even sympy lacks those

@isuruf Do we presently require such an omni-directional infinity in symengine ?

I don’t see

I don’t see

`(1+I)/sqrt(2)`

kind of infinity being used very frequently. I might be wrong though.
For now, the 3 directions are okay, but make sure the design is good enough to handle any direction later

I think following Pynac’s design would be appropriate then.

It has Infinity with direction as an argument as opposed to sympy which has multiple immutable singletons for different infinities.

`numer_denom.cpp`

use`Ptr<RCP<const Basic>>`

? Couldn’t the same functionality be achieved by just using`RCP<const Basic>&`

?

@isuruf Can you please explain about this?

Both should be the same in Release mode, but in Debug mode there are some extra checks.

Can you give some example on this? I mean what check would cause

`RCP<const Basic>&`

to fail in Debug mode?
I mean in the implementation we are nowhere using the pointer itself we are always dereferencing it to get a

`RCP`

.
Yes, that's in Release mode, which should be as fast. In Debug mode in Teuchos implementation, there are several checks

Oh right. Thanx :smile:

@isuruf Is it preferable to use

`Number`

in `FiniteSet`

as well ?