[sage-devel] [ANN] Flint 2.9 Released

['Bill Hart' via sage-devel]

Hi all,

It is with pleasure that we release Flint version 2.9.

This is the final release where William Hart will be release manager.
Fredrik Johansson will take over as Maintainer of Flint from now on.
We will also transition to his repository as the official Flint
repository in the coming weeks.

Here are the main additions for this release.

* Add fmpz_mod_poly_div function
* Add _flint_get_memory function
* Add Eulerian polynomials
* Support "multivariate" polynomials with zero variables
* Improve Stirling numbers of both kinds
* Speed up numerous fmpz functions for small inputs
* Improve Bell numbers
* Speedups to nmod arithmetic
* Improve nmod_mat LU decomposition
* Fully separate nmod module from nmod_vec
* Speed up Hermite polynomials
* Add n-th derivative for Z[x] and Q[x]
* Improve fq_default module (nmod is now used where optimal)
* Add sqrt functions for numerous polynomial/series modules and finite fields
* Add FFT matrix multiplication
* Improve CI
* Improve LLL for general use
* Add matrix-vector products over Q
* Add can_solve function for fmpq_mat, handling non-square/singular matrices
* Document fmpz_mod_vec module
* Fix and document qadic_sqrt function
* Add parallel programming helpers
* Innumerable additional bug fixes and speedups

Note that we have also made the following change which will affect
existing code:

* Change the order of arguments in the fmpz_divisor_sigma function

The main contributors to this release were:

* Dan Schultz
* Fredrik Johansson
* Albin Ahlback
* William Hart

We would also like to thank the many other contributors to this
release, including:

David Einstein, Julian Ruth, Andreas Enge, Matthias Koeppe, math-gout,
Gonzalo Tornaria, Erico Nogueira Rolim, Dima Pasechnik, Tommy Hofmann,
Isuru Fernando and numerous others who contributed patches, testing,
bug reports and other assistance.

Best Wishes,

Flint Development Team

-- 
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/CAB0xFnsiLL8cT7MUY_XSdgib1s2%3DfpFGXkKZO8vTOx%3DXD49Wzw%40mail.gmail.com.

[sage-devel] [ANN] Flint-2.9.0 release candidate 2

['Bill Hart' via sage-devel]

Hi all,

I have just tagged release candidate 2 of Flint version 2.9, see [1].

This release candidate makes changes to the Flint build system
(internally only; from the user's perspective it still operates the
same way) so we would be pleased to receive reports of any new build
failures.

In particular it should build more easily with MinGW64 now.

There are also numerous critical bugs fixed in this release candidate
(these are new bugs for 2.9 and did not exist in a released version of
Flint).

I am hopeful that this will be the final release candidate and that
Flint will now be released on Friday next week.

Bill.

[1] https://github.com/wbhart/flint2/releases/tag/2.9.0-rc2

-- 
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/CAB0xFnvOprMKt-paLwjjDEUujXYU7pq_FM4%3DQydy4zgBBXF7_A%40mail.gmail.com.

[sage-devel] [ANN] Flint-2.9.0 release candidate 1

['Bill Hart' via sage-devel]

Hi all,

I have just tagged release candidate 1 of Flint version 2.9, see [1].

If there are no issues reported this means Flint-2.9.0 will be
released in one week from today. We reset the timer if additional
fixes and release candidates are required.

Fredrik Johansson will be giving a talk on Flint at a Global SageDays
in about 7 hours (9pm CET) where he will be discussing what is in
Flint-2.9 and the future of Flint. It is also a good overview talk for
people who aren't familiar with what Flint does or want to catch up
with recent developments.

All interested people should register for this event at the link [2].

Bill.

[1] https://github.com/wbhart/flint2/releases/tag/2.9.0-rc1
[2] https://researchseminars.org/talk/SageDays112358/12/

-- 
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/CAB0xFnvDJ%2Bd2Msncu7zVyhhrTu%3D%3DRD4y8kg66GK-ndXWCKuVQQ%40mail.gmail.com.

[sage-devel] [ANN] Flint 2.9 beta release (testing required)

['Bill Hart' via sage-devel]

Hi all,

We have finalised the new flint-2.9 release up to the point of beta
testing [1], and so now we value your help testing as usual. There are
many new features, speedups and bugfixes which you can find in the
NEWS file.

There are some changes internal to the build system and there are some
changes that make this version not 100% compatible with previous
releases, including:

* reordering the elements in some structs, e.g. fmpq_poly (making it
binary incompatible)
* reordering the arguments to fmpz_divisor_sigma (which will require
changes to code using this function)
* previously deprecated function macros have been removed entirely

Therefore we recommend testing to check for any issues.

Once build reports start coming in and new issues seem to settle down
we'll issue the first release candidate and start working towards the
final release.

Tarballs for 2.9.0-beta1 can be downloaded from GitHub [1].

The trunk branch has now been designated 2.10 provisionally so work
can continue there whilst bugfixes can be backported to the new
flint-2.9 branch as usual. The beta release is tagged as 2.9.0-beta1
within the flint-2.9 branch.

Best Wishes,

Bill.

[1] https://github.com/wbhart/flint2/releases/tag/2.9.0-beta1

-- 
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/CAB0xFnti0oMGWZr3Fo08vkSvUxmbiV3%2BLvDnWhY_o5RzYywgzA%40mail.gmail.com.

[sage-devel] Flint 2.8.4 Released

['Bill Hart' via sage-devel]

Hi all,

I just tagged Flint-2.8.4. This is a critical bug fix release and so
we strongly recommend upgrading.

 * Fix a serious bug in fmpz_mod_poly_xgcd for polynomials of large length
 * Fix an assertion failure in fmpz_mat_solve_fflu (only relevant if
asserts enabled)
 * Fix some bugs on 32 bit machines
 * Work around a compiler bug on Apple M1
 * Fix bug in nmod_mpoly_factor (returned 0 for some factorisations)
 * Fix some documentation build errors and some doc formatting issues

Please note that the C++ wrapper is now considered unmaintained. We
will keep it compiling in its current state, but will not be wrapping
additional flint functions.

If any C++ developers would like to take over maintenance, we estimate
it would be about 3-4 months of effort full time to wrap the remaining
flint functions in C++ for a VERY experienced C++ developer. Replacing
the old metaprogramming wrapper with a new one using more modern C++
features would be about 4-6 months full time work for an experienced
C++ developer.

If you would like to volunteer, but not be paid for your effort,
please let us know [1].

Bill.

[1] Application forms are available at Flint Headquarters, Abandoned
House, Pfälzerwald.

-- 
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/CAB0xFnuZxOvO5EYwF03MeK4q-gTs91rb-VPEKxqwjpeUc%2BAknw%40mail.gmail.com.

[sage-devel] Flint-2.8.3 released (serious bug fixed)

['Bill Hart' via sage-devel]

Hello all,

I have tagged flint-2.8.3 which fixes a very serious bug in:

* fmpq_poly_xgcd
* fmpz_poly_xgcd
* nmod_poly_xgcd

which has been there for many years and which occurs for polynomials
of length at least 340.

The bug would result in incorrect results being returned. It was
caused by an overrun in a step that was not needed in a certain case
in the final iteration of a loop.

The website will be updated shortly, however we currently recommend
obtaining tarballs from GitHub [1], not our website, due to an
apparent bug in the web server which causes it to serve the wrong
tarball (with the correct name).

Bill.

[1] https://github.com/wbhart/flint2/tags

-- 
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/CAB0xFnuk7mFbfN_izCOcO%2Ba1mwns37TOHWiaOMEG6XvABQNbVA%40mail.gmail.com.

Re: [sage-devel] Re: Flint 2.8.2 Released

['Bill Hart' via sage-devel]

No, the problem is with the tarballs on the Flint website, NOT the
ones on GitHub.

On Fri, 15 Oct 2021 at 14:39, Dima Pasechnik  wrote:
>
>
>
> On Fri, 15 Oct 2021, 13:19 'Bill Hart' via sage-devel, 
>  wrote:
>>
>> Hi all,
>>
>> I have just tagged and release Flint-2.8.2.
>>
>> This fixes an issue with the --disable-dependency-tracking option on
>> some distributions. The tarballs being served by the website seem to
>> be incorrect (reason unknown).
>
>
> is this the not uncommon github issue that their auto-generated tarballs/zips 
> are not stable?
>
> You can upload a tarball to a github release (they call these "binary assets" 
> iirc)
>
>
>
>> In the meantime I encourage downloading
>> tarballs from GitHub [1]. I recommend redownloading if you obtained
>> your last tarball from the website.
>>
>> Best Wishes,
>>
>> Bill.
>>
>> [1] https://github.com/wbhart/flint2/tags
>>
>> --
>> 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/CAB0xFnuSe0dxKuJRX5p1KMoV3TA5e5RAtEj8NcJc6VpXL%3DVrWQ%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "nemo-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to nemo-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit 
> https://groups.google.com/d/msgid/nemo-devel/CAAWYfq2FQGxM0r2%3Dd%2BTx2EFEGnAMuCoCw0GqYFMgQQQpoSJo_A%40mail.gmail.com.

-- 
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/CAB0xFnu1u1tXQewobCQNAHxCz1QgpBKL9kmOnbpGGep%3DYR09mA%40mail.gmail.com.

[sage-devel] Re: Flint 2.8.2 Released

['Bill Hart' via sage-devel]

Hi all,

I have just tagged and release Flint-2.8.2.

This fixes an issue with the --disable-dependency-tracking option on
some distributions. The tarballs being served by the website seem to
be incorrect (reason unknown). In the meantime I encourage downloading
tarballs from GitHub [1]. I recommend redownloading if you obtained
your last tarball from the website.

Best Wishes,

Bill.

[1] https://github.com/wbhart/flint2/tags

-- 
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/CAB0xFnuSe0dxKuJRX5p1KMoV3TA5e5RAtEj8NcJc6VpXL%3DVrWQ%40mail.gmail.com.

[sage-devel] Flint 2.8.1 Released

['Bill Hart' via sage-devel]

Hi all,

I have just tagged and release Flint-2.8.1.

This fixes numerous bugs in the Flint-2.8 series and allows one to
disable gcc dependency tracking when building, using the new
--disable-dependency-tracking option.

Best Wishes,

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAB0xFnvW1zF0z5sfs%3DxxR_La6gQeJbdLwQmWOB5473Q7hw7i%2BA%40mail.gmail.com.

[sage-devel] Flint-2.8.0 Released!

['Bill Hart' via sage-devel]

Hi all,

It is with pleasure that we announce the release of Flint 2.8.0 which
can be downloaded from our website [1] under Downloads or from our
GitHub [2] under tags.

All bugs should be reported on GitHub issues.

Flint has now reached around 600k lines of code!

The main changes in this release are:

 * New fq_default module which combines existing finite fields
 * Speedups for linear algebra when using BLAS and/or threading
 * New series expansions with coefficients in QQ
 * Faster CRT
 * New fmpz_mod_mpoly module
 * Polynomial factoring improvements over ZZ
 * Fixed bugs in gmpcompat on Windows
 * Add fmpz_mat_can_solve_fflu and fmpz_mat_can_solve
 * Cleanup of the nmod_poly and nmod_poly_factor code
 * Implement nmod_mat_det_howell
 * Add fmpz_mod_poly_divides, fmpz_divides, n_divides, nmod_poly_divides
 * Interface for multiplying matrices by vectors and arrays
 * Nearest Euclidean division
 * Subresultant GCD interface
 * XGCD over ZZ with canonical Bezout coefficients
 * Add fmpz_mpoly resultant and discriminant
 * Add deprecations list
 * Add FLINT_SGN macro
 * Speedups for series computations
 * Switch to GitHub Actions for CI
 * Improve Taylor shift
 * Numerous bug fixes and speedups

Contributors to this release include:

* William Hart
* Dan Schultz
* Fredrik Johansson
* Albin Ahlback
* Michael Orlitzky
* Tethys Svensson
* Edgar Costa
* Jan Jancar

Numerous others contributed bug reports.

Deprecations in 2.8:

* fmpz_multi_crt_t => fmpz_multi_CRT_t
* fmpz_multi_crt_init => fmpz_multi_CRT_init
* fmpz_multi_crt_precompute => fmpz_multi_CRT_precompute
* fmpz_multi_crt_precompute_p gone
* fmpz_multi_crt_precomp => fmpz_multi_CRT_precomp now with sign option
* fmpz_multi_crt_precomp_p gone
* fmpz_multi_crt => fmpz_multi_CRT now with sign option
* fmpz_multi_crt_clear => fmpz_multi_CRT_clear

See deprecations.txt in the repository for a list of all past deprecations.

Best Wishes,

The Flint Development Team.

[1] https://www.flintlib.org/
[2] https://github.com/wbhart/flint2

-- 
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/CAB0xFnu-z7DwK7YWkFaOh-iRhz_NjhzBGzs2hzEyGUrHAkrPeA%40mail.gmail.com.

[sage-devel] Re: Flint-2.8.0 Beta testing

['Bill Hart' via sage-devel]

Hi all,

I've now tagged 2.8.0-rc1, our first release candidate for the
flint-2.8 branch. Development on trunk now continues for the next
release.

Please report all remaining issue to our GitHub issue tracker. We will
issue release candidates until there are no further critical issues
reported for 3 working days in a row.

Bill.

On Fri, 9 Jul 2021 at 23:36, Bill Hart  wrote:
>
> Hi all,
>
> After a successful Flint-2.8.0-dev release a few months back, we have
> decided to enter beta testing of Flint-2.8.0.
>
> I have therefore tagged flint-2.8.0-beta1 on GitHub. Please report
> issues to our issue tracker:
>
> https://github.com/wbhart/flint2/issues
>
> It is expected that release candidates will start being issued next
> week, once any issues with the beta release are resolved and some
> final polishing is done.
>
> Best Wishes,
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAB0xFnuGAPH3i5%3D0FDNQf%2BP90V5P%3DsFLUKS_ZTytv-v%2B0x%3D_hQ%40mail.gmail.com.

[sage-devel] Flint-2.8.0 Beta testing

['Bill Hart' via sage-devel]

Hi all,

After a successful Flint-2.8.0-dev release a few months back, we have
decided to enter beta testing of Flint-2.8.0.

I have therefore tagged flint-2.8.0-beta1 on GitHub. Please report
issues to our issue tracker:

https://github.com/wbhart/flint2/issues

It is expected that release candidates will start being issued next
week, once any issues with the beta release are resolved and some
final polishing is done.

Best Wishes,

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAB0xFnsbmy4s9fjZ8DbJdg7iJV-70mJ37O7sRgDr-dunEjVmdg%40mail.gmail.com.

[sage-devel] Flint 2.7.1 released

['Bill Hart' via sage-devel]

Hi all,

I have just released flint-2.7.1. This fixes a number of (serious)
bugs and build issues with the recent flint-2.7.0.

A list of changes can be found in our NEWS file [1].

Please report any bugs to our GitHub issue tracker.

Best Wishes,

Bill.

[1] https://github.com/wbhart/flint2/blob/trunk/NEWS

-- 
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/CAB0xFnv6XgZc85ZT52iypB4O3iJj1jM%2B3cX5xxy-oSEd0kDbyA%40mail.gmail.com.

[sage-devel] Flint 2.7.0 Released!

['Bill Hart' via sage-devel]

Hi all,

It is with pleasure that we release Flint 2.7.0. available at our
GitHub [1] and Website [2]. Documentation is available at [3]. Brian
Gladman also maintains MSVC solution files at [4].

New Improvements
===

The main improvements in this release are:

 * Multivariate factorisation
 * Square root and square testing for finite fields
 * Square root and square testing for multivariates
 * Zassenhaus factoring speedups (incl. degree pruning)
 * Fast factorisation of cubic univariate polynomials
 * Add context objects to fmpz_mod_poly functions
 * Use BLAS for matrix multiplication over Z/nZ (small n)
 * Linear solving for non-square/singular matrices (can_solve)
 * Speed up factorisation over Z/nZ (for multiprecision n)

Deprecations
==

The following are deprecated from the previous release:

n_gcd_full -> n_gcd
fmpz_poly_is_x -> fmpz_poly_is_gen
fmpz_mod_poly_is_x -> fmpz_mod_poly_is_gen
fmpq_poly_is_x -> fmpq_poly_is_gen

They will be removed shortly.

In addition, the following function has been deprecated

nmod_mat_scalar_mul_add (please use nmod_mat_scalar_addmul_ui instead).

Backwards incompatible changes
==

As promised, we have introduced a context object for the fmpz_mod_poly
module. All functions in this module now take an additional context
object.

Note that the fmpz_mod_mat module will get a similar update in the
not-too-distant future!

Contributors
==

The main contributors to this release were:

* Daniel Schultz
* William Hart

Additional contributions were made by:

Matthias Koeppe, Vincent Delecroix, Tommy Hofmann, Debian User, Max
Horn, Isuru Fernando, Fredrik Johansson, Jan Engelhardt, Ivan Tsybulin
and Mahrud Sayrafi.

Once again thanks to all the very many contributors to the Flint project!

The Flint Development Team

[1] https://github.com/wbhart/flint2/releases/tag/v2.7.0
[2] https://flintlib.org/
[3] https://flintlib.org/doc
[4] https://github.com/BrianGladman/flint

-- 
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/CAB0xFnuLaZN3wx%2BGVvJOFP-2yjK6CRsggetyw4JKeQVxFq2mtA%40mail.gmail.com.

[sage-devel] Re: Flint 2.7.0 release candidate 1

['Bill Hart' via sage-devel]

Hi all,

I have now tagged flint-2.7-rc2. There are some minor fixes and in
particular some CMake issues fixed in this RC. It is not expected that
there will be a further RC and the final release will be made some
time on Friday if no more serious issues are reported.

Bill.

On Thu, 10 Dec 2020 at 09:24, Bill Hart  wrote:
>
> I forgot to mention that there is a big change to the fmpz_mod_poly
> module. We have finally made the long promised change to using a
> context object.
>
> Hopefully nobody was using this module other than projects I have been
> directly involved in, as the module was in quite a bit of disarray and
> pretty unreliable. It's somewhat improved now after focusing on it for
> two release cycles, though still has some cleaning up to be done,
> which we hope won't result in major changes to the interface. I'll say
> more on this when we do the final release.
>
> But for now, if you have code written against this interface, you now
> need to add context objects to every call.
>
> Bill.
>
>
> On Wed, 9 Dec 2020 at 21:34, Bill Hart  wrote:
> >
> > Hi all,
> >
> > We are planning to do a Flint release this week or early next week and
> > so I have tagged flint-2.7.0-rc1.
> >
> > The main big change in this release is multivariate factorisation by
> > Dan Schultz. However a full changelog and list of authors will be made
> > available in the next rc (if there is one) or in the final release.
> >
> > All bugs should be reported on our GitHub issue tracker:
> >
> > https://github.com/wbhart/flint2/issues
> >
> > Note that the function nmod_mat_scalar_mul_add has been deprecated and
> > replaced with nmod_mat_scalar_addmul.
> >
> > 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAB0xFnueyPA%2BdZLqrg_2b2msZPDf_2_DdG0rgZeoftVg%3DPgy_A%40mail.gmail.com.

[sage-devel] Re: Flint 2.7.0 release candidate 1

['Bill Hart' via sage-devel]

I forgot to mention that there is a big change to the fmpz_mod_poly
module. We have finally made the long promised change to using a
context object.

Hopefully nobody was using this module other than projects I have been
directly involved in, as the module was in quite a bit of disarray and
pretty unreliable. It's somewhat improved now after focusing on it for
two release cycles, though still has some cleaning up to be done,
which we hope won't result in major changes to the interface. I'll say
more on this when we do the final release.

But for now, if you have code written against this interface, you now
need to add context objects to every call.

Bill.


On Wed, 9 Dec 2020 at 21:34, Bill Hart  wrote:
>
> Hi all,
>
> We are planning to do a Flint release this week or early next week and
> so I have tagged flint-2.7.0-rc1.
>
> The main big change in this release is multivariate factorisation by
> Dan Schultz. However a full changelog and list of authors will be made
> available in the next rc (if there is one) or in the final release.
>
> All bugs should be reported on our GitHub issue tracker:
>
> https://github.com/wbhart/flint2/issues
>
> Note that the function nmod_mat_scalar_mul_add has been deprecated and
> replaced with nmod_mat_scalar_addmul.
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAB0xFnvXUHR02edYW9sJ7p_Vx-m0Bsy5y3HxnA%2BoE47LNe1i4g%40mail.gmail.com.

[sage-devel] Flint 2.7.0 release candidate 1

['Bill Hart' via sage-devel]

Hi all,

We are planning to do a Flint release this week or early next week and
so I have tagged flint-2.7.0-rc1.

The main big change in this release is multivariate factorisation by
Dan Schultz. However a full changelog and list of authors will be made
available in the next rc (if there is one) or in the final release.

All bugs should be reported on our GitHub issue tracker:

https://github.com/wbhart/flint2/issues

Note that the function nmod_mat_scalar_mul_add has been deprecated and
replaced with nmod_mat_scalar_addmul.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAB0xFntKqNC%3DovSeWE2FsEMS8%2BCE14G%2BN29bfT__Raxi08d1Qw%40mail.gmail.com.

[sage-devel] [ANN] Flint 2.6.3 released

['Bill Hart' via sage-devel]

Hi all,

Flint v2.6.3 has been released. This fixes some issues, including a
critical issue with the generator of a finite field in char 2.

Best Wishes,

Bill Hart.

[1] http://flintlib.org/
[2] https://github.com/wbhart/flint2

-- 
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/CAB0xFnurXAVZR_NZn5TZZeXM_%2B10Qg%3D6rzuhMf1gXW3hLnR7mA%40mail.gmail.com.

[sage-devel] [ANN] Flint 2.6.2 released

['Bill Hart' via sage-devel]

Hello all,

We have just released Flint-2.6.2. This combines numerous fixes for
various platforms (included in version 2.6.1, which we didn't announce
due to more bugs surfacing) along with all remaining critical issues
that we are aware of.

The release can be downloaded from our website [1] or is tagged on our
github repository [2].

The next major release of Flint will be Flint-2.7, hopefully out later
this year.

Many thanks to Julien Puydt for reporting and assisting with numerous
issues detected by the Debian build infrastructure.

Best Wishes,

The Flint Development Team.

[1] http://flintlib.org/downloads.html
[2] https://github.com/wbhart/flint2

-- 
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/CAB0xFnsGEYav-4kce%2BwkLsnJ1qnTdsA-su%2B%2B%3DokcS0%3DrpcZ%2BtA%40mail.gmail.com.

[sage-devel] Flint 2.6.0 Released!

['Bill Hart' via sage-devel]

Hi all,

It is with pleasure that we announce the release of Flint-2.6.0. This
is the first update of Flint in five years and probably the largest
release ever!

Flint is now almost 500,000 lines of code.

It is available for download from our website in the download section
[1]. Flint documentation is now available online in our new Sphinx
documentation [2].

Flint now supports (native) Windows, Linux, OSX, FreeBSD and OpenBSD.

For MSVC solution files please access Brian Gladman's port [3].

Please note the following deprecations for this release. The functions
have been renamed and the original symbols will be removed in a later
release.

n_gcd_full -> n_gcd
fmpz_poly_is_x -> fmpz_poly_is_gen
fmpz_mod_poly_is_x -> fmpz_mod_poly_is_gen
fmpq_poly_is_x -> fmpq_poly_is_gen

New Features
===

Here are the main new features:

  * multivariate polynomials over most standard rings (sparse distributed)
  * APR-CL primality proving
  * elliptic curve integer factoring
  * minpoly and charpoly
  * improved quadratic sieve for integer factoring
  * embeddings of finite fields
  * pollard rho integer factoring
  * p+1 integer factoring
  * best of breed smooth integer factoring routine
  * best of breed general integer factoring routine
  * howell and strong echelon form
  * large speedups for solve and hence inverse over Z and Q
  * randprime and nextprime functions
  * pernet-stein HNF improvements
  * moller-granlund precomputed inverses
  * resultant_modular_div
  * fibonacci polynomials
  * exception mechanism/flint_abort
  * sqrt of series and polynomials
  * division of series over Z
  * power sums
  * improved base cases of various power series functions
  * ability to switch memory allocators
  * fast recurrence for Hermite polys
  * shifted Legendre polynomials
  * Laguerre polynomials
  * Gegenbauer polys
  * sphinx documentation
  * van hoeij with gradual feeding implementation of polynomial factoring over Z
  * perfect power detection
  * divisibility testing for polynomials
  * fast block based memory manager for bundling fmpz allocations
  * uniform random generation
  * CMake build system
  * linear algebra speedups when everything can be kept in longs
  * nmod module for integers mod (small) n
  * fmpz_mod_mat module for matrices over integers mod multiprecision n
  * kronecker product (tensor product)
  * random primitive polys (for finite fields)
  * thread pool implementation
  * threading of FFT for integer and polynomial multiplication over Z
  * threading of quadratic sieve for integer factoring
  * improved threading of factoring of polynomials mod p
  * threading for multivariate polynomial multiplication, division and GCD
  * threaded multiplication of matrices mod p
  * Berlekamp-Massey (nmod)
  * fmpz_mod module for integers mod multiprecision n
  * Pohlig-Hellman (discrete log)
  * farey_neighbours
  * remove openMP option
  * additional integer division variants
  * speed up mpn_mulmod_preinv
  * fft precaching
  * cyclotomic polynomial detection
  * polynomial root finding over finite fields
  * GMP 6.2 support
  * MPIR 3.0.0 support
  * many small speedups and additional convenience functions added

Contributors
==

This release would not have been possible without an extraordinary
number of contributions. Here are the main contributors to this
release:

* Daniel Schultz - multivariate polynomials, root finding, thread
pool, many speedups and bug fixes
* Fredrik Johansson - Speedup of inverse and solve, speedup of
basecases with small entries, Sphinx documentation, many other
improvements, maintenance and patch review
* William Hart - Maintainer, qsieve, ecm, threading, polynomial
factoring, minpoly, charpoly, fft precaching, speedup of inverse and
solve, many other improvements
* Vladimir Glazachev - APRCL
* Kushagra Singh - qsieve improvements, pollard rho
* Nitin Kumar - qsieve improvements
* Tommy Hofmann - matrix normal forms, bug fixes
* Dan Roche - randprime, nextprime, some work on minpoly
* Claus Fieker - flint_abort, qadics without Conway polynomials, bug fixes
* Alex Best - integer factor improvements, bug fixes
* Shrivin Srivastava - Fibonacci polynomials, speed up linear
composition, bug fixes
* Ralf Stephan - Hermite, Laguerre, Shifted Legendre, Gegenbauer polynomials
* Isuru Fernando - testing, build issues, bug fixes
* Vincent Delecroix - power sums, polynomial speedups, root counting
* Luca De Feo - Embeddings of finite fields
* Martin Raum - Kronecker product
* xoviat - CMake support
* Edouard Rousseau - Embeddings of finite fields
* David Einstein - documentation proofreading, CMake fixes
* Jerry James - memory leak fixes, array overrun fixes
* Brian Gladman - Windows MSVC support

We wish to give special thanks to two contributors, namely Daniel
Schultz and Isuru Fernando. Daniel because of the extraordinary amount
of outstanding new code contributed (well over 100,000 lines of code)
and Fernando for going above and beyond in helping track down curl

[sage-devel] Re: Flint 2.6.0-rc1

['Bill Hart' via sage-devel]

Dear all,

I've tagged Flint 2.6.0-rc4 [2]. The new changes are:

* fixes for C++ wrapper
* fix verbose mode for build/tests
* fix quiet mode CXX printing

Assuming there are no additional serious bugs found, the release will
become final this Friday 5th June.

Issue to be reported on our GitHub issue tracker [2].

Bill.

[1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc4
[2] https://github.com/wbhart/flint2/issues


On Fri, 29 May 2020 at 20:30, Bill Hart  wrote:
>
> Dear all,
>
> I've tagged Flint 2.6.0-rc3 [2]. The new changes are:
>
> * better support for old version of MSVC (fix some prototypes)
> * support for building Flint without pthreads (only useful for old platforms)
> * add const to some mpoly functions
>
> As these are not considered serious problems, the release is still
> scheduled for Monday.
>
> Bill.
>
> [1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc3
> [2] https://github.com/wbhart/flint2/issues
>
> On Thu, 28 May 2020 at 17:41, Bill Hart  wrote:
> >
> > Dear all,
> >
> > I have now tagged Flint 2.6.0-rc2 [2]. If no further major issues are
> > found the release will become final on Monday June 1st.
> >
> > Issues should be reported on our issue tracker[2]. Successful builds
> > can be reported here.
> >
> > Bill.
> >
> > [1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc2
> > [2] https://github.com/wbhart/flint2/issues
> >
> > On Tue, 26 May 2020 at 14:06, Bill Hart  wrote:
> > >
> > > Dear all,
> > >
> > > I have just tagged Flint 2.6.0-rc1 on GitHub [1], where tarballs are
> > > now available to download and try out.
> > >
> > > If there are no further bug reports by this Friday 29 May 2020 the
> > > final release of flint-2.6.0 will be made.
> > >
> > > Please report bugs on our GitHub issues and successful builds here.
> > >
> > > This is now a final opportunity for everyone, including end users, to
> > > report any issues before the final release (hopefully) on Friday.
> > >
> > > Note that Flint now has new online sphinx documentation [3].
> > >
> > > Contributors have been updated on our website [4], however we will
> > > acknowledge contributors to this release when the final release
> > > announcement is made on Friday and final release tarballs are put on
> > > the website.
> > >
> > > Please note that the soname will not be incremented for the final
> > > release. It has already been incremented for 2.6.0 in anticipation of
> > > the release.
> > >
> > > The only tasks that remain for the release are:
> > >
> > > * further updating of our website
> > > * Windows MSVC solution file documentation
> > > * release announcement
> > >
> > > Please note that the flint-2.5 branch in our repository is now
> > > defunct. All backporting from trunk will now occur on flint-2.6.
> > >
> > > Bill.
> > >
> > > [1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc1
> > > [2] https://github.com/wbhart/flint2/issues
> > > [3] http://flintlib.org/doc/
> > > [4] http://flintlib.org/authors.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAB0xFnuRCpX9LN%2B38r7bUkiP%2BVmLZ%2B8cdyKJmL%3D5-MAD3hqY%3DQ%40mail.gmail.com.

[sage-devel] Re: Flint 2.6.0-rc1

['Bill Hart' via sage-devel]

Dear all,

I've tagged Flint 2.6.0-rc3 [2]. The new changes are:

* better support for old version of MSVC (fix some prototypes)
* support for building Flint without pthreads (only useful for old platforms)
* add const to some mpoly functions

As these are not considered serious problems, the release is still
scheduled for Monday.

Bill.

[1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc3
[2] https://github.com/wbhart/flint2/issues

On Thu, 28 May 2020 at 17:41, Bill Hart  wrote:
>
> Dear all,
>
> I have now tagged Flint 2.6.0-rc2 [2]. If no further major issues are
> found the release will become final on Monday June 1st.
>
> Issues should be reported on our issue tracker[2]. Successful builds
> can be reported here.
>
> Bill.
>
> [1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc2
> [2] https://github.com/wbhart/flint2/issues
>
> On Tue, 26 May 2020 at 14:06, Bill Hart  wrote:
> >
> > Dear all,
> >
> > I have just tagged Flint 2.6.0-rc1 on GitHub [1], where tarballs are
> > now available to download and try out.
> >
> > If there are no further bug reports by this Friday 29 May 2020 the
> > final release of flint-2.6.0 will be made.
> >
> > Please report bugs on our GitHub issues and successful builds here.
> >
> > This is now a final opportunity for everyone, including end users, to
> > report any issues before the final release (hopefully) on Friday.
> >
> > Note that Flint now has new online sphinx documentation [3].
> >
> > Contributors have been updated on our website [4], however we will
> > acknowledge contributors to this release when the final release
> > announcement is made on Friday and final release tarballs are put on
> > the website.
> >
> > Please note that the soname will not be incremented for the final
> > release. It has already been incremented for 2.6.0 in anticipation of
> > the release.
> >
> > The only tasks that remain for the release are:
> >
> > * further updating of our website
> > * Windows MSVC solution file documentation
> > * release announcement
> >
> > Please note that the flint-2.5 branch in our repository is now
> > defunct. All backporting from trunk will now occur on flint-2.6.
> >
> > Bill.
> >
> > [1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc1
> > [2] https://github.com/wbhart/flint2/issues
> > [3] http://flintlib.org/doc/
> > [4] http://flintlib.org/authors.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAB0xFnvs%3Dz392FNwJkfV_e0Pg75bMZFwy%3DOvjFu3VpKDC58DVg%40mail.gmail.com.

[sage-devel] Re: Flint 2.6.0-rc1

['Bill Hart' via sage-devel]

Dear all,

I have now tagged Flint 2.6.0-rc2 [2]. If no further major issues are
found the release will become final on Monday June 1st.

Issues should be reported on our issue tracker[2]. Successful builds
can be reported here.

Bill.

[1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc2
[2] https://github.com/wbhart/flint2/issues

On Tue, 26 May 2020 at 14:06, Bill Hart  wrote:
>
> Dear all,
>
> I have just tagged Flint 2.6.0-rc1 on GitHub [1], where tarballs are
> now available to download and try out.
>
> If there are no further bug reports by this Friday 29 May 2020 the
> final release of flint-2.6.0 will be made.
>
> Please report bugs on our GitHub issues and successful builds here.
>
> This is now a final opportunity for everyone, including end users, to
> report any issues before the final release (hopefully) on Friday.
>
> Note that Flint now has new online sphinx documentation [3].
>
> Contributors have been updated on our website [4], however we will
> acknowledge contributors to this release when the final release
> announcement is made on Friday and final release tarballs are put on
> the website.
>
> Please note that the soname will not be incremented for the final
> release. It has already been incremented for 2.6.0 in anticipation of
> the release.
>
> The only tasks that remain for the release are:
>
> * further updating of our website
> * Windows MSVC solution file documentation
> * release announcement
>
> Please note that the flint-2.5 branch in our repository is now
> defunct. All backporting from trunk will now occur on flint-2.6.
>
> Bill.
>
> [1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc1
> [2] https://github.com/wbhart/flint2/issues
> [3] http://flintlib.org/doc/
> [4] http://flintlib.org/authors.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAB0xFnsG%3D0D4MmAgkHkpsthkFFe%3DTVzyuEKh00xonq-M3Gge7g%40mail.gmail.com.

[sage-devel] Flint 2.6.0-rc1

['Bill Hart' via sage-devel]

Dear all,

I have just tagged Flint 2.6.0-rc1 on GitHub [1], where tarballs are
now available to download and try out.

If there are no further bug reports by this Friday 29 May 2020 the
final release of flint-2.6.0 will be made.

Please report bugs on our GitHub issues and successful builds here.

This is now a final opportunity for everyone, including end users, to
report any issues before the final release (hopefully) on Friday.

Note that Flint now has new online sphinx documentation [3].

Contributors have been updated on our website [4], however we will
acknowledge contributors to this release when the final release
announcement is made on Friday and final release tarballs are put on
the website.

Please note that the soname will not be incremented for the final
release. It has already been incremented for 2.6.0 in anticipation of
the release.

The only tasks that remain for the release are:

* further updating of our website
* Windows MSVC solution file documentation
* release announcement

Please note that the flint-2.5 branch in our repository is now
defunct. All backporting from trunk will now occur on flint-2.6.

Bill.

[1] https://github.com/wbhart/flint2/releases/tag/2.6.0-rc1
[2] https://github.com/wbhart/flint2/issues
[3] http://flintlib.org/doc/
[4] http://flintlib.org/authors.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAB0xFns5AumRwRV0eUtv_iLZDPwiNO_zCP9O%3D8ZJ6u5ZJ4Px1Q%40mail.gmail.com.

Re: [sage-devel] Flint-2.6.0 alpha release (testing requested)

['Bill Hart' via sage-devel]

I will tag the first release candidate, as already mentioned. I don't like 
the repo being filled up with tags, so if we are going to use them I'll be 
keeping them to a minimum. Having tags permanently in there for something 
that served a purpose for one week only seems horrible to me.

Having said that, I should clean up more dead branches in my repo.

On Thursday, 21 May 2020 13:30:49 UTC+2, Julien Puydt wrote:
>
> Le jeudi 14 mai 2020 à 18:51 +0200, 'Bill Hart' via sage-devel a 
> écrit : 
>
> > The (latest) commit c6319d1d36248f2fc699e833ab2f6fa70d21e906 in the 
> > official Flint repository [1] is flint-2.6.0-alpha1. 
>
> You could tag it : that would be clearer. 
>
> Something like "git tag 2.6.0-alpha1" then "git push --tags" is enough. 
> That way the repository will document which tag is that alpha1, and 
> github will make tarballs automatically. 
>
> Cheers, 
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/bf7e3148-b32b-4019-b720-058ff3acb242%40googlegroups.com.

[sage-devel] Re: [mpir-devel] Re: Flint-2.6.0 alpha release (testing requested)

['Bill Hart' via sage-devel]

Thanks Dima!

On Thu, 21 May 2020 at 12:31, Dima Pasechnik  wrote:
>
> On Wed, May 20, 2020 at 5:40 PM 'Bill Hart' via mpir-devel
>  wrote:
> >
> > Hi again,
> >
> > Commit a960857c7d8e5ea7c4d4c2958e38ec52778d85d9  of the Flint
> > repository [1] is now flint-2.6.0-alpha2
> >
> > This is the last chance for developers working on related projects to
> > see if Flint works as expected for them, before we start asking end
> > users/distributions to start testing.
> >
> > We have made many modifications since alpha1, including:
> >
> > * removing all known memory leaks
> > * fixing a bug in the integer gcd (leak, inefficiency, very slim
> > chance of wrong answer)
> > * properly supporting GMP-6.2
> > * making matrices with zero rows/columns more robust
> > * many other less important fixes (35 commits total)
> > * fixing a bug/crash in the _f functions in the fmpz_mod_poly module
> >
>
> OK, so now it passes on everything I tried it on (most exotic:
> clang-8.0.1 on OpenBSD, with NTL enabled)
> Will now try to test it with Sage (https://trac.sagemath.org/ticket/29719)
>
>
> > We don't foresee the need for any further alpha releases, (assuming no
> > major issues are found). The next release will likely either be a beta
> > or release candidate. Please note the only important things that
> > remain to be done as far as we know are documentation/paperwork
> > related [2].
> >
> > Please report bugs on our GitHub issue tracker. Successful builds can
> > be reported here.
> >
> > Best Wishes,
> >
> > The Flint Development Team
> >
> > P.S. thanks to the Flint package maintainer in the Fedora project who
> > did early reporting/patching of many issues and to the numerous people
> > who gave feedback on the first alpha! Many more acknowledgements to
> > come in the release announcement!
> >
> > [1] https://github.com/wbhart/flint2
> > [2] https://github.com/wbhart/flint2/milestone/2
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "mpir-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to mpir-devel+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/mpir-devel/CAB0xFnsg%3DQM%2BMuPG6AppwMepQXOsF9qhzXNy-4cKu%3D%2BJZ75row%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mpir-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mpir-devel/CAAWYfq2niPvfTcBY7BaLDPxZagpX5ugqe2Q3VyZ20eiGVCYbEg%40mail.gmail.com.

-- 
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/CAB0xFntf06AcOmmw%3DfcDHznkdRwV1dH87mCJj1bhtEGSBeJNXA%40mail.gmail.com.

[sage-devel] Re: Flint-2.6.0 alpha release (testing requested)

['Bill Hart' via sage-devel]

Hi again,

Commit a960857c7d8e5ea7c4d4c2958e38ec52778d85d9  of the Flint
repository [1] is now flint-2.6.0-alpha2

This is the last chance for developers working on related projects to
see if Flint works as expected for them, before we start asking end
users/distributions to start testing.

We have made many modifications since alpha1, including:

* removing all known memory leaks
* fixing a bug in the integer gcd (leak, inefficiency, very slim
chance of wrong answer)
* properly supporting GMP-6.2
* making matrices with zero rows/columns more robust
* many other less important fixes (35 commits total)
* fixing a bug/crash in the _f functions in the fmpz_mod_poly module

We don't foresee the need for any further alpha releases, (assuming no
major issues are found). The next release will likely either be a beta
or release candidate. Please note the only important things that
remain to be done as far as we know are documentation/paperwork
related [2].

Please report bugs on our GitHub issue tracker. Successful builds can
be reported here.

Best Wishes,

The Flint Development Team

P.S. thanks to the Flint package maintainer in the Fedora project who
did early reporting/patching of many issues and to the numerous people
who gave feedback on the first alpha! Many more acknowledgements to
come in the release announcement!

[1] https://github.com/wbhart/flint2
[2] https://github.com/wbhart/flint2/milestone/2

-- 
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/CAB0xFnsg%3DQM%2BMuPG6AppwMepQXOsF9qhzXNy-4cKu%3D%2BJZ75row%40mail.gmail.com.

[sage-devel] Flint-2.6.0 alpha release (testing requested)

['Bill Hart' via sage-devel]

Hi all,

The (latest) commit c6319d1d36248f2fc699e833ab2f6fa70d21e906 in the
official Flint repository [1] is flint-2.6.0-alpha1.

This is an opportunity for early testing and feedback before our first
official beta which will be released about Wednesday next week.

Some release tasks have not yet been done [2] and will follow in the
next few days, but shouldn't affect very much.

However, we might slip in some more deprecations before the beta
cycle, though the old function names will continue to be available
until the next release. Please report if you find this is not the
case.

Please place bug reports in GitHub issues. Successful builds can be
reported here.

A full release announcement of all new contributors and features will
be made when the new release is finally issued.

Best Wishes,

The Flint Development Team.

[1] https://github.com/wbhart/flint2
[2] https://github.com/wbhart/flint2/milestone/2

P.S Here is how I configure and build Flint for my system:

./configure --prefix=/home/wbhart/usr/ --with-gmp=/home/wbhart/usr
--with-mpfr=/home/wbhart/usr/
make -j install
make -j check

-- 
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/CAB0xFntZOWPOu8hUdsMr4_p9wGc%2BoZmOZ_6ufR8QuOyy_%2BDFbw%40mail.gmail.com.

Re: [sage-devel] Re: Can Sage compute the Groebner basis of a module?

['Bill Hart' via sage-devel]

On Tuesday, 22 October 2019 23:23:44 UTC+2, Dima Pasechnik wrote:
>
> On Tue, Oct 22, 2019 at 9:51 PM 'Bill Hart' via sage-devel 
> > wrote: 
> > 
> > 
> > 
> > On Friday, 18 October 2019 15:21:05 UTC+2, Dima Pasechnik wrote: 
> >> 
> >> Hi, 
> >> well, Sage's functionality for modules over polynomial rings is quite 
> limited. 
> >> It assumes that a submodule of a free module is free. 
> > 
> > 
> > In what way does it assume this? There are limitations, but I'm not so 
> sure I would summarise them like this. 
>
> I am talking about Sage, not Singular. Singular's functionality to 
> work with modules over polynomial rings is not exposed in Sage at all. 
>
> In Sage every (sub)module comes with a basis. This works only for 
> modules over PIDs, if I recall 
> correctly. 
>

A submodule of a free module over a PID is free, of course.

But yes, Singular handles more general modules, at least over a polynomial 
ring. 

-- 
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/da53d12c-db47-4d1c-b1da-200e702286ca%40googlegroups.com.

Re: [sage-devel] Re: Can Sage compute the Groebner basis of a module?

['Bill Hart' via sage-devel]

On Tuesday, 22 October 2019 23:23:44 UTC+2, Dima Pasechnik wrote:
>
> On Tue, Oct 22, 2019 at 9:51 PM 'Bill Hart' via sage-devel 
> > wrote: 
> > 
> > 
> > 
> > On Friday, 18 October 2019 15:21:05 UTC+2, Dima Pasechnik wrote: 
> >> 
> >> Hi, 
> >> well, Sage's functionality for modules over polynomial rings is quite 
> limited. 
> >> It assumes that a submodule of a free module is free. 
> > 
> > 
> > In what way does it assume this? There are limitations, but I'm not so 
> sure I would summarise them like this. 
>
> I am talking about Sage, not Singular. Singular's functionality to 
> work with modules over polynomial rings is not exposed in Sage at all. 
>
> In Sage every (sub)module comes with a basis. This works only for 
> modules over PIDs, if I recall 
> correctly. 
>

A submodule of a free module over a PID is free, of course.

But yes, Singular handles more general modules, at least over a polynomial 
ring. 

-- 
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/9a7113b7-3a22-4b19-b36d-19ae9ec6f219%40googlegroups.com.

Re: [sage-devel] Re: Can Sage compute the Groebner basis of a module?

['Bill Hart' via sage-devel]

>From the Singular documentation [1]:

"Hence any finitely generated [image: $R$]-module can be represented in S
INGULAR by its module of relations."

[1] https://www.singular.uni-kl.de/Manual/4-0-3/sing_134.htm

On Tuesday, 22 October 2019 22:51:45 UTC+2, Bill Hart wrote:
>
>
>
> On Friday, 18 October 2019 15:21:05 UTC+2, Dima Pasechnik wrote:
>>
>> Hi, 
>> well, Sage's functionality for modules over polynomial rings is quite 
>> limited. 
>> It assumes that a submodule of a free module is free. 
>>
>
> In what way does it assume this? There are limitations, but I'm not so 
> sure I would summarise them like this.
>
> We discussed this at length at a recent Sage/Macaulay2 coding sprint at 
>> IMA, 
>> and concluded that it would be quite a bit of work to do. 
>>
>
> There is a major effort planned/underway to implement more sophisticated 
> modules (in fact as I understand it, J. Boehm already has a prototype/first 
> implementation in Singular itself, conducted under his supervision by a 
> student). 
>

-- 
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/aa28eab3-49da-402f-a35a-f141e19b40d2%40googlegroups.com.

Re: [sage-devel] Re: Can Sage compute the Groebner basis of a module?

['Bill Hart' via sage-devel]

On Friday, 18 October 2019 15:21:05 UTC+2, Dima Pasechnik wrote:
>
> Hi, 
> well, Sage's functionality for modules over polynomial rings is quite 
> limited. 
> It assumes that a submodule of a free module is free. 
>

In what way does it assume this? There are limitations, but I'm not so sure 
I would summarise them like this.

We discussed this at length at a recent Sage/Macaulay2 coding sprint at 
> IMA, 
> and concluded that it would be quite a bit of work to do. 
>

There is a major effort planned/underway to implement more sophisticated 
modules (in fact as I understand it, J. Boehm already has a prototype/first 
implementation in Singular itself, conducted under his supervision by a 
student). 

-- 
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/9fc49cba-a627-4f50-849f-a93dd37102c4%40googlegroups.com.

Re: [sage-devel] NTL 11.3.4

['Bill Hart' via sage-devel]

[OT] We recently bashed our way through (some version of) the NTL build 
script (for NTL 10.5.2 maybe??) to allow cross compilation from Linux to 
OSX, which is important for the Julia BinaryBuilder infrastructure.

If you are interested in those changes, we can send you the changes we made 
once we are done. Of course we have to rely on generic or x86 tuning, but 
that is not a problem for our application.

Apologies if I overlooked somewhere that this has been done already with a 
more recent version of NTL. I did find a very old post where this was 
discussed, but nothing more recent.

-- 
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/f49fbfca-5a06-4d6b-aad8-ec5c83ae3347%40googlegroups.com.

Re: [sage-devel] Re: issues (memory leak + slowness) with multivariate polynomials

['Bill Hart' via sage-devel]

Both Singular and libsingular.so use omalloc, which is some kind of bump 
allocator (currently being given multithreading support BTW). It's much 
faster than xmalloc for that application (libsingular and Singular use it 
for allocating the objects in the linked list implementations of sparse 
distributed polynomials which are required for fast polynomial x monomial 
arithmetic critical to GB's). But Dima is correct, libsingular also misses 
important optimisations in Singular proper, even aside from the modular 
issue.

On Monday, 17 June 2019 10:51:05 UTC+2, Dima Pasechnik wrote:
>
> On Mon, Jun 17, 2019 at 9:01 AM Simon King  > wrote: 
> > 
> > Hi! 
> > 
> > On 2019-06-16, Dima Pasechnik > wrote: 
> > > libsingular interface is a mess, cf e.g. 
> > > https://trac.sagemath.org/ticket/27508 
> > 
> > Singular uses a peculiar memory manager that is optimized for Gröbner 
> > basis computations. If that memory manager is replaced by ordinary 
> > malloc (which makes sense for debugging) then everything becomes a lot 
> > slower. Does libsingular use the same memory manager than Singular? 
>
> IMHO it does. IMHO the problem is that libsingular interface calls 
> low-level functions in libsingular 
> to do polynomial reductions etc, and it misses important optimisations 
> which are done in Singular proper. 
>
>
> > 
> > Best regards, 
> > 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-...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/qe7hcm%24mvj%241%40blaine.gmane.org.
>  
>
> > 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9f10526d-86aa-4473-9c54-d1ddf744761f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: issues (memory leak + slowness) with multivariate polynomials

['Bill Hart' via sage-devel]

I would guess that `libsingular' is the C++ kernel of Singular which does 
not implement all strategies for GB's over Q. There are additional 
strategies implemented both in Singular library code and in the Singular 
interpreter. Presumably the `singular' interface is using the interpreter, 
if not a Singular library, which makes use of more advanced strategies. In 
particular there is a library for a modular approach.

On Saturday, 15 June 2019 14:23:25 UTC+2, Markus Wageringel wrote:
>
> If I compute a Gröbner basis using libSingular, it is much slower than 
> using the Singular interface. Could this be related to the memory leaks or 
> is it a different issue?
>
> sage: I = sage.rings.ideal.Katsura(PolynomialRing(QQ, 'x', 9))
> sage: %time gb1 = I.groebner_basis(algorithm='singular')
> CPU times: user 1.34 s, sys: 47.5 ms, total: 1.38 s
> Wall time: 13 s
> sage: I = sage.rings.ideal.Katsura(PolynomialRing(QQ, 'x', 9))
> sage: %time gb2 = I.groebner_basis(algorithm='libsingular')
> CPU times: user 49.2 s, sys: 122 ms, total: 49.4 s
> Wall time: 49.4 s
> sage: gb1 == gb2
> True
>
> This defaults to the Singular function `groebner`, but choosing others 
> like `std` or `slimgb` gives similar timings.
>
> Over finite fields, the above issue does not seem to occur – the 
> libSingular computation is slightly faster than Singular, as expected. 
> However, there seems to be a different issue with the Singular interface: 
> repeating the same computation causes a significant slowdown. This does not 
> happen using libSingular.
>
> sage: I = sage.rings.ideal.Katsura(PolynomialRing(GF(2^31-1), 'x', 10))
> sage: %time gb1 = I.groebner_basis(algorithm='singular')
> CPU times: user 1.86 s, sys: 110 ms, total: 1.97 s
> Wall time: 18.4 s
> sage: I = sage.rings.ideal.Katsura(PolynomialRing(GF(2^31-1), 'x', 10))
> sage: %time gb2 = I.groebner_basis(algorithm='singular')
> CPU times: user 1.89 s, sys: 117 ms, total: 2 s
> Wall time: 1min 13s
> sage: gb1 == gb2
> True
>
> This was tested using Sage 8.7 on a MBP 8,1 with OS X 10.13.6. I observed 
> similar results on other machines as well.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b32474cf-ef6a-4163-b96d-b9140c549921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: A Sage interface for FGb (Gröbner bases)

['Bill Hart' via sage-devel]

On Saturday, 15 December 2018 22:22:09 UTC+1, parisse wrote:
>
>
>
> Le samedi 15 décembre 2018 20:57:02 UTC+1, Bill Hart a écrit :
>>
>>
>>
>> And even if giac did all that, it is one of many projects doing 
>> multivariate polynomial arithmetic in Europe. There's also Trip, Piranha, 
>> Factory, Pari/GP, Gap. I really don't think it is a valid argument that 
>> just because your CAS/library can do multivariate arithmetic that we should 
>> stop working on it!
>>
>>
>> I never said that. The point is that many people seems to ignore Giac. 
> This is how I interpret the thread subject here or the fact that I was 
> never contacted when the ODK project was launched. But perhaps it's better 
> to be ignored in the end, I'm free to implement whatever I want.
>

We were not contacted either. You can actually find the point where I heard 
about OpenDreamKit on sage-devel. I brought it to the attention of my 
bosses, and they contacted the project leader to get involved!

But anyway, I better understand what you are saying now. I thought I must 
have been misunderstanding something. 

-- 
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: A Sage interface for FGb (Gröbner bases)

['Bill Hart' via sage-devel]

On Saturday, 15 December 2018 18:19:53 UTC+1, parisse wrote:
>
> Bill, my feeling is that part of ODK money was used to improve 
> multivariate polynomial arithmetic implementations precisely in a domain 
> where Giac behaves well (and maybe I should emphasize that unlike almost 
> all other CAS, Giac is a library, i.e. is interoperable with any software 
> that can interact with a C++ library). Despite that, ODK ignores Giac.
>

I'm really puzzled by this. There is even overlap *within* ODK.

Our local site and another colleague of ours also contributed to parallel 
root clustering, a superoptimiser, a Jupyter interface, SIMD optimisation, 
a quadratic sieve and so on. I think Giac barely covers any of that. We 
aren't trying to do multivariate arithmetic; we are trying to improve and 
modernise the system that we have been developing for 30 years in the 
direction of HPC, and expose it to a VRE so that it can be a more useful 
tool in the "toolbox". Giac does not address that for us.

But even if we just focus on multivariate arithmetic (which we obviously 
need, just as you do), the new implementation we are working on seems to 
have different goals:

* lex, deglex, degrevlex (and soon, weighted) orderings in an arbitrary 
number of variables
* multiprecision exponents (to support new algorithms for sparse 
interpolation)
* near linear scaling of all major algorithms up to many cores with a 
highly optimised threaded memory manager
* fast specialised multivariate arithmetic and gcd over Z/pZ, Z and Q (and 
some initial work over finite fields and extensions insofar as it is 
necessary for the other)
* ideal reduction
* specialised cases for dense, quasi-sparse and sparse algorithms
* integration with Singular via Factory (the library of Singular that does 
multivariate arithmetic for applications other than GBs)
* exposure to a VRE
* clear, modularised code, documentation and tests

It's not clear to me how much of all that giac supports. And I am sure I've 
mentioned most of these goals, both publicly and privately. I apologise if 
I have not made this more clear in the past. It is certainly not our goal 
to just do what giac already does.

And even if giac did all that, it is one of many projects doing 
multivariate polynomial arithmetic in Europe. There's also Trip, Piranha, 
Factory, Pari/GP, Gap. I really don't think it is a valid argument that 
just because your CAS/library can do multivariate arithmetic that we should 
stop working on it!

Also, I don't believe we've ignored giac at all. I've sent dozens of emails 
to you personally. I've mentioned your work to many of my colleagues, and 
when we benchmark our stuff, I have benchmarked giac, and been in contact 
with you personally when we do. I vaguely recall inviting you for a visit 
once.

Surely, I am missing your point here. 

Well, I'm not sure it's the right place to discuss that, and anyway past is 
> the past.
> Now that I made the effort to fine tune my gbasis code, it behaves very 
> well on Q on multi-CPUs architectures. We'll see if there is more interest 
> or not.
>

Great. I will mention this to my colleagues next door, who are working on 
GB's. I am sure they will be very interested to hear about and compare the 
progress you have made.

-- 
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: A Sage interface for FGb (Gröbner bases)

['Bill Hart' via sage-devel]

On Saturday, 15 December 2018 17:10:10 UTC+1, Bill Hart wrote:
>
>
>
> On Sunday, 9 December 2018 11:22:48 UTC+1, Dima Pasechnik wrote:
>
> 
>
> I cannot comment on why certain implementations did not use Giac code, 
>> I am not involved in this work. 
>>
>
> I am involved in that, 
>

I should probably rather say, I was paid by ODK to write the original 
implementation of our code, but we now have a different person paid by ODK 
to (exceedingly capably) do that work. I now serve only an advisory role. 
Of course I maintain an active interest; my day-to-day job is something 
else entirely.

-- 
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: A Sage interface for FGb (Gröbner bases)

['Bill Hart' via sage-devel]

On Sunday, 9 December 2018 11:22:48 UTC+1, Dima Pasechnik wrote:



I cannot comment on why certain implementations did not use Giac code, 
> I am not involved in this work. 
>

I am involved in that, but I believe there may be some misconceptions here. 
The implementations we are doing for ODK are not for Groebner bases. 
However, the group I work for, who develop the system our code will 
contribute to, has been involved in GB computation for something like 
thirty years. Our work on GB's, which is not funded by ODK, is ongoing work 
for that entire period. 

As for polynomial arithmetic for applications other than GBs, that work 
builds on two separate projects that have been ongoing in one form or 
another since late 2006 in the one case and for some decades in the other 
case. Integration with those code bases is desirable for a number of 
reasons.

Bernard, if you have the impression that ODK went out looking for a 
polynomial library to use then you have the wrong impression. ODK is not a 
CAS, it's a toolbox. Giac could be part of that toolbox just as easily as 
any of the other tools developed in Europe, so long as it was designed to 
integrate with that toolbox. ODK is ultimately about exposing tools to a 
VRE and making those tools usable for researchers building their own VRE's.

Here is not the place for me to spell out the specific goals we have for 
the polynomial arithmetic we are implementing for ODK, but usability, 
flexibility, maintainability, testing, documentation, performance and 
exposure to a VRE all feature heavily in the feature set we've targeted. 
Note that the code we are developing is part of the HPC subproject of ODK. 
You can find information about the whole project, including the explicit 
subtasks we are contributing to, by digging into the OpenDreamKit website 
and GitHub repositories. Absolutely *everything* is fully public and 
accessible, from the initial grant proposal (even the drafts, I believe), 
through our meetings, goals, funding, performance indicators, through our 
code and dissemination.

-- 
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.

[sage-devel] Re: A Sage interface for FGb (Gröbner bases)

['Bill Hart' via sage-devel]

On Friday, 7 December 2018 21:41:41 UTC+1, Markus Wageringel wrote:
>
> Am Freitag, 7. Dezember 2018 13:07:45 UTC+1 schrieb Bill Hart:
>>
>> How many physical cores do you have on the machine (not logical cores), 
>> and how many CPU sockets and what is the cache structure? (I assume it is 
>> at least 16 physical cores, but I'm asking more because this sort of thing 
>> often happens because of shared caches.)
>>
>
> It has 2 CPU sockets, each having 8 physical cores with 2 threads each. As 
> for the cache:
>
> L1d cache: 32K
> L1i cache: 32K
> L2 cache: 256K
> L3 cache: 20480K
>
> Does this answer the question? Also, here is a specification: 
> https://ark.intel.com/products/64584/Intel-Xeon-Processor-E5-2660-20M-Cache-2-20-GHz-8-00-GT-s-Intel-QPI-
>

I don't know for sure, but it looks like it has a shared L3 cache across 
many cores in each socket. I wouldn't be terribly surprised if this was 
relevant. Of course, only an extended effort with many timings could 
confirm this for 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: A Sage interface for FGb (Gröbner bases)

['Bill Hart' via sage-devel]

On Friday, 7 December 2018 07:53:18 UTC+1, Markus Wageringel wrote:



While there will be some overhead due to the conversion from and to Sage, 
> it is the same in both cases. In fact, I observe similar times with the 
> native Giac that is installed into the Sage environment, when applied to 
> the Giac input file cyclic8 you linked above [1]: 0m27.309s using 4 threads 
> and 1m43.493s using 16. Indeed, CPU usage rarely surpasses 400% during the 
> computation. I am not sure what could be wrong here. Perhaps it is 
> something related to the patches of the Giac in Sage [2]?
>

How many physical cores do you have on the machine (not logical cores), and 
how many CPU sockets and what is the cache structure? (I assume it is at 
least 16 physical cores, but I'm asking more because this sort of thing 
often happens because of shared caches.)

-- 
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.

[sage-devel] Re: A Sage interface for FGb (Gröbner bases)

['Bill Hart' via sage-devel]

On Wednesday, 5 December 2018 23:44:43 UTC+1, Markus Wageringel wrote:
>
>
> I am a bit surprised about some of the Singular results being a lot worse 
> than reported in [5], cyclic7 in particular. Perhaps starting this 
> computation with some different options can help here.
>
> 
 

> [5] http://www.cecm.sfu.ca/~rpearcea/mgb.html
>

All the other systems are using modular methods here, so Roman use the 
modstd library (the command is modStd) in Singular to get those timings. 
Indeed cyclic7 over Q takes about 20s on my laptop in Singular using this 
approach. 

-- 
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.

[sage-devel] Re: A Sage interface for FGb (Gröbner bases)

['Bill Hart' via sage-devel]

On Saturday, 24 November 2018 20:25:13 UTC+1, john_perry_usm wrote:
>
> I walk into this discussion with some hesitancy, but Christian Eder has 
> developed a rather efficient F4 algorithm. [1] I know it works and is quite 
> fast, though I haven't compared it to the implementations mentioned above. 
> Unfortunately, I haven't heard from him in a while after he went off to 
> Iran for a few weeks, and he doesn't seem to have updated his site since 
> then, either.
>

I assure you he is quite alive. I saw him a few minutes ago! 

>From his recent talks, his implementation is nowadays more than competitive.

-- 
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.

[sage-devel] MPIR community repository

['Bill Hart' via sage-devel]

I thought now might be a good time to give an update on the status of the 
MPIR project.

Brian Gladman (the Windows MSVC "maintainer") and William Hart (the 
Linux/OSX "maintainer") have decided to separate the Windows MSVC 
development from the Linux/OSX development. There will be separate 
repositories for this. Currently, there are no maintainers for other 
platforms, and only x86_64 is targeted.

In order to ensure continuity of MPIR for all projects that continue to use 
it, we have decided to revert to a continuously maintained community 
repository, instead of issuing official releases. We will no longer be 
maintainers, but curators. This means our sole job is to ensure no garbage 
ends up in the repository, the performance and stability is not degraded on 
targeted platforms, pull requests are only accepted if continuous 
integration passes, and to offer assistance to serious developers as time 
permits. We will no longer offer assistance to ordinary users of MPIR.

I have brought the Linux/OSX repository into a workable state after recent 
efforts of Dima Pasechnik, Brian Gladman and others, and MSVC solution 
files have been removed. A number of improvements that have been in the 
pipe for a long time have been finally merged, and a few well-known bugs 
have been fixed. The continuous integration passes all tests. I have also 
updated the website.

The most important thing is to ensure the integrity of the MPIR repository 
and allow projects that currently use MPIR to continue to do so, and that 
patches can be contributed by anyone across the entire community.

The biggest issue going forward will be packaging. Most distros will want 
to see official releases. As this is simply too much work for two 
"curators", there will need to be a discussion on how this can be achieved.

I intend to make a more complete announcement in say a month about how 
exactly everything is going to work.

The immediate takeaway is that MPIR is *not* being actively developed, but 
we accept patches (*) from the community at large and review them. 

I hope everyone will understand that we do not have time to have extensive 
discussions on this that aren't about actual improvements of the code in 
the repository.

---

(*) Unfortunately we do not have CI resources to test new assembly code, 
therefore this can only be contributed by individuals that we can verify 
have the necessary technical skills.

-- 
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.

[sage-devel] Re: zn_poly status?

['Bill Hart' via sage-devel]

Those are absolutely incredible numbers. I know just how technically insane 
zn_poly is, so to be beating that by a factor of more than two, especially 
in the FFT range is *absolutely phenomenal*!!

I now feel a little bit embarrassed at only having said, "NTL is probably 
your best bet".

On Tuesday, 11 September 2018 16:14:00 UTC+2, Victor Shoup wrote:
>
> I got curious, so I collected some data.  Here are timing results 
> comparing NTL's zz_pX multiplication
> to zn_poly's zn_array_mul.  For various values of n, I multiplied 
> polynomials of degree < n
> modulo a 50 bit number.  The values of n are powers of 2 and halfway 
> between powers of 2,
> ranging between 512 and 512K.
> Both NTL and zn_poly were compiled using their default configurations.
> Timings were done on a Skylake Xeon using gcc 8.2.0.
> Each row reports n and the ratio (time for zn_poly)/(time for NTL).
> So a ratio > 1 means NTL is faster.
>
> Also, by now, NTL implements a divide-and-conquer style truncated FFT, 
> using code some of which
> is ultimately derived from some other code originally written by David 
> Harvey (fft62).
>
> 512 0.706683
> 768 0.84687
> 1024 0.922457
> 1536 0.923881
> 2048 1.02458
> 3072 0.982044
> 4096 1.0894
> 6144 1.32346
> 8192 1.33724
> 12288 1.61943
> 16384 1.44681
> 24576 1.35887
> 32768 1.43008
> 49152 1.34462
> 65536 1.40433
> 98304 1.48556
> 131072 1.42532
> 196608 1.3503
> 262144 1.43245
> 393216 1.61353
>
> One can also compile NTL with an option that enables an AVX-based FFT 
> implementation.
> With that option set, the numbers look like this.
>
> 512 1.30262
> 768 1.45693
> 1024 1.60583
> 1536 1.46475
> 2048 1.58405
> 3072 1.6219
> 4096 1.78167
> 6144 2.1571
> 8192 2
> 12288 2.52612
> 16384 2.25737
> 24576 2.25134
> 32768 2.32498
> 49152 2.28747
> 65536 2.15306
> 98304 2.52464
> 131072 2.18056
> 196608 2.22606
> 262144 2.13347
> 393216 2.56471
>
> If anyone wants to the program I used for timing, let me know.
>
> On Friday, September 7, 2018 at 9:53:43 AM UTC-4, Erik Bray wrote:
>>
>> Hi all, 
>>
>> Does anyone know what that current status is of the upstream zn_poly 
>> package?  According to its website 
>> http://cims.nyu.edu/~harvey/zn_poly/ it is "no longer maintained", 
>> though it has been re-released under a BSD-compatible license. 
>>
>> Since its last upstream release the package for it in Sage has 
>> accumulated a number of patches as well, and I believe I may need to 
>> add one more patch to it for building properly on Cygwin :(  See 
>> https://trac.sagemath.org/ticket/26050 
>>
>> If it's alright, I would propose creating a new repository for it 
>> under the sagemath gitlab organization (or GitHub) which would become 
>> the new "upstream" for zn_poly.  Then we can merge in all these 
>> patches; maybe even implement a new, more standard build system (I 
>> would be happy to do this).  In fact the current "build system" is 
>> going to have problems long-term, as it currently consists primarily 
>> of a Python script that will not work, as written, on Python 3. 
>>
>

-- 
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.

[sage-devel] Re: zn_poly status?

['Bill Hart' via sage-devel]

NTL is your best best. However zn_poly is a tour de force. It would be hard 
to beat.

On Friday, 7 September 2018 19:13:32 UTC+2, Antonio Rojas wrote:
>
>
>
> El viernes, 7 de septiembre de 2018, 15:53:43 (UTC+2), Erik Bray escribió:
>>
>> Hi all, 
>>
>> Does anyone know what that current status is of the upstream zn_poly 
>> package?  According to its website 
>> http://cims.nyu.edu/~harvey/zn_poly/ it is "no longer maintained", 
>> though it has been re-released under a BSD-compatible license. 
>>
>>
> Given that the library has been unmaintained for years, has someone looked 
> into whether its functionality can be provided by some other library 
> nowadays? 
>

-- 
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.

[sage-devel] Re: Error testing package flint-2.5.2.p2 (Red Hat 6.10)

['Bill Hart' via sage-devel]

The log shows there's a linking error for NTL. I assume it's something to 
do with the C++ standard used when compiling NTL. Not sure how to fix that. 
Hopefully someone has seen this before and knows how to fix 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: NTL 11.2.0

['Bill Hart' via sage-devel]

Hi Victor,

Thanks. That makes sense now. I was reading your diagram upside down! 
Indeed, on your diagram we use SSA below the diagonal.

The multimodular algorithm was not faster than Kronecker substitution for 
us. But I think that was simply because we don't have a small primes FFT, 
or something like that. I remember we discussed this once before.

Bill.

On Tuesday, 10 July 2018 14:09:05 UTC+2, Victor Shoup wrote:
>
> Bill,
>
> Above the diagonal, I believe Flint is using a Kronecker substitution 
> algorithm, while NTL is using a multi-modular FFT.  NTL always outperformed 
> Flint in this region. It is the region below the diagonal where both are 
> using Schoenhage-Strassen, and there you can see that NTL still lags behind 
> Flint somewhat, though not as much as it used to.
>
> The benchmark programs are available on the NTL web site, and I encourage 
> anyone who wants to run similar benchmarks on a different platform to do 
> so, and to verify that the benchmark software is fair.
>
> -Victor
>
> On Monday, July 9, 2018 at 8:33:12 AM UTC-4, Bill Hart wrote:
>>
>> These are ery interesting timings. In the region above the diagonal (and 
>> sufficiently far to the right - degree 12 I think), I believe we still use 
>> the SSA algorithm directly for polynomial arithmetic over Z. So your 
>> timings indicate that you are actually beating the Flint FFT directly.
>>
>> This is quite remarkable given the work that went into it on in Flint (it 
>> was already significantly faster than the FFT's in Magma and GMP, and 
>> faster than the Gaudry, Kruppa, Zimmermann FFT.
>>
>> I congratulate you on what must be some truly impressive work. (I keep 
>> telling whoever will listen that we should spend some time trying to catch 
>> back up with the NTL benchmarks you have been publishing, but there seems 
>> to be little opportunity to work on such projects these days, and there 
>> seems to be a real shortage of young people taking on challenges like this. 
>> We do know what needs to be done. It's more an issue of finding people who 
>> could actually carry out the work.)
>>
>> Anyway, thanks again for the impressive work you've been doing on NTL, 
>> for making your code Open Source, so that we can all learn from it, and for 
>> the benchmarks you have been making available!
>>
>> Bill.
>>
>> On Saturday, 7 July 2018 20:39:59 UTC+2, Victor Shoup wrote:
>>>
>>> I just released NTL 11.2.0 at http://www.shoup.net/ntl
>>>
>>> The main change is a new and improved implementation of the 
>>> Schoenhage-Strassen FFT for multiplication of polynomials over the 
>>> integers. The new implementation includes a truncated FFT algorithm, the 
>>> "sqrt 2" trick, and better engineered low-level "butterfly" code.  See 
>>> http://www.shoup.net/ntl/doc/tour-changes.html for details, including 
>>> some benchmarks.
>>>
>>> Also see http://www.shoup.net/ntl/benchmarks.pdf for an updated version 
>>> of NTL vs FLINT report.
>>>
>>

-- 
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.

[sage-devel] Re: NTL 11.2.0

['Bill Hart' via sage-devel]

These are ery interesting timings. In the region above the diagonal (and 
sufficiently far to the right - degree 12 I think), I believe we still use 
the SSA algorithm directly for polynomial arithmetic over Z. So your 
timings indicate that you are actually beating the Flint FFT directly.

This is quite remarkable given the work that went into it on in Flint (it 
was already significantly faster than the FFT's in Magma and GMP, and 
faster than the Gaudry, Kruppa, Zimmermann FFT.

I congratulate you on what must be some truly impressive work. (I keep 
telling whoever will listen that we should spend some time trying to catch 
back up with the NTL benchmarks you have been publishing, but there seems 
to be little opportunity to work on such projects these days, and there 
seems to be a real shortage of young people taking on challenges like this. 
We do know what needs to be done. It's more an issue of finding people who 
could actually carry out the work.)

Anyway, thanks again for the impressive work you've been doing on NTL, for 
making your code Open Source, so that we can all learn from it, and for the 
benchmarks you have been making available!

Bill.

On Saturday, 7 July 2018 20:39:59 UTC+2, Victor Shoup wrote:
>
> I just released NTL 11.2.0 at http://www.shoup.net/ntl
>
> The main change is a new and improved implementation of the 
> Schoenhage-Strassen FFT for multiplication of polynomials over the 
> integers. The new implementation includes a truncated FFT algorithm, the 
> "sqrt 2" trick, and better engineered low-level "butterfly" code.  See 
> http://www.shoup.net/ntl/doc/tour-changes.html for details, including 
> some benchmarks.
>
> Also see http://www.shoup.net/ntl/benchmarks.pdf for an updated version 
> of NTL vs FLINT report.
>

-- 
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.

[sage-devel] Re: Suggestion for the SageMath website

['Bill Hart' via sage-devel]

Yeah, I actually agree with that now after looking at it.

On Thursday, 7 June 2018 09:30:04 UTC+2, Vincent Klein wrote:
>
>
>> On side note: Is there any problem with alphabetical order if the whole 
>> list is there?
>>
>>
> Yes in my opinion. The animation takes 180 sec to display the whole list. 
> I think that's way longer than the average time people stay on the home 
> page.
> The result is a inequal exposure because the firsts in the list are the 
> most viewed. 
>

-- 
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.

[sage-devel] Re: Suggestion for the SageMath website

['Bill Hart' via sage-devel]

I just mean so it appears below the part visible in standard desktop 
browsers, i.e. so it is not the first thing you see when you load the page. 
"Below the fold" is my terminology for something that requires an action to 
read it, such as was required on this ancient IBM ThinkPad:

http://www.acontinuouslean.com/2009/10/01/the-original-ibm-thinkpad/

On side note: Is there any problem with alphabetical order if the whole 
list is there?

On Wednesday, 6 June 2018 17:31:32 UTC+2, Vincent Klein wrote:
>
> Le mercredi 6 juin 2018 17:06:45 UTC+2, Bill Hart a écrit :
>>
>> I would personally put it on the lower part of the page, so that it is 
>> "below the fold" on most browsers (due to its scrolly nature). But maybe 
>> others prefer it higher up. 
>>
> "below the fold", you mean under library and search button ? 
>
> Side Note : The package list in the prototype is in alphabetical order, i 
> keep in mind to randomize the list if we keep this solution.
>

-- 
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.

[sage-devel] Re: Suggestion for the SageMath website

['Bill Hart' via sage-devel]

On Wednesday, 6 June 2018 16:36:44 UTC+2, Vincent Klein wrote:
>
> Another alternative is to display all the packages in a slow scrolling 
> horizontal list ScrollingPackagePrototype.html 
> 
> . 
> Im not sure if the move is too disturbing for the reader or not. 
>

That's actually exactly what I had in mind when I made my suggestion. I 
would personally put it on the lower part of the page, so that it is "below 
the fold" on most browsers (due to its scrolly nature). But maybe others 
prefer it higher up. 

-- 
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: Suggestion for the SageMath website

['Bill Hart' via sage-devel]

On Friday, 1 June 2018 18:02:35 UTC+2, Bill Hart wrote:
>
>   hence my suggestion to randomise the shortlist or remove it.
>

Another technical solution, if the list is retained in any form on the 
front page, would be to have a scrolling list. This might reduce the 
technical task to the insertion of a standard javascript element. Of course 
I know nothing about the technical requirements for the Sage website, e.g. 
load times, use of javascript, etc. It's just a technical suggestion, in 
case it is useful. 

-- 
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: Suggestion for the SageMath website

['Bill Hart' via sage-devel]

On Friday, 1 June 2018 16:48:14 UTC+2, William wrote:
>
> > 
> > As I say, I don't think it is justifiable, except on technical and 
> > historical grounds. The work of all of those people is obviously, and 
> has 
> > obviously always been highly regarded and valued. 
>
> PR's are very, very welcome! 
>

I will not personally be able to work on this. 

I think you may have misunderstood what I wrote, though. I was referring to 
the work of all the people who wrote the libraries on which Sage relies. 
The Sage community has obviously always valued their work (independently of 
any PR's to the Sage project), and not being acknowledged on the front page 
doesn't represent anything except lack of space on the main page and the 
instantaneous recollection of the person who formulated that list. It's 
purely a historical and technical accident, it has nothing to do with how 
much their work is or isn't valued, hence my suggestion to randomise the 
shortlist or remove it. It appears to have the opposite effect of what is 
intended!

-- 
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.

[sage-devel] Re: Suggestion for the SageMath website

['Bill Hart' via sage-devel]

On Friday, 1 June 2018 15:12:31 UTC+2, kcrisman wrote:
>
>
> This seems very reasonable; the list probably dates to a much earlier time 
> when there were some "main" dependencies but now there are SO many ...  Can 
> you make a ticket on http://github.com/sagemath/website so that Harald 
> (and others who might have a way to deal with it) is more likely to see it?
>

By the way, there are even some major dependencies not listed there. And 
these have been dependencies for many, many years. I accept that the list 
is there for historical reasons, but I don't think that is the reason.

As I say, I don't think it is justifiable, except on technical and 
historical grounds. The work of all of those people is obviously, and has 
obviously always been highly regarded and valued.

-- 
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.

[sage-devel] Re: Suggestion for the SageMath website

['Bill Hart' via sage-devel]

Done. [1]

[1] https://github.com/sagemath/website/issues/133

On Friday, 1 June 2018 15:12:31 UTC+2, kcrisman wrote:
>
>
>
> On Friday, June 1, 2018 at 8:46:52 AM UTC-4, Bill Hart wrote:
>>
>> Hi all,
>>
>> I've been aware for a while that some libraries are not happy that their 
>> package is not explicitly mentioned by name on the sagemath.org home 
>> page and that you have to click through to the "and many more" to see their 
>> package credited.
>>
>> I have a suggestion how this could be made more equitable for the many 
>> dependencies of Sage. The home page could randomly rotate the names of 
>> external dependencies that are listed on the main page so they all get 
>> equal exposure. It could even say, "Here is a selection updated randomly: 
>> ... but there are many _more_". (My apologies if this is already the 
>> case, but after a number of refreshes, the list doesn't appear to change, 
>> presently.)
>>
>>
> This seems very reasonable; the list probably dates to a much earlier time 
> when there were some "main" dependencies but now there are SO many ...  Can 
> you make a ticket on http://github.com/sagemath/website so that Harald 
> (and others who might have a way to deal with it) is more likely to see 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Suggestion for the SageMath website

['Bill Hart' via sage-devel]

Hi all,

I've been aware for a while that some libraries are not happy that their 
package is not explicitly mentioned by name on the sagemath.org home page 
and that you have to click through to the "and many more" to see their 
package credited.

I have a suggestion how this could be made more equitable for the many 
dependencies of Sage. The home page could randomly rotate the names of 
external dependencies that are listed on the main page so they all get 
equal exposure. It could even say, "Here is a selection updated randomly: 
... but there are many _more_". (My apologies if this is already the 
case, but after a number of refreshes, the list doesn't appear to change, 
presently.)

Obviously, the intention of this suggestion is to bring more prominent 
credit to authors of those other packages, which they deserve. As such, I'd 
prefer if we could avoid discussions to justify listing only certain 
packages on the main page (other than technical considerations, such as 
limited space on the main page), as this would have the opposite of the 
intended effect, which is to prominently recognize their work, which is 
well-deserved. 

I'm aware there may be other technical considerations, such as static vs 
dynamic nature of the html, SEO optimisation considerations related to 
regular changes to the page, etc. I guess those need to be considered. But 
I also believe this is a very important social issue, or I wouldn't raise 
it.

(The alternative, of course, would be to remove the short list on the main 
page and only have the very long list on the "and many more" page.)

Sorry it's taken me so long to get around to mentioning this, after it had 
been repeatedly brought to my attention by various people over the years.

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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: division in Zmod(6)

['Bill Hart' via sage-devel]

Correction: the corresponding issue in the Nemo.jl project will be fixed in 
Nemo 0.8.4, not the next release 0.8.3, which apparently has already been 
tagged and is already in the Julia METADATA queue. We will of course tag 
0.8.4 as soon as 0.8.3 clears the queue. The issue has been fixed in 
Nemo/master today, of course.

Thanks Samuel and William for trying this out in our project. It's nice 
when this sort of cross-comparison happens and shakes loose more bugs. In 
this case the code to deal with this was there in Nemo.jl, but had a typo, 
and the test code restricted to the easy case (because that is all the old 
code handled).

(We also took the opportunity to replace the implementation with a simpler 
faster one.)

-- 
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: division in Zmod(6)

['Bill Hart' via sage-devel]

In Julia and Nemo, the slash operator is floating point division. For 
example, 1/2 is 0.5 not a half. For division in a ring, you want divexact 
(there is also a separate operator, div, for Euclidean division).

At the moment, the code in Nemo for this is actually incorrect, so it only 
gives you an answer in one of the two examples in this thread and an 
exception in the other case. It's not a difficult fix. It should be in the 
next version of Nemo.

In AbstractAlgebra (pure Julia, no Flint), we get:

julia> using AbstractAlgebra

Welcome to AbstractAlgebra version 0.0.6

AbstractAlgebra comes with absolutely no warranty whatsoever

julia> R = ResidueRing(ZZ, 6)
Residue ring of Integers modulo 6

julia> a = R(5)
5

julia> b = R(4)
4

julia> c = a*b
2

julia> divexact(c, a)
4

julia> divexact(c, b)
2

-- 
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.

[sage-devel] Re: What does MPolynomial_libsingular.reduce() do?

['Bill Hart' via sage-devel]

Hans added that one should not rely on the behaviour that Singular reorders 
the list. This may change in a future version of Singular. He mentioned it 
only to explain the behaviour that is currently observed.

On Thursday, 19 October 2017 11:20:05 UTC+2, Bill Hart wrote:
>
> According to Hans Schoenemann:
>
> "Usually (i.e. in a ring with a well ordering and no additional flags)
> reduce/kNF (p,I) computes p' (with p a polynomial and I a list of 
> polynomials)
> with p-p' is in the ideal generated by I and no monomial of p' is
> divisible by any L(f) for f in I.
> If I is a standard basis then p' is unique.
> Otherwise, the result depends on the internally used algorithm.
> In Singular's implementation p' does not depend on the order of the
> polynomials in I because it starts with sorting I
> (wrt. to the monomial ordering or the total degree)."
>
> On Monday, 16 October 2017 18:41:50 UTC+2, Luca De Feo wrote:
>>
>> Hi everyone, 
>>
>> Here's a Sage session: 
>>
>> sage: A. = QQ[] 
>> sage: (x+y).reduce([(x-y), (x+y)]) 
>> 0 
>> sage: (x-y).reduce([(x-y), (x+y)]) 
>> -2*y 
>>
>> The docstring says reduce computes "the normal form of self w.r.t. I, 
>> i.e. [...] the remainder of this polynomial with respect to the 
>> polynomials in I". 
>>
>> Does anyone have any idea how this normal form is defined? It doesn't 
>> seem to depend on the order of the polynomials in I. 
>>
>> From the source code, I can only tell it calls Singular's kNF, but I 
>> can't find any doc for it. Maybe this function should be underscored? 
>>
>> Cheers, 
>> Luca 
>>
>

-- 
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.

[sage-devel] Re: What does MPolynomial_libsingular.reduce() do?

['Bill Hart' via sage-devel]

According to Hans Schoenemann:

"Usually (i.e. in a ring with a well ordering and no additional flags)
reduce/kNF (p,I) computes p' (with p a polynomial and I a list of 
polynomials)
with p-p' is in the ideal generated by I and no monomial of p' is
divisible by any L(f) for f in I.
If I is a standard basis then p' is unique.
Otherwise, the result depends on the internally used algorithm.
In Singular's implementation p' does not depend on the order of the
polynomials in I because it starts with sorting I
(wrt. to the monomial ordering or the total degree)."

On Monday, 16 October 2017 18:41:50 UTC+2, Luca De Feo wrote:
>
> Hi everyone, 
>
> Here's a Sage session: 
>
> sage: A. = QQ[] 
> sage: (x+y).reduce([(x-y), (x+y)]) 
> 0 
> sage: (x-y).reduce([(x-y), (x+y)]) 
> -2*y 
>
> The docstring says reduce computes "the normal form of self w.r.t. I, 
> i.e. [...] the remainder of this polynomial with respect to the 
> polynomials in I". 
>
> Does anyone have any idea how this normal form is defined? It doesn't 
> seem to depend on the order of the polynomials in I. 
>
> From the source code, I can only tell it calls Singular's kNF, but I 
> can't find any doc for it. Maybe this function should be underscored? 
>
> Cheers, 
> Luca 
>

-- 
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.

[sage-devel] Re: EU Copyright reform threatens open source

['Bill Hart' via sage-devel]

On Monday, 2 October 2017 23:40:55 UTC+2, Bill Hart wrote:
>
> I think what is likely to happen is that any GitHub code which is NOT Open 
> Source, is likely to be used in the new filters. If 10 consecutive lines of 
> copyrighted, proprietary code is found in a repository not owned by the 
> copyright holders, it might be worth investigating as possible piracy.
>

If I were GitHub, I would implement this feature now, and roll it out for 
all holders of repositories of proprietary code on GitHub, and make sure it 
is very well tested against all such other repositories. :-) 

-- 
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.

[sage-devel] Re: EU Copyright reform threatens open source

['Bill Hart' via sage-devel]

Thanks for the link. The way I read this, GitHub might be required to 
implement filters that prevent an individual uploading content they were 
not licensed to upload, but which had already been uploaded to GitHub.

I think GitHub could easily do this at the level of repositories. It would 
be much harder, if not impossible, to implement at the level of files or 
legally significant blocks of code (10 lines, I believe). 

I think what is likely to happen is that any GitHub code which is NOT Open 
Source, is likely to be used in the new filters. If 10 consecutive lines of 
copyrighted, proprietary code is found in a repository not owned by the 
copyright holders, it might be worth investigating as possible piracy.

On Monday, 2 October 2017 22:54:50 UTC+2, Dima Pasechnik wrote:
>
>
>
> On Monday, October 2, 2017 at 9:45:41 PM UTC+1, Bill Hart wrote:
>>
>> There's not much detail on how this could affect Open Source development, 
>> except that GitHub and the like might be forced to implement "flawed 
>> filters".
>>
>> But how could this be implemented by GitHub? What are they going to check 
>> projects against? The source code of all the closed source products on the 
>> planet? I think not.
>>
>> They are going to be checking for pirated works that have been published 
>> publicly, e.g. movies, books, etc. If these are on GitHub, they shouldn't 
>> be.
>>
>> I'd like to see a little more explanation of what exactly is wrong with 
>> the proposed law. Otherwise it sounds like FUD to me.
>>
>
> well, how about this:
> https://edri.org/files/copyright/copyright_proposal_article13.pdf
>  
>
>>
>> On Monday, 2 October 2017 10:38:15 UTC+2, Nicolas M. Thiéry wrote:
>>>
>>>Dear Sage developers, 
>>>
>>> Summary: the EU is looking to pass a new copyright act that would 
>>> require sharing platforms to filter for copyright infringements. For 
>>> software sharing platforms like GitHub, GitLab, ... this is very 
>>> problematic and might endanger open source development as we know it. 
>>>
>>> You may want to read https://savecodeshare.eu/ and sign the open letter 
>>> by the Free Software Foundation Europe to the EU there. 
>>>
>>> The letter can be signed as an individual or as an organization. 
>>> OpenDreamKit is planning to sign as an organization. Maybe the 
>>> SageMath fundation could sign as an organization as well on behalf of 
>>> the community? (unless of course some SageMath dev would object now). 
>>>
>>> Cheers, 
>>> Nicolas 
>>> -- 
>>> Nicolas M. Thiéry "Isil"  
>>> http://Nicolas.Thiery.name/ 
>>>
>>

-- 
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.

[sage-devel] Re: EU Copyright reform threatens open source

['Bill Hart' via sage-devel]

There's not much detail on how this could affect Open Source development, 
except that GitHub and the like might be forced to implement "flawed 
filters".

But how could this be implemented by GitHub? What are they going to check 
projects against? The source code of all the closed source products on the 
planet? I think not.

They are going to be checking for pirated works that have been published 
publicly, e.g. movies, books, etc. If these are on GitHub, they shouldn't 
be.

I'd like to see a little more explanation of what exactly is wrong with the 
proposed law. Otherwise it sounds like FUD to me.

On Monday, 2 October 2017 10:38:15 UTC+2, Nicolas M. Thiéry wrote:
>
>Dear Sage developers, 
>
> Summary: the EU is looking to pass a new copyright act that would 
> require sharing platforms to filter for copyright infringements. For 
> software sharing platforms like GitHub, GitLab, ... this is very 
> problematic and might endanger open source development as we know it. 
>
> You may want to read https://savecodeshare.eu/ and sign the open letter 
> by the Free Software Foundation Europe to the EU there. 
>
> The letter can be signed as an individual or as an organization. 
> OpenDreamKit is planning to sign as an organization. Maybe the 
> SageMath fundation could sign as an organization as well on behalf of 
> the community? (unless of course some SageMath dev would object now). 
>
> Cheers, 
> Nicolas 
> -- 
> Nicolas M. Thiéry "Isil" > 
> http://Nicolas.Thiery.name/ 
>

-- 
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] problem building mpir

['Bill Hart' via sage-devel]

I think preferring clang over gcc on OSX is probably the right solution for 
this.

Just to be clear: this is completely different to the Skylake issue, which 
has to do with the actual Yasm assembly code in MPIR (or actually the M4 
macros used by it), not the assembly code output by the C compiler.

On Monday, 2 October 2017 20:27:58 UTC+2, mhampton wrote:
>
> Thanks, using CFLAGS=-Wa,-q seems to work for me so far.
>
> On Monday, October 2, 2017 at 1:05:28 PM UTC-5, Isuru Fernando wrote:
>>
>> This is the same as https://github.com/wbhart/mpir/issues/217 and 
>> https://trac.sagemath.org/ticket/23549 
>> 
>>
>> Isuru
>>
>> On Mon, Oct 2, 2017 at 12:37 PM, mhampton  wrote:
>>
>>> Hi,
>>>
>>> I'm having trouble building either 8.0 or 8.1.beta6, it halts at mpir.  
>>> The log for that is here:
>>>
>>> http://www.d.umn.edu/~mhampton/mpir-3.0.0.p0.log
>>>
>>> I see that some other people had problems on skylake machines, but I 
>>> have a "late 2013" macbook pro, the cpu is an i5-4288U (Haswell).  The 
>>> operating system is 10.9.5.  In case its relevant, the Xcode is version 6.2.
>>>
>>> -M.Hampton
>>>
>>> -- 
>>> 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.

[sage-devel] Re: Blog post on parallel multivariate arithmetic : comparing all the things!

['Bill Hart' via sage-devel]

The dense multicore examples will take months to run in Flint, since we 
haven't written the code yet! :-)

But your explanation about the cost of conversion in the sparse case 
certainly more than accounts for overall difference in performance.

Giac also has a symbolic front end, too, which Flint and Nemo do not. That 
is certainly important for people to realise.

On Tuesday, 26 September 2017 13:13:06 UTC+2, parisse wrote:
>
>
>
> Le mardi 26 septembre 2017 10:43:10 UTC+2, Bill Hart a écrit :
>>
>> We used to do this, and Daniel noticed that it wasn't really threadsafe.
>>
>
> It would be in my implementation, but inserting requires sometimes memory 
> allocation and it seems to slow down too much. Anyway, as explained 
> earlier, conversions from packed exponent-int128 coefficients to 
> polynomials with unpacked exponents and generic coefficients takes too much 
> time in the sparse case, I think is not worth rewriting a thread-efficient 
> sparse multivariate polynomial multiplication algorithms in giac. For 
> example in the n=12 case, the effective multiplication takes 1.3s on my Mac 
> and conversion takes twice more, in the n=16 case, effective multiplication 
> takes 11.5s and conversion 19s (run export GIAC_DEBUG=6 in a shell or 
> debug_infolevel:=6; in a script to see some details while running giac). 
> It's probably the same problem for Maple with their "native" vs sdmp 
> polynomial representation. This is something that the reader of your 
> benchmarks should keep in mind.
> Thinks are completely different for dense polynomials, because the 
> conversion is dominated by the multiplication time (but fortunately 
> thread-efficient multiplication code is available for giac for these kind 
> of polynomials).
>

-- 
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.

[sage-devel] Re: Blog post on parallel multivariate arithmetic : comparing all the things!

['Bill Hart' via sage-devel]

We used to do this, and Daniel noticed that it wasn't really threadsafe. I 
don't know the current status of this. At some point he said it didn't make 
any difference after he got the delayed insertion working.

I didn't check carefully, but maybe he stores it in the final heap location 
now. But I'm not sure. I'll ask him when I get a chance. [2]

[2] https://github.com/wbhart/flint2/blob/trunk/mpoly.h (lines 582 ff.)

On Tuesday, 26 September 2017 10:12:23 UTC+2, parisse wrote:
>
> I found a way to get better timings by caching the index of the insertion 
> chain of the previous monomial. But now multi-threaded execution is slower 
> than 1 thread execution most certainly because of locks during insertion... 
> I will probably force 1 thread sparse multiplication.
>

-- 
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.

[sage-devel] Re: Blog post on parallel multivariate arithmetic : comparing all the things!

['Bill Hart' via sage-devel]

Roman Pearce said he would put up some code to explain this. (The 
conditions Daniel uses are quite complex in comparison.) I therefore think 
that it's ok to quote the following from correspondence with Roman (since I 
put up my blog):

[The idea is based on ] "Ellis Horowitz, A Sorting Algorithm for Polynomial 
Multiplication
Journal of the ACM, Volume 22 Issue 4, Oct. 1975, Pages 450-462
http://dl.acm.org/citation.cfm?doid=321906.321908

Before inserting f_i * g_j into the heap, check if there exists
f_k * g_j in the heap where k < i, and if so, do not insert the
product.  We simply check if f_{i-1} * g_j is the next unmerged
product for f_{i-1} whether it is in the heap or not.  Then you
have to put the dropped products back in the heap later.  After
extracting f_i * g_j from the heap, check if f_{i+1} has a term
in the heap, and if not, insert f_{i+1} * g_j."

This is what I had remembered from what Roman explained at ISSAC. But 
Daniel wasn't able to figure out something along those lines that improved 
timings. Clearly it does though, since Roman uses it to great effect. And 
thanks very much to Roman for suggesting this very important improvement!

I haven't yet looked in detail at Daniel's conditions. It will be 
interesting to compare. You can see then in fmpz_mpoly/mul_heap_threaded.c 
in the Flint repository [1]. To my eye, they don't look that complicated. I 
think it is the lines 187 and following. Perhaps they will end up being 
equivalent.

[1] https://github.com/wbhart/flint2/blob/trunk/fmpz_mpoly/mul_heap_threaded.c
 
On Tuesday, 26 September 2017 07:52:27 UTC+2, parisse wrote:
>
>
>
> Le lundi 25 septembre 2017 18:56:26 UTC+2, Bill Hart a écrit :
>>
>> Do you use anything special for memory management? Mickael Gastineau 
>> recommended jemalloc, which we haven't tried yet. I assume you expected to 
>> see better times for the threaded benchmarks with giac? 
>>
>
> I'm not using anything specific for memory management. Thread-efficient 
> memory management would certainly help improve performances, because more 
> than half of the time is done in conversions inside giac, and conversions 
> to mpz types are not parallelized because it would be slower to wait for 
> locks. I was asking about the compiler because I looked at my code and saw 
> that some optimizations are disabled for clang. 
> Can you give some precisions about what you call delayed insertion in the 
> heap? I can delay insertion of the initial product monomials f[i]*g[0] but 
> that does not improve much the timings, at least with 1 thread. 
>

-- 
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.

[sage-devel] Re: Blog post on parallel multivariate arithmetic : comparing all the things!

['Bill Hart' via sage-devel]

Do you use anything special for memory management? Mickael Gastineau 
recommended jemalloc, which we haven't tried yet. I assume you expected to 
see better times for the threaded benchmarks with giac? We've had to work 
way too hard to get good timings for this. But we see the same issues on 
multiple machines. Trip just scales beautifully, and Piranha does really 
well too.

Do you mainly do timings on a Mac? 

On Monday, 25 September 2017 16:39:24 UTC+2, Bill Hart wrote:
>
> On the main benchmark machine we have gcc-4.8.4.
>
> On Monday, 25 September 2017 12:32:39 UTC+2, parisse wrote:
>>
>> Hi,
>>
>> Which compiler are you running?
>>
>

-- 
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.

[sage-devel] Re: Blog post on parallel multivariate arithmetic : comparing all the things!

['Bill Hart' via sage-devel]

On the main benchmark machine we have gcc-4.8.4.

On Monday, 25 September 2017 12:32:39 UTC+2, parisse wrote:
>
> Hi,
>
> Which compiler are you running?
>

-- 
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.

[sage-devel] Blog post on parallel multivariate arithmetic : comparing all the things!

['Bill Hart' via sage-devel]

Hi all,

I've written a new blog post on our OpenDreamKit project to provide fast 
parallel multivariate arithmetic [1].

I have timings of all the major systems now, including our first timings of 
parallel multivariate multiplication.

Bill.

[1] http://wbhart.blogspot.de/2017/09/parallel-multivariate-multiplication.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.

Re: [sage-devel] Re: Sage 8.0 Build Error on MacOS, [mpir-3.0.0.p0] Error building MPIR.

['Bill Hart' via sage-devel]

That's right. For now that is the only workaround. We know what the problem 
is now, but don't have a working patch to fix it. It's the JMPENT macro in 
mpn/x86_64/x86_64-defs.m4 that doesn't work on 64 bit OSX.

Details of the issue can be found here, I believe [1].

Bill.

[1] https://gmplib.org/list-archives/gmp-bugs/2012-December/002836.html

On Tuesday, 22 August 2017 19:37:50 UTC+2, Alex J Best wrote:
>
> As the problem is skylake I assume mpn/x86_64/skylake/avx/addmul_1.asm is 
> the one to patch out.
>
> On Monday, August 21, 2017 at 11:51:28 AM UTC-4, Dima Pasechnik wrote:
>>
>>
>>
>> On Monday, August 21, 2017 at 4:15:29 PM UTC+1, Michael Frey wrote:
>>>
>>> What is the best way to do this?  The file is extracted from the 
>>> mpir-3.0.0.tar.bz2 every time make is run.
>>>
>>
>> the standard way would be to add the patch removing  this file (which one 
>> exactly, there are few files named so?)
>> build/pkgs/mpir/patches/
>>
>>
>>
>>> On Wednesday, August 2, 2017 at 5:41:01 PM UTC-4, Bill Hart wrote:

 The only workaround I'm currently aware of is to remove the offending 
 addmul_1.asm file. It is to do with our use of jump tables.


>>

-- 
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.

[sage-devel] Re: Some polynomial timings

['Bill Hart' via sage-devel]

We are faster for sparse multivariate multiplication on multiple cores too. 
We just haven't blogged about it yet. :-)

But you are right, Giac is years ahead at this point. We do not envision 
adding multivariate factorisation within the scope of the OpenDreamKit 
funded project that is allowing us to work on this. We do hope to add it 
eventually of course.

Just to correct a misconception earlier in the thread, the issue with 
Skylake has nothing to do with Flint. That is an issue in MPIR which is a 
community supported project. No one is currently paid to work on MPIR. 

On Tuesday, 5 September 2017 07:54:10 UTC+2, parisse wrote:
>
> And why not giac? flint is a little faster for basic multivariate 
> polynomial arithmetic on 1 thread, but giac is multithread and has more 
> advanced fast functionnalities like gcd, factorization, Groebner basis or 
> rational univariate representation.
>

-- 
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] Unable to compile 8.0.rc2 on mac

['Bill Hart' via sage-devel]

Reimer Behrends has helped me track down the explicit issue. We don't have 
a patch yet, but the bug (and solution) is described here [1].

Basically the M4 macro JMPENT in mpn/x86_64/x86_64-defs.mac needs to do 
more than just subtract the two addresses on Mac. However, I'm confused why 
this isn't affecting every 64 bit Skylake Mac out there. But his has only 
been reported twice! Are Skylake Macs really rare or something?

Bill.

[1] https://gmplib.org/list-archives/gmp-bugs/2012-December/002836.html

On Wednesday, 19 July 2017 11:15:09 UTC+2, Bill Hart wrote:
>
> It's certainly not a generic problem affecting Mac [0]. It's Skylake 
> specific and something their linker doesn't like that works on that 
> architecture on Linux.
>
> Bill.
>
> [0] 
> https://travis-ci.org/wbhart/mpir/builds/252901954?utm_source=github_status&utm_medium=notification
>
> On Wednesday, 19 July 2017 11:12:37 UTC+2, Bill Hart wrote:
>>
>> Alex Best pointed out this morning that something similar came up for the 
>> GMP guys a while back. Apparently something to do with jump tables. That is 
>> probably affecting our code here [1].
>>
>> We'll look into it. Unfortunately, in the mean time, the best one can 
>> really do is delete the affected file.
>>
>> Bill.
>>
>> [1] 
>> https://github.com/wbhart/mpir/blob/master/mpn/x86_64/skylake/avx/addmul_1.asm#L100
>>
>> On Wednesday, 19 July 2017 01:46:48 UTC+2, Andrew wrote:
>>>
>>>
>>>
>>> On Wednesday, 19 July 2017 00:59:27 UTC+10, Dima Pasechnik wrote:

 Surely MPIR guys would appreciate feedback.
 This might be their assembler bug.

 Will let them know.
>>> A. 
>>>
>>

-- 
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 8.0 Build Error on MacOS, [mpir-3.0.0.p0] Error building MPIR.

['Bill Hart' via sage-devel]

The only workaround I'm currently aware of is to remove the offending 
addmul_1.asm file. It is to do with our use of jump tables.

On Monday, 31 July 2017 19:13:57 UTC+2, Michael Frey wrote:
>
> Hi François,
>
> Thank you for your help.
>
> I tried as you suggested from a clean source.  Unfortunately the result is 
> the same.  I have attached the log and script files just to make sure I 
> made the correct changes..
>
> Mike
>
> On Sunday, July 30, 2017 at 10:05:43 PM UTC-4, François Bissey wrote:
>>
>> Michael in view of my experiments I want you to try something different. 
>> Forget about the CFLAGS and the environment variable. 
>> Instead, can you edit the file build/pkgs/mpir/spkg-install and remove 
>> the following section 
>> # In some cases (see SAGE_ROOT/spkg/bin/sage-env), on Darwin, 
>> # CC might be set to clang, but MPIR doesn't seem to build 
>> # with clang. 
>> CLANG=`command -v clang` 
>> GCC=`command -v gcc` 
>> if [ -n "$CC" ] && [ "$CC" = "$CLANG" ] && [ -n "$GCC" ] ; then 
>> export CC="$GCC" 
>> fi 
>>
>> and try again. 
>>
>> François 
>>
>> > On 31/07/2017, at 13:11, Michael Frey  wrote: 
>> > 
>> > I have attached the log for muir, the command I used was 
>> "AS_INTEGRATED_ASSEMBLER=1 make -j1" and using the export CFLAGS="-Wa,-q 
>> $CFLAGS" 
>> > 
>> > On Saturday, July 29, 2017 at 8:05:54 PM UTC-4, François Bissey wrote: 
>> > Can we have a bit more of that log? I would like to see the full 
>> > command. 
>> > 
>> > François 
>>
>>

-- 
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] Unable to compile 8.0.rc2 on mac

['Bill Hart' via sage-devel]

It's certainly not a generic problem affecting Mac [0]. It's Skylake 
specific and something their linker doesn't like that works on that 
architecture on Linux.

Bill.

[0] 
https://travis-ci.org/wbhart/mpir/builds/252901954?utm_source=github_status&utm_medium=notification

On Wednesday, 19 July 2017 11:12:37 UTC+2, Bill Hart wrote:
>
> Alex Best pointed out this morning that something similar came up for the 
> GMP guys a while back. Apparently something to do with jump tables. That is 
> probably affecting our code here [1].
>
> We'll look into it. Unfortunately, in the mean time, the best one can 
> really do is delete the affected file.
>
> Bill.
>
> [1] 
> https://github.com/wbhart/mpir/blob/master/mpn/x86_64/skylake/avx/addmul_1.asm#L100
>
> On Wednesday, 19 July 2017 01:46:48 UTC+2, Andrew wrote:
>>
>>
>>
>> On Wednesday, 19 July 2017 00:59:27 UTC+10, Dima Pasechnik wrote:
>>>
>>> Surely MPIR guys would appreciate feedback.
>>> This might be their assembler bug.
>>>
>>> Will let them know.
>> A. 
>>
>

-- 
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] Unable to compile 8.0.rc2 on mac

['Bill Hart' via sage-devel]

Alex Best pointed out this morning that something similar came up for the 
GMP guys a while back. Apparently something to do with jump tables. That is 
probably affecting our code here [1].

We'll look into it. Unfortunately, in the mean time, the best one can 
really do is delete the affected file.

Bill.

[1] 
https://github.com/wbhart/mpir/blob/master/mpn/x86_64/skylake/avx/addmul_1.asm#L100

On Wednesday, 19 July 2017 01:46:48 UTC+2, Andrew wrote:
>
>
>
> On Wednesday, 19 July 2017 00:59:27 UTC+10, Dima Pasechnik wrote:
>>
>> Surely MPIR guys would appreciate feedback.
>> This might be their assembler bug.
>>
>> Will let them know.
> A. 
>

-- 
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

['Bill Hart' via sage-devel]

It seems like you've done a good job with it anyway. Thanks for the 
description.

Bill.

On Thursday, 13 July 2017 20:46:21 UTC+2, bluescarni wrote:
>
> 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-...@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,
>>>&g

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

['Bill Hart' via sage-devel]

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.

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

['Bill Hart' via sage-devel]

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.

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

['Bill Hart' via sage-devel]

On Tuesday, 11 July 2017 20:26:51 UTC+2, Johan S. H. Rosenkilde wrote:
>
> > That's absolutely correct, and a point I make in my blog. One heuristic 
> is 
> > that GBs tend to have a large number of very small polynomials and so 
> one 
> > can dispatch larger arithmetic operations to a different back end safely 
> > (converting to and from some other format on the fly). This is something 
> > Singular already does, I believe. 
>
> I guess for a system like Sage it makes sense to use a default backend 
> that optimises for fast arithmetic. A GB computation is something one 
> expects to be long, so it seems OK to take a small amount of time 
> converting to a GB-optimised backend whenever a GB-computation is 
> called. 
>

I would personally agree with that. It doesn't make sense for Singular, 
since Singular is really dedicated to a particular problem domain where GBs 
are almost everything. But Sage is more general purpose.

People probably care more about multivariate gcd and factorisation than 
they do about basic arithmetic though, except for very small polynomials. 
Having slow arithmetic does make it hard to coopt it for other purposes 
though.

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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

['Bill Hart' via sage-devel]

On Tuesday, 11 July 2017 12:20:15 UTC+2, Simon King wrote:
>
> Hi, 
>
> On 2017-07-10, mmarco > wrote: 
> > It is surprising the difference between singular and Sage, considering 
> that 
> > Sage mostly relies on Singular for multivariate polynomial arithmetic. 
>
> Note that Singular is optimised for Gröbner basis computations, but 
> certainly 
> not optimised for fast arithmetics. So, it is absolutely no surprise that 
> polynomial arithmetics can be improved by using a different backend. 
> However, 
> keep in mind that the other backend probably will be much slower than 
> Singular 
> in doing Gröbner basis computations. 
>
> Best regards, 
> Simon 
>
>
That's absolutely correct, and a point I make in my blog. One heuristic is 
that GBs tend to have a large number of very small polynomials and so one 
can dispatch larger arithmetic operations to a different back end safely 
(converting to and from some other format on the fly). This is something 
Singular already does, I believe.

Of course there are also libraries that do GBs and still have basic 
arithmetic that is comparable to the timings I've given. This is definitely 
something we care about and will be working on in future. The main goal of 
the ODK work we are doing, as we see it, is to speed up Singular (by 
speeding up Factory).

We are also independently looking at parallelising GBs (in a totally 
different way, of course). So once this project is done, we may get the 
best of both worlds! It's a very interesting project that a number of 
people are having input into. 

-- 
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: [ODK participants] Blog post on fast multivariate arithmetic

['Bill Hart' via sage-devel]

On Monday, 10 July 2017 17:05:10 UTC+2, vdelecroix wrote:
>
> On 10/07/2017 16:36, 'Bill Hart' via sage-devel wrote: 
> >> BTW, it would be good to have them in the post! 
> >> 
> > 
> > It already says in the post that for systems that didn't provide the 
> > required function, I used quotient with remainder. 
>
> I meant code snippets. 
>

I suppose that could be useful, but it's a lot of work for little clear 
benefit (5 systems, 6 benchmarks). The code is pretty much exactly what 
Ralph wrote, except that I used a for loop for the operation being timed, 
and timed that. This was the same in all the systems.

I used quo_rem for division with remainder (for the divisibility test with 
quotient benchmark) and * for multiplication. For quotient only, I don't 
recall if I used quo_rem or //. It's clear from the timings I didn't use /, 
and I do recall checking the documentation very carefully for that.

-- 
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: [ODK participants] Blog post on fast multivariate arithmetic

['Bill Hart' via sage-devel]

Switching to Singular for working over ZZ seems like a good idea. I timed 
it over ZZ and QQ in Singular and don't notice much difference in the 
timings.

I'm sure the following is obvious, but let me mention it just in case. In 
the blog post I explain that some systems do not explicitly provide 
arithmetic over Z (e.g. Giac, which internally optimises for Z, but works 
over Q from the point of view of the user). The answer to a general 
division over Z will not necessarily be the same as the answer over Q. I 
chose the specific benchmark examples so that this is actually the case, 
but it isn't true in general. This was the only way to give meaningful 
comparison with Giac. But this doesn't imply that one can always work over 
Q instead of Z of course!

Apparently, Factory does have code to work over Z instead of Q, which could 
be called directly (after explicit conversion, sanity checking, etc). But 
note that the code in Factory for working over Z certainly gets less of a 
workout than the code over Q, so caveat emptor.

Apparently, one comment in my blog about Singular calling Factory for one 
of the commands I was issuing, is incorrect. I will correct this in my 
blog. We traced it through, and in fact I was using Singular functions only.

Bill.

On Monday, 10 July 2017 14:02:51 UTC+2, mmarco wrote:
>
> This is now #23395 
>
> El lunes, 10 de julio de 2017, 13:43:46 (UTC+2), mmarco escribió:
>>
>> If you used quo_rem, beware that Sage only uses Singular if the 
>> coefficient ring is a field. So if you define your polynomials over QQ 
>> instead of ZZ you will get timings similar to those of Singular. In the 
>> case of ZZ, it will do so with some generic python implementation of 
>> division.
>>
>> I guess we could rely on Singular also for the case of Integers.
>>
>> El lunes, 10 de julio de 2017, 12:48:55 (UTC+2), mmarco escribió:
>>>
>>> It is surprising the difference between singular and Sage, considering 
>>> that Sage mostly relies on Singular for multivariate polynomial arithmetic. 
>>> In the case of divisions, I suspect that it has to do with the fact that 
>>> Sage treats division of polynomials as an operation in the fraction field, 
>>> so it would construct the fraction, look for common factors in the 
>>> numerator and denominator, and cancel them. That is probably not what other 
>>> systems do.
>>>
>>> Which commands/instructions did you use in your benchmarks?
>>>
>>> El lunes, 10 de julio de 2017, 12:13:00 (UTC+2), Bill Hart escribió:

 The reason that I required the quotient as well in the divisibility 
 benchmark was that Magma does the n = 20 dense case in 0.15s otherwise, 
 and 
 I don't believe it is possible to do it that fast if you aren't doing it 
 heuristically, as I explained in the blog post. Therefore, all the systems 
 timed must return the quotient if the division is exact (which it is in 
 the 
 benchmark examples, since that is the hard case), so that Magma can't 
 possibly "cheat".

 As mentioned, if the various systems don't provide such a function, I 
 substituted divrem, since it is possible to look at the remainder to see 
 if 
 it was divisible, and then take the quotient as required by the benchmark.

 It is really hard to benchmark a bunch of systems against one another. 
 When I first timed Giac, I wasn't aware of a bunch of special parameters 
 you can pass to the Giac functions which make them run much faster. And 
 basically, there aren't many functions that all the systems happen to 
 implement with the same semantics, so I have to simulate what a user would 
 do if that is the semantics they want. I didn't do it to make Sage look 
 bad, honest!

 On Monday, 10 July 2017 12:05:28 UTC+2, Bill Hart wrote:
>
> 7.6
>
> On Monday, 10 July 2017 11:56:32 UTC+2, vdelecroix wrote:
>>
>> On 10/07/2017 09:34, Ralf Stephan wrote: 
>> > On Monday, July 10, 2017 at 8:55:23 AM UTC+2, vdelecroix wrote: 
>> >> 
>> >> He was certainly not using the awfully slow symbolic ring 
>> >> 
>> > 
>> > Then his slow timings for e.g. "Divisibility test with quotient 
>> (sparse)" 
>> > needs a different explanation. 
>>
>> Sage version? 
>>
>>

-- 
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: [ODK participants] Blog post on fast multivariate arithmetic

['Bill Hart' via sage-devel]

On Monday, 10 July 2017 13:31:26 UTC+2, vdelecroix wrote:
>
> On 10/07/2017 12:48, mmarco wrote: 
> > It is surprising the difference between singular and Sage, considering 
> that 
> > Sage mostly relies on Singular for multivariate polynomial arithmetic. 
> In 
> > the case of divisions, I suspect that it has to do with the fact that 
> Sage 
> > treats division of polynomials as an operation in the fraction field, so 
> it 
> > would construct the fraction, look for common factors in the numerator 
> and 
> > denominator, and cancel them. That is probably not what other systems 
> do. 
>
> Indeed, for (internal) division one should use // and not / 
>
> > Which commands/instructions did you use in your benchmarks? 
>

It looks like I used quo_rem, since you need both the quotient and whether 
or not it is divisible, for which you need the remainder.
 

>
> BTW, it would be good to have them in the post! 
>

It already says in the post that for systems that didn't provide the 
required function, I used quotient with remainder. 
 

-- 
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: [ODK participants] Blog post on fast multivariate arithmetic

['Bill Hart' via sage-devel]

The reason that I required the quotient as well in the divisibility 
benchmark was that Magma does the n = 20 dense case in 0.15s otherwise, and 
I don't believe it is possible to do it that fast if you aren't doing it 
heuristically, as I explained in the blog post. Therefore, all the systems 
timed must return the quotient if the division is exact (which it is in the 
benchmark examples, since that is the hard case), so that Magma can't 
possibly "cheat".

As mentioned, if the various systems don't provide such a function, I 
substituted divrem, since it is possible to look at the remainder to see if 
it was divisible, and then take the quotient as required by the benchmark.

It is really hard to benchmark a bunch of systems against one another. When 
I first timed Giac, I wasn't aware of a bunch of special parameters you can 
pass to the Giac functions which make them run much faster. And basically, 
there aren't many functions that all the systems happen to implement with 
the same semantics, so I have to simulate what a user would do if that is 
the semantics they want. I didn't do it to make Sage look bad, honest!

On Monday, 10 July 2017 12:05:28 UTC+2, Bill Hart wrote:
>
> 7.6
>
> On Monday, 10 July 2017 11:56:32 UTC+2, vdelecroix wrote:
>>
>> On 10/07/2017 09:34, Ralf Stephan wrote: 
>> > On Monday, July 10, 2017 at 8:55:23 AM UTC+2, vdelecroix wrote: 
>> >> 
>> >> He was certainly not using the awfully slow symbolic ring 
>> >> 
>> > 
>> > Then his slow timings for e.g. "Divisibility test with quotient 
>> (sparse)" 
>> > needs a different explanation. 
>>
>> Sage version? 
>>
>>

-- 
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: [ODK participants] Blog post on fast multivariate arithmetic

['Bill Hart' via sage-devel]

7.6

On Monday, 10 July 2017 11:56:32 UTC+2, vdelecroix wrote:
>
> On 10/07/2017 09:34, Ralf Stephan wrote: 
> > On Monday, July 10, 2017 at 8:55:23 AM UTC+2, vdelecroix wrote: 
> >> 
> >> He was certainly not using the awfully slow symbolic ring 
> >> 
> > 
> > Then his slow timings for e.g. "Divisibility test with quotient 
> (sparse)" 
> > needs a different explanation. 
>
> Sage version? 
>
>

-- 
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: [ODK participants] Blog post on fast multivariate arithmetic

['Bill Hart' via sage-devel]

Because it is "divisibility test with quotient", not "divisibility test". 
It is equivalent to calling Magma's "IsDivisibleBy" with two return 
arguments.

On Monday, 10 July 2017 09:34:39 UTC+2, Ralf Stephan wrote:
>
> On Monday, July 10, 2017 at 8:55:23 AM UTC+2, vdelecroix wrote:
>>
>> He was certainly not using the awfully slow symbolic ring 
>>
>
> Then his slow timings for e.g. "Divisibility test with quotient (sparse)" 
> needs a different explanation.
>

-- 
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.

[sage-devel] MPIR-3.0.0 released

['Bill Hart' via sage-devel]

Hi all,

We have just released MPIR-3.0.0.

http://mpir.org/

Note that you now need to have the latest yasm to build MPIR.

http://yasm.tortall.net/

To build yasm, download the tarball:

./configure
make

To test MPIR, download the tarball:

./configure --enable-gmpcompat --with-yasm=/path_to_yasm/yasm
make
make check

Major changes in MPIR-3.0.0 are:

* Separate yasm from MPIR build (use --with-yasm=/path_to_yasm/yasm with
MPIR's configure, or install yasm systemwide if you prefer)
* New Intel Skylake assembly support due to Jens Nurmann, Alex Kruppa and
GMP
* New Intel Haswell assembly support due to Alex Kruppa and GMP
* Rudimentary Broadwell support (no optimisation)
* Improved AMD Bulldozer support due to Alex Kruppa
* Faster mpz_powm, mpz_powm_ui from GMP
* New mpz_limbs functionality from GMP 6
* New mpn_sizeinbase, mullow_n_basecase, binvert, redc_1, redc_2, redc_n
functions from GMP
* New mpn_nsumdiff_n function (speeds up FFT on haswell)
* Visual Studio 2017 support due to Brian Gladman
* mpir.net for interface to .net languages due to Alex Dyachenko
* Appveyor-CI support
* GMP 6 compatibility
* Numerous bug fixes

Known issues with the 3.0.0 release:

* No Intel Broadwell optimisation [1]
* No Intel Kaby Lake support [2]
* No AMD Steamroller support [3]
* No AMD Excavator support [4]
* No ARM64 support [5]
* No ARM-UWP support [6]
* New GMP 6.1 functionality not fully supported [7, 8]
* Tuning values for many architectures missing [9]
* Fat binary not available on OSX [10]

As all MPIR funding has now run out, MPIR is again maintained by community
volunteers. Patches in the form of complete GitHub Pull Requests are very
welcome.

This release of MPIR was supported in part by the OpenDreamKit EU
Horizon2020 grant. In particular, Alex Best and Alex Kruppa wrote an
assembly superoptimiser which has been used to superoptimise for some of
the above architectures.

The main contributors to this release were:

   Alex Best, Alex Kruppa, Brian Gladman, Jens Nurmann, Alex Dyachenko, JP
   Flori, Isuru Fernando, William Hart

As usual we would also like to acknowledge the GMP developers for their
indirect contribution through the official GNU project, and numerous others
who submitted tuning values, bug fixes or bug reports, including:

   Tommy Hofmann, Averkhaturau, Marcell Keller, Sergey Taymanov, sav-ix
(Alexander), jengelh

Thanks to William Stein for providing access to a Bulldozer machine.

Bill.
[1] https://github.com/wbhart/mpir/issues/198
[2] https://github.com/wbhart/mpir/issues/199
[3] https://github.com/wbhart/mpir/issues/200
[4] https://github.com/wbhart/mpir/issues/201
[5] https://github.com/wbhart/mpir/issues/108
[6] https://github.com/wbhart/mpir/issues/177
[7] https://github.com/wbhart/mpir/issues/191
[8] https://github.com/wbhart/mpir/issues/190
[9] https://github.com/wbhart/mpir/issues/194
[10] https://github.com/wbhart/mpir/issues/212

-- 
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] fail to build mpir

['Bill Hart' via sage-devel]

The new MPIR fixes this and will be out by the 28th.

On Thursday, 23 February 2017 21:02:21 UTC+1, vdelecroix wrote:
>
> Thanks! Applying the patch it just went fine. 
>
> (I might create a relevant patch for Sage but we might migrate to the 
> newer mpir in preparation...) 
>
> On 23/02/2017 20:38, Isuru Fernando wrote: 
> > See 
> > 
> https://github.com/wbhart/mpir/commit/fdb590023f7ca4b2e881a2e9573718e7ed180f03
>  
> > 
> > Isuru Fernando 
> > 
> > On Fri, Feb 24, 2017 at 12:46 AM, Vincent Delecroix < 
> > 20100.d...@gmail.com > wrote: 
> > 
> >> Hello, 
> >> 
> >> I just installed archlinux on my laptop and I fail to compile mpir. 
> During 
> >> the configuration I had some weird message concerning sed. 
> >> 
> >> Any help welcome, 
> >> Vincent 
> >> 
> >> -- 
> >> 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.

[sage-devel] Re: Crash in smith_normal_form

['Bill Hart' via sage-devel]

Possibly, but it is only calling Flint for gcd, presumably over Z/nZ. It
could just as easily be a bug in Sage itself, calling Flint with invalid
data.

On 21 February 2017 at 16:59, Dima Pasechnik  wrote:

> Apparently it's a bug in Flint, no?
>
>
> On Tuesday, February 21, 2017 at 2:03:21 PM UTC, Clemens Heuberger wrote:
>>
>> Roswitha Rissner found a 25x26 matrix over GF(3)[x] such that calling
>> smith_form() leads to a crash:
>>
>> *** Error in `python': free(): invalid next size (normal):
>> 0x03ad4fe0 ***
>>
>> Input file as well as the full output are below.
>>
>> The mathematical problem itself does seem to be solvable: pari can handle
>> it.
>>
>> A1 = A.transpose().augment(vector(R, 26*[0])).transpose()
>> S = pari(A1).matsnf(3)
>> def to_sage(gen):
>> return matrix(R, [[R(entry) for entry in column] for column in
>> gen]).transpose()
>> U = to_sage(S[0])
>> V = to_sage(S[1])
>> D = to_sage(S[2])
>> assert U*A1*V == D
>> assert U.det() == 1
>> assert V.det() == 1
>> assert matrix.diagonal(D.diagonal()) == D
>>
>> Regards, Clemens
>>
>> 
>>
>> R. = GF(3)[]
>> A = matrix([[x^4 + x^3 + 2*x + 2, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [2*x^3 + x + 1, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [2*x^3 + 2*x + 2, 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [x^3 + x^2, 0, 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [x^3 + 2, 0, 0, 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [2*x^3 + 2*x^2, 0, 0, 0, 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [x^4 + x^3 + x^2 + x + 2, 0, 0, 0, 0, 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 +
>> 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [2*x^3 + x + 2, 0, 0, 0, 0, 0, 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [2*x^3 + x, 0, 0, 0, 0, 0, 0, 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [2*x^2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [x^3 + 2*x, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [2*x^3 + x^2 + 2*x + 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2*x^5 + x^4 +
>> 2*x^3 + x^2 + 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [x^4 + x + 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2*x^5 + x^4 + 2*x^3 +
>> x^2 + 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [x^3 + 2*x^2 + 2*x + 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2*x^5 +
>> x^4 + 2*x^3 + x^2 + 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [x^2 + 2*x, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2*x^5 + x^4 +
>> 2*x^3 + x^2 + 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [x^2 + 2*x + 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2*x^5 + x^4
>> + 2*x^3 + x^2 + 2, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [x^3 + 2*x^2 + 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2*x^5
>> + x^4 + 2*x^3 + x^2 + 2, 0, 0, 0, 0, 0, 0, 0, 0],
>>  [2*x^3 + 2*x^2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2*x^5
>> + x^4 + 2*x^3 + x^2 + 2, 0, 0, 0, 0, 0, 0, 0],
>>  [x^4 + 2*x^3 + 2*x^2 + 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0, 0, 0, 0, 0, 0],
>>  [x + 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2*x^5 +
>> x^4 + 2*x^3 + x^2 + 2, 0, 0, 0, 0, 0],
>>  [x^2 + x, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0, 0, 0, 0],
>>  [x^3 + x^2 + 2*x, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0, 0, 0],
>>  [2*x^3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0, 0],
>>  [x^2 + 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2, 0],
>>  [x^4 + x^3 + 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 2*x^5 + x^4 + 2*x^3 + x^2 + 2]])
>> A.smith_form()
>>
>> 
>>
>>
>> *** Error in `python': free(): invalid pointer: 0x0485b630 ***
>> === Backtrace: =
>> /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fb0d65da7e5]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x7fe0a)[0x7fb0d65e2e0a]
>> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fb0d65e698c]
>> /local/sage/sage-7.6.beta4/local/lib/libflint.so.13(_nmod_
>> poly_xgcd_hgcd+0x1baa)[0x7fb0c836787a]
>> /local/sage/sage-7.6.beta4/local/lib/libflint.so.13(nmod_poly_xgcd+0x14a)[0x7fb0c83604aa]
>>
>> /local/sage/sage-7.6.beta4/local/lib/python2.7/site-packages
>> /sage/rings/polynomial/polynomial_zmod_flint.so(+0xf147)[0x7fafa7c69147]
>> /local/sage/sage-7.6.beta4/l

[sage-devel] MPIR-3.0.0-rc1 released

['Bill Hart' via sage-devel]

Hi all,

We have just released MPIR-3.0.0-rc1. If no issues are reported with this
release candidate by 28th Feb, we will make it the final MPIR-3.0.0 release.

The only changes since the last alpha were additional Broadwell CPUs
supported, which should only affect you if your Broadwell chip was
misidentified.

Download MPIR-3.0.0-rc1 from:

http://mpir.org/

Note that you now need to have the latest yasm to build MPIR.

http://yasm.tortall.net/

To build yasm, download the tarball:

./configure
make

To test MPIR, download the tarball:

./configure --enable-gmpcompat --with-yasm=/path_to_yasm/yasm
make
make check

Major changes in MPIR-3.0.0 are:

* Separate yasm from MPIR build (use --with-yasm=/path_to_yasm/yasm with
MPIR's configure, or install yasm systemwide if you prefer)
* New Intel Skylake assembly support due to Jens Nurmann, Alex Kruppa and
GMP
* New Intel Haswell assembly support due to Alex Kruppa and GMP
* Rudimentary Broadwell support (no optimisation)
* Improved AMD Bulldozer support due to Alex Kruppa
* Faster mpz_powm, mpz_powm_ui from GMP
* New mpz_limbs functionality from GMP 6
* New mpn_sizeinbase, mullow_n_basecase, binvert, redc_1, redc_2, redc_n
functions from GMP
* New mpn_nsumdiff_n function (speeds up FFT on haswell)
* Visual Studio 2017 support due to Brian Gladman
* mpir.net for interface to .net languages due to Alex Dyachenko
* Appveyor-CI support
* GMP 6 compatibility
* Numerous bug fixes

Known issues with the 3.0.0 release:

* No Intel Broadwell optimisation (it is now being worked on for MPIR-3.1.0)
* No Intel Kaby Lake support
* No AMD Steamroller support
* No AMD Excavator support
* No ARM64 support
* No ARM-UWP support
* New GMP 6.1 functionality not fully supported
* Tuning values for many architectures missing

As all MPIR funding has now run out, MPIR is again maintained by community
volunteers. Patches in the form of complete GitHub Pull Requests are very
welcome.

This release of MPIR was supported in part by the OpenDreamKit EU
Horizon2020 grant. In particular, Alex Best and Alex Kruppa wrote an
assembly superoptimiser which has been used to superoptimise for some of
the above architectures.

The main contributors to this release were:

   Alex Best, Alex Kruppa, Brian Gladman, Jens Nurmann, Alex Dyachenko, JP
   Flori, Isuru Fernando, William Hart

As usual we would also like to acknowledge the GMP developers for their
indirect contribution through the official GNU project, and numerous others
who submitted tuning values, bug fixes or bug reports. Other contributors
to this release include:

   Tommy Hofmann, Averkhaturau, Marcell Keller, Sergey Taymanov, sav-ix
(Alexander)

Thanks to William Stein for providing access to a Bulldozer machine.

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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Updated job advertisement

['Bill Hart' via sage-devel]

Hi all,

We have decided to change the requirements for the ~2.5 year mathematical
software developer job opening we have at TU Kaiserslautern.

The main changes are to the type of person we are seeking. It now says we
are interested in candidates with an interest in either:

   * algebra or number theory or algebraic geometry,
   * fast arithmetic; or
   * the design and development of computer algebra systems

Note that the requirement for this position is a Masters degree, but the
position could also possibly be used as a postdoc.

Full details on the position, requirements and how to apply, are available
here [1].

Bill.

[1] http://opendreamkit.org/2016/12/15/developer-position-kaiserslautern/

-- 
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.

[sage-devel] MPIR 3.0.0 alpha2 released

['Bill Hart' via sage-devel]

Hi all,

MPIR-3.0.0-alpha2 has now been released. This adds support for MinGW and
MSVC 2013, 2015 and 2017. There are no changes to the Linux build, except
slightly better tuning for Broadwell.

We plan to start doing release candidates (for Linux, at least) early next
week, with a final release at the end of the month. Download
MPIR-3.0.0-alpha from:

http://mpir.org/

Note that you now need to have the latest yasm to build MPIR.

http://yasm.tortall.net/

To build yasm, download the tarball:

./configure
make

To test MPIR, download the tarball:

./configure --enable-gmpcompat --with-yasm=/path_to_yasm/yasm
make
make check

Major changes in MPIR-3.0.0 are:

* Separate yasm from MPIR build (use --with-yasm=/path_to_yasm/yasm with
MPIR's configure, or install yasm systemwide if you prefer)
* New Intel Skylake assembly support due to Jens Nurmann, Alex Kruppa and
GMP
* New Intel Haswell assembly support due to Alex Kruppa and GMP
* Rudimentary Broadwell support (no optimisation)
* Improved AMD Bulldozer support due to Alex Kruppa
* Faster mpz_powm, mpz_powm_ui from GMP
* New mpz_limbs functionality from GMP 6
* New mpn_sizeinbase, mullow_n_basecase, binvert, redc_1, redc_2, redc_n
functions from GMP
* New mpn_nsumdiff_n function (speeds up FFT on haswell)
* Visual Studio 2017 support due to Brian Gladman
* mpir.net for interface to .net languages due to Alex Dyachenko
* Appveyor-CI support
* GMP 6 compatibility
* Numerous bug fixes

Known issues with the 3.0.0 release:

* No Intel Broadwell optimisation
* No Intel Kaby Lake support
* No AMD Steamroller support
* No AMD Excavator support
* No ARM64 support
* No ARM-UWP support
* New GMP 6.1 functionality not fully supported
* Tuning values for many architectures missing
* OSX 10.11 and above not supported (due to disabling of DYLD_LIBRARY_PATH)

As all MPIR funding has now run out, MPIR is again maintained by community
volunteers. Patches in the form of complete GitHub Pull Requests are very
welcome.

This release of MPIR was supported in part by the OpenDreamKit EU
Horizon2020 grant. In particular, Alex Best and Alex Kruppa wrote an
assembly superoptimiser which has been used to superoptimise for some of
the above architectures.

The main contributors to this release were:

   Alex Best, Alex Kruppa, Brian Gladman, Jens Nurmann, Alex Dyachenko, JP
   Flori, Isuru Fernando, William Hart

As usual we would also like to acknowledge the GMP developers for their
indirect contribution through the official GNU project, and numerous others
who submitted tuning values, bug fixes or bug reports. Other contributors
to this release include:

   Tommy Hofmann, Averkhaturau, Marcell Keller, Sergey Taymanov, sav-ix
(Alexander)

Thanks to William Stein for providing access to a Bulldozer machine.

Bill Hart.

-- 
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: Groebner basis (rounding?) bug

['Bill Hart' via sage-devel]

I asked Hans Schoenemann about this. Whilst Singular does support doing 
Groebner bases over inexact fields, there is no error checking and so this 
is not considered useful. It's only there for people who want to run the 
computation and examine the output themselves and see if they think it is 
meaningful. If not, they can increase the precision and try again.

We are aware that other techniques exist, such as working with interval 
arithmetic, or working with both a floating point approximation _and_ a mod 
p representation (and if the value is less than epsilon, check if the mod p 
value is zero). However, Singular does not currently implement these 
methods.

I hope this answers the question. If not, please let me know and I'll ask 
Hans some more about this.

I personally wonder whether it might be possible to do this computation 
using Arb as the coefficient field, which Singular should support, with 
some effort.

Bill.

On Friday, 17 February 2017 12:01:23 UTC+1, Dima Pasechnik wrote:
>
>
>
> On Friday, February 17, 2017 at 4:51:49 AM UTC, john_perry_usm wrote:
>>
>> On Thursday, February 16, 2017 at 1:46:18 AM UTC-6, Dima Pasechnik wrote:
>>>
>>>
>>>
>>> On Thursday, February 16, 2017 at 6:59:04 AM UTC, William wrote:

 **Disclaimer: I consider myself very naive about computational 
 commutative algebra, especially with floating point numbers.  Dima, 
 thanks for answering the question, but I think you are maybe jumping 
 to wronc conclusions. See below. ** 
 ...
>>>
>>>
 Just because you think it's nuts to use floating point numbers in the 
 context of commutative algebra doesn't mean it is...   It's a whole 
 research area, e.g., 

 http://link.springer.com/chapter/10.1007/978-3-540-87827-8_23 

>>>
>>> a paper from 2008 with one citation and one self-citation is not a 
>>> "whole research area", come on...
>>>
>>
>> Okay, how about this:
>>
>> http://www.springer.com/us/book/9783211993132
>>
>> http://www.sciencedirect.com/science/article/pii/S0378475496000274
>>
>> http://link.springer.com/chapter/10.1007/978-3-662-43799-5_10
>>
>>
>> http://library.wolfram.com/infocenter/Conferences/7536/ApproximateGroebnerBases.pdf
>>
>> http://hal.upmc.fr/hal-01336590v1
>>
>>
>> http://www.risc.jku.at/publications/download/risc_273/Nr.7_paper-revised.pdf
>>
>> http://dl.acm.org/citation.cfm?doid=258726.258763
>>
>> DOI 10.1145/780506.780540 
>>
>> I don't mean to quibble with the underlying premise that Gröbner bases 
>> may not be the best tool with approximate coefficients, and yes, maybe 
>> William should have given a better reference, but come on, when you see 
>> names like Faugère, Kreuzer, Lichtblau, Robbiano, and Traverso publishing 
>> on the topic, it's kind of hard to deny it's a whole research area. (I 
>> leave Sasaki out of that list only because he doesn't seem to impress Dima, 
>> but my understanding is that Sasaki is an expert on the topic -- he 
>> certainly gave a great talk on it at ISSAC'11.)
>>
>
> I agree that I have missed a large part of this floating point Groebner 
> bases activity, sorry. 
> However, note that most of these references are  5+-10+ years old, or not 
> really Groebner basis-only things. 
> Approximate commutative algebra/polynomial system solving has largely 
> moved onto greener pastures (numerical homotopy methods and sums of squares 
> based methods), leaving behind systems that cannot correctly compute 
> Groebner basis even in semi-trivial cases:
> https://trac.sagemath.org/ticket/22387#comment:2
>
> Dima
>  
>
>>
>> john perry
>>
>

-- 
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.

[sage-devel] MPIR 3.0.0-alpha release (Linux testers needed)

['Bill Hart' via sage-devel]

Hi all,

We have released mpir-3.0.0-alpha1 to give people the opportunity to report
any issues on Linux before we start issuing release candidates.

N.B: this alpha release is Linux only! We will issue an alpha with
MSVC/MinGW support as soon as the Windows build files are finalised.

N.B: when testing MPIR on Linux, if the first line of ./configure shows
that your machine is detected as x86_64 or something old like core2 or k8,
then your machine probably isn't supported and MPIR will run very slowly!

We plan to start doing release candidates (for Linux, at least) early next
week, with a final release at the end of the month. Download
MPIR-3.0.0-alpha from:

http://mpir.org/

Note that you now need to have the latest yasm to build MPIR.

http://yasm.tortall.net/

To build yasm, download the tarball:

./configure
make

To test MPIR, download the tarball:

./configure --enable-gmpcompat --with-yasm=/path_to_yasm/yasm
make
make check

Major changes in MPIR-3.0.0 are:

* Separate yasm from MPIR build (use --with-yasm=/path_to_yasm/yasm with
MPIR's configure, or install yasm systemwide if you prefer)
* New Intel Skylake assembly support due to Jens Nurmann, Alex Kruppa and
GMP
* New Intel Haswell assembly support due to Alex Kruppa and GMP
* Rudimentary Broadwell support (no optimisation)
* Improved AMD Bulldozer support due to Alex Kruppa
* Faster mpz_powm, mpz_powm_ui from GMP
* New mpz_limbs functionality from GMP 6
* New mpn_sizeinbase, mullow_n_basecase, binvert, redc_1, redc_2, redc_n
functions from GMP
* New mpn_nsumdiff_n function (speeds up FFT on haswell)
* Visual Studio 2017 support due to Brian Gladman
* mpir.net for interface to .net languages due to Alex Dyachenko
* Appveyor-CI support
* GMP 6 compatibility
* Numerous bug fixes

Known issues with the 3.0.0 release:

* No Intel Broadwell optimisation
* No Intel Kaby Lake support
* No AMD Steamroller support
* No AMD Excavator support
* No ARM64 support
* No ARM-UWP support
* New GMP 6.1 functionality not fully supported
* Tuning values for many architectures missing

As all MPIR funding has now run out, MPIR is again maintained by community
volunteers. Patches in the form of complete GitHub Pull Requests are very
welcome.

This release of MPIR was supported in part by the OpenDreamKit EU
Horizon2020 grant. In particular, Alex Best and Alex Kruppa wrote an
assembly superoptimiser which has been used to superoptimise for some of
the above architectures.

The main contributors to this release were:

   Alex Best, Alex Kruppa, Brian Gladman, Jens Nurmann, Alex Dyachenko, JP
   Flori, Isuru Fernando, William Hart

As usual we would also like to acknowledge the GMP developers for their
indirect contribution through the official GNU project, and numerous others
who submitted tuning values, bug fixes or bug reports. Other contributors
to this release include:

   Tommy Hofmann, Averkhaturau, Marcell Keller, Sergey Taymanov, sav-ix
(Alexander)

Thanks to William Stein for providing access to a Bulldozer machine.

Bill Hart.

-- 
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.

[sage-devel] Re: [mpir-devel] Re: Tuning values needed for MPIR (help needed)

['Bill Hart' via sage-devel]

Thanks very much! I'll insert these today. I'll attach the broadwell ones
to a ticket, until someone can sort out the configuration for that system.
There are probably numerous cpuid family/model pairs that correspond to
Broadwell, so we'll have to add these as they become known.

On 14 February 2017 at 10:24, Isuru Fernando  wrote:

> Attached are tuning values for nehalem, ivybridge, broadwell and skylake.
> (Also cpuinfo for the broadwell one)
>
> Isuru Fernado
>
> On Tue, Feb 14, 2017 at 1:29 PM, 'Bill Hart' via mpir-devel <
> mpir-de...@googlegroups.com> wrote:
>
>> Apparently if you have a very recent machine, yasm may fail to build the
>> assembly files for your architecture. To get around this, install the
>> latest yasm [1] and use MPIR's --with-system-yasm option.
>>
>> If your system is recent and detects as core2 or k8 or simply x86_64 or
>> something else obviously out-of-date, when tuning, please also send us a
>> copy of cat /proc/cpuinfo so we can add support for your processor to MPIR.
>>
>> Bill.
>>
>> [1] http://yasm.tortall.net/
>>
>> On 13 February 2017 at 18:41, Bill Hart 
>> wrote:
>>
>>> Hi all,
>>>
>>> MPIR has been modified recently, and new tuning crossovers have been
>>> added.
>>>
>>> If you have a machine that you want MPIR to run fast on, we would really
>>> appreciate help getting tuning values for your machine. Here is how.
>>>
>>> git clone https://github.com/wbhart/mpir
>>> cd mpir
>>> ./configure --enable-gmpcompat
>>> make -j4
>>> make check
>>> cd tune
>>> make tune
>>>
>>> Please attach the tuning values that are printed to this post. Please
>>> ensure that the first line is not missing, e.g.
>>>
>>>Parameters for ./mpn/x86_64/k8/k10/k102/gmp-mparam.h
>>>
>>> as this tells us what machine the values are for.
>>>
>>> If the tuning program crashes, or starts to take too long, just send us
>>> the values you have.
>>>
>>> Any help that people can provide is really appreciated.
>>>
>>> Note that we DON'T require tuning values for the following arches:
>>>
>>> mpn/x86_64/k8/k10/k102
>>> mpn/x86_64/haswell
>>>
>>> If someone already attached values for your arch, no need to supply them
>>> again.
>>>
>>> Bill.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mpir-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mpir-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to mpir-de...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/mpir-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-de...@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-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.

[sage-devel] Re: Tuning values needed for MPIR (help needed)

['Bill Hart' via sage-devel]

Apparently if you have a very recent machine, yasm may fail to build the
assembly files for your architecture. To get around this, install the
latest yasm [1] and use MPIR's --with-system-yasm option.

If your system is recent and detects as core2 or k8 or simply x86_64 or
something else obviously out-of-date, when tuning, please also send us a
copy of cat /proc/cpuinfo so we can add support for your processor to MPIR.

Bill.

[1] http://yasm.tortall.net/

On 13 February 2017 at 18:41, Bill Hart  wrote:

> Hi all,
>
> MPIR has been modified recently, and new tuning crossovers have been added.
>
> If you have a machine that you want MPIR to run fast on, we would really
> appreciate help getting tuning values for your machine. Here is how.
>
> git clone https://github.com/wbhart/mpir
> cd mpir
> ./configure --enable-gmpcompat
> make -j4
> make check
> cd tune
> make tune
>
> Please attach the tuning values that are printed to this post. Please
> ensure that the first line is not missing, e.g.
>
>Parameters for ./mpn/x86_64/k8/k10/k102/gmp-mparam.h
>
> as this tells us what machine the values are for.
>
> If the tuning program crashes, or starts to take too long, just send us
> the values you have.
>
> Any help that people can provide is really appreciated.
>
> Note that we DON'T require tuning values for the following arches:
>
> mpn/x86_64/k8/k10/k102
> mpn/x86_64/haswell
>
> If someone already attached values for your arch, no need to supply them
> again.
>
> 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds

['Bill Hart' via sage-devel]

I can only answer one of your questions.

On Saturday, 11 February 2017 17:16:29 UTC+1, Jakob Kroeker wrote:
>
> By default, Singular uses 16 bit exponents. But it is perfectly capable of 
>> working with exponents up to 64 bits. That will be slower of course.
>>
>
> How to change this? Is it runtime or compile-time?
>

I believe it can be set at runtime. Hans surely knows how to change it.
 

> Is it transparent for overflow detection?
>

I don't understand the question.
 

>
> I guess it isn't easy for Sage to change the relevant ring upon overflow 
>> to one using 64 bit exponents.
>>
>
> I have no idea;
>
> Jakob
>

-- 
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.

[sage-devel] Tuning values needed for MPIR (help needed)

['Bill Hart' via sage-devel]

Hi all,

MPIR has been modified recently, and new tuning crossovers have been added.

If you have a machine that you want MPIR to run fast on, we would really
appreciate help getting tuning values for your machine. Here is how.

git clone https://github.com/wbhart/mpir
cd mpir
./configure --enable-gmpcompat
make -j4
make check
cd tune
make tune

Please attach the tuning values that are printed to this post. Please
ensure that the first line is not missing, e.g.

   Parameters for ./mpn/x86_64/k8/k10/k102/gmp-mparam.h

as this tells us what machine the values are for.

If the tuning program crashes, or starts to take too long, just send us the
values you have.

Any help that people can provide is really appreciated.

Note that we DON'T require tuning values for the following arches:

mpn/x86_64/k8/k10/k102
mpn/x86_64/haswell

If someone already attached values for your arch, no need to supply them
again.

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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.