Introduction, GSOC 2012

[Nicolae TItus]

Hello,

My name is Titus Nicolae, I am a 3rd year student at Politehnica University Timisoara.

I am working on Pynac during Google Summer of Code 2012.

With the help of Burcin Erocal I'll be implementing support for MPFR, GMP, MPFC 

in Pynac and solve some old issues. I'll post updates related to Pynac on this blog.

Cheers,

Titus Nicolae

[William Stein]

Your description on your blog says "The scope is to improve the speed
of symbolic computations by using the MPFR library instead of the
current CLN library for the number representation and operations."
However, Sage's pynac does not use CLN, so what do you mean?

You had a much more detailed proposal before, I think -- could you
post a link to that somewhere again?

> Cheers,
> Titus Nicolae
>
> --
> To post to this group, send an email to pynac...@googlegroups.com
> To unsubscribe from this group, send an email to
> pynac-devel...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/pynac-devel
> URL: http://pynac.sagemath.org



--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[Nicolae Titus]

Hello,

I've updated the blog and corrected the error. 

When I wrote that I was thinking of pynac replacing cln in ginac.

Unfortunately on http://planet.sagemath.org/ the entry isn't updated

with the modified entry.

Cheers,

Titus Nicolae

[Jean-Pierre Flori]

Good luck, the cohabitation of Number_T and numeric classes was indeed disturbing!
Will the definitive name for the merged class be Number_T or numeric?
(I'd be in favour of numeric to follow the original GiNaC coding style, but in fact I really don't care)

If you have some time, you could also have a look at the comparison functions (just kidding... if I happen to find some time I'll do)

Best,

Titus Nicolae

> pynac-devel+unsubscribe@googlegroups.com

> For more options, visit this group at
> http://groups.google.com/group/pynac-devel
> URL: http://pynac.sagemath.org

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

--
To post to this group, send an email to pynac...@googlegroups.com

To unsubscribe from this group, send an email to pynac-devel+unsubscribe@googlegroups.com

[Burcin Erocal]

On Tue, 22 May 2012 00:17:08 -0700 (PDT)
Jean-Pierre Flori <jpf...@gmail.com> wrote:

> Good luck, the cohabitation of Number_T and numeric classes was
> indeed disturbing!
> Will the definitive name for the merged class be Number_T or numeric?
> (I'd be in favour of numeric to follow the original GiNaC coding
> style, but in fact I really don't care)

I agree, numeric is the name used by GiNaC and we should keep that.

In the long term (well, by the end of the summer since someone is
actually working on this now), we might have a small class hierarchy to
store the different types of numbers pynac supports.

This will be similar to, but much more light weight than what CLN does.
Using the C++ method dispatch mechanism instead of the case statements
we have right now would make the code easier to maintain without losing
any speed.

> If you have some time, you could also have a look at the comparison
> functions (just kidding... if I happen to find some time I'll do)

Note that I tidied up the patch queue by merging patches not related
to the ordering issue and released a new Pynac version:

http://trac.sagemath.org/sage_trac/ticket/12950

I don't have time to make an spkg for this. I couldn't even find time
to announce it on this mailing list. :)


Cheers,
Burcin

[Jean-Pierre Flori]

Hi Burcin and thanks for the update,

On Tuesday, May 22, 2012 11:45:57 AM UTC+2, Burcin Erocal wrote:

I agree, numeric is the name used by GiNaC and we should keep that.

In the long term (well, by the end of the summer since someone is
actually working on this now), we might have a small class hierarchy to
store the different types of numbers pynac supports.

This will be similar to, but much more light weight than what CLN does.
Using the C++ method dispatch mechanism instead of the case statements
we have right now would make the code easier to maintain without losing
any speed.

Great!

Note that I tidied up the patch queue by merging patches not related
to the ordering issue and released a new Pynac version:

http://trac.sagemath.org/sage_trac/ticket/12950

I don't have time to make an spkg for this. I couldn't even find time
to announce it on this mailing list. :)

I should have some time in June that I can dedicate to Sage hacking, so I'll have a look at this ticket and ordering problems hopefully. 

Cheers,
J

[Burcin Erocal]

On Wed, 23 May 2012 00:49:04 -0700 (PDT)
Jean-Pierre Flori <jpf...@gmail.com> wrote:

> I should have some time in June that I can dedicate to Sage
> hacking, so
> I'll have a look at this ticket and ordering problems hopefully.

I will also have some time after the first week of June, after the
linear algebra and Groebner bases workshop we are organizing:

http://wiki.lmona.de/events/elagb


Maybe we can get the order rewrite in a Pynac 0.3.0 release by July.
Then Titus' rewrite of the numeric class can be 0.4.0 due by the end of
August, mid September.


Cheers,
Burcin

[Ralf Stephan]

On Tuesday, May 22, 2012 at 9:17:08 AM UTC+2, Jean-Pierre Flori wrote:

Good luck, the cohabitation of Number_T and numeric classes was indeed disturbing!
Will the definitive name for the merged class be Number_T or numeric?
(I'd be in favour of numeric to follow the original GiNaC coding style, but in fact I really don't care)

For the record, this was done in Pynac-0.3.8.

Regards,