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,
>
>   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+...@googlegroups.com .
>> To post to this group, send email to sage-...@googlegroups.com 
>> .
>> Visit this group at 

[sage-devel] Re: Bug in groebner_basis()?

[Simon King]

Hi Daniel,

On 2017-07-14, Daniel Krenn  wrote:
>>> R. = PolynomialRing(QQ, 'lex')
>> That's not what you want.
>> [...]
>> Instead you have to do
>>   sage: R. = PolynomialRing(QQ, order='lex')
>> (i.e., specify what parameter is 'lex' being assigned to)
>
> What does the polynomial ring constructor do with the 'lex' in the first
> example? Why is no error raised?

The preparser translates it into
  R = PolynomialRing(QQ, 'lex', names=('x', 'y',)); (x, y,) = R._first_ngens(2)

And we have the following function head:
def PolynomialRing(base_ring, arg1=None, arg2=None,
   sparse=False, order='degrevlex',
   names=None, name=None,
   var_array=None,
   implementation=None):

So, "lex" ends up in "arg1". Unfortunately, the documentation of
the PolynomialRing constructor is not very clear about what happens
with arg1. But in the source code, I find that arg1 is used to override the
parameter `name` (not `names`). However it seems that if both `name` and `names`
is present then the value of `name` has no effect. Let's try:

  sage: PolynomialRing(QQ, name='lex', names=('x','y'))
  Multivariate Polynomial Ring in x, y over Rational Field
  sage: _.term_order()
  Degree reverse lexicographic term order

Cheers,
Simon


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

Re: [sage-devel] Re: Bug in groebner_basis()?

[Daniel Krenn]

On 2017-07-14 16:41, Simon King wrote:
> On 2017-07-14, Johannes Schwab  wrote:
>> Here is the code:
>> R. = PolynomialRing(QQ, 'lex')
> That's not what you want.
> [...]
> Instead you have to do
>   sage: R. = PolynomialRing(QQ, order='lex')
> (i.e., specify what parameter is 'lex' being assigned to)

What does the polynomial ring constructor do with the 'lex' in the first
example? Why is no error raised?

-- 
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: Bug in groebner_basis()?

[Simon King]

Hi Johannes,

On 2017-07-14, Johannes Schwab  wrote:
> Here is the code:
> R. = PolynomialRing(QQ, 'lex')

That's not what you want.
  sage: R.term_order()
  Degree reverse lexicographic term order

Instead you have to do
  sage: R. = PolynomialRing(QQ, order='lex')
(i.e., specify what parameter is 'lex' being assigned to)

And then you'll get the correct result:
  sage: f = x^2 + 2*y
  sage: g = x*y - y^2 + 1
  sage: I = [f,g]*R
  sage: I.groebner_basis()
  [x - y^3 - 2*y^2 + y, y^4 + 2*y^3 - 2*y^2 + 1]

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-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] Bug in groebner_basis()?

[Johannes Schwab]

Hello,

I think I stumbled across a bug in groebner_basis(). The example below 
doesn't generate the unique reduced Groebner basis of the ideal generated 
by f and g, but instead the set 

[y^3 + 2*y^2 - x - y, x^2 + 2*y, x*y - y^2 + 1]
is returned.

This set isn't a Groebner basis at all. The correct basis should be
[1 - 2*y^2 + 2*y^3 + y^4, x + y - 2*y^2 - y^3]
.

Here is the code:
R. = PolynomialRing(QQ, 'lex')
f = x^2 + 2*y
g = x*y - y^2 + 1
I = ideal([f,g])
print I.groebner_basis()

I tested it with version 6.7, 8.0.rc1 and on sagecell.sagemath.org and with 
different algorithms as argument to groebner_basis(), the result is always the 
same.

Is this a bug, or do I have some stupid error in my code?

Regards,
Johannes

-- 
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 installing OpenBlas on Linux Mint

[Christopher Phoenix]

I had the same issue with openblas, but on a Thinkpad 11e with an intel 
Celeron N2940 processor. Setting OPENBLAS_CONFIGURE="TARGET=ATOM" fixed 
this for me as well.  
https://groups.google.com/d/msg/sage-devel/-Exvx0bane8/9kC8hBEFBwAJ

I assumed this was limited to lower-end processors like the Celeron, but 
since you are on an i7 I guess not! I wonder if there is anything we can do 
to help improve the CPU detection issues? At any rate it's pretty easy to 
fix once you know to set the cpu TARGET variable manually.

On Saturday, July 1, 2017 at 11:02:33 AM UTC-7, Gabriel Lipnik wrote:
>
> Hey!
>
> I wanted to install Sage and got an error message while installing 
> OpenBlas. Here's the log file, can someone help me?
>
>
>

-- 
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 building Sage on UM 16.04: error making OpenBLAS

[Christopher Phoenix]

Well, I have successfully built Sage on my 11e—over a period of several 
hours! :-) Right now I'm running the tests with ./sage --testall to make 
sure everything is a-ok, but cli Sage starts, as does the notebook, so it 
looks good so far.

Maybe I'll try building the dev version of openblas on this hardware later, 
but I'm not really sure what to do to test it once it does build. This was 
my first time building a big program from source, so I'm still getting used 
to it all. It would be interesting to see if this detection issue with 
lower-end x86-64 cpus continues in the dev version. 

On Friday, July 14, 2017 at 12:25:57 AM UTC-7, Dima Pasechnik wrote:
>
> Indeed, OPENBLAS_CONFIGURE="TARGET=ATOM" is a catch-all x86_64 processors 
> target.
> Perhaps one can try the development version of openblas on these processors
> (from https://github.com/xianyi/OpenBLAS)
>
> On Friday, July 14, 2017 at 12:29:12 AM UTC+1, Christopher Phoenix wrote:
>>
>> I'm building Sage 7.6 on my laptop, and there was an error making 
>> openblas that directed me to the log files for that package. The log file 
>> said that detecting CPU failed, and to set TARGET explicitly. It also 
>> suggested I email this google group to explain the problem, with the 
>> relevant part of the log files. So I've attached it below. 
>>
>> OS: Ubuntu Mate 16.04 LTS
>> Sage Version: 7.6
>> HW: Lenovo Thinkpad 11e, 500gb HD, 4 gb ram, Intel Celeron N2940 with 4 
>> cpu cores
>>
>> Before the build, I made sure that I had all the listed dependencies and 
>> suggested packages already installed. Then I cloned the Git repo, set 
>> MAKE='make -j5 -4' and typed make. Make ran for about 45 min or more before 
>> it stopped and reported the error. I asked about this issue on sage-support 
>> earlier (https://groups.google.com/forum/#!topic/sage-support/NlRyew12xDQ
>> ).
>>
>> Someone had the same issue on very similar hardware (another 11e) here: 
>> https://groups.google.com/d/msg/sage-devel/zQsZsivts0I/cblwvEkNDgAJ The 
>> log files look almost exactly the same. They reported that setting 
>> OPENBLAS_CONFIGURE="TARGET=ATOM" resolved this cpu detection issue, so I'm 
>> going to try setting this and building Sage again later today. I was a 
>> little confused since a Celeron is not an Atom afaik, I'm guessing this is 
>> a catch-all setting for lower-end processors?
>>
>> Any advice will be greatly appreciated!
>>
>

-- 
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] Two issues about the coding theory method "weight_enumerator"

[David Joyner]

On Fri, Jul 14, 2017 at 5:35 AM, Johan S. H. Rosenkilde
 wrote:
> Thanks a lot for reporting! We *really* appreciate any feedback from
> using Sage in classes: on bugs, designs and feature requests.
>
> This bug is now #23433. I'll push a patch momentarily.
>

Thank you, Johan!

> Best,
> Johan Rosenkilde
>
>

...

>>>
>>> This mistake could be my fault, since I wrote the original version
>>> (long long ago). Unfortunately, I lack the git skills to submit a
>>> patch.
>>>

...

-- 
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] Two issues about the coding theory method "weight_enumerator"

[Johan S . H . Rosenkilde]

Thanks a lot for reporting! We *really* appreciate any feedback from
using Sage in classes: on bugs, designs and feature requests.

This bug is now #23433. I'll push a patch momentarily.

Best,
Johan Rosenkilde


Dima Pasechnik writes:

> On Thursday, July 13, 2017 at 11:43:18 AM UTC+1, David Joyner wrote:
>>
>> On Thu, Jul 13, 2017 at 5:59 AM, 'B. L.' via sage-devel 
>>  wrote: 
>> > Dear Sage-Developers, 
>> > 
>> > I'd like to report two issues that I came across when working with the 
>> > coding theory classes of SAGE. 
>> > 
>> > The Sage Reference Manual: Coding Theory, Release 7.6 [1] explains on p. 
>> 31: 
>> > weight_enumerator [...] This is the bivariate, homogeneous polynomial in 
>> 푥 
>> > and 푦 whose coefficient to x^iy^{n-i} is the number of codewords of 
>> > 푠푒푙푓 of Hamming weight 푖. Here, 푛 is the length of 푠푒푙푓. 
>> > Actually, Sage returns another polynomial, namely the polynomial in 푥 
>> and 
>> > 푦 whose coefficient to x^{n-i}y^i is the number of codewords of 
>> 푠푒푙푓 of 
>> > Hamming weight 푖. (So the roles of x and y are interchanged). 
>> > This can be directly with C.weight_enumerator?? in the example below 
>> [2]. 
>> > 
>> > I suggest to either change the description in the reference or to alter 
>> the 
>> > code in Sage. 
>> > 
>>
>> I'd propose just switching the x,y in the code: 
>>
>> (1) On line 3503 of linear_code.py, change "return 
>> sum(spec[i]*x**(n-i)*y**i for i in range(n+1))" to "return 
>> sum(spec[i]*x**(i)*y**(n-i) for i in range(n+1))" 
>>
>> (2) On line 3507, change "return sum(spec[i]*x**(n-i) for i in 
>> range(n+1))" to "return sum(spec[i]*x**(i) for i in range(n+1))" 
>>
>> (3) Some of the examples may change accordingly. 
>>
>> This mistake could be my fault, since I wrote the original version 
>> (long long ago). Unfortunately, I lack the git skills to submit a 
>> patch. 
>>
>> A patch can be produced by
>
> git diff > stuff.patch
>
> It would be great if you opened a ticket and posted this diff as an 
> attachment...
>  
>  
>
>>
>> > The function weight_enumerator(bivariate=False) returns the evaluation 
>> of 
>> > the the above polynomial for y=1. Should't it be (in the current 
>> version) 
>> > the evaluation with x=1? In other words: Wouldn't one expect a 
>> polynomial in 
>> > x (or y) whose coefficient to x^i (or y^i) is the number of codewords of 
>> > 푠푒푙푓 of Hamming weight 푖? 
>> > The example below [2] illustrates my point: The code has four codewords, 
>> one 
>> > of weight 0, two of weight 3, one of weiht 4. Sage gives x^5 + 2*x^2 + x 
>> as 
>> > the univariate weight enumerator. I would have expected either 1 + 2*x^3 
>> + 
>> > x^4 or 1 + 2*y^3 + y^4. 
>> > 
>> > If you agree, I suggest to alter the code accordingly. 
>> > 
>> > Kind regards 
>> > Barbara 
>> > PS: I tested the code with Sage version 7.6 on an iMac. 
>> > 
>> > 
>> > [1] http://doc.sagemath.org/pdf/en/reference/coding/coding.pdf 
>> > 
>> > [2] Sage code for  the SageMathCell 
>> > 
>> > C= LinearCode(Matrix(GF(2),2,5, [[1,1,0,1,0], [0,0,1,1,1]])) 
>> > print C.list() 
>> > print C.spectrum() 
>> > print C.weight_enumerator() 
>> > print C.weight_enumerator(bivariate=False) 
>> > C.weight_enumerator?? 
>> > 
>> > 
>> http://sagecell.sagemath.org/?z=eJxztlXwycxLTSxyzk9J1fBNLCnKrNBwd9Mw0tQx0jHVUYiONtQx1DEA4VggzwDMBMLYWE1NXq6Cosy8EgVnvZzM4hINJH5xQWpySVFpLrJYeWpmekZJfGpeaW5qUWJJfhF-yaTMssSizMSSVFu3xJziVKBaLKrs7QGIgD2K=sage
>>  
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "sage-devel" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to sage-devel+unsubscr...@googlegroups.com. 
>> > To post to this group, send email to sage-devel@googlegroups.com. 
>> > Visit this group at https://groups.google.com/group/sage-devel. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>

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

Re: [sage-devel] Two issues about the coding theory method "weight_enumerator"

[Dima Pasechnik]

On Thursday, July 13, 2017 at 11:43:18 AM UTC+1, David Joyner wrote:
>
> On Thu, Jul 13, 2017 at 5:59 AM, 'B. L.' via sage-devel 
>  wrote: 
> > Dear Sage-Developers, 
> > 
> > I'd like to report two issues that I came across when working with the 
> > coding theory classes of SAGE. 
> > 
> > The Sage Reference Manual: Coding Theory, Release 7.6 [1] explains on p. 
> 31: 
> > weight_enumerator [...] This is the bivariate, homogeneous polynomial in 
> 푥 
> > and 푦 whose coefficient to x^iy^{n-i} is the number of codewords of 
> > 푠푒푙푓 of Hamming weight 푖. Here, 푛 is the length of 푠푒푙푓. 
> > Actually, Sage returns another polynomial, namely the polynomial in 푥 
> and 
> > 푦 whose coefficient to x^{n-i}y^i is the number of codewords of 
> 푠푒푙푓 of 
> > Hamming weight 푖. (So the roles of x and y are interchanged). 
> > This can be directly with C.weight_enumerator?? in the example below 
> [2]. 
> > 
> > I suggest to either change the description in the reference or to alter 
> the 
> > code in Sage. 
> > 
>
> I'd propose just switching the x,y in the code: 
>
> (1) On line 3503 of linear_code.py, change "return 
> sum(spec[i]*x**(n-i)*y**i for i in range(n+1))" to "return 
> sum(spec[i]*x**(i)*y**(n-i) for i in range(n+1))" 
>
> (2) On line 3507, change "return sum(spec[i]*x**(n-i) for i in 
> range(n+1))" to "return sum(spec[i]*x**(i) for i in range(n+1))" 
>
> (3) Some of the examples may change accordingly. 
>
> This mistake could be my fault, since I wrote the original version 
> (long long ago). Unfortunately, I lack the git skills to submit a 
> patch. 
>
> A patch can be produced by

git diff > stuff.patch

It would be great if you opened a ticket and posted this diff as an 
attachment...
 
 

>
> > The function weight_enumerator(bivariate=False) returns the evaluation 
> of 
> > the the above polynomial for y=1. Should't it be (in the current 
> version) 
> > the evaluation with x=1? In other words: Wouldn't one expect a 
> polynomial in 
> > x (or y) whose coefficient to x^i (or y^i) is the number of codewords of 
> > 푠푒푙푓 of Hamming weight 푖? 
> > The example below [2] illustrates my point: The code has four codewords, 
> one 
> > of weight 0, two of weight 3, one of weiht 4. Sage gives x^5 + 2*x^2 + x 
> as 
> > the univariate weight enumerator. I would have expected either 1 + 2*x^3 
> + 
> > x^4 or 1 + 2*y^3 + y^4. 
> > 
> > If you agree, I suggest to alter the code accordingly. 
> > 
> > Kind regards 
> > Barbara 
> > PS: I tested the code with Sage version 7.6 on an iMac. 
> > 
> > 
> > [1] http://doc.sagemath.org/pdf/en/reference/coding/coding.pdf 
> > 
> > [2] Sage code for  the SageMathCell 
> > 
> > C= LinearCode(Matrix(GF(2),2,5, [[1,1,0,1,0], [0,0,1,1,1]])) 
> > print C.list() 
> > print C.spectrum() 
> > print C.weight_enumerator() 
> > print C.weight_enumerator(bivariate=False) 
> > C.weight_enumerator?? 
> > 
> > 
> http://sagecell.sagemath.org/?z=eJxztlXwycxLTSxyzk9J1fBNLCnKrNBwd9Mw0tQx0jHVUYiONtQx1DEA4VggzwDMBMLYWE1NXq6Cosy8EgVnvZzM4hINJH5xQWpySVFpLrJYeWpmekZJfGpeaW5qUWJJfhF-yaTMssSizMSSVFu3xJziVKBaLKrs7QGIgD2K=sage
>  
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "sage-devel" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to sage-devel+unsubscr...@googlegroups.com. 
> > To post to this group, send email to sage-devel@googlegroups.com. 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>

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

[sage-devel] Re: Error building Sage on UM 16.04: error making OpenBLAS

[Dima Pasechnik]

Indeed, OPENBLAS_CONFIGURE="TARGET=ATOM" is a catch-all x86_64 processors 
target.
Perhaps one can try the development version of openblas on these processors
(from https://github.com/xianyi/OpenBLAS)

On Friday, July 14, 2017 at 12:29:12 AM UTC+1, Christopher Phoenix wrote:
>
> I'm building Sage 7.6 on my laptop, and there was an error making openblas 
> that directed me to the log files for that package. The log file said that 
> detecting CPU failed, and to set TARGET explicitly. It also suggested I 
> email this google group to explain the problem, with the relevant part of 
> the log files. So I've attached it below. 
>
> OS: Ubuntu Mate 16.04 LTS
> Sage Version: 7.6
> HW: Lenovo Thinkpad 11e, 500gb HD, 4 gb ram, Intel Celeron N2940 with 4 
> cpu cores
>
> Before the build, I made sure that I had all the listed dependencies and 
> suggested packages already installed. Then I cloned the Git repo, set 
> MAKE='make -j5 -4' and typed make. Make ran for about 45 min or more before 
> it stopped and reported the error. I asked about this issue on sage-support 
> earlier (https://groups.google.com/forum/#!topic/sage-support/NlRyew12xDQ
> ).
>
> Someone had the same issue on very similar hardware (another 11e) here: 
> https://groups.google.com/d/msg/sage-devel/zQsZsivts0I/cblwvEkNDgAJ The 
> log files look almost exactly the same. They reported that setting 
> OPENBLAS_CONFIGURE="TARGET=ATOM" resolved this cpu detection issue, so I'm 
> going to try setting this and building Sage again later today. I was a 
> little confused since a Celeron is not an Atom afaik, I'm guessing this is 
> a catch-all setting for lower-end processors?
>
> Any advice will be greatly appreciated!
>

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