[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

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

[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

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 invol

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

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 re

[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

[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

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 o

[sage-devel] Re: Flint 2.6.0-rc1

, 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

[sage-devel] Re: Flint 2.6.0-rc1

[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

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

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

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 arithm

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

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 ca

[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

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 regi

[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

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

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

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

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

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

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

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

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

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 thr

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

t. [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? Micka

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

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

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

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

[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

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 cer

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

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 m

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

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

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

m 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

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

(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

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)

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,

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

2017 at 10:24, Isuru Fernando <isu...@gmail.com> 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

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

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 <goodwillh...@googlemail.com> wrote: > Hi all, > > MPIR has been modified re

[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   4   5   6   7   8   9   10   >