Re: [sage-devel] Modularization project: I. The goals

[Francesco Biscani]

On Fri, 9 Jun 2023 at 02:02, Matthias Koeppe 
wrote:

> On Thursday, June 8, 2023 at 4:40:06 PM UTC-7 Michael Orlitzky wrote:
>
> Pip [...] can't do anything with the non-python software on which sage
> subsists.
> To make sage-via-pip work, we'll have to maintain a new pseudo-
> distribution on pypi that either ships people pre-built wheels or wraps
> autotools/cmake/etc in python. As was made clear in recent threads,
> many developers don't want to be maintaining the *first* sage
> distribution, much less a second one.
>
>
> That's right, building binary wheels to be distributed on PyPI (in
> addition to the source distributions) will be one of the key steps in order
> to make it very user-friendly -- i.e., on par with doing "pip install
> scipy" on standard platforms.
>
> It is normal practice of Python projects to create binary wheels and make
> them available on PyPI. There is sufficient mainstream infrastructure (such
> as https://github.com/pypa/cibuildwheel) that makes it easy.
>

What is your plan for dealing with sage's non-Python dependencies?

Binary wheels which bundle compiled non-Python dependencies using tools
such as auditwheel are extremely fragile, as there is nothing preventing
the user from installing a package which might bundle a different version
of the same library, resulting in hard-to-debug erratic runtime errors due
to ABI inconsistencies, symbol collisions, etc.

The scipy situation is not the same, as, to my knowledge, scipy's depends
only on widely available libraries with simple and stable ABIs (e.g., BLAS,
lapack).

I do not think it's realistic to expect to be able to sanely manage a
multi-language software distribution with language-specific package
managers.

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAHExjCtsSEksU8TJioNEKWfrU9zk1gKDxO22je52QZsC4hbpeA%40mail.gmail.com.

Re: [sage-devel] Re: Automatic Differentiation - Taylor Arithmetics

[Francesco Biscani]

(Apologies for reviving this old thread, but since I saw a couple of
mentions of ODE integration via Taylor's method in the mailing list
archive, I thought that some people might be interested)

We just released the latest version of our Taylor integrator heyoka.py:

https://github.com/bluescarni/heyoka.py

heyoka.py is an implementation of Taylor's method for the numerical
integration of systems of ODEs based on automatic differentiation and
just-in-time compilation via LLVM.

Current features include:

- support for both double-precision and extended-precision floating-point
types,
- the ability to maintain machine precision accuracy over tens of billions
of timesteps,
- high-precision zero-cost dense output,
- fast and accurate event detection,
- excellent performance,
- batch mode integration to harness the power of modern SIMD instruction
sets.

heyoka.py needs to represent the ODEs symbolically in order to apply the
automatic differentiation rules necessary for an efficient implementation
of Taylor's method. For this purpose, heyoka.py uses its own expression
system, but in recent versions we added the ability to convert heyoka.py's
symbolic expressions to/from SymPy. Here's a simple example of
interoperability between heyoka.py and SymPy:

https://bluescarni.github.io/heyoka.py/notebooks/sympy_interop.html

It should not be difficult in principle to implement similar basic
interoperability with Sage's expression system.

More tutorials and examples are available here:

https://bluescarni.github.io/heyoka.py/tutorials.html
https://bluescarni.github.io/heyoka.py/examples.html

Thanks and kind regards,

  Francesco.

On Mon, 29 Apr 2019 at 12:12, mmarco  wrote:

> You might be interested in taking a look at tides [1]. It is a library for
> integration of ODE's in high precission using precisely automatic
> differentiation and Taylor arithmetic. It doesn't use interval arithemtic
> (so, no certified computation), but maybe some ideas could be useful.
> The way it works is by translating the function that defines your ODE to
> c-code and then compiling it.
>
> There is a tides optional package for sage, and an interface to it.
>
>
>
>
> [1] https://iuma.unizar.es/es/investigacion/software/TIDES
>
> El viernes, 19 de abril de 2019, 14:48:09 (UTC+2), Nisoli Isaia escribió:
>>
>> Dear all,
>> I was planning in doing a Cython implementation of Forward automatic
>> differentiation and
>> Taylor arithmetics  as in
>> https://press.princeton.edu/titles/9488.html
>> to use to implement a library for Sage with rigorous quadrature and
>> integration of ODE.
>>
>> I'm trying to understand which parent class could be the best for these
>> objects for them
>> to be compatible with Sage coercion model.
>>
>> What is the usual procedure, I read through
>>
>> http://doc.sagemath.org/html/en/reference/structure/sage/structure/element.html
>> but I'm still confused.
>>
>> Best wishes
>> Isaia
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAHExjCvSLtAbMW1KwhsF63ORvJXH55bTb2WkGWXp-OYV3%2BLyVQ%40mail.gmail.com.

Re: [sage-devel] SCIP integration into sage

[Francesco Biscani]

On 14 April 2018 at 17:59, jplab  wrote:

> Hi,
>
> Maybe I just give my basic knowledge about SCIP and ZIB.
>
> Le vendredi 13 avril 2018 11:20:25 UTC+2, bluescarni a écrit :
>>
>> http://scip.zib.de/academic.txt
>>
>> """
>> 1. This license applies to you only if you are a member of a
>> noncommercial
>>and academic institution, e.g., a university. The license expires as
>>soon as you are no longer a member of this institution.
>> """
>>
>>
> Perhaps including the very first sentence of the license would put a bit
> more context:
>
> ''This license for ZIB software is designed to guarantee freedom to share and
> change software for academic use, but restricting commercial firms
> from exploiting your knowhow for their benefit.''
>
>
That's a declaration of intent, which is fine and all, but what matters is
the rest of the license, where the exact terms are laid out.


>
> ... this somehow reminds me of some long discussions I've seen pass by on
> sage-devel. Anyhow, the
> discussion here is about announcing that it would now be possible to use
> SCIP inside Sage. I think this is
> a good news. As far as I know, it has been possible to use other Ma's
> softwares inside Sage, and I don't
> see why it couldn't be the same with SCIP.
>
> According to Gurobi, they are the best non-proprietary LP optimization
> package that you can get. [see p.17 of http://www.gurobi.com/pdfs/ben
> chmarks.pdf]
>

> So basically these acedemics, I imagine funded with taxpayers' money, are
>> preventing the general public to use software they paid for?
>>
>
> As for ZIB, in 2016, it had almost 8M€ in third party funding, see
> http://www.zib.de/institute/zib-in-numbers
> If you go in the Research section, and you know that it is a German based
> institute, you may guest some companies that fund them.
>
> That said, of course, the publish "Publish or Perish" has a role to play
> in the choice of license. But since I
> don't want to spend time rewriting an optimization package, I will gladly
> cite them and say  that I used their
> software.
>

Actually what pissed me off the most was the fact that apparently you have
to be a "member of a noncommercial and academic institution" to use SCIP
for free (and "the license expires as soon as you are no longer a member of
this institution"). So, again, if you are, say, an interested citizen, an
independent researcher or a developer who does open source in his/her free
time while being employed in the industry as your day job, apparently you
cannot get access to a piece of software you paid for with your taxes (or,
you have to pay for it twice - perhaps this sounds familiar to a certain
other situation going on in academia :)). This seems to be a completely
gratuitous restriction to me.

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] SCIP integration into sage

[Francesco Biscani]

On 13 April 2018 at 11:25, Vincent Delecroix <20100.delecr...@gmail.com>
wrote:

> On 13/04/2018 11:20, Francesco Biscani wrote:
>
>> http://scip.zib.de/academic.txt
>>
>> """
>> 1. This license applies to you only if you are a member of a noncommercial
>> and academic institution, e.g., a university. The license expires as
>> soon as you are no longer a member of this institution.
>> """
>>
>> So basically these acedemics, I imagine funded with taxpayers' money, are
>> preventing the general public to use software they paid for?
>>
>> Talk about ivory tower...
>>
>
> This is indeed a problem with PySCIPOpt. I don't think this is a bad
> intention. My point of view is that they wanted to have a form of dual
> licensing for making happy (paying) customers that in many situations do
> not like open source. Not to prevent users to use it. Moritz might
> infirm or confirm.
>
> If the package appears to be useful (I think it is) we could ask
> kindly to package PySCIPOpt under GPL or LGPL.
>
> I know of at least the CGAL project where the distinction is made
> cleaner [1]: they offer a GPL and a commercial version... and they *do*
> have customers (enough for 8 salaries).
>
> Best
> Vincent
>
>   [1] https://www.cgal.org/license.html


I can sort-of sympathise with the intention. But I cannot understand why
they decided to roll their own license instead of going with the usual dual
licensing everyone is doing. Perhaps because they wanted to enforce the
"thou shalt cite me" clause?

As an academic myself, I also cannot understand how they could possibly
think that putting artificial barriers for the use of the software by
non-academic "non-commercial" individuals could possibly be a good idea
ethically.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] SCIP integration into sage

[Francesco Biscani]

http://scip.zib.de/academic.txt

"""
1. This license applies to you only if you are a member of a noncommercial
   and academic institution, e.g., a university. The license expires as
   soon as you are no longer a member of this institution.
"""

So basically these acedemics, I imagine funded with taxpayers' money, are
preventing the general public to use software they paid for?

Talk about ivory tower...

On 11 April 2018 at 18:27, moritz  wrote:

> SCIP is an optimization software, that can solve mixed interger
> (non)linear programs: http://scip.zib.de/
> It has a python interface: PySCIPOpt https://github.com/SCIP-
> Interfaces/PySCIPOpt
> #24662 
> We have now added this as a sage package and written a backend, see
> #21003,  which is based on #24662.
> 
>
> It would be great if some people could test it  and possibly review it!
>
> Cheers
>  Moritz
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Fwd: [ODK participants] Blog post on fast multivariate arithmetic

[Francesco Biscani]

mppp also uses a small value optimisation. The number of limbs that can be
stored without dynamic memory allocation can be selected at compile time,
and the benchmarks on the website are done using 1 limb (64 bits) of static
storage.

I can think of a few things that might influence positively mppp's
performance with respect to FLINT:

- inlining (as mppp is header-only) avoids the overhead of function calls
and might allow the compiler to optimise better.
- mppp does not do automatic downsizing, once you are using dynamic storage
it's up to you to demote to a static integer. I would imagine this saves a
few branches with respect to FLINT.
- I spent a lot of time tinkering with the add/sub/mul code, trying to find
the code flow/layout that would squeeze out the best performance for small
operands. Maybe I just got lucky with a specific way of arranging the code
particularly friendly to GCC, but I don't know really - I am not a
low-level/assembly type of guy. I just tried many different variations and
picked the one that performed better.

Cheers,

  Francesco.

On 13 July 2017 at 12:25, 'Bill Hart' via sage-devel <
sage-devel@googlegroups.com> wrote:

> So why is it faster than Flint say? Except for the overhead in the Flint
> fmpz type, which uses a single word initially and only upgrades to an mpz_t
> on overflow, it should currently be doing more allocations than Flint. And
> Flint should be faster for something like a dot product, especially if the
> integers are all small, since it never actually allocates mpz_t's in that
> case. What is the new innovation?
>
> Bill.
>
> On Wednesday, 12 July 2017 16:00:16 UTC+2, bluescarni wrote:
>>
>> In the benchmarks I use the C++ interfaces of FLINT and
>> Boost.Multiprecision only for ease of initialization/destruction. The bulk
>> of the operations is performed using directly the C API of FLINT and GMP.
>> mp++ itself has some moderate template metaprogramming in place, but for
>> instance it is currently lacking expression templates support (unlike
>> fmpzxx), the focus at the moment being on fast low-level primitives
>> (add/sub/mul/addmul etc.).
>>
>> Cheers,
>>
>>   Francesco.
>>
>> On 12 July 2017 at 15:13, 'Bill Hart' via sage-devel <
>> sage-...@googlegroups.com> wrote:
>>
>>> Beware, Bernard Parisse has just helped me track down why the Flint
>>> timings for the sparse division only benchmark looked so ridiculously low.
>>> It turns out that due to an accident of interfacing between Nemo and Flint,
>>> it was using reflected lexicographical ordering instead of true
>>> lexicographical ordering. If I had labelled them "exact division", instead
>>> of "quotient only" and not included the x^(n - 3) term in the benchmark
>>> itself, the timings could be considered correct (though Giac would also
>>> have been able to do the computation much faster in that case). But
>>> unfortunately, this discovery means I had to change the timings for Flint
>>> for that benchmark. It is now correct on the blog.
>>>
>>> The timings for mppp are really good. I'm surprised you beat the Flint
>>> timings there, since we use pretty sophisticated templating in our C++
>>> interface. But clearly there are tricks we missed!
>>>
>>> Bill.
>>>
>>> On Wednesday, 12 July 2017 12:16:33 UTC+2, bluescarni wrote:

 Interesting timings, they give me some motivation to revisit the dense
 multiplication algorithm in piranha :)

 As an aside (and apologies if this is a slight thread hijack?), I have
 been spending some time in the last few weeks decoupling the multiprecision
 arithmetic bits from piranha into its own project, called mp++:

 https://github.com/bluescarni/mppp

 So far I have extracted the integer and rational classes, and currently
 working on the real class (arbitrary precision FP).

 Cheers,

   Francesco.

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "sage-devel" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to sage-devel+...@googlegroups.com.
>>> To post to this group, send email to sage-...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/sage-devel.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, 

Re: [sage-devel] Fwd: [ODK participants] Blog post on fast multivariate arithmetic

[Francesco Biscani]

In the benchmarks I use the C++ interfaces of FLINT and
Boost.Multiprecision only for ease of initialization/destruction. The bulk
of the operations is performed using directly the C API of FLINT and GMP.
mp++ itself has some moderate template metaprogramming in place, but for
instance it is currently lacking expression templates support (unlike
fmpzxx), the focus at the moment being on fast low-level primitives
(add/sub/mul/addmul etc.).

Cheers,

  Francesco.

On 12 July 2017 at 15:13, 'Bill Hart' via sage-devel <
sage-devel@googlegroups.com> wrote:

> Beware, Bernard Parisse has just helped me track down why the Flint
> timings for the sparse division only benchmark looked so ridiculously low.
> It turns out that due to an accident of interfacing between Nemo and Flint,
> it was using reflected lexicographical ordering instead of true
> lexicographical ordering. If I had labelled them "exact division", instead
> of "quotient only" and not included the x^(n - 3) term in the benchmark
> itself, the timings could be considered correct (though Giac would also
> have been able to do the computation much faster in that case). But
> unfortunately, this discovery means I had to change the timings for Flint
> for that benchmark. It is now correct on the blog.
>
> The timings for mppp are really good. I'm surprised you beat the Flint
> timings there, since we use pretty sophisticated templating in our C++
> interface. But clearly there are tricks we missed!
>
> Bill.
>
> On Wednesday, 12 July 2017 12:16:33 UTC+2, bluescarni wrote:
>>
>> Interesting timings, they give me some motivation to revisit the dense
>> multiplication algorithm in piranha :)
>>
>> As an aside (and apologies if this is a slight thread hijack?), I have
>> been spending some time in the last few weeks decoupling the multiprecision
>> arithmetic bits from piranha into its own project, called mp++:
>>
>> https://github.com/bluescarni/mppp
>>
>> So far I have extracted the integer and rational classes, and currently
>> working on the real class (arbitrary precision FP).
>>
>> Cheers,
>>
>>   Francesco.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Fwd: [ODK participants] Blog post on fast multivariate arithmetic

[Francesco Biscani]

Interesting timings, they give me some motivation to revisit the dense
multiplication algorithm in piranha :)

As an aside (and apologies if this is a slight thread hijack?), I have been
spending some time in the last few weeks decoupling the multiprecision
arithmetic bits from piranha into its own project, called mp++:

https://github.com/bluescarni/mppp

So far I have extracted the integer and rational classes, and currently
working on the real class (arbitrary precision FP).

Cheers,

  Francesco.

On 9 July 2017 at 17:39, William Stein  wrote:

> New blog post from Bill Hart.  It includes a section claiming Sage’s
> multivariate polynomial arithmetic speed is much worse than expected...
>
> -- Forwarded message -
> From: Bill Hart 
> Date: Sun, Jul 9, 2017 at 8:34 AM
> Subject: [ODK participants] Blog post on fast multivariate arithmetic
> To: Opendreamkit participants 
>
>
> Dear all,
>
> I've written a blog post on the fast multivariate arithmetic we've been
> doing for ODK [1]. This is a deliverable which is due at the end of the
> four years, so we've got a long way to go, but it is progressing nicely in
> the interim.
>
> The next stage is to parallelise this, and we've hired Daniel Schultz to
> work on our ODK deliverable which will do precisely this. He's an
> experienced developer from the US who was already writing his own CAS (in
> assembly language, believe it or not!)
>
> Bill.
>
> [1] https://wbhart.blogspot.de/2017/07/update-on-fast-
> multivariate-polynomial.html
> --
> -- William Stein
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Multivariate polynomial factoring and bug(?)

[Francesco Biscani]

On 4 November 2016 at 14:33, 'Bill Hart' via sage-devel <
sage-devel@googlegroups.com> wrote:
>
> There are many completely incorrect published algorithms for GCD, even in
> the univariate and integer case. Dan Bernstein has a hilarious rant about
> this somewhere online. It's tempting to completely ignore literature by
> people who didn't implement their algorithms and test them on known hard
> cases and real world examples. But just occasionally, really good ideas
> turn up in papers by people who don't know how to use a computer, so this
> isn't a winning strategy.
>

:)

Thanks for the pointers, I might end up revisiting this topic one day. My
end goal was to have a reasonably fast/robust rational function class, but
it seems this is still too research-y for me (and I've solved the original
practical problem that prompted this detour in another way eventually). I
would be interested to hear your progress in Nemo regarding this type of
functionality, if you want to keep us posted here.

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Multivariate polynomial factoring and bug(?)

[Francesco Biscani]

For what it's worth I spent some time earlier this year experimenting with
multivariate poly GCD in piranha (e.g., here's the PSR_SR implementation
https://github.com/bluescarni/piranha/blob/master/src/polynomial.hpp#L197).
It's alpha-quality experimental code which I am about to remove for the
time being from the project, but it does produce correct results in all the
tests I have thrown at it (which incidentally helped finding a GCD bug in
sympy, which I was using as a comparison
https://github.com/sympy/sympy/issues/10996). The main motivation in
implementing the functionality was to have some capability of handling
rational functions.

Overall it was a pretty frustrating experience. For starters, Piranha uses
a sparse multivariate representation based on hash tables, which are of
course unordered and thus not suitable for operations such as division and
GCD. In order to have a real chance of competitive performance, I need to
implement an alternative ordered representation to switch to when
performing these operations (probably the ordered vector representation
with the Pearce heap multiplication algorithm).

Secondly, despite the abundance of literature on the subject, it was very
hard to understand which algorithm it was worth to attempt implementing,
with performance claims all over the place. In the end I settled on the PSR
and the GCDHEU algorithms, mostly because they were the easiest to
implement. PSR tended to work well most of the time, GCDHEU was quite
effective for small operands. Still, there were cases in which, for very
specific and innocuous-looking polynomials, the runtime would be atrocious
for one algorithm and reasonable for the other, or vice-versa. I have no
idea on how one would pick a good heuristic to choose the better algorithm
before actually performing the computation. It also didn't help that many
books and papers I consulted provided "implementations" (using the term
very loosely) of the algorithms which to me, as a non-expert on the topic,
were either vague, incomplete or sometimes (I suspect) seemed outright
wrong.

Anyway, sorry for the rantish mode, and good luck :)

  Francesco.





On 4 November 2016 at 13:39, 'Bill Hart' via sage-devel <
sage-devel@googlegroups.com> wrote:

>
>
> On Thursday, 3 November 2016 23:42:27 UTC+1, Dima Pasechnik wrote:
>>
>> Are there open-source implementations of this available?
>>
>
> Pari might be a good place to look. Otherwise, I doubt it. If Bernard
> Parisse hasn't done it, it probably doesn't exist.
>
> I remember one of the Maple people getting pretty annoyed back in about
> 2010 that no one in the Sage community seemed to be interested in actually
> doing something about hard problems like multivariate GCD (and by
> extension, factorisation).
>
> Much of the stuff in Factory happened since then, but not much else, as
> far as I'm aware (though I am sure the Pari guys have been slowly improving
> their implementation over the years). Factory was a big improvement over
> what Singular was doing before. But it's such a huge area that it didn't
> make much of a dent. For example, the other day I found two polynomials in
> 4 variables with just 30 terms, which Factory takes a minute to find the
> GCD of. Even Magma takes about 3s!
>
> For what it is worth, I'm currently working on multivariate GCD in Julia,
> and eventually Flint, with a view to eventually doing multivariate
> factoring the right way.
>
> I just got a reasonable, but not world beating, univariate factoring
> algorithm going over Z. Multivariate GCD turns out to be an unbelievably
> hard problem; much, much harder than I gave it credit for.
>
> Anyway, there are people here in Kaiserslautern very interested in both
> multivariate GCD and factoring, so if anyone is interested in this and
> would like to contribute, feel free to contact us.
>
> For use in multivariate GCD over Z, I eventually want to implement Soo
> Go's algorithm [1], and over fields, probably a highly optimised Zippel.
> For more generic GCD I can't find anything better than the subresultant
> pseudoremainder algorithm of Collins. If anyone knows of anything better
> that works fairly generically, please let us know.
>
> In some sense, algorithms for factoring are understood fairly well, but
> there's a lot of infrastructure one needs to implement any of them. What
> Nils has suggested above is correct, though it is obviously still an area
> of active research.
>
> Bill.
>
> the only (somewhat) fast library I know is
>> Singular's factory
>> (https://github.com/Singular/Sources/blob/spielwiese/factory/README)
>> used both in Singular and in Macaulay2...
>>
>
>> Also, if you need to output factors, which might exist only over proper
>> extensions, you would have
>> to build these extensions, no?
>>
>>
>>
>> On Thursday, November 3, 2016 at 7:37:58 PM UTC, Nils Bruin wrote:
>>>
>>> On Thursday, November 3, 2016 at 1:37:25 PM UTC-4, Dima Pasechnik wrote:



 On Thursday, November 3, 2016 

Re: [sage-devel] Re: survey ==> Python3

[Francesco Biscani]

>
> That would be difficult to substantiate I think.
>

If you look at languages with "true" multithreading, what they provide are
not only the basic building blocks which Python also has (threads, locks,
mutexes, condition variables, etc.), but also a whole conceptual model of
how a multi-threaded abstract machine is supposed to behave. The memory
model, guarantees on instruction reordering by the compiler/interpreter,
definition of the conditions for data races, atomic operations, and all
that jazz.

Correct me if I am wrong, but my understanding is that Python is currently
lacking a formal model for threading. Even if the GIL were to be removed
from CPython, Python would still lack crucial parts to make it really
useable as a portable multithreaded language.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: survey ==> Python3

[Francesco Biscani]

On 25 July 2016 at 17:21, Erik Bray  wrote:

> The GIL is an implementation detail and has nothing to do with the
> language.  It could (in principle) be removed at any time without
> breaking existing code, and does not exist in other implementations.


Fair enough. At the same time though I do believe that the existence of the
GIL in the most widespread Python implementation has effectively dragged
back the language as a whole in terms of parallel programming.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: survey ==> Python3

[Francesco Biscani]

It does not have to be a black and white matter. C++11 is not 100%
compatible with C++03, for instance, but the transition in practice has
been widely painless and successful (to the point that many prominent
projects today *require* C++11).

While I personally use and enjoy Python 3, I've heard a lot of grumbling
about the transition, and it's not hard to see why. I think the main
criticism boils down to the fact that retro-compatibility was broken often
in subtle ways, yielding sometimes questionable benefits (e.g., not many
people in the scientific community perceiving the need for the
string/bytes/UTF8 changes) and at the same time not addressing some of the
historical sore points of Python (looking at you, GIL).

In my view, how the transition was conceived and handled does raise some
legitimate concerns regarding the viability of Python as a language for
long-term software projects (a-la Axiom's 30 year horizon).

Cheers,

  Francesco.


On 25 July 2016 at 16:18, Dima Pasechnik  wrote:

>
>
> On Monday, July 25, 2016 at 2:54:17 PM UTC+1, rjf wrote:
>>
>> I found this
>> https://docs.python.org/3/howto/pyporting.html
>> Which says that, in spite of various tools, you might have to rewrite
>> code "manually".
>>
>> If you write code in Python 2.x and it has to be changed to run in Python
>> 2.y and then
>> again in Python 3,  then that counts as a bad mark against Python, in my
>> opinion.
>> What is your opinion?  What part of the culture am I missing?
>>
>
> IMHO fully backward-compatible languages are a minority; e.g. Fortran and
> C are not.
> Maybe from the CL ivory tower things look differently, though.
>
>
>>
>> Given the occasional use of arithmetic in Sage, it would seem to be a
>> issue to
>> redefine  "/"  .
>> R
>>
>>
>>
>> On Sunday, July 24, 2016 at 9:14:17 PM UTC-7, William wrote:
>>>
>>> On Sun, Jul 24, 2016 at 9:07 PM, rjf  wrote:
>>> > Maybe flamebait .. see below.
>>>
>>> No -- it seems that you might be a little ignorant about the culture
>>> and development of Python.   You might try a google search for
>>>
>>> python2 python3
>>>
>>>
>>>
>>> --
>>> William (http://wstein.org)
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: how we develop sage

[Francesco Biscani]

On 14 April 2016 at 15:51, Erik Bray  wrote:

> I disagree that Sage is all that special.  Or at least, I don't
> believe there's any need for it to be, whether or not it is currently.
>

If the past is any indication, you will find some cultural resistance about
this point in the Sage community. Sometimes it seems like Sage lives in a
reality distortion field in which normal software development practices do
not apply :)

William's change of heart about modularization is a relatively recent
development, which - I speculate - might have been brought forward by his
increased involvement with the Python (and non-Python) ecosystems while
working on SMC.

FWIW, I think you are doing the right thing and wish you all the best luck
in the effort :)

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage 7.1 Windows 8.1 Cygwin make error

[Francesco Biscani]

On 5 April 2016 at 10:59, Dima Pasechnik  wrote:
>
> MSYS2 has a  mingw toolchain and a Cygwin toolchain.
>
> http://stackoverflow.com/questions/25019057/how-are-msys-msys2-and-msysgit-related-to-each-other
>

I did not know that msys2 also had a cygwin toolchain. But then, I don't
want to touch cygwin with a barge pole so that's hardly surprising :)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage 7.1 Windows 8.1 Cygwin make error

[Francesco Biscani]

On 29 March 2016 at 20:41, Dima Pasechnik  wrote:

> (this is perhaps not quite the same as the "proper" cygwin patch - MSYS2
> is a fork of Cygwin,
> which is sort of more developer-friendly --- perhaps we should consider
> switching to it)
>

As far as I know MSYS2  is not a fork of cygwin, it is a native mingw
toolchain + plus a bunch of natively-compiled packages managed by the
package manager of Arch linux, called pacman.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Linux on Windows

[Francesco Biscani]

On the theme of hell freezing over, this also happened:

https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/

On 31 March 2016 at 02:17, 'Bill Hart' via sage-devel <
sage-devel@googlegroups.com> wrote:

> It's almost a year since I predicted Microsoft would do something like
> this. I have an email from September last year which was a followup email
> some months after I told a colleague something like this would happen. If I
> recall our conversation correctly, I was pretty specific about being able
> to run native Linux apps in a console similar to the usual dos console but
> without a VM or something like Cygwin. Naturally he thought I was mad.
>
> I almost feel like I should make another tech prediction to celebrate.
> However, I still have a few outstanding. Towards the end of 2014 I
> predicted 2015-2025 would be a decade of AI breakthroughs. A couple of
> weeks ago I made two additional predictions. 1) Within 3 years someone will
> show how to beat world champions at Go on a computer without neural nets or
> AI, 2) Within 5 years someone will demonstrate meaningful theorem proving
> using neural networks, say theorems in set theory, group theory and other
> elementary algebraic topics. Both I will enjoy.
>
> Bill.
>
> On Thursday, 31 March 2016 01:52:40 UTC+2, Bill Hart wrote:
>>
>> It looks like this thing is going to be pretty solid [1]. I'm actually
>> incredibly excited about it, more than I have been about Windows for about
>> 20 years.
>>
>> Bill.
>>
>> [1] https://channel9.msdn.com/Events/Build/2016/P488
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL 9.7.0

[Francesco Biscani]

I remember that you mentioned some time ago that you were working on a
solving (or working around) GMP's horrid error handling (especially with
respect to memory errors). Did you make any progress on that front?

Cheers,

  Francesco.

On 12 March 2016 at 22:32, Victor Shoup  wrote:

> Just released a new version of NTL!
> In a nutshell: faster, better matrix arithmetic over zz_p (small moduli),
> some improved thread pooling facilities,
> and several other small improvements.
>
> For more details, go here: http://shoup.net/ntl/doc/tour-changes.html
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Sage "and" Anaconda

[Francesco Biscani]

On 11 March 2016 at 14:50, Michael Orlitzky  wrote:

> Start over with "let's figure out how to do cross-platform source-based
> package management." Why isn't it a fair comparison? Gentoo prefix, Nix,
> and Conda all do the same thing.
>

I have been a Gentoo user for more than 12 years now, and I wholeheartedly
agree that - at least on paper - Gentoo prefix seems like a very good fit
for what the Sage distribution aims to be. Gentoo devs have been dealing
for a long time with all sorts of issues related to compilation from
source, including dependency management, library versioning, ABI breakages,
major version updates (Python 2 vs 3, Perl, etc.), and so on. IMO, they
have done a fantastic job at it.

As a piece of anecdotal evidence, my main workstation at home was built in
2009, and the Gentoo system on it has been updated in a continuous
(rolling) fashion ever since. Among others, it has survived:

- various GCC upgrades (from 4.5 -> 5.3, including various libstdc++ ABI
changes),
- various breaking Python/Perl/Ruby/etc. updates, including my current
setup in which Python 2 and 3 are installed at the same time (all python
packages are installed automatically in their Python 2 and 3 versions),
- continuous kernel upgrades,
- various major switches of low-level system components, including ALSA ->
pulseaudio, systemV -> openrc-> systemd, and more,
- simultaneous multilib installation of 32-bit and 64-bit packages (in my
current setup, most packages are compiled both in 32-bit and 64-bit mode,
in order to provide dependencies for binary-only 32-bit packages such as
Skype).

A fantastic feature is that whenever an ABI-breaking changes happens in a
library, the package manager keeps around the previous version's .so files
until all packages depending on it have been updated (then the old files
get automatically removed). Reverse dependency checking provides a way to
eliminate cruft once the dependencies of a software change. And so on and
on. To me, the portage package system is an amazing piece of engineering.
Even if the Sage project decides not to use it, I think it would be really
beneficial to study how things are done in portage. All other package
manager I have used after portage (pip, yum, hashstack, even apt-get) have
frankly felt like a child's toy in comparison.

With that said, my experiences with the prefix version of gentoo on OSX
have been a bit of a mixed bag. It felt to me like it was very close to be
generally viable, but a lot of manual tweaking was still needed. I have no
experiences with it on Windows platforms, but I think it does have some
support for cygwin.

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: The Sage Project (Nathann Cohen)

[Francesco Biscani]

I think your points are very important. Competing with a commercial CAS (or
with any commercial software really) is much more about boring aspects of
software development rather than exciting ones. In my experience the FLOSS
community can excel at solving technically challenging problem, but it
often struggles when it comes to subjects like QA, documentation, user
interfaces, etc. Those are chronically weak points in projects such as
LibreOffice, Firefox, the linux desktop environments in general, office
programs, etc. It should not matter as much in math/science oriented
software, but for whatever reason it seems like the CAS crowd needs to be
pampered much more than (say) the numerical computing crowd.

The other point you make is really about academia being (for the most part)
ethically bankrupt. I doubt this will change substantially in the
short-medium term.

On 26 February 2016 at 13:44, parisse 
wrote:

> Regarding the mission statement, I'm a little bit skeptic one can build a
> viable alternative to Magma on one side and Maple, Mathematica, Matlab on
> the other side. Magma is a very specialized software that is probably
> unknown to most mathematicians, and almost certainly unknown in other
> scientific fields, while most mathematicians and many scientists in other
> fields have heard about Maple, Mathematica and Matlab. From my very little
> experience trying sagemath, the system seems to me to be more designed to
> be an alternative to Magma than to Maple, Mathematica or Matlab.
> Perhaps because it's fun to code something exciting related to your math
> research while it's not fun to write interfaces, fix bugs, support windows,
> write documentation targetting large number of students, code heuristics
> for nice solvers and antiderivatives... That's probably the reason why
> Maple, Mathematica and Matlab are commercial softwares: people doing the
> boring work want to be rewarded for that. And you can not expect to be
> rewarded by the math community, most mathematicians don't care about
> software production, about opensourceness, just look how the scientific
> editors make money with the work of mathematicians and scientists in
> general.
> I don't know if the opendreamkit will succeed doing the boring work, but I
> believe there are several obstacles: the proposed salaries, the career
> perspectives, the code long term support... It's safer to bet on one person
> who is dedicated to the software, but the size of sagemath is probably too
> huge to be supported by one person alone.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Cross-compiling for SailfishOS (ARM)

[Francesco Biscani]

You could also try distcc + cross compiler on a beefy machine. I almost got
it working on my Raspberry PI before losing interest. IMO this would be the
best solution if you can manage to make it work. Good luck!

https://wiki.gentoo.org/wiki/Raspberry_Pi/Cross_building
http://archlinuxarm.org/developers/distcc-cross-compiling


On 18 February 2016 at 03:20, David Llewellyn-Jones 
wrote:

> Thanks for the advice. I read in this group about previous attempts
> (including yours) building on ARM Android devices, which encouraged me to
> try it on Sailfish. At the moment my build is still chugging away, although
> it got killed earlier and I had to set it off again (but it seems to be
> making progress again now).
>
> If it fails again I'll look into the possibility of emulation, but then
> I'll probably have to build my own Mer images, which I'd rather avoid! Too
> bad about the cross-compiling, but I'm sure making the build changes falls
> well outside my capability.
>
> So, I'll stick with attempting to build on the device until either it or I
> get stuck. Thanks again for the very useful advice.
>
>
> On Wednesday, 17 February 2016 12:40:08 UTC, mmarco wrote:
>>
>> Long ago i succeded at compiling sage in an arm tablet. It took around
>> two weeks (the power button got damaged, but I don't know if was related to
>> the heating of the device during the compiling or if it was an independent
>> problem).
>>
>> Cross compiling has the problem that some elements of Sage perform tests
>> in compile time by running the compiled code, so that would fail. You
>> should change manually the build process to prevent it (which is probably
>> not a good idea, because it is a lot of work, and because that kind of
>> automated testing might be really important, for instance ATLAS compiles
>> with different options, tests all of them and then chooses the fastest one).
>>
>> Another option is to emulate a full ARM machine in a x86 one. That is
>> doable, and theoretically would allow you to use much more RAM than what a
>> phisical ARM device has available, but there is a huge overhead, so it will
>> take also a lot of time.
>>
>> Finally, you have the option of using the arm builds that Sage provides.
>> They are not the last version, but not too old either. The might problem
>> you can find is that they are built for Ubuntu only, but you can overcome
>> that by setting up an ubuntu chroot environment in your device.
>>
>> El miércoles, 17 de febrero de 2016, 12:12:51 (UTC+1), David
>> Llewellyn-Jones escribió:
>>>
>>> Hello,
>>>
>>> I'm new to Sage, but interested to build it for Sailfish OS, an ARM
>>> Linux phone built atop Mer (see for example http://www.merproject.org/
>>> and https://sailfishos.org/ ). I'm doing it out of intrigue, so not
>>> necessarily expecting a practical result.
>>>
>>> Cross-compiling using Scatchbox2 (x86 VM building for armv7hl; see
>>> https://wiki.merproject.org/wiki/Platform_SDK_and_SB2 ) failed when
>>> attempting to execute genautomata. My uneducated guess is that it's
>>> building genautomata for ARM and then trying to execute it in the x86 build
>>> environment.
>>>
>>> Is it possible to cross-compile sage for ARM? Other posts on this list
>>> don't look encouraging, but any advice would be appreciated.
>>>
>>> David
>>>
>>> P.S. My back-up plan is to build it on the phone itself, but so far this
>>> hasn't yielded results (it's gobbling up increasingly large SD cards before
>>> running out of space).
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Hacker news thread about math software ("Announcing Wolfram Programming Lab")

[Francesco Biscani]

I am not a Mathematica user, so I cannot really comment about Mathematica's
flaws

(Incidentally, I remember some years ago someone built a system to feed
random input to CASes, with which he found many mathematical bugs in the
big Ms. I wonder if he's still doing it?)

But the fact that it is a black box should be a showstopper for any serious
use in research.

On 26 January 2016 at 22:05, rjf  wrote:

> I think it is somewhat disheartening to see Mathematica accepted as
> a program whose major or only flaw is that it is not open source.
>
> But maybe I didn't read all the comments.  It seems that the
> ycombinator contributors tend to rattle on a while.
> RjF
>
> On Wednesday, January 20, 2016 at 5:49:13 AM UTC-8, bluescarni wrote:
>>
>> It's somewhat refreshing to see that the idea that one should not use
>> black box software in science is finally starting to sink in.
>>
>> On 20 January 2016 at 13:30, William Stein  wrote:
>>
>>> There's a big thread on Hacker News about math software in which Sage
>>> is mentioned a few times:
>>>
>>> https://news.ycombinator.com/item?id=10934666
>>>
>>> I have the impression very few of the comments are from
>>> mathematicians...  Nonetheless, some people may find the comments
>>> interesting, since they reflect how open source math and scientific
>>> software such as Sage/Python/Sympy/Octave are (mis-)perceived by one
>>> group of potential users.
>>>
>>>  -- William
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "sage-devel" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to sage-devel+...@googlegroups.com.
>>> To post to this group, send email to sage-...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/sage-devel.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Hacker news thread about math software ("Announcing Wolfram Programming Lab")

[Francesco Biscani]

Ah thanks for the pointer, it took some google fu to get finally to his
website. In case anyone is interested:

http://www.cas-testing.org/



On 28 January 2016 at 18:39, William Stein <wst...@gmail.com> wrote:

> On Thu, Jan 28, 2016 at 9:17 AM, Francesco Biscani <bluesca...@gmail.com>
> wrote:
> > I am not a Mathematica user, so I cannot really comment about
> Mathematica's
> > flaws
> >
> > (Incidentally, I remember some years ago someone built a system to feed
> > random input to CASes, with which he found many mathematical bugs in the
> big
> > Ms. I wonder if he's still doing it?)
> >
>
> That's v...@ukr.net, who is subscribed to this list, often posts about
> Ukraine-related issues here, and has spoken at Sage Days in the past.
>  I really apprecaite that he put hard work into showing that these
> black boxes shouldn't be trusted.
>
> William
>
> > But the fact that it is a black box should be a showstopper for any
> serious
> > use in research.
> >
> > On 26 January 2016 at 22:05, rjf <fate...@gmail.com> wrote:
> >>
> >> I think it is somewhat disheartening to see Mathematica accepted as
> >> a program whose major or only flaw is that it is not open source.
> >>
> >> But maybe I didn't read all the comments.  It seems that the
> >> ycombinator contributors tend to rattle on a while.
> >> RjF
> >>
> >> On Wednesday, January 20, 2016 at 5:49:13 AM UTC-8, bluescarni wrote:
> >>>
> >>> It's somewhat refreshing to see that the idea that one should not use
> >>> black box software in science is finally starting to sink in.
> >>>
> >>> On 20 January 2016 at 13:30, William Stein <wst...@gmail.com> wrote:
> >>>>
> >>>> There's a big thread on Hacker News about math software in which Sage
> >>>> is mentioned a few times:
> >>>>
> >>>> https://news.ycombinator.com/item?id=10934666
> >>>>
> >>>> I have the impression very few of the comments are from
> >>>> mathematicians...  Nonetheless, some people may find the comments
> >>>> interesting, since they reflect how open source math and scientific
> >>>> software such as Sage/Python/Sympy/Octave are (mis-)perceived by one
> >>>> group of potential users.
> >>>>
> >>>>  -- William
> >>>>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups "sage-devel" group.
> >>>> To unsubscribe from this group and stop receiving emails from it, send
> >>>> an email to sage-devel+...@googlegroups.com.
> >>>> To post to this group, send email to sage-...@googlegroups.com.
> >>>> Visit this group at https://groups.google.com/group/sage-devel.
> >>>> For more options, visit https://groups.google.com/d/optout.
> >>>
> >>>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "sage-devel" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to sage-devel+unsubscr...@googlegroups.com.
> >> To post to this group, send email to sage-devel@googlegroups.com.
> >> Visit this group at https://groups.google.com/group/sage-devel.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to sage-devel+unsubscr...@googlegroups.com.
> > To post to this group, send email to sage-devel@googlegroups.com.
> > Visit this group at https://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> William (http://wstein.org)
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Hacker news thread about math software ("Announcing Wolfram Programming Lab")

[Francesco Biscani]

It's somewhat refreshing to see that the idea that one should not use black
box software in science is finally starting to sink in.

On 20 January 2016 at 13:30, William Stein  wrote:

> There's a big thread on Hacker News about math software in which Sage
> is mentioned a few times:
>
> https://news.ycombinator.com/item?id=10934666
>
> I have the impression very few of the comments are from
> mathematicians...  Nonetheless, some people may find the comments
> interesting, since they reflect how open source math and scientific
> software such as Sage/Python/Sympy/Octave are (mis-)perceived by one
> group of potential users.
>
>  -- William
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

Some random thoughts:

- I am not so convinced the strategy of automatic long -> long long
patching is actually feasible, I think in practice this is gonna be a big
can of worms. Pushing upstream to fix their code is a much better long-term
solution IMO (and I'd rather have nothing to do with projects which refuse
portability and code-quality patches, but that's just me :)
- mingw-w64 is a high quality compiler. I recently had to develop for a
while on a Windows 64 machine, and had to recompile a full stacks of
dependencies (MPFR, GMP, Boost, etc.). It was not so easy (most issues were
related to build systems), but the end result was pretty impressive
performance-wise.
- While for C code you can probably interoperate with libraries compiled
with MSVC, for C++ you will end up having issues related, e.g., to
different implementations of exception handling. My suggestion would be to
forget about MSVC and compile the full stack of dependencies exclusively
with mingw.
- Python on windows 64 does not play properly with mingw due to some
long-standing issues in some header files. If you want to compile Python
C/C++ extensions on Win64 you will have to patch slightly the Python
headers and re-generate the definitions of the Python library. The issue is
explored, e.g., here:

http://ascend4.org/Setting_up_a_MinGW-w64_build_environment#Setup_Python_for_compilation_of_extensions

Generally speaking, mingw-w64 is a really good option for C/C++ development
on Windows. The biggest problem is the proliferation of distributions
(mingw-w64, TDM mingw, mingw-build, msys2, etc.), but the toolchain is
solid. clang is getting there as well, so it's worth keeping it in mind for
the future.

Cheers,

  Francesco.


On 7 October 2015 at 16:35, Bill Hart  wrote:

> HI all,
>
> William Stein recently bemoaned the fact that SageMath currently only runs
> natively on some brands of Linux, and not natively on the latest Windows or
> OSX (that is to say nothing of BSD). [1]
>
> Until recently, a port of SageMath to Windows has seemed like a pipe
> dream. However, things have changed a lot, and I think it would now be
> possible to achieve this (for some definition of the word "native").
>
> I've tried VM's before and it has always ended in disaster. They either
> screw up my networking, they have performance issues, or don't support my
> mouse properly, or change my keyboard layout, or it's impossible to get
> files from my hard drive into the system easily, or they take up too much
> disk space or need to be constantly downloaded to update them, or some
> features don't work, or people stop supporting them, etc. The disadvantages
> of VMs are so numerous I hardly need to enumerate them. And even if it is a
> solution for users, it's hardly a solution for serious Windows developers.
>
> As some people know, I've been recently working on a Julia based "computer
> algebra system" for a much more limited subset of "computer algebra" than
> Sage targets. What people may not know is that that entire technology stack
> works natively on Windows.
>
> I can't express how fantastic it was to be sitting on a train recently,
> with no web access whatsoever and to be able to do work on my Windows 10
> (64 bit) laptop on the train. And everything ran as fast, or in some cases
> faster, than my Linux server. That's the first time that has happened since
> I started doing computational stuff about 10 years ago!
>
> MSYS2 as a solution
> 
>
> The new technology that makes all this work is MSYS2. Here are some of its
> features:
>
> * Installing MSYS2 on Windows couldn't be easier. [2]
> * It supports proper Windows exception handling protocols.
> * It has an amazing command line package manager called Pacman, which Just
> Works TM.
> * Unlike Cygwin, it's very minimal, and takes little time to install.
> * It's fast. Very fast.
> * Parallel make works.
> * The resulting binaries are fast, sometimes faster on my laptop than on
> the Linux server I usually use for development.
> * MSYS2 provides a posix layer! (Applications can be distributed with an
> MSYS2 dll for this.)
> * Multithreading using pthreads Just Works TM (Applications can be
> distributed with a winthreads dll for this. I've actually used this, no
> patching required, so I am not speaking theoretically here.)
> * Like native Windows, sizeof(long) = 4 and sizeof(long long) = 8 on
> MSYS2. This means interop with native Windows applications or assembly
> objects is a cynch.
> * The resulting applications can be run on Windows as essentially native
> applications. They don't have to be run from within the MSYS2 shell. They
> can also be distributed as binary packages for those that don't care about
> the source code. But here's the thing: it's not *necessary* to distribute
> them as binary packages. It's now quite feasible for developers to actually
> *build* packages on Windows. And let's face it, this is the type of
> developer we actually 

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

PARI requires (required?) sizeof(mp_limb_t)==sizeof(void*), which is not
guaranteed and not enforceable by PARI (as it's up to GMP to decide what
exactly an mp_limb_t is).

On 7 October 2015 at 19:03, Bill Hart  wrote:

>
>
> On Wednesday, 7 October 2015 18:37:41 UTC+2, Jean-Pierre Flori wrote:
>>
>>
>>
>> On Wednesday, October 7, 2015 at 6:35:36 PM UTC+2, bluescarni wrote:
>>>
>>>
> * PARI which assumes that sizeof(long) == sizeof(void*), there is an
> experimental branch fixing this:
> http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html
>

 I am using Pari (not GP) today on Windows 64. It was minimal effort on
 my part to do so. I am not using a special branch.

>>>
>>> This was a problem for the x32 architecture as well. See, e.g., here:
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724320
>>>
>>> Glad that the PARI devs fixed this eventually.
>>>
>> It was not fixed by an "actual" PARI dev, but what's important is that
>> some code is now publicly available.
>>
>
> I read through that entire Debian issue and still haven't got a clue what
> the issue was. There seems to have been a lot of arguing there about whose
> fault this actually was. None of these people is a dummy, so I don't
> understand why they couldn't figure it out.
>
> Anyway, x32 is not something I'm interested in supporting. It's great that
> GMP does, and some other software does, and Flint is moving towards
> supporting it. But it's not a priority.
>
> Bill.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

Practically, it's an architecture that supports "natively" 64 bit ints but
the pointers are 32 bits wide. AFAIK, this is supposed to improve
performance for pointer-heavy workloads that do not need to allocate much
RAM but still benefit from the 64 bit ints.

On 7 October 2015 at 19:54, Bill Hart  wrote:

> Actually, now I'm not even sure I understand what x32 is.
>
> I looked it up and found this page and found considerable disagreement on
> what it is:
>
>
> http://stackoverflow.com/questions/7635013/difference-between-x86-x32-and-x64-architectures
>
> I think I'll give it a miss for a while.
>
> Bill.
>
> On Wednesday, 7 October 2015 19:03:18 UTC+2, Bill Hart wrote:
>>
>>
>>
>> On Wednesday, 7 October 2015 18:37:41 UTC+2, Jean-Pierre Flori wrote:
>>>
>>>
>>>
>>> On Wednesday, October 7, 2015 at 6:35:36 PM UTC+2, bluescarni wrote:


>> * PARI which assumes that sizeof(long) == sizeof(void*), there is an
>> experimental branch fixing this:
>> http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html
>>
>
> I am using Pari (not GP) today on Windows 64. It was minimal effort on
> my part to do so. I am not using a special branch.
>

 This was a problem for the x32 architecture as well. See, e.g., here:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724320

 Glad that the PARI devs fixed this eventually.

>>> It was not fixed by an "actual" PARI dev, but what's important is that
>>> some code is now publicly available.
>>>
>>
>> I read through that entire Debian issue and still haven't got a clue what
>> the issue was. There seems to have been a lot of arguing there about whose
>> fault this actually was. None of these people is a dummy, so I don't
>> understand why they couldn't figure it out.
>>
>> Anyway, x32 is not something I'm interested in supporting. It's great
>> that GMP does, and some other software does, and Flint is moving towards
>> supporting it. But it's not a priority.
>>
>> Bill.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

I think in FLINT you also have the issue that you are using tagged pointers
(last time I checked anyway).

On 7 October 2015 at 20:03, Bill Hart  wrote:

>
>
> On Wednesday, 7 October 2015 19:48:54 UTC+2, bluescarni wrote:
>>
>> PARI requires (required?) sizeof(mp_limb_t)==sizeof(void*), which is not
>> guaranteed and not enforceable by PARI (as it's up to GMP to decide what
>> exactly an mp_limb_t is).
>>
>
> I think I understand now. I was misled by the person claiming Pari
> required sizeof(long) == sizeof(void*) and Bill Allombert debunking it.
> Bill was of course correct (he is a Pari dev).
>
> As for assuming sizeof(mp_limb_t) == sizeof(void*) we probably have the
> same issue in Flint. We will very slowly address this and have been making
> patches here and there. It's not a priority.
>
> However, that issue is entirely irrelevant to MSYS2. By default on that
> system both sizeof(mp_limb_t) and sizeof(void*) are 8 on Windows 64.
>
> The x32 issue is only affecting people who are wanting to support this
> trendy new ABI.
>
> Bill.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

On 7 October 2015 at 20:13, Bill Hart  wrote:

> I could be wrong, but this doesn't sound like it includes SageMath. :-)
>

Probably :)

I am not sure about the allocation limit, as the limit might only apply to
large contiguous allocations. Or there might be other memory addressing
tricks at play. Not 100% sure.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

>
>
>> * PARI which assumes that sizeof(long) == sizeof(void*), there is an
>> experimental branch fixing this:
>> http://pari.math.u-bordeaux.fr/archives/pari-dev-1505/msg00021.html
>>
>
> I am using Pari (not GP) today on Windows 64. It was minimal effort on my
> part to do so. I am not using a special branch.
>

This was a problem for the x32 architecture as well. See, e.g., here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724320

Glad that the PARI devs fixed this eventually.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Porting SageMath to Windows 64

[Francesco Biscani]

>
> I agree that's better if they will allow it. But I'm not sure some of the
> things SageMath depends on are even still maintained, let alone do all
> projects have the resources to keep maintaining such things, which is
> eventually what they get asked to do. Moreover, not all developers feel
> equally warm and fuzzy when you mention Windows. Some people are positively
> against supporting Windows. So what I am suggesting is a pragmatic
> compromise. And based on what I've seen with Pari, it works quite well. (I
> am sorry, I just haven't had the chance to look up when this porting work
> was done and how often it has been maintained, but I think it was something
> like 2008 or 2010 and with zero maintenance since, and it still works
> today).
>

I think we risk of mixing different things up. One thing is actively
supporting a Windows port from the point of view of build systems,
providing binary packages, and so on (which people might or might not want
to do due to personal inclinations, time/effort tradeoffs, etc.), another
thing is code quality. The issue above with PARI, for instance, was
affecting Linux x32 as well and it is just poor engineering in general.

I think that a high-quality project not providing support for on a OS as a
"first-class citizen" is fixable with relatively little effort, even if
upstream is not cooperative. To some extent, that is what the packagers of
linux distributions do. But it becomes orders of magnitude more difficult
if the project relies on platform-dependent system calls, libraries, or if
it just happens to work only on specific arch/OS setups.

Personally I don't care about Windows or OSX as a user, but I make sure my
software does compile and run properly on those platforms as a matter of
code quality. Also, as you pointed out, it helps a lot if one starts doing
this early in the development.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: FLINT/NTL benchmarks

[Francesco Biscani]

On 5 October 2015 at 13:13, Victor Shoup  wrote:
>
> I hesitate somewhat to get involved in SIMD game, as all the assembly code
> / intrinsics stuff is a huge time sink that
> will yield code that will probably be obsolete in 10 years.  Multicore, on
> the other hand, seems like a better
> investment, especially since C++11 (and C11) now standardize many aspects
> of it, so one can write portable
> code now.
>

I have been thinking the same. It also seems like the number of cores in
CPUs has been increasing faster than the width of SIMD instructions.

I know nothing about assembly language - so I am not sure how useful this
would be in practice - but I wish some type of SIMD support were
standardised in C++. The Boost.SIMD library, part of NT2,

https://github.com/jfalcou/nt2
https://meetingcpp.com/tl_files/mcpp/slides/12/simd.pdf

looks promising though.

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Re: [sage-devel] categories

[Francesco Biscani]

FWIW that's what Piranha does as well:

polynomial x{"x"};
 // This will print "1".
std::cout << std::is_same>::value << '\n';


On 1 October 2015 at 21:35, Bill Page  wrote:

> In FriCAS
>
> (1) -> x:Polynomial(Integer)
>Type:
> Void
> (2) -> x + 1/2
>
> 1
>(2)  x + -
> 2
>   Type:
> Polynomial(Fraction(Integer))
>
> On 1 October 2015 at 15:28, 'Bill Hart' via sage-devel
>  wrote:
> >
> >
> > On 1 October 2015 at 20:23, William Stein  wrote:
> > 
> >
> >> By the way, look at how coercion "works" in Magma:
> >>
> >> $ magma
> >> Magma V2.18-5 Thu Oct  1 2015 16:59:12 on compute3-us [Seed =
> >> 629019987]
> >> Type ? for help.  Type -D to quit.
> >> > R := PolynomialRing(IntegerRing());
> >> > x + 1/2;
> >>
> >> >> x + 1/2;
> >>  ^
> >> Runtime error in '+': Bad argument types
> >> Argument types given: RngUPolElt[RngInt], FldRatElt
> >
> >
> > We are call this "complex coercion" in our Nemo discussions
> >
> > [...as opposed to simple coercion:
> >
> >  R, x = PolynomialRing(QQ, "x")
> >  K, a = NumberField(x^3 + 3x + 1,"a")
> >
> >  a + 1/2 # simple coercion since the result lives in K
> > ]
> >
> > It's definitely quite easy to add complex coercion in Nemo/Julia (via
> Julia
> > generic catchall functions), but I'm resisting it quite obstinately for
> the
> > time being.
> >
> > One reason is that it easily leads to functions that are not
> > type-consistent. You can quite easily write functions whose output type
> > depends on the values, rather than the types of the inputs. This
> completely
> > screws with type inference and Jit compilation, though Julia does allow
> it.
> >
> > Since Nemo focuses on highly performant generics for the time being, I'm
> > trying to avoid introducing complex coercions, at least until we have a
> very
> > fast core. (Though naturally, mathematicians are keen to introduce this
> > feature as soon as possible, since it is basically germane to any real
> > mathematics.)
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Sources of funding - perhaps computer manufacturers?

[Francesco Biscani]

On 28 September 2015 at 19:37, William Stein  wrote:
>
> 1. Magma is also an Ma.   Magma's incredibly good at pure mathematics.
> You seem to be leaving out Magma above.
>

I admit I know basically nothing about Magma (I did not know it even
existed before joining this list :).


> 2. You say "... better served in the Python space by the
> Numpy/SciPy/SymPy/Matplotlib stack as an alternative to the Ma's
> rather than SAGE."   Sage includes "Numpy/SciPy/SymPy/Matplotlib", so
> we don't have to worry about that chunk of people with respect to our
> mission statement.
>

I can install the NSPM stack on any modern platform (Windows included) with
pip (or my distro's package manger, if I am on linux) in probably less than
5 minutes with a reasonable internet connection. I don't have to worry
about sizeable downloads, virtual machines, containers, emulation layers
a-la cygwin, installing a separate compiler toolchain/python version/set of
libraries, or anything of the sort.

It is true that you can use the NSPM stack from SAGE, but what are the key
advantages of doing so? It is a honest question, maybe there's something I
am overlooking.

3. There is a lot more to mathematics than just what Magma does and
> *also* much more to it than just what Numpy/SciPy/SymPy/Matplotlib do.
>   There's a huge amount of interesting things that could be
> systematically computed with in mathematics that no existing package
> does yet.
>

Yes, nobody has the monopoly on what "mathematics on a computer" means :)

My comment was merely a marketing/strategic one: I think there exists a
disconnect between the mission statement and what SAGE actually is (and
maybe what the SAGE community wants it to be).

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Sources of funding - perhaps computer manufacturers?

[Francesco Biscani]

>
> Exactly.  And also the mission statement: viable alternative to the Ma's -
> that is tricky!
>

I have always felt a tad confused and mislead by this statement.

As someone who has interacted over the years with physicists and engineers
using daily Mathematica, Maple and Matlab, I see very little overlap
between their typical use of these tools and the typical usages of SAGE, at
least from the point of view of a lurker on this list. It seems like SAGE
caters to (and is run mostly by) researchers in pure mathematics, and that
is little interest on other use cases. Pragmatically, it seems to me that a
sizeable chunk of people "doing mathematics on a computer" is today better
served in the Python space by the Numpy/SciPy/SymPy/Matplotlib stack as an
alternative to the Ma's rather than SAGE.

This is of course completely fine! I am not questioning anyone's motives,
inclinations or desires. But IMO continuing to push the idea that SAGE aims
to be a viable alternative to the Ma's tout-court risks of being a source
of confusion.

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] What can we assume about our C compiler

[Francesco Biscani]

FWIW, here's my experience with various C++11 compilers:

- GCC >= 4.8 is C++11 feature complete (core language, not necessarily
library-wise) and quite usable (this includes MinGW);
- clang >= 3.3 is C++11 feature complete and in general slightly better for
standard-conformance and stability than GCC;
- Intel's compiler is reasonably feature-complete as of version 15 (at
least on Unix-like archs), but it's an ICE trainwreck when one tries to use
even slightly complex metaprogramming. I would expect it to choke on many
modern C++ libraries;
- MSVC is still lagging a lot behind.

My suggestion would be to require GCC 4.8 or greater and do not bother with
anything earlier. Features will be missing and the likelihood of bugs in
implemented features is much higher before 4.8.

Another random thing to keep in mind is that OSX clang disables some C++11
features because "Apple". E.g., C++11 thread-local storage is still
disabled pending some ABI changes in Apple's ecosystem:

http://stackoverflow.com/questions/23791060/c-thread-local-storage-clang-503-0-40-mac-osx
http://stackoverflow.com/questions/28094794/why-does-apple-clang-disallow-c11-thread-local-when-official-clang-supports

(this is a real drag for parallel programming)

Cheers,

  Francesco.

On 23 September 2015 at 22:09, Clement Pernet 
wrote:

> The Givaro-LinBox-fflas-ffpack ecosystem now requires C++11 support.
> I'm hitting this problem, while working on #17635, upgrading the spkgs of
> these 3 libraries.
>
> Therefore:
>
> > 1) Do we want to mandate c++11 support
> Y[X]
> N[ ]
> >
> > 2) if yes what c++11 features do we want?
> Feature complete [X]
>
> as many features are used.
>
> > List of features [ ] (list needed features)
> Tentative list of what's currently being used (I may have missed some)
>  * using
>  * enable_if
>  * auto
>  * fixed width types and related constant suffixes (ex uint64_t x=2_ui64;)
>  * ...
>
> Clément
> >  * override
> >
> > François
> >
> >> On 22/09/2015, at 15:27, Ralf Stephan  wrote:
> >>
> >> On Monday, September 21, 2015 at 6:38:50 PM UTC+2, Volker Braun wrote:
> >>> Afaik we already require C++11 support to compile Pynac
> >>
> >> Yes, Pynac git master requires it but we're still installing backported
> versions (0.3.9.x vs 0.4.x).
> >>
> >> The ticket that never got finished was
> >> http://trac.sagemath.org/ticket/18323
> >>
> >> Regards,
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+unsubscr...@googlegroups.com.
> >> To post to this group, send email to sage-devel@googlegroups.com.
> >> Visit this group at http://groups.google.com/group/sage-devel.
> >> For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Sage and independent C++ code

[Francesco Biscani]

On 13 September 2015 at 20:31, William Stein  wrote:

> I think  pip is good enough these to support
> install/uninstall/versions/dependencies/c++ code, etc.
>

I think the situation is still dire for c/c++ extensions. Compiled wheels
seem to be viable for platforms like OSX and Windows, but for source builds
one runs into the usual problems:

- setuptools is not good enough for complex c/c++ projects,
- no integration with system-wide package managers,
- difficult to deal with dependencies outside the Python ecosystem.

These are real difficulties for projects which are not primarily
Python-based but which offer Python bindings. Even in the best-case
scenario one still has to port over an already-functional build system
(autotools, CMake, ...) to setuptools, and maintain it. It seems really
hard to solve the Python packaging problem without first solving the
general packaging problem.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Generate Python classes from C++ headers?

[Francesco Biscani]

On 5 September 2015 at 18:10, William Stein  wrote:

> With sip/swig, I think it's much more automated, since on
> the Python side you get normal Python classes, which support multiple
> inheritance.
>

With Boost Python you also get the original C++ class as a Python class. It
also supports inheritance (you want to expose your base C++ class as Python
class, inherit from it in Python and store it in a vector of base pointers
on the C++ side? You can), overriding of virtual methods from Python
(including pure virtuals and abstract base classes), iterators, automatic
exception translation, embedding, overloaded functions, custom converters,
automatic pickle support, automatic handling of smart pointers and a host
of other features.

The documentation was recently updated here:

http://boostorg.github.io/python/doc/html/reference/index.html

IMO its only problem is that no new features have been added in ages and it
is essentially in maintenance mode (unless someone picks the development
up). The last substantial development was when Python 3.x support was
added, so at least it is future proofed for a while. To me its design is
unparalleled by any C++ wrapping tool for any language.

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Generate Python classes from C++ headers?

[Francesco Biscani]

For exposing C++ to Python I personally dislike solutions which require
external tools. I have been using Boost.Python for years and I very
satisfied with it:

http://www.boost.org/doc/libs/1_59_0/libs/python

If you are reasonably comfortable working with modern C++, that would be me
first choice.

It's not automatic, in the sense that you will have to write C++ source
files in which you are specifying exactly what and how you want to expose.
But it gives you a very deep integration between the two languages.

Alternatively you can today do interactive C++ with things like Cling and
Cxx.jl

https://github.com/vgvassilev/cling
https://github.com/Keno/Cxx.jl

Cling looks impressively promising in particular. It also has a IPython
kernel:

https://github.com/minrk/clingkernel

Cheers,

  Francesco.

On 3 September 2015 at 17:31, Nathann Cohen  wrote:

> Yo !
>
> > There are, however, a bunch of libraries that have been developed over
> > the years that parse C++ header files and generate Python/C API
> > bindings, including:
> >
> > swig = standard wrapper and interface generator
> > sip = ?
>
> Thaanks ! It seems that "SWIG" is still alive (and kicking, as
> they are apparently suing somebody for a license violation). I
> forwarded the conversation to Alain Jean-Marie, and maybe that will
> help them :-)
>
> Good evening,
>
> Nathann
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [sage-combinat-devel] Sage Days 65 mini report

[Francesco Biscani]

On 19 June 2015 at 10:12, Volker Braun vbraun.n...@gmail.com wrote:

 Yeah but Apple, in their infinite wisdom, has decided to put
 /usr/local/include at place #2 in the header include path. Even before
 /usr/include. So there is that.


Oh boy.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [sage-combinat-devel] Sage Days 65 mini report

[Francesco Biscani]

Wait, so Apple does not support an OS which came out in late 2013?

On 14 June 2015 at 11:05, Volker Braun vbraun.n...@gmail.com wrote:

 I don't think more testing is the answer. Really, the problems boil down
 to

 a) OSX users running outdated and usupported OSX versions (i.e. anything 
 10.10); Do you want to run a buildbot with an OS version that has major
 unfixed security issues and that has been EOL'ed by the manufacturer?
 Apple's valuation is 7x the cost of the Apollo program and they don't do
 it; How many resources do we have at our disposal?

 b) random crap installed in /usr/local thanks to homebrew. That nothing
 imports / links from /usr/local could be automatically tested using strace,
 a compiler wrapper, or poisoned headers like the fake
 /usr/local/include/gmp.h on my osx buildslave. But more machines won't help
 unless you want to install random crap on them.

 c) no windows support

 d) abuse of LD_LIBRARY_PATH makes Sage impossible to build/use on some
 Linux distros, e.g. if Sage readline clashes with the version that bash
 needs then you are SOL.




 On Sunday, June 14, 2015 at 12:08:03 AM UTC+2, Jeroen Demeyer wrote:

 On 2015-06-13 01:26, William Stein wrote:
  suggestions about how to address this
  problem using new ideas.
 More testing? More and different buildbot machines testing more
 operating systems? Perhaps using VM's?

  --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] The future of polybori

[Francesco Biscani]

 Or at least it is not hard to write modern  C++ that is very difficult for
 others to work on.


Isn't it true for most languages? I have seen nested list comprehension
one-liners in Python that make my skin crawl.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: (off topic) Re: [sage-devel] The future of polybori

[Francesco Biscani]

I agree partially about your best programming language statement: there
are languages which are useful for very few things - see Fortran - while
others have broader applicability. With C++ one can do well and comfortably
enough scientific computing, system programming, graphics, and a host of
other things. It does not have to be a zero sum game.

Regarding the difficulty of deciphering, I guess it is in the eye of the
beholder. Try explaining metaclasses, decorators, __new__() overloading or
the method resolution order for multiple inheritance in Python to someone
who makes a living doing embedded programming in C :)

Python certainly has a lower barrier of entry than many other languages,
but any sufficiently complicated language will look alien once you get off
the beaten path. This is especially true when a language evolves; you
mentioned modern C++ in an earlier mail, and it is true that it will look
alien to most people who learned '90s style C++. On the other hand, it
allows you to do things that no other language can, so I am not sure it is
fair to say it is difficult to decipher - it is just an entirely different
thing.

Anyway, sorry for the rambling :)

  Francesco.

On 11 June 2015 at 18:50, William Stein wst...@gmail.com wrote:

 (off topic)

 On Thu, Jun 11, 2015 at 8:58 AM, Francesco Biscani bluesca...@gmail.com
 wrote:
  Or at least it is not hard to write modern  C++ that is very difficult
 for
  others to work on.
 
 
  Isn't it true for most languages?

 In my opinion, absolutely unequivocally not.Each programming
 languages has a huge range of pros and cons.   Each programming
 language (and standard library) is good at expressing certain things
 and bad at others.   Ability to easily write very
 difficult-to-decipher code is something C/C++ is better at than some
 other languages such as Python.

 I'm sure that anybody who has really learned a few very different
 programming languages well (having written and worked on a few tens of
 thousands of lines of code in each) would agree.

 In my mind I do not view Python is the best programming language for
 everything any more than I view my impact driver as the best tool in
 my toolshed for everything.  (Though impact drivers are pretty
 awesome.)

 William

   I have seen nested list comprehension
  one-liners in Python that make my skin crawl.



 
  --
  You received this message because you are subscribed to the Google Groups
  sage-devel group.
  To unsubscribe from this group and stop receiving emails from it, send an
  email to sage-devel+unsubscr...@googlegroups.com.
  To post to this group, send email to sage-devel@googlegroups.com.
  Visit this group at http://groups.google.com/group/sage-devel.
  For more options, visit https://groups.google.com/d/optout.



 --
 William (http://wstein.org)

 --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: (off topic) Re: [sage-devel] The future of polybori

[Francesco Biscani]

On 11 June 2015 at 20:13, Travis Scrimshaw tsc...@ucdavis.edu wrote:

Difficult-to-dechiper can be considered a pro by bigger businesses with
 proprietry software to help prevent reverse-engineering (although from what
 I've been told, they typically run it through a scrambler before compiling
 the code for release).


Not sure what you mean by that. I have worked in the past for a
multinational company (100k employees) on software which costs hundreds of
thousands of dollars per license, and never heard of that. I am not an
assembly guy but I would think that the binary of a non-trivial software is
already scrambled well enough (especially in release mode where the
compiler is gonna pull all sorts of tricks for optimisation).


 However, from my experience, it is the quality of the code, comments, and
 documentation that determines the readability of the code, not so much the
 language. That's not to say some languages don't make it really difficult;
 specifically the non-standard/joke/developed-by-a-guy-with-too-much-ego
 *coughmathmaticacough* language, but these are relatively rare in practice.


I agree with you. I would not even consider Mathematica (or Wolfram code,
or whatever it is called nowadays) a proper language.

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: (off topic) Re: [sage-devel] The future of polybori

[Francesco Biscani]

Bravo, that was pretty good :)

On 11 June 2015 at 21:10, William Stein wst...@gmail.com wrote:

 On Thu, Jun 11, 2015 at 11:55 AM, Francesco Biscani
 bluesca...@gmail.com wrote:
  On 11 June 2015 at 20:13, Travis Scrimshaw tsc...@ucdavis.edu wrote:
 
 Difficult-to-dechiper can be considered a pro by bigger businesses
 with
  proprietry software to help prevent reverse-engineering (although from
 what
  I've been told, they typically run it through a scrambler before
 compiling
  the code for release).
 
 
  Not sure what you mean by that. I have worked in the past for a
  multinational company (100k employees) on software which costs hundreds
 of
  thousands of dollars per license, and never heard of that. I am not an
  assembly guy but I would think that the binary of a non-trivial software
 is
  already scrambled well enough (especially in release mode where the
 compiler
  is gonna pull all sorts of tricks for optimisation).
 
 
  However, from my experience, it is the quality of the code, comments,
 and
  documentation that determines the readability of the code, not so much
 the
  language. That's not to say some languages don't make it really
 difficult;
  specifically the non-standard/joke/developed-by-a-guy-with-too-much-ego
  *coughmathmaticacough* language, but these are relatively rare in
 practice.
 
 
  I agree with you. I would not even consider Mathematica (or Wolfram
 code, or
  whatever it is called nowadays) a proper language.

 It's officially called The Wolfram Language [1] beating out [2] many
 other options such as Wolframese, Wolframic, Wolframian, Wolframish
 or Wolframaic, perhaps Wolfese, Wolfic or Wolfish, Wolfian or Wolfan
 or Wolfatic, ,the exotic Wolfari or Wolfala? Wolvese or Wolvic?
 WolframCode or WolframScript—or Wolfcode or Wolfscript—but these sound
 either too obscure or too lightweight. Then there’s the somewhat
 inelegantWolframLang, or it shorter forms WolfLang and WolfLan, which
 sound too much like Wolfgang. Then there are names like WolframX and
 WolfX, but it’s not clear the “X” adds much. Same with WolframQ or
 WolframL. There’s also WolframPlus (Wolfram+),WolframStar (Wolfram*)
 or WolframDot. Or Wolfram1 (when’s 2?), WolframCore(remember core
 memory?) or WolframBase. There are also Greek-letter suffixes,
 Wolfram|Alpha-style, like Wolfram Omega or Wolfram Lambda (“wolf”,
 “ram” and “lamb”: too many animals!). Or one could go shorter, like
 the W Language...

 [1] http://en.wikipedia.org/wiki/Wolfram_Language

 [2]
 http://blog.stephenwolfram.com/2013/02/what-should-we-call-the-language-of-mathematica/



 
  Cheers,
 
Francesco.
 
  --
  You received this message because you are subscribed to the Google Groups
  sage-devel group.
  To unsubscribe from this group and stop receiving emails from it, send an
  email to sage-devel+unsubscr...@googlegroups.com.
  To post to this group, send email to sage-devel@googlegroups.com.
  Visit this group at http://groups.google.com/group/sage-devel.
  For more options, visit https://groups.google.com/d/optout.



 --
 William (http://wstein.org)

 --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-flame] Re: [sage-devel] For french readers

[Francesco Biscani]

Hello Bill,

On 2 April 2015 at 18:06, Bill Hart goodwillh...@googlemail.com wrote:

 We are very deliberately targeting the leading/bleeding edge because there
 is just so much amazing, useful stuff in the works that we really can't
 ignore (dramatically improved gc, much better C struct support, staged
 functions, C++ interface support, including inline C++, many speedups and
 bug fixes). We have numerous local hacks so that we can keep working
 through all the chaos.


I just went to take a look at Cxx.jl, and it looks very promising! There's
not much documentation about it though, so I was wondering if you know
about the following:

- does it support templates?
- can you define julia structs/classes (if it makes any sense) on top of
the C++ ones (that is, I would like to be able to expose C++ classes and
their methods/operators, and to be able to call them from julia)? Or does
it support only functions?
- is the REPL stuff going to be basically an interactive C++ interpreter?
It seems to reference in some places Cling (
https://root.cern.ch/drupal/content/cling), which I had read about
previously.

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

[Francesco Biscani]

Hello William,

On 20 February 2015 at 01:22, William Stein wst...@gmail.com wrote:

 This has been discussed over and over again and it plainly doesn't
 work. The Sage in Debian does not pass doctests, not even close. In
 general the combinatorial explosion of configurations to debug is way
 too large and it is next to impossible to find any distribution where
 the version numbers even remotely match. We updated to GAP 4.4.12 in
 Sage 3.3 and the doctests involving GAP will in certain files be
 broken with any previous GAP release. If you used the Debian packages
 for Singular Sage won't work since we patch NTL and when those NTL
 libs come in conflict either Sage doesn't compile or Singular blows
 up. I can go on and on and on about similar issues and that is only
 the stuff I know about right on top of my head. I have never taken the
 time to go out and do dumb things to break Sage :)

 In the near future we plan to upgrade to a svn release of the
 development version of pari and then closely track it as bugs we
 report are often only fixed in pari-2.4.3svn. There is *no* way any
 distribution can track this without potentially breaking other code
 dependent on pari and you will be royally screwed if you want to use
 pari 2.3.4 in Sage (the stable release at this point) since Sage won't
 even build. We will fix all in tree code that gets broken with the new
 pari-svn and push it back upstream, but until that shows up in a
 distribution we will long have shipped Sage 4.0.

 The way we do it is the only way and I have doubts that any
 distribution packaged Sage will even be able to keep up with the
 official release given that I (=Michael Abshoff) spend working full
 time as the Sage
 release manager :)


With due respect, all these points indicate software engineering
deficiencies (e.g., the inability to guarantee a stable API, variations in
the results of identical commands from one version to another, etc.).


 Those are a different domain of software engineering.  Mathematics
 software is fundamentally different than word processing, graphical
 desktop, and web browser software.   It doesn't matter much if a line
 in a UI is off by one pixel.  In mathematics, being off by 1 can
 result in major bugs all over Sage.


I disagree with this argument. Mathematics software is exactly the same as
any other software. I am pretty sure that off-by-one errors are taken
pretty seriously, e.g., in the Linux kernel, in GCC, Glibc, Python or the
cryptographic code in Firefox or Chrome. Also, your statement here seems to
be at odds with he paragraph above, where Michael laments that changing the
versions of software changes the result of computations?

The point was about handling long dependency chains (so I picked as
examples a bunch of projects with a long dependency list). Why is it that I
can expect to be able upgrade seamlessly, on my linux box, a library like
libpng or openssl - on which hundreds of other packages depend - without
breaking any of them? Again, this has only to do with software engineering
best practices.


 The Sage distribution model, which has frequently been attacked every
 single year for nearly a decade, is one of the most important reasons
 for Sage's success.


Still, after ten years it is still not possible to do yum install sage or
apt-get ... . I would say that this is a barrier for a lot of people to
use sage.


 That said, if somebody had the energy to make and maintain a
 branch/fork of Sage that could easily integrate with Linux distros,
 more power to them.  I'd be happy to host it, point to it on the sage
 website, etc.   If I had infinite resources (money) I would definitely
 hire somebody to create and maintain such a thing.  It wouldn't even
 be a question.The problem is that right now we have *extremely*
 limited resources and have to make choices.


In all honesty, I think you should throw golden bridges to people like
Julien and Francois who are doing all this heavy-lifting work on the
software engineering side of things. I think that having sage integrating
with distro packages would not only be a benefit from the point of view of
expanding the userbase, I think it would also greatly increase the software
engineering quality of sage and related packages.

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

[Francesco Biscani]

On 19 February 2015 at 18:05, Julien Puydt julien.pu...@laposte.net wrote:

 All distributions have thousands of packages, and deps are not a big
 issue. Sage-the-distribution has about a hundred, and it's a big issue.


This is something I have failed to understand so far. What is it that makes
Sage require such special handling of dependencies (i.e., package
everything in one monolithic blob and with ad-hoc patching)?

There's a lot of complex software around with long dependency chains
(Firefox, Chrome, KDE, GNOME, OpenOffice, ...) and it seems like most Linux
distributions are able to deal with this, without too many issues, via
system-wide libraries. Even in the presence of libraries that do not do
stable releases (e.g., ffmpeg a few years ago is a notable example I think)
or do not guarantee a stable API. Of course, problems and incompatibilities
arise occasionally, but many distributions have developed mechanisms to
cope with this (e.g., SLOTs in Gentoo, proper versioning, reverse
dependency checking, blockers, etc.).

I understand that the big blob probably makes it easier on platforms such
as OSX, but honestly, all this stuff about packaging, versioning, etc. has
been a solved problem on Linux distributions for quite a while now.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Is CMake OK for a standard spkg?

[Francesco Biscani]

On 6 February 2015 at 14:47, Jeroen Demeyer jdeme...@cage.ugent.be wrote:

 Not true. Building a package using autotools doesn't require autotools.
 Autotools generates files like configure which are shipped with the
 sources. Executing those files does not require autotools.


But it requires some sort of GNU environment to be available... Which in
platforms such as Windows could be a problem.

CMake was chosen as the build system for KDE starting with version 4 and -
as far as I have seen - it has become the de-facto standard for Qt
applications in general. It is certainly up to the task of being able to
deal with non-trivial software projects.

I am not a big fan of the macro syntax, but after having used CMake for a
quite a long time I am rather satisfied with it personally.

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: What are we unable to do right now ?

[Francesco Biscani]

On 5 December 2014 at 21:45, maldun dom...@gmx.net wrote:

 I agree with you that it is not that important as it was some years ago.
 Nevertheless be aware that many professional users in engineering
 and research can't go online that simply, because of security reasons, and
 company policies (I know that from first hand),
 and they are a big market which we should not underestimate.


+1

In many engineering/industrial/technical contexts, especially in big
corporations, a Windows workstation is still the default setup, OSX is
non-existent, and Linux/Unix is relegated to HPC and clusters. This is not
going to change substantially in the short term.

I think there is also a code-quality rationale for having strong
multi-platform and multi-architecture support. Software is a bit like a
lifeform, living in and adapting to different environments makes it
stronger and more resilient.

Cheers,

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: What are we unable to do right now ?

[Francesco Biscani]

On 5 December 2014 at 20:48, 'Martin R' via sage-devel 
sage-devel@googlegroups.com wrote:

 A famous example is

 integrate(x/sqrt(x^4+10*x^2+-96*x-71),x)

 which Mathematica won't do, although it is elementary, i.e., has a
 solution in terms of elementary functions:


 log((x^6+15*x^4+-80*x^3+27*x^2+-528*x+781)*(x^4+10*x^2+-96*x+-71)^(1/2)+(x^8
 +20*x^6+-128*x^5+54*x^4+-1408*x^3+3124*x^2+10001))/8


That is pretty interesting, I would've treated this as an elliptic integral
without thinking about it twice. I have two questions:

- I imagine if you calculate it as an elliptic integral (say, using the
Weierstrassian functions) you would end up with elliptic invariants g1 and
g2 with special values that make the elliptic integral collapse to an
elementary function?
- The factorization of the polynomial in the integrand yields a
suspiciously symmetrical form in the factors, is that the reason why the
integral can be evaluated with elementary functions?

Sorry for the OT!

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Call qsort from cython code .... with an inlined comparison function ?!

[Francesco Biscani]

On 23 November 2014 at 18:07, Volker Braun vbraun.n...@gmail.com wrote:

 C++ std::sort will be able to inline the comparator.


+1

std::sort() will do exactly what you describe, only in a type-safe and
compiler-checked automatic way.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Call qsort from cython code .... with an inlined comparison function ?!

[Francesco Biscani]

On 23 November 2014 at 19:05, Thierry Dumont tdum...@math.univ-lyon1.fr
wrote:

 Is gprof enough powerful with modern architectures on such programs? from
 my point of view, no.
 There are non free, commercial, tools like vtune which can do fantastic
 measurement job. Vtune shows, for example, that a call to std::copy is not
 as fast as a for loop, which is turned by the compiler in a memcopy
 (probably std::copy is not!). I do not think we can see this with gprof.
 But ok, you are not supposed to buy vtune...


I would be surprised if any modern c++ library implementation does not have
specialisations of std::copy for POD types that use memcpy() or some other
trick.


 What about likwid https://code.google.com/p/likwid ? It is free. Did
 somebody used it to measure cython code performances?

 Likwid (and Vtune) have in common to use  performance counters on Intel
 and AMD processors (not sure for AMD with Vtune...).

 What is the size of what you are sorting ? If it is small enough to fit in
 the caches, and better in the L1 cache, you can possibly improve something
 with your modification, but otherwise it is certainly memory bounded and
 you cannot do much...
 You have to measure the bandwidth of your program. Vtune does this,
 possibly likwid too.


I used callgrind() in the past with some success... I would like to try the
google cpu profiler to see how it fares, but I haven't had the chance yet.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Call qsort from cython code .... with an inlined comparison function ?!

[Francesco Biscani]

On 23 November 2014 at 20:41, Thierry Dumont tdum...@math.univ-lyon1.fr
wrote:

 But what about the quick sort? is it sure that the implementation cannot
 degenerate? it is well known all the efficiency can be lost if the key
 used for partition is not chosen  as it should be... What about replacing
 the quick sort by an other method ? (the tree based one?).


qsort is not necessarily quick sort. AFAIK, the C/C++ libraries only
guarantee that the sorting has logarithmic complexity in the number of
comparisons.

std::sort is often implemented as a mix of introsort and other sorting
algorithms, with special casing for small/big objects, small/large number
of items to be sorted, etc.

  F.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Call qsort from cython code .... with an inlined comparison function ?!

[Francesco Biscani]

icc is a pretty garbage C++ compiler, unless you are doing exactly the type
of linear algebra operations that they optimise to death (on Intel
processors at least :) for benchmarketing.

On 23 November 2014 at 21:53, Thierry Dumont tdum...@math.univ-lyon1.fr
wrote:

 Le 23/11/2014 20:53, Jeroen Demeyer a écrit :

 On 2014-11-23 19:05, Thierry Dumont wrote:

 Vtune shows, for example, that a call to std::copy is
 not as fast as a for loop, which is turned by the compiler in a memcopy
 (probably std::copy is not!).

 If that's the case, get a better C++ compiler.

  heum... it is icc :-)
 A c++ compiler as some unpredicable aspects...


 --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] c++11, mpirxx, and normaliz problem

[Francesco Biscani]

Looks like this might be the root:

https://gcc.gnu.org/gcc-4.9/porting_to.html

Unformatted quoting:


Header cstddef changes

The cstddef header was updated for C++11 support and this breaks some
libraries which misuse macros meant for internal use by GCC only. For
instance with GMP versions up to 5.1.3, you may see:

/usr/include/c++/4.9.0/cstddef:51:11: error: ‘::max_align_t’ has not been
declared
   using ::max_align_t;
   ^
Another possible error is:

someheader.h:99:13: error: ‘ptrdiff_t’ does not name a type

A workaround until libraries get updated is to include cstddef or
stddef.h before any headers from that library.


On 18 November 2014 15:39, Dima Pasechnik dimp...@gmail.com wrote:

 basically, current (upstream) normaliz does not compile with gcc 4.9.2;
 (with Sage 4.5.beta0).
 I tracked it down to the following test, showing that mpir(xx) does
 something strange...

 $ cat b.cpp
 #include mpirxx.h
 int main()
 {
 return alignof(std::max_align_t);
 }

 $ g++   -std=c++11 -c b.cpp
 In file included from
 /home/scratch/dimpase/sage/sage6.3/local/include/mpir.h:53:0,
  from
 /home/scratch/dimpase/sage/sage6.3/local/include/mpirxx.h:44,
  from b.cpp:1:
 /home/scratch/dimpase/sage/sage6.3/local/include/c++/4.9.2/cstddef:51:11:
 error: '::max_align_t' has not been declared
using ::max_align_t;
^
 b.cpp: In function 'int main()':
 b.cpp:6:20: error: 'max_align_t' is not a member of 'std'
  return alignof(std::max_align_t);

 e$ g++ -v
 Using built-in specs.
 COLLECT_GCC=/home/scratch/dimpase/sage/sage6.3/local/bin/g++

 COLLECT_LTO_WRAPPER=/home/scratch/dimpase/sage/sage6.3/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
 Target: x86_64-unknown-linux-gnu
 Configured with: ../src/configure
 --prefix=/home/scratch/dimpase/sage/sage6.3/local
 --with-local-prefix=/home/scratch/dimpase/sage/sage6.3/local
 --with-gmp=/home/scratch/dimpase/sage/sage6.3/local
 --with-mpfr=/home/scratch/dimpase/sage/sage6.3/local
 --with-mpc=/home/scratch/dimpase/sage/sage6.3/local --with-system-zlib
 --disable-multilib --disable-nls --enable-languages=c,c++,fortran
 --disable-libitm
 Thread model: posix
 gcc version 4.9.2 (GCC)


 --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Fwd: NTL v7 -- thread safety

[Francesco Biscani]

Nice to see that C++11 is gaining wider acceptance.

On 11 November 2014 14:45, John Cremona john.crem...@gmail.com wrote:

 -- Forwarded message --
 From: Victor Shoup sh...@cs.nyu.edu
 Date: 8 November 2014 17:43
 Subject: NTL v7 -- thread safety
 To: nmbrt...@listserv.nodak.edu


 I'd like to announce a new release of NTL, a high-performance C++ library
 for doing arithmetic in a variety of fundamental rings.

 Version 7 of NTL is now thread safe.  This is a major milestone for NTL.
 However, to actually use it, you will need a bleeding edge C++ that
 supports
 C++11 concurrency features.  Please see

http://shoup.net/ntl/doc/tour-changes.html

 for more details on this and several other new features.

 To download NTL, please go here:

http://shoup.net/ntl/

 Thanks,

 Victor Shoup

 
 Prof. Victor Shoup
 Dept. of Computer Science
 New York University

 --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Future NTL versions and exception handling

[Francesco Biscani]

OOM exception handling is gonna be hard to implement, as GMP does not
provide any mechanism to recover from memory errors. You can replace the
GMP memory management functions but the usual problem with that approach is
that you might be potentially interacting with other packages which might
also want to override the default functions. Another problem is that IIRC
throwing C++ exceptions from C is undefined (or maybe
implementation-defined?) behaviour.

In any case, exceptions are the way to go when you program in C++. A
well-coded C++ program should state precisely what level of exception
safety the routines provide (no-throw, strong, basic), and how and what a
routine can throw. Ideally you would want strong exception safety always -
this is quite doable but sometimes for the sake of performance basic
exception safety is a good compromise. Of course anything involving move
semantics should be marked noexcept. Another typical suggestion is always
to use RAII patterns when coding routines that can throw - that way you are
guaranteed that any resource is properly cleaned up before exiting the
function through an exception.

C++11 also has good support for handling exceptions in threads, including
transporting exceptions between threads. In particular, using an
std::future for managing the return value of (or the exception thrown
within) a thread is pretty handy.

Cheers,

  Francesco.

On 12 November 2014 00:05, Jean-Pierre Flori jpfl...@gmail.com wrote:



 On Tuesday, November 11, 2014 11:55:49 PM UTC+1, Volker Braun wrote:

 What kind of error states are we talking about? divide by zero and out of
 memory?

 Exactly, that is exactly the kind of stuff Victor mentioned.


 IMHO a C++ library should just throw C++ exceptions, thats what they are
 here for. If only for better readability - less bugs. If you declare
 methods with except + to Cython then they will automatically be converted
 into Python exceptions, so its also very convenient for us. Pynac uses that
 all the time.

 Pretty much the only potential downside are rumors that exceptions might
 possibly hinder the optimizer. Though I've never seen that in a reasonable
 benchmark. While that is certainly a possibility, it would just be an
 optimizer bug. All reasonable C++ compilers uses a zero-cost model so its
 at least as fast as handling / returning some error flag. What _is_
 expensive is when an exception occurs, but in C++ you are not supposed to
 use exceptions for program flow like in Python.



 On Tuesday, November 11, 2014 10:15:44 PM UTC, Jean-Pierre Flori wrote:

 Dear all,

 As you must have noticed, Victor Shoup just released a new thread safe
 version of NTL.

 He also took the opportunity to ask me (and surely a bunch of other
 people) what would be expected from exception handling in NTL
 Currently NTL just prints something and then aborts.
 Note that we patch that in Sage to call one of our own functions and
 avoid aborting.
 I'm no C++ expert and don't usually play with exceptions, so I don't
 have anything that sart to say.
 But your comments/ideas/suggestions are more than welcomed.
 I can gather them and forward them back to Victor.

 Best,
 JP

  --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Can We Trust Computer Algebra Systems?

[Francesco Biscani]

On 24 October 2014 05:30, kcrisman kcris...@gmail.com wrote:


It was an interesting read. The article (at potential risk of starting
 a firestorm) does seem to suggest that open-source software like Sage is
 more trustworthy for computational proofs as one can (in principle) verify
 the code's logic and can look at the list of known bugs.



 In principle.  But naturally we have a bug tracker for a reason.  Also, I
 didn't have time to look at the article they referenced about some
 experience with open source; perhaps someone could summarize it.


The fact that it is possible to do it in principle is the important bit,
not if actually people do so. When I am writing a paper I don't necessarily
go and check each and every previous result on which the paper is built,
but it is essential to be able to do so if desired or needed.

Likewise, it's not really important (from the point of view of this
discussion anyway) if Sage or another open-source software is more or less
trustworthy in practice than a closed-source system. The important bit is
that one can go and check. Trust and blind faith are two different things.

I find it quite depressing how publications relying on (or describing)
black boxes are routinely accepted and I wish the research community were
intellectually honest about this issue.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Question about Arbitrary Precision Logarithms And Number of Correct Digits

[Francesco Biscani]

I ran exactly into this some time ago while sanity-checking some
high-precision MPFR computations with the results of Wolfram Alpha (which
also wraps real literals into its own, I presume exact, representation).

On 3 October 2014 11:42, Volker Braun vbraun.n...@gmail.com wrote:

 Real literals are wrapped in their own type on the Sage command line, they
 are not hardware-floats (like in plain Python):

 sage: 0.001
 0.00100
 sage: type(_)
 type 'sage.rings.real_mpfr.RealLiteral'


I am curious, why the extra zeroes in that representation in the second
line?

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Eric Raymond on open source and math

[Francesco Biscani]

Hi,

On 1 October 2014 17:59, Simon King simon.k...@uni-jena.de wrote:

 There are famous results obtained by computer-assisted proofs, such as
 Four Colour Theorem; but I don't know if a specific software was needed.


Yes I had read about it, that was one of the things I had in mind :)


 And there are of course explicit computations, in my case computations
 of modular cohomology rings of finite groups. Here, new methods were
 needed, and I found Sage a very good environment to implement these
 methods. It would have been near to impossible in Magma (unless I was a
 core developer).


This sounds similar to my experience in fields like dynamical astronomy and
theoretical physics. Lots of people using computer algebra to do explicit
computations, usually in Mathematica, Maple or some custom package.

Thanks for the other pointers as well.

Cheers,

  Francesco.




 --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Eric Raymond on open source and math

[Francesco Biscani]

On 1 October 2014 10:59, Nathann Cohen nathann.co...@gmail.com wrote:


 Twenty-four years later, the vast majority of the world’s pure mathematicians 
 do in fact use *Mathematica* in one way or another.


 The vast majority of world's pure mathematicians ?..

 Beware boy, you seem to reject on principle the idea that mathematica may
 not be the best math software around. Or that it could come to change, even
 if it were :-)


As a non-mathematician, I would be curious to know what (if any) big
results in pure mathematics can be ascribed directly to the use of
Mathematica or other mathematical software. I.e., results that would have
not happened (or would have not happened in a realistic time frame, in case
of computer-assisted proofs maybe?)  without a specific software.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Fwd: [GDML] [gdml] ICERM report and comments

[Francesco Biscani]

On 13 September 2014 11:00, Dr. David Kirkby (Kirkby Microwave Ltd) 
drkir...@kirkbymicrowave.co.uk wrote:

 5) I do agree with much of what is written about portability and the
 ***ing GNU compiler. People now write in GNU C, which is a
 constantly changing like the wind direction.

 I myself have tried to get bits of Sage working on obscure platforms,
 with non GNU compilers, as I think it does aid portability. Maybe my
 efforts achieved nothing beyond getting Sage working on Solaris,
 though I suspect they have made porting to other platforms somewhat
 easier.


I did not understand much the original point about GCC. My impression was
that he was complaining that it is difficult to get recent versions of GCC
and Clang *working* on older platforms.

But it's a fact that starting from version 4.x GCC has become more and more
strict about language standards (especially in C++ land), and that's a good
thing. Likewise, Clang is famous for being even stricter.

I agree with you though that the lack of portability is a problem. In my
opinion not so much for the GNU-isms, though, but rather for the smart
tricks that a lot of scientific code uses and which are technically
implementation-defined or undefined behaviour. Stuff like assuming certain
bit widths for the fundamental integral types, signed integer
representation and overflow behaviour, floating-point representations,
memory model (see tagged pointers), etc. etc. Writing standard-conforming
code can be mind-numbingly tedious but it ensures a high degree of
portability and reproducibility.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: compiling sage 6.3 on a raspberry pi

[Francesco Biscani]

What you want is called cross-compilation, and in general is a
non-trivial thing to do. You have to set up a toolchain on your x86 boxes
able to compile for ARM, use it to compile SAGE and finally move the binary
over to the Raspberry.

I mucked around with it on Gentoo a long time ago (I think it was for a
Nokia n800 I got off ebay, anyone remembers those things?)  and it seemed
not too difficult to do:

http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1chap=2

For Debian, the first google hit is:

http://jeremy-nicola.info/portfolio-item/cross-compilation-distributed-compilation-for-the-raspberry-pi/

which points to an official Raspberry PI cross-compile toolchain.

HTH,

  Francesco.

On 10 September 2014 14:35, simon.eigeldin...@vol.at wrote:

 Hi,

 thanks for the suggestion with the hard drive.
 i might try that one.
 how can i do the swap to disk thing?
 never have done that.

 btw i have more linux boxes but those are all 32 bit (x86) machines. so i
 don't know how to do a compilation for armv6l on those.


 maybe someone could tell me how this can be done?

 greetings and thanks,
 simon



 On Wed, 10 Sep 2014 05:19:07 -0700 (PDT)
  mmarco mma...@unizar.es wrote:

 It is theoretically possible, but you would need swap memory (the RAM of
 the device is not enough), which would be very slow (i don'trecommend doing
 it using the SD card as swap device, too much read/write for it), so go for
 a USB hard drive. And even then, it will be quite slow (the USB port is
 much slower than a standard IDE/ATA connection for hard drives).

 Don't be surprised if the time needed to finish the compilation is
 measured in days, or even weeks.

 A better idea would be to run the compilation in another device.

 El miércoles, 10 de septiembre de 2014 13:40:14 UTC+2, simon.ei...@vol.at
 escribió:



 Hi folks,
 I thought i might ask this question on this list as well. I once thought
 of compiling Sage 5.13 for the raspberry pi but as far as i can tell it was
 not so easy at that time a few months ago.
 Now we have Sage 6.3 so i wonder if this got any easier?
 I am running Raspbian (Debian 7 Wheezy) on a older Raspberry Pi Model B
 Rev 2 with 256 MB of RAM. The system is up to date.

 There is a 5.13 package for armv6 but this one is pretty outdated now so
 i thought of compiling a package myself.
 Do i have to consider anything?
 Or can i use the instructions for the normal debian/ubuntu boxes?

 Maybe someone has some step by step instructions if something is
 different?
 greetings and thanks very much, Simon


 --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


 --
 Simon Eigeldinger
 simon.eigeldin...@vol.at


 --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: compiling sage 6.3 on a raspberry pi

[Francesco Biscani]

That's too bad. How about using distcc from the PI to leverage the
cross-compiler on the x86 machines though?

On 12 September 2014 11:57, Jean-Pierre Flori jpfl...@gmail.com wrote:



 On Friday, September 12, 2014 11:15:19 AM UTC+2, bluescarni wrote:

 What you want is called cross-compilation, and in general is a
 non-trivial thing to do. You have to set up a toolchain on your x86 boxes
 able to compile for ARM, use it to compile SAGE and finally move the binary
 over to the Raspberry.

 Sure cross compilation would be much nicer and faster.
 But I don't feel Sage is anything next to be able to be croos compiled.

 --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [sage-release] You don't really think that Sage has failed, do you? (a comment about it)

[Francesco Biscani]

I don't have any direct experience with EU funding, but I did work at a
European-level institution (ESA) for a few years and I must say that what
Bill says rings true to my ears. You have to understand that anything
European is really undertaken by a patchwork of different nations pulling
towards different directions and often competing with each other. ESA for
instance has a policy of geographic return that regulates many aspects of
the activity of the agency, from hiring to funding:

http://www.esa.int/About_Us/Industry/Industry_how_to_do_business/Industrial_policy_and_geographical_distribution

Any type of interaction with non-European entities is very complicated, to
the point, e.g., of requiring special permission from upper management to
hire unpaid interns from outside Europe. Going to conferences outside
Europe is very difficult. When we started SOCIS some years ago,

http://sophia.estec.esa.int/socis/

I remember going through numerous meetings in which we had to came up with
a way to make the project European, whereas our first impulse was to just
let it open to any student in the world. In the end we found a compromise
in the requirement that any participating student needs to be enrolled in a
European University.

I have no difficulties believing the EU operates under similar constraints.


On 29 August 2014 19:03, Bill Hart goodwillh...@googlemail.com wrote:

 To be fair, in context, you were talking about nationalism and objecting
 to me apparently characterising Sage as a US project. The *mathematical*
 diversity of the contributors is completely tangential to that argument.

 I think I made my argument transparent enough. You aren't going to help
 European mathematical software projects, such as the ones listed, by
 applying for money to work directly on Sage. Referees will see through it
 immediately if you try to make that claim.

 To my knowledge, the European Union funding agencies did not have a
 significant stake in the origin and development of Sage, but the NSF and
 other US institutions did. From the point of view of the European Union, as
 far as I can tell, Sage is a US originating project. As such, you aren't
 going to have a chance of convincing them that development of Sage is
 funding a European software project!

 On the other hand, a European software project, which is focused on
 cooperation (at the technical and professional level) of existing European
 mathematical software projects, *whether or not* making use of Sage, can be
 sold to referees and stakeholders. Then, as was pointed out by someone
 else, you make the case that Sage is an *international collaboration*, not
 a US project. At that level, Sage is not a US project.

 But any European project must really and substantially benefit European
 software projects and the primary impact should be to the European economy!

 My very first sentence was Nicolas, I wish you the best with a European
 grant based on Sage. Indeed, I hope a large scale European software
 project based on Sage is successful. But it needs to directly address the
 issue of how it helps mathematical software developed here in Europe. I
 hope it is also clear from those words that I was fully anticipating that
 Nicolas did have have in mind something of great benefit to those of us in
 Europe working on libraries and software projects used by Sage!

 It's difficult to come up with an example that makes the European
 situation clear, since for example Magma has received substantial funding
 from the US, precisely because it benefits US stakeholders. That in spite
 of the fact that most of its IP belongs to USyd. However, the argument
 would be similar if I applied for money from the EU to develop Magma on
 account of it having a numerous developers in Europe and that it uses
 European developed software libraries. Obviously the primary beneficiaries
 in such an arrangement would be Australian taxpayers and certainly not
 those European software projects! Referees just aren't going to go for that.

 That doesn't mean that Magma can't be part of the overall strategy of such
 a grant, as I'm sure is the case for a number of projects funded from
 within the EU currently. But it can't be the focus of such a grant.

 Anyway, we've drifted way off topic. I merely wanted to encourage Nicolas,
 to mention some of the things that I personally think might be factors in
 such a proposal being successful in Europe, and to vaguely bring his
 attention to other similar efforts, without getting deeply involved myself
 (I'm just a lowly postdoc and have no say in these matters).

 I'm sorry I wasn't clearer in the first instance. I hope I'm being clear
 now.

 Bill.

 On Friday, 29 August 2014 17:10:53 UTC+2, Volker Braun wrote:

 On Friday, August 29, 2014 1:03:06 PM UTC+1, Bill Hart wrote:

 What sets Sage apart from GAP/Singular (and, I dare say: Flint) is the
 scale and the diversity of its contributors.


 No, what sets it apart is the number of contributors. 

Re: [sage-devel] reddit'ers at it again discussing sage...

[Francesco Biscani]

There is again this point cropping up in the comments:

But Sage's mission is to be a viable alternative to Mathematica

This is being discussed tangentially in another sage-devel thread, but I
think it's something to be considered carefully. There is a difference
between saying it is ok for Sage to develop in a direction which makes it
a viable replacement for Matlab, Maple and Mathematica and Sage's mission
statement is to be a viable alternative to MMMs. I think it creates false
expectations and ultimately disillusion in potential users.

My impression as a lurker on the mailing list is that Sage is heavily
oriented towards the needs of the math research community and that not much
effort is being put into other areas of scientific computing that might be
of interest to physicists and engineers (which are heavy users of MMM). My
impression is that the Scipy-Numpy-Sympy ecosystem is a better fit than
Sage, at least for numerical purposes.

All of this is of course all fine and dandy, but I think it should be
stated more precisely (if that is really the case and not just my
impression :).

Cheers,

  Francesco.


On 27 August 2014 14:06, William A Stein wst...@uw.edu wrote:


 http://www.reddit.com/r/math/comments/2eo9ku/sage_open_source_mathematics_software_you_dont/

 --
 William Stein
 Professor of Mathematics
 University of Washington
 http://wstein.org
 wst...@uw.edu

 --
 You received this message because you are subscribed to the Google Groups
 sage-devel group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sage-devel+unsubscr...@googlegroups.com.
 To post to this group, send email to sage-devel@googlegroups.com.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] reddit'ers at it again discussing sage...

[Francesco Biscani]

On 27 August 2014 22:29, Volker Braun vbraun.n...@gmail.com wrote:

 홶푟℮햺픱 ℹퟃℯ핒!


 On Wednesday, August 27, 2014 8:43:30 PM UTC+1, maldun wrote:

 With Ibus you can simply type every UTF-8 Character with ease like: ∞, Σ,
 ∫ｆ(α)ｄα using the well known latex commands =D
 今晩は皆さ


My browser was actually capable of rendering all that... What a time to be
alive!

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: How practical/useful would a native windows subset be?

[Francesco Biscani]

On 25 August 2014 12:27, Jean-Pierre Flori jpfl...@gmail.com wrote:

 PARI/GP is definitely not native.
 It is Cygwin or MinGW.


MinGW and Cygwin are two completely different things. I don't know what you
mean with native, but MinGW is as native on Windows as, e.g., the Intel
compiler is.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: How practical/useful would a native windows subset be?

[Francesco Biscani]

On 25 August 2014 15:04, Dima Pasechnik dimp...@gmail.com wrote:

 cause M$ is unwilling to release specifications of kernel
 calls needed to make a good modern implementation of fork().

 It is a constant fight against a fundamentally shaky fork()
 as implemented in Cygwin :-(


Is the fork() implementation in SUA shaky as well?

http://stackoverflow.com/questions/4243880/substitute-for-forking-in-windows
http://www.microsoft.com/en-us/download/details.aspx?id=2391

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: How practical/useful would a native windows subset be?

[Francesco Biscani]

On 25 August 2014 16:28, Dima Pasechnik dimp...@gmail.com wrote:

 apparently it's better, but it's only supported on certain more
 expensive versions of Windows 7 and Windows Server 2008.

 to quote:

 Supported Operating Systems: Windows Server 2008 R2; Windows 7 Enterprise;
 Windows 7 Enterprise 64-bit edition; Windows 7 Ultimate; Windows 7 Ultimate
 64-bit edition;


Ah bummer... I wonder if the version check is strict or if it can be worked
around somehow. Seems like at some point Debian had an Interix port:

http://www.debian-interix.net/

(As a side question, what versions of Windows are commonly found on
desktops/laptops these days? Are people switching over to Windows 8?)

There's quite a bit of material on how to write a replacement of fork()
using the Windows API. See, e.g.,

http://stackoverflow.com/questions/985281/what-is-the-closest-thing-windows-has-to-fork/985525#985525
http://doxygen.scilab.org/5.3/d0/d8f/forkWindows_8c_source.html#l00216

And it seems MinGW has the prototype for fork(), although not the
implementation:

http://stackoverflow.com/questions/9612315/why-does-my-compiler-not-accept-fork-despite-my-inclusion-of-unistd-h

Even if the implementation is not 100% conforming, it would probably be
adequate for some purposes. Is the lack of fork() the biggest showstopper
or just one of many roadblocks? I would imagine a lot of external
components included in sage are not written with platform independence in
mind (but IMO this would rather be an argument to work with upstream to
rectify the issue instead of working around it).

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] On scientific computing, Python and Julia

[Francesco Biscani]

Hello Stefan,

thanks for the explanations, this all looks really interesting to me.

On 19 July 2014 22:10, Stefan Karpinski ste...@karpinski.org wrote:

 This can be pretty straightforwardly handled with multiple dispatch
 promotion in a parametric type system. Similar things are done in real code
 regularly in Julia. Although I'm not going to try to define these
 particular types, the polynomial, power series, and finite field example is
 quite possible given appropriate type definitions – people have done similar
 things http://acooke.org/cute/FiniteFiel1.html. An example that already
 works and is similar in spirit, is figuring out that a Complex{BigInt} plus
 a Vector{Rational{Int}} should be a Vector{Complex{Rational{BigInt}}}. This
 falls out of a surprisingly small set of generic function methods and
 promotion rules (which are just methods):

 julia big(3)^100*im + [1, 1//2, 2]
 3-element Array{Complex{Rational{BigInt}},1}:
  1//1+515377520732011331036461129765621272702107522001//1*im
  1//2+515377520732011331036461129765621272702107522001//1*im
  2//1+515377520732011331036461129765621272702107522001//1*im


It's funny because I have been thinking about this for quite a long time
from a modern C++ perspective, and I had come to the conclusion that with
constructs like std::enable_if you can get to these results with template
metaprogramming in C++11. The tricky bit is to write arithmetic operators
that are generic but do not swallow up every type. In this specific case,
you would have the Vector's operator+ kick in instead of the Complex's one
(somewhere the Vector's operator+ should be defined to have a higher rank
than the operator+ of Complex), then you would need to deduce the common
type from Complex{BigInt} + Complex{Rational{...}} (possibly via
decltype()), and proceed to a recursion down in the type hierarchy. Of
course as you point out you would need all the ancillary functions to
actually perform the conversions from one type to the other.

All this would entail quite a bit of template trickery, but I find it
interesting that it could be implemented all at compile time.

(I have a primitive prototype version of something like this implemented in
a project of mine, hopefully eventually I will get around to do it properly
:)

Anyway, cheers for the interesting discussion.

  Francesco.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] new talk: The Development of Symbolic Calculus in Sage

[Francesco Biscani]

On Sat, Jul 17, 2010 at 11:03 AM, Thierry Dumont
tdum...@math.univ-lyon1.fr wrote:
 2) For the ODEs, the best and the most *modern* methods are there:
 http://www.unige.ch/~hairer/software.html
 H. Hairer, G. Wanner, C. Lubich are among the best specialist of numerical
 methods for ODE and their programs (even if written in f77) are wonderful,
 and very robust and efficient. Writing an interface may not be a so large
 task (there is already a Matlab interface) and we would have the best for
 stiff systems, Hamiltonian systems (make celestial mechanics with Sage) and
 so on... This would be in the spirit of Sage, I think: use the best software
 available, written by true specialists.

Nice pointer, did not know about that page :)

Another interesting approach for ODE that I did not see mentioned is
that of Taylor integrators, e.g.:

http://www.maia.ub.es/~angel/taylor/

It should not bee to hard to wrap in Python using Weave and
translating symbolic expressions into the text format used by the
integrator.

Cheers,

  Francesco.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] SAGE talk @ ESA?

[Francesco Biscani]

Hello list,

I just noticed on the website that the next SAGE days will be held in
Leiden. I'm currently working as a research fellow at the European
Space Agency establishment ESTEC in Noordwijk (~10 km from Leiden). I
was wondering if there is any interest in giving a presentation about
SAGE to my research team:

http://www.esa.int/gsp/ACT/index.htm

Every Friday we organise short informal talks (~30 min) on
scientific/technical topics, the audience being composed mostly by
members of the team and research fellows/engineers/young graduate
trainees from other departments. The background of the audience is
prevalently rooted in engineering, with a minority of physicists and
virtually no mathematicians (at least that I know of). So I can
imagine a lot of questions of the viability of SAGE as a Matlab
replacement would be popping up :-)

I just checked the calendar and the Friday 9 talk slot is still
available. I think it would be very nice to have an introductory talk
about SAGE in order to expose my team fellows to it, and to highlight
the existence of alternatives to the tools they are currently using. I
think it would be also interesting and instructive to have a glimpse
of the open development process taking place in SAGE - open
source/governance being methodologies we are trying to push and
promote within the agency.

Cheers,

  Francesco.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Multivariate polynomial multiplication over Z

[Francesco Biscani]

Hi Bill,

On Fri, May 14, 2010 at 3:28 PM, Bill Hart goodwillh...@googlemail.com wrote:
 If I make a couple of simplifications, namely assume that the output
 fits into two limbs, and that none of the polynomials has length 
 2^32 - 1, etc, I get pretty good times, certainly better than reported
 in Francesco's paper. I also don't know if any assumptions about the
 coefficients being unsigned are made in any of the benchmarks. That
 would further reduce the times, etc.

Just for the record, in the paper the only integer coefficients I
consider in the benchmarks are plain out-of-the-box GMP mpz types
(well, the C++ interface to them to be precise :). So I imagine that
such coefficients will incur in a lot of overhead, from heap
allocation to function calling overhead, suboptimal cache usage from
random memory accesses etc.

For my own purposes, right now I'm mostly interested in
double-precision floating point real and complex coefficients, but I
do intend to perform benchmarks/optimisation on fixed-width
multi-precision integers in the future.

Cheers,

  Francesco.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Multivariate polynomial multiplication over Z

[Francesco Biscani]

Hi Bill,

in my own experience Kronecker substitution can be effective in a
number of situations. It would also automatically handle the case you
mention about working only on a subset of variables (i.e., the ones
involved in the multiplication).

I have the description of my implementation and some benchmarks here:

http://arxiv.org/abs/1004.4548

The paper is still missing a discussion on the impact of
coding/decoding times, the implementation of the highly sparse data
structure has changed a bit recently and has better performance than
those described in the paper.

Cheers,

 Francesco.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Support Vector Machine

[Francesco Biscani]

Hi Sergey,

On Sun, May 9, 2010 at 10:15 AM, Sergey Bochkanov
sergey.bochka...@alglib.net wrote:
 Hello, Francesco.

 I  know  about expression templates, but even with templates sometimes
 creation  of temporary is the only way to calculate value of a complex
 expression  like  x  =  ((a+b)*(c+d)-e)/(f+3). Am I wrong?

 ALGLIB is full of code like this.

If the expression is to be intended like this:

for i in (0,size):
  x[i] =((a[i] + b[i]) * (c[i] + d[i]) - e[i]) / (f[i] + 3)

(i.e., element-wise), then I'm pretty confident expression templates
could eliminate all temporaries.

Cheers,

  Francesco.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Support Vector Machine

[Francesco Biscani]

Hi Sergey,

On Sun, May 9, 2010 at 7:32 PM, Sergey Bochkanov
sergey.bochka...@alglib.net wrote:
 I  am talking about non-vectorized form of the expression. And I can't
 imagine  how  (a+b)*(c+d) can be calculated without temporaries :) Can
 you give an example?

My bad, for some strange reason I had assumed we were talking about
overhead resulting from temporary vectors/matrices, not from the
underlying numerical primitives :) Sorry for the noise...

Cheers,

  Francesco

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Support Vector Machine

[Francesco Biscani]

Hi Sergey,

On Sat, May 8, 2010 at 10:13 PM, Sergey Bochkanov
sergey.bochka...@alglib.net wrote:
 (3)  -  OOP  overhead.  Multiple  precision ALGLIB makes use of OOP to
 implement  multiple  precision  expressions  like x=y+z. However, it
 leads  to  excessive creation of temporaries, so I will replace OOP by
 something  less  human-readable  but  more efficient. It is relatively
 easy  to do because I use automatic translation to generate MP ALGLIB,
 so I just have to make slight changes in the translator.

Just FYI, you might want to look into C++ expression templates - they
might allow you to retain the convenient notation with no overhead.
This library has some nice examples of the convenience of expression
templates:

http://eigen.tuxfamily.org/index.php?title=Main_Page

Cheers,

  Francesco.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] MPIR and GMP: an announcement

[Francesco Biscani]

Erm, April 1st?

 Francesco.

On Thu, Apr 1, 2010 at 4:48 PM, Robert Miller r...@rlmiller.org wrote:
 MPIR Team wrote:
 We'd like the community to comment on this proposal. An announcement
 of our first v3+ version of MPIR will be forthcoming in a few days.

 David Kirkby wrote:
 This stikes me as admitting the GMP developers are correct in their
 claims, which you should not do if they are incorrect.

 This just obviates the need to defend against such claims. And now
 anything released in current or future versions of GMP is fair game
 :).

 Personally, I don't see how accusations of using open source code in
 other open source code can be taken seriously in the first place. The
 only thing which does make me seriously think about it is the fact
 that I want to be sure that people will follow the GPL/LGPL license to
 the letter, whatever the subtle requirements might be. With MPIR
 licensed under v3+, it will be possible to use more code than before,
 resulting in better quality, more sharing, and hopefully, less
 bickering in the future.



 --
 Robert L. Miller
 http://www.rlmiller.org/

 --
 To post to this group, send an email to sage-devel@googlegroups.com
 To unsubscribe from this group, send an email to 
 sage-devel+unsubscr...@googlegroups.com
 For more options, visit this group at 
 http://groups.google.com/group/sage-devel
 URL: http://www.sagemath.org

 To unsubscribe, reply using remove me as the subject.


-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: MPIR and GMP: an announcement

[Francesco Biscani]

I'm having a hard time understanding whether this thread is flooding
with sarcasm or is completely devoid of it.

;)

Francesco.

On Thu, Apr 1, 2010 at 6:21 PM, Jaap Spies j.sp...@hccnet.nl wrote:
 Tom Boothby wrote:

 On Thu, Apr 1, 2010 at 7:58 AM, Francesco Biscanibluesca...@gmail.com
  wrote:

 Erm, April 1st?

 An Australian, playing a prank?  I shouldn't think they'd know how.
 They're such a serious bunch.  I've hardly even seen Bill crack a
 smile, let alone laugh!


 You clearly didn't met him at dinner with a glass of good Australian wine.

 Jaap


 --
 To post to this group, send an email to sage-devel@googlegroups.com
 To unsubscribe from this group, send an email to
 sage-devel+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/sage-devel
 URL: http://www.sagemath.org

 To unsubscribe, reply using remove me as the subject.


-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] What is padus / pardus?

[Francesco Biscani]

I suppose it refers to this:

http://en.wikipedia.org/wiki/Pardus_%28operating_system%29

Cheers,

  Francesco

On Mon, Jan 25, 2010 at 1:20 PM, John Cremona john.crem...@gmail.com wrote:
 Looking in the SPKG.txt file for eclib (eclib-20080310.p8) I see the
 following block:

 == Distribution ==

 === Padus ===

  * Contact: Ismail Dönmez
  * EMail: ism...@pardus.org.tr
  * Website: N/A

 Does anyone have any idea what that is about?  Is one of padus/pardus
 a typo?  the URL pardus.org.tr does exist but is all written in
 Turkish, and I have no idea at all what it has to do with eclib.

 As I am about to update the spkg, I could delete this.  I will unless
 someone can give em a reason why not.  At the same time I guess I
 could remove Michael Abshoff for the list of maintainers.  Likewise
 Ralph Philip Weinmann -- does anyone know what happened to him?

 John

 --
 To post to this group, send an email to sage-devel@googlegroups.com
 To unsubscribe from this group, send an email to 
 sage-devel+unsubscr...@googlegroups.com
 For more options, visit this group at 
 http://groups.google.com/group/sage-devel
 URL: http://www.sagemath.org


-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] [OT] GMP 5.0.0

[francesco biscani]

Hi all,

looks like GMP 5.0.0 has been released:

http://gmplib.org/gmp5.0.html

Cheers,

  Francesco.
-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Mathematical Software and Me: A Very Personal Recollection

[francesco biscani]

Very inspiring, thanks for sharing.

  Francesco.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Does Sage need a Fortran compiler?

[francesco biscani]

On Wed, Sep 30, 2009 at 8:16 AM, Dr. David Kirkby
david.kir...@onetel.net wrote:

 Does there need to be a Fortran compiler on the system to build Sage, or
  is the fortran-20071120.p9 package a fortran compiler able to build Sage?

 The reason I ask is that if there is no need for a Fortran compiler, it
 is quite possible the standard C/C++ compiler shipped with Solaris
 (3.4.3) could build Sage. It would appear that whatever code in
 ratpoints is requiring a 4.0.1 or later compiler is not compiled on
 Solaris.

 There is an issue with PolyBoRi, but I suspect with a minor change to
 the code that could be worked around.

Just out of curiosity, what is the reason behind Solaris shipping with
such an ancient compiler? I mean, GCC 3.4.3 was released short of 5
years ago, it is not maintained anymore by the original developers (I
think), it has no Fortran  77 support, poor compliance to C++
standard, etc.

 F.

--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: CUDA and Sage

[Francesco Biscani]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Michael,

mabshoff wrote:
| Various people have started looking into this, but so far no one has
| produced code. One big issue (at least for me) with pycuda is the
| requirement for boost, but I am not sure how that could be overcome.
| [...]
| The main issue with boost I see is that PolyBoRi ships with a subset
| of boost and installs it into $SAGE_LOCAL/include/boost. I assume that
| it will not be enough of boost, i.e. boost python is not part of it.
| Since PolyBoRi also has an interface to Python using boost Python we
| might be able to add the bits needed to the polybori.spkg, otherwise I
| see potentially huge trouble by colliding boost versions in the tree.
| And shipping boost itself is not really an option due to its rather
| large size.

If the Boost headers are all that is needed (in many cases they are,
since most Boost libraries are header-only), it may be worth to ship
them together with Sage. I just checked and the complete Boost headers
amount to a compressed tarbz2ball of 2.9 MB, so packing them in Sage
should not be a big deal.

With the non-header-only Boost libraries (such as Boost.Python), a
possible approach could be that of modifying the build system of a
package that uses them to compile and link the needed Boost libraries
together with the package's own library. I.e., add the Boost libraries'
.cpp files directly in the project's Makefile.

Another possibility (especially if the use of Boost is widespread among
Sage packages) would be to compile shared library versions of the needed
Boost libraries when building Sage and use them when building the
packages that need them.

Just a couple of thoughts :)

Best regards,

~  Francesco.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiFltUACgkQFCtI0YdDCEs8DACdG93ZTG4wpyPxXMJMyl5bJqU7
zh0AnRfhIZ+wF+AOOpUVMp/6s8Qi2N6S
=T7jJ
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: New Sage website

[Francesco Biscani]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi William,

William Stein wrote:
| That said I really *really* want a full native version of Sage on
Windows...

I've been wondering about this for a while. Are you referring
specifically to MSVC support or it gets compiled natively under
windows (i.e., MinGW or Intel...)? In other words, are you going
specifically for Microsoft's compilers' support and, if so, what is the
reason behind this decision?

Best regards,

~  Francesco.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhEYfwACgkQFCtI0YdDCEvJ8gCgu8SrT3nC9ERy6mhQ6cFJ60te
kaUAoMMAL3QpVMlziT4xe5G5jLX5D/ik
=8n3c
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: New Sage website

[Francesco Biscani]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Michael,

mabshoff wrote:
| For 32 bits we are fixing the Cygwin issues and one goal for Dev1
| [starting in a little less than two weeks] is to get that port up and
| working again. MinGW's support for Python is allegedly problematic, at
| least during the 2.4 release of python. I have not tried Python
| 2.5+MinGW.  Right now Windows Python 2.5 is build per default with
| MSVC 2005 in 32 as well as 64 bit mode. It works perfect with Cygwin
| in 32 bit mode, but there are some problems related to DLL address
| space which are solvable. Python 2.6 as well as 3.0 will switch to
| MSVC 2008 as default compiler.
|
| For 64 bit Windows the compilers by Microsoft [C/C++] and Intel
| [Fortran] are the only technical viable option today. On the 64 bit
| MinGW front things are changing, but I don't expect that compiler to
| work well this year and we want to be done with the port this year,
| hopefully by the fall. Once MinGW catches up we are more than happy to
| support that compiler assuming we don't run into any showstoppers that
| we cannot fix.
|
| For the Intel compilers: I am planning to add support for at least
| Linux/Itanium, so the Intel compiler on Linux ought to work at some
| point. The Intel compiler on Windows behaves differently than the
| Linux version since the Linux version is supposed to be gcc compatible
| while the Windows version is supposed to be a drop in replacement for
| MSVC.  So once we have MSVC working I will surely see how far I get
| with the Intel compiler on Windows, too.
|
| In the we are willing to support any reasonable compiler, i.e. I am
| adding Sun Forte support on Solaris at the moment, and obviously
| welcome fixes from other platforms assuming they don't break the
| other  builds.

Thanks for the info. I had no idea about the status of 64-bit MinGW, so
I understand better your desire to support MSVC.

A couple of technical questions:

1) how do you cope with mixed C/C++ - Fortran builds under Windows,
given that, AFAIK, it is generally not possible to mix these languages
using different compilers (and that Microsoft does not provide a Fortran
compiler)?

2) more generally, I think that such an effort must undergo tight
coordination with upstream. Given that AFAICT most open-source
mathematical software is developed on the GCC toolchain, how do you cope
with upstream projects using compiler/standard library features present
only in GCC? I'm thinking mainly about stuff like assembly support, but
also modern C++ standard library features. What do you do if, let's say,
Singular starts using TR1's features implemented in GCC but not in MSVC?
(in such case the solution could be using Boost's TR1 wrapper, but this
requires notable interaction and coordination with the Singular devs)

Thanks and best regards,

~  Francesco.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhEa2AACgkQFCtI0YdDCEuPrACeNBqnPZS0a0KAw0xsRGSDbHxk
P2sAn2yzALjWeMQjdHeTgNvXYPS/7Yza
=rap4
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: New GMP for SAGE

[Francesco Biscani]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Bill,

may I ask what your take on language bindings for mpir is? I think it
would be important to be able to use it from C++, Python, Ruby, etc. I
would certainly be glad to help in such an effort.

Best regards,

~  Francesco.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgl55MACgkQFCtI0YdDCEvWvACfZEeDB1rPXi+JAp/YeNh/nqft
P+kAn3mF8/gi/pFvpdWHSRWWu8Jwzwr0
=s078
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Giac/Xcas? (was Re: multivariate factoring - use maxima ?)

[Francesco Biscani]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

parisse wrote:
| (c)  Create some sort of C/C++ library interface.  This is very
| very difficult.
|
|
| I had some hope that swig could help do the bridge between the C++
| giac library and python, but I never tried.

If your code is heavy on templates, I suggest to try out
Boost.Python[1]. You just need a decent C++ compiler to use it (no
external tools), I use it for my project and it is really a blessing. As
far as I can tell, performance is indistinguishable from C++.

Best regards,

~ Francesco.

[1] http://www.boost.org/doc/libs/release/libs/python/doc/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgDLs0ACgkQFCtI0YdDCEs0kACgv2MtXfUOCNG+Eme0K6fscozk
l10AnRvyCut47zTvS+YLebw/j6C3xQkp
=1uWd
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Describing Sage as a Mathematics Computing Environment

[Francesco Biscani]

On Sunday 30 December 2007, Jaap Spies wrote:
 As an alternative:

 Generic Mathematics Computing System,
 [...]
 Eventualy Generic Mathematics Computing Software?
 Or Generic Mathematics Computing Environment?

 Jaap

Personally I liked the comprehensive someone mentioned, hence my suggestion 
would be: Comprehensive Computing System.

 Francesco.





signature.asc
Description: This is a digitally signed message part.

[sage-devel] Interest in a Poisson series manipulator?

[Francesco Biscani]

Hi all,

I've been working on an algebraic manipulator dedicated to Celestial 
Mechanics, and, in particular, Poisson and Fourier series. It is written in 
C++, and it comes with a set of bindings for Python written using 
Boost.Python.

I was wondering if in the SAGE community there is some interest around such a 
tool. The (new) website is located here:

http://piranha.tuxfamily.org/index.php5?title=Main_Page

Some information is still on the old website:

http://code.google.com/p/piranha-psm/

(sorry, I'm in the middle of a hosting migration). I also try to keep a blog:

http://piranha-psm.blogspot.com/

There is not much info yet on the website, so if someone is interested they'd 
just better ask me directly :)

Best regards to everybody,

  Francesco Biscani.


signature.asc
Description: This is a digitally signed message part.

[sage-devel] Re: Interest in a Poisson series manipulator?

[Francesco Biscani]

On Friday 14 December 2007, mhampton wrote:
 I am interested - I have done some work in celestial mechanics,
 although not using poisson and fourier series.  Since I don't have a
 lot of expertise, I'm not sure I can be much help, but I thought I
 would at least make a gesture of support :)

 I think it would be nice, on the wiki page, if you showed an example
 calculation in which Piranha was used.  That would help me understand
 its scope better.

 Cheers,
 Marshall Hampton
 University of Minnesota, Duluth

Hi Marshall,

first of all let me thank you for your reply. You are right, the wiki badly 
needs more input, and I'll try to update it soon. At the moment I'm quite 
busy coding and completing my thesis, which you can find as a work in 
progress under this git tree:

http://git.tuxfamily.org/?p=gitroot/piranha/doc.git;a=summary

In the thesis, if you are interested, you can find more in-depth discussion 
about Poisson series and Piranha. In the rest of this mail I'll try, as 
tersely as possible, to explain briefly the deal with Poisson series and 
Piranha.

Poisson series are, simply put, multi-variate Fourier series in which the 
coefficients are multi-variate polynomials. In classical Celestial Mechanics, 
the subset of Poisson series in which the coefficients are purely numerical 
are sometimes called simply Fourier series.

Such objects arise in perturbative methods in Celestial Mechanics. The 
expansion of the perturbing gravitational potential, for instance, naturally 
leads to Poisson series. Briefly put, the Poisson series form is convenient 
because it allows to determine the spectrum of the perturbation and hence 
apply the known methods of solution for the motion of systems of 
self-gravitating celestial bodies (Solar System, planetary systems, etc.).

In Celestial Mechanics research one typically has to deal with Poisson series 
in which the number of terms goes from few tens to millions, and hence 
specialized manipulators are needed. Performance is of primary concern, as 
optimal memory utilization is. The operations needed to be performed on 
Poisson sereis are typically simple conceptually: addition/subtraction, 
multiplication, square root, differentiation, etc.

Piranha is a manipulation framework: this means that it defines rules and 
provides ready-to-use routines to build your own manipulator with little 
effort. This is done through extensive use of the so-called modern C++ 
programming style - template (meta)programming and extensive use of 
Object-Oriented facilities (e.g., inheritance, operator-overloading, etc.). 
Performance is never sacrificed though, since runtime Object-Oriented 
programming style (e.g., dynamic polymorphism) is avoided in favour of 
a static (i.e., compile time) style which makes use of template-related 
design patterns (like the Curiously Recurring Template Pattern).

As a result, Piranha compares favourably performance-wise with 
well-established manipulators in the field, like the closed-source TRIP, 

http://www.imcce.fr/Equipes/ASD/trip/trip.php

but at the same time retaining a clean and well-structured architecture that 
allows for easy extensions and improvements. On of the problems of Poisson 
series manipulators is in fact that they are often either too much 
specialized or difficult to extend (when the source code is available at 
all). As far as I know, Piranha is the first OO Poisson series manipulator.

Piranha at the moments provides 4 manipulators, of which 3 are Fourier series 
manipulator and the other one is a Poisson series manipulator (at the moment 
it is broken because it is being re-worked). Code re-use between these 
manipulators is very high thanks to Piranha's architecture. SLOCs are around 
12,000.

Piranha internally uses data structures like binary search trees and 
hash-tables, and make also extensive use of the Boost C++ library:

http://www.boost.org

It also contains an implementation of a technique for the multiplication of 
Poisson series and sparse multivariate polynomials which, as _far_ as I know, 
seems original and I've called coded arithmetics, which seems to give 
pretty good performance.

The set of Python bindings for Piranha is called Pyranha (heh), and aims to 
expose all the functionality of the underlying C++ classes 
(the manipulators) in Python. Pyranha has some graphics capabilities in the 
form of matplotlib interaction for series plotting and a embryo GUI in PyQt.

I think it is enough for now, I hope I was not too boring ;) Surely I left 
something out but... please ask me if you want to know more.

Thanks again,

  Francesco.


signature.asc
Description: This is a digitally signed message part.