[sage-devel] [ANN] Flint 2.9 Released

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

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

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

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

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

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

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

[sage-devel] Flint 2.8.4 Released

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

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

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

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

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 an

[sage-devel] Re: Flint 2.8.2 Released

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

[sage-devel] Flint 2.8.1 Released

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

[sage-devel] Flint-2.8.0 Released!

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

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

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

[sage-devel] Flint-2.8.0 Beta testing

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

[sage-devel] Flint 2.7.1 released

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]

[sage-devel] Flint 2.7.0 Released!

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

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

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

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

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

[sage-devel] Flint 2.7.0 release candidate 1

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)

[sage-devel] [ANN] Flint 2.6.3 released

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

[sage-devel] [ANN] Flint 2.6.2 released

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

[sage-devel] Flint 2.6.0 Released!

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

[sage-devel] Re: Flint 2.6.0-rc1

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

[sage-devel] Re: Flint 2.6.0-rc1

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

[sage-devel] Re: Flint 2.6.0-rc1

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

[sage-devel] Flint 2.6.0-rc1

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

>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

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

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

Re: [sage-devel] NTL 11.3.4

[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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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]

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

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

[sage-devel] MPIR community repository

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

[sage-devel] Re: zn_poly status?

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

[sage-devel] Re: zn_poly status?

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

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

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] Re: NTL 11.2.0

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

[sage-devel] Re: NTL 11.2.0

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

[sage-devel] Suggestion for the SageMath website

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

Re: [sage-devel] problem building mpir

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

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

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

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

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

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

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

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

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

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

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

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

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]

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

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]

[sage-devel] Re: Some polynomial timings

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

Re: [sage-devel] Unable to compile 8.0.rc2 on mac

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

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

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.

Re: [sage-devel] Unable to compile 8.0.rc2 on mac

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_medium=notification On Wednesday, 19 July 2017

Re: [sage-devel] Unable to compile 8.0.rc2 on mac

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

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

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

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

ent 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

[sage-devel] MPIR-3.0.0 released

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

Re: [sage-devel] fail to build mpir

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

[sage-devel] Re: Crash in smith_normal_form

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,

[sage-devel] MPIR-3.0.0-rc1 released

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

[sage-devel] Updated job advertisement

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

[sage-devel] MPIR 3.0.0 alpha2 released

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

Re: [sage-devel] Re: Groebner basis (rounding?) bug

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

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

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

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

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

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

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

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

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

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

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

  1   2   3   >