Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

[Dima Pasechnik]

On Thu, Jan 21, 2021 at 8:04 PM parisse  wrote:
>
> Well, searching for "lisp infix notation" is not very convincing (unless I 
> missed something?), compared to built-in infix support. You might prefer Lisp 
> to C/C++, it's your choice, but I don't see any objective reason that one 
> should stay away from C/C++. And Giac is a proof that one can actually write 
> a CAS in C/C++, that compares very well with the Lisp-based CAS Maxima.

Maxima is ~40 years old with a bit of work done since then, but the
core is that old, as far as I know:
https://en.wikipedia.org/wiki/Macsyma

As for staying away from C++,  most people who might be trying to do
something with supposedly state of the art library like boost,
would run away screaming, closely followed by 100 screens of error messages :-)
Or, now mostly gone (?), iterator_traits (my closest encounter with
C++, contributing to CGAL, 20 years ago, where these had to be
generated by a script for some classes, otherwise compilers kept
crashing...)





> Le jeudi 21 janvier 2021 à 18:07:14 UTC+1, dim...@gmail.com a écrit :
>>
>> On Wed, Jan 20, 2021 at 7:13 PM parisse  wrote:
>> >
>> > As the author of a CAS, I can state that you need much more than 2 weeks 
>> > to learn a programming language to make a CAS, and much much more if you 
>> > want to be fast. Life is short, therefore choose your programming language 
>> > carefully! I don't regret my choice for C (+ C++ STL and operator 
>> > redefinition) made 20 years ago, because C can interact with a lot of 
>> > languages (including compilation to Javascript). If I had to choose today, 
>> > I would perhaps choose Julia. Not Python, it's much too slow. I don't know 
>> > for Lisp speed, but it's not a language I would choose anyway, I like to 
>> > write e.g. a+b*c when I do algebraic computations in my source code.
>>
>> There are macro packages for infix maths in Common Lisp, so this by no
>> means should be a deal-breaker for anyone.
>>
>> Needless to say, C++ has its own can of worms, which anyone who tried
>> to used it might easily produce, as a reason to stay
>> away from it.
>>
>> >
>> > Le mercredi 20 janvier 2021 à 19:47:01 UTC+1, rjf a écrit :
>> >>
>> >> I think you have to figure that there is a difference in productivity of 
>> >> people who just learned Python in high school and would really like to 
>> >> write a computer algebra system
>> >> versus people who know more mathematics, are comfortable spending 2 weeks 
>> >> learning lisp, spending ?? (weeks? months?) studying the state of the art 
>> >> in
>> >> computer algebra systems as evolved over 60 years, and want to contribute 
>> >> to advancing the art (rather than re-programming the easy stuff).
>> >> I am under the impression that learning python is a reasonable stepping 
>> >> stone to learning lisp.
>> >>
>> >> As far as checking results for various systems, there is a category of 
>> >> CAS bugs that are syistem independent.
>> >> That is, they occur in many systems! Sometimes they depend on secretly 
>> >> dividing by zero, or doing something
>> >> that is invalid at a singularity. So "Maple and Mathematica and ... all 
>> >> agree" does not mean they are right!
>> >>
>> >> I think my essential point previously is that rewriting easy stuff (in a 
>> >> different language) typically fails to push the frontier.
>> >>
>> >>
>> >>
>> >> On Wednesday, January 20, 2021 at 5:54:51 AM UTC-8 kcrisman wrote:
>> 
>> 
>>  As to the question of replacing backends, there is already a ticket 
>>  (which I cannot find right now, my apologies) which started the process 
>>  of seeing what doctests would fail if we went to Sympy as default. 
>>  Presumably something similar could be done with this engine (I don't 
>>  know if it is more for low-level symbolics or also things like 
>>  integration).
>> >>>
>> >>>
>> >>> In particular, the (very minimal) documentation (really an API is all) 
>> >>> makes it seems more a replacement for things like Ginac (already in 
>> >>> C++), not Maxima et al. I don't know if that would provide a noticeable 
>> >>> speedup per se, though the SageManifolds ticket mentioned 
>> >>> parallelization so perhaps it is better suited for that?
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "sage-devel" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to sage-devel+...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/sage-devel/879dd941-95a0-4f2f-b5ac-96f60439f80dn%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/53e6e905-27ec-4545-a2ef-bca1eb01029c

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

[Thierry Dumont]

There was a message from B. Paisse some days ago, about C (++) and Julia 
for CAS.


May be this https://arxiv.org/pdf/1705.06134v1.pdf
is interesting.

t.d.

Le 22/01/2021 à 15:07, Dima Pasechnik a écrit :

On Thu, Jan 21, 2021 at 8:04 PM parisse  wrote:


Well, searching for "lisp infix notation" is not very convincing (unless I 
missed something?), compared to built-in infix support. You might prefer Lisp to C/C++, 
it's your choice, but I don't see any objective reason that one should stay away from 
C/C++. And Giac is a proof that one can actually write a CAS in C/C++, that compares very 
well with the Lisp-based CAS Maxima.


Maxima is ~40 years old with a bit of work done since then, but the
core is that old, as far as I know:
https://en.wikipedia.org/wiki/Macsyma

As for staying away from C++,  most people who might be trying to do
something with supposedly state of the art library like boost,
would run away screaming, closely followed by 100 screens of error messages :-)
Or, now mostly gone (?), iterator_traits (my closest encounter with
C++, contributing to CGAL, 20 years ago, where these had to be
generated by a script for some classes, otherwise compilers kept
crashing...)






Le jeudi 21 janvier 2021 à 18:07:14 UTC+1, dim...@gmail.com a écrit :


On Wed, Jan 20, 2021 at 7:13 PM parisse  wrote:


As the author of a CAS, I can state that you need much more than 2 weeks to 
learn a programming language to make a CAS, and much much more if you want to 
be fast. Life is short, therefore choose your programming language carefully! I 
don't regret my choice for C (+ C++ STL and operator redefinition) made 20 
years ago, because C can interact with a lot of languages (including 
compilation to Javascript). If I had to choose today, I would perhaps choose 
Julia. Not Python, it's much too slow. I don't know for Lisp speed, but it's 
not a language I would choose anyway, I like to write e.g. a+b*c when I do 
algebraic computations in my source code.


There are macro packages for infix maths in Common Lisp, so this by no
means should be a deal-breaker for anyone.

Needless to say, C++ has its own can of worms, which anyone who tried
to used it might easily produce, as a reason to stay
away from it.



Le mercredi 20 janvier 2021 à 19:47:01 UTC+1, rjf a écrit :


I think you have to figure that there is a difference in productivity of people 
who just learned Python in high school and would really like to write a 
computer algebra system
versus people who know more mathematics, are comfortable spending 2 weeks 
learning lisp, spending ?? (weeks? months?) studying the state of the art in
computer algebra systems as evolved over 60 years, and want to contribute to 
advancing the art (rather than re-programming the easy stuff).
I am under the impression that learning python is a reasonable stepping stone 
to learning lisp.

As far as checking results for various systems, there is a category of CAS bugs 
that are syistem independent.
That is, they occur in many systems! Sometimes they depend on secretly dividing 
by zero, or doing something
that is invalid at a singularity. So "Maple and Mathematica and ... all agree" 
does not mean they are right!

I think my essential point previously is that rewriting easy stuff (in a 
different language) typically fails to push the frontier.



On Wednesday, January 20, 2021 at 5:54:51 AM UTC-8 kcrisman wrote:



As to the question of replacing backends, there is already a ticket (which I 
cannot find right now, my apologies) which started the process of seeing what 
doctests would fail if we went to Sympy as default. Presumably something 
similar could be done with this engine (I don't know if it is more for 
low-level symbolics or also things like integration).



In particular, the (very minimal) documentation (really an API is all) makes it 
seems more a replacement for things like Ginac (already in C++), not Maxima et 
al. I don't know if that would provide a noticeable speedup per se, though the 
SageManifolds ticket mentioned parallelization so perhaps it is better suited 
for that?


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/879dd941-95a0-4f2f-b5ac-96f60439f80dn%40googlegroups.com.


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




--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from 

[sage-devel] Bug in expansion of a symbolic expression, which happens to be a rational function

['Martin R' via sage-devel]

I would like to advertise https://trac.sagemath.org/ticket/31077, which I 
think it is a rather troubling bug.  It occurs when expanding a symbolic 
expression, which happens to be a rational function.  I narrowed down the 
bug to a call to pynac, I do not know, however, whether the bug occurs 
within pynac or in the communication between pynac and sage.  The smallest 
example I currently know of is reproduced below.

I don't know who could help, which is why I am advertising here.

Best wishes,

Martin

sage: var("A B C x")

sage: p = A^2*B^2*C^3*x^2 + A^2*B^2*C^2*x^3 + A^2*B^2*C^2*x^2 + A^2*C^3*x^3 
+ A^5*B^2 + A^2*B^2*C^3 + A^3*B^2*C*x + A^2*B^2*C^2*x + A^3*B^2*x^2 + 
A^4*x^3 + A^3*C*x^3 + A^4*C^2 + A^2*B^2*C^2 + A^3*C^3 + A^3*B^2*x + 
B^2*C^3*x + A^3*C*x^2 + A^2*C^2*x^2 + A*C^3*x^2 + A*C^2*x^3 + C^3*x^3 + 
A^3*B^2 + A^2*B*C^2 + A*B*C^3 + A*B*C^2*x + B^2*C^2*x + A^3*x^2 + C^3*x^2 + 
A^2*x^3 + B^2*x^3 + A*C*x^3 + C^2*x^3 + A^4 + A^3*C + A^2*C^2 + B^2*C^2 + 
A*C^3 + B*C^3 + A^2*B*x + A*B*C*x + A*C*x^2 + B*C*x^2 + C^2*x^2 + A^2*B + 
B^2*C + B*C^2 + C^3 + A*B*x + A*x^2 + C*x^2 + x^3 + A^2 + B^2 + A*C + B*C + 
C^2 + B*x + x^2 + B + C + x + 1 sage: G = (((A + B + x) * (A + B^2 + 1) * p 
+ (A + B + 1)/x)*(A+1))

sage: G.expand().is_polynomial(x) != G.is_polynomial(x)

True

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

[sage-devel] Re: Unable to build develop branch

[dwb...@gmail.com]

Thanks!

But it didn't fix it for me. For me the u/jhpalmieri/scipy-big-sur 
 
fails 
in numpy and
doesn't get to scipy. So I merged the change in #31166 (addressing numpy) 
into
the scipy-big-sur branch and that fails to build in scipy again.

Dan

On Thursday, January 21, 2021 at 8:09:14 PM UTC-8 John H Palmieri wrote:

> Ticket 31183 (https://trac.sagemath.org/ticket/31183) should fix that. 
> Merging that into the develop branch works for me.
>
> -- 
> John
>
>
> On Thursday, January 21, 2021 at 8:03:55 PM UTC-8 dwb...@gmail.com wrote:
>
>> I'm unable to build the develop branch since upgrading my iMac to Big 
>> Sur. I have python3 and scipy installed through homebrew. In /usr/local/bin 
>> I have a symbolic link from python to python3.
>>
>> Although I have scipy through homebrew, Sage insists on installing the 
>> spkg. In previous build attempts (in late December) the build failed in 
>> numpy.
>>
>> I'm attaching my scipy.1.5.4.log. I would appreciate any suggestions.
>>
>> Thank you,
>> Daniel Bump
>>
>>
>>

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

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

[parisse]

I (almost) do not code C++ myself, probably 99% of my code is C-style, but 
I'm using a C++ compiler, that way I can link to the C++ standard template 
library and benefit of features like operator overload. Doing so, I do not 
have screens of error messages.

Le vendredi 22 janvier 2021 à 15:07:51 UTC+1, dim...@gmail.com a écrit :

> On Thu, Jan 21, 2021 at 8:04 PM parisse  
> wrote:
> >
> > Well, searching for "lisp infix notation" is not very convincing (unless 
> I missed something?), compared to built-in infix support. You might prefer 
> Lisp to C/C++, it's your choice, but I don't see any objective reason that 
> one should stay away from C/C++. And Giac is a proof that one can actually 
> write a CAS in C/C++, that compares very well with the Lisp-based CAS 
> Maxima.
>
> Maxima is ~40 years old with a bit of work done since then, but the
> core is that old, as far as I know:
> https://en.wikipedia.org/wiki/Macsyma
>
> As for staying away from C++, most people who might be trying to do
> something with supposedly state of the art library like boost,
> would run away screaming, closely followed by 100 screens of error 
> messages :-)
> Or, now mostly gone (?), iterator_traits (my closest encounter with
> C++, contributing to CGAL, 20 years ago, where these had to be
> generated by a script for some classes, otherwise compilers kept
> crashing...)
>
>
>
>
>
> > Le jeudi 21 janvier 2021 à 18:07:14 UTC+1, dim...@gmail.com a écrit :
> >>
> >> On Wed, Jan 20, 2021 at 7:13 PM parisse  
> wrote:
> >> >
> >> > As the author of a CAS, I can state that you need much more than 2 
> weeks to learn a programming language to make a CAS, and much much more if 
> you want to be fast. Life is short, therefore choose your programming 
> language carefully! I don't regret my choice for C (+ C++ STL and operator 
> redefinition) made 20 years ago, because C can interact with a lot of 
> languages (including compilation to Javascript). If I had to choose today, 
> I would perhaps choose Julia. Not Python, it's much too slow. I don't know 
> for Lisp speed, but it's not a language I would choose anyway, I like to 
> write e.g. a+b*c when I do algebraic computations in my source code.
> >>
> >> There are macro packages for infix maths in Common Lisp, so this by no
> >> means should be a deal-breaker for anyone.
> >>
> >> Needless to say, C++ has its own can of worms, which anyone who tried
> >> to used it might easily produce, as a reason to stay
> >> away from it.
> >>
> >> >
> >> > Le mercredi 20 janvier 2021 à 19:47:01 UTC+1, rjf a écrit :
> >> >>
> >> >> I think you have to figure that there is a difference in 
> productivity of people who just learned Python in high school and would 
> really like to write a computer algebra system
> >> >> versus people who know more mathematics, are comfortable spending 2 
> weeks learning lisp, spending ?? (weeks? months?) studying the state of the 
> art in
> >> >> computer algebra systems as evolved over 60 years, and want to 
> contribute to advancing the art (rather than re-programming the easy stuff).
> >> >> I am under the impression that learning python is a reasonable 
> stepping stone to learning lisp.
> >> >>
> >> >> As far as checking results for various systems, there is a category 
> of CAS bugs that are syistem independent.
> >> >> That is, they occur in many systems! Sometimes they depend on 
> secretly dividing by zero, or doing something
> >> >> that is invalid at a singularity. So "Maple and Mathematica and ... 
> all agree" does not mean they are right!
> >> >>
> >> >> I think my essential point previously is that rewriting easy stuff 
> (in a different language) typically fails to push the frontier.
> >> >>
> >> >>
> >> >>
> >> >> On Wednesday, January 20, 2021 at 5:54:51 AM UTC-8 kcrisman wrote:
> >> 
> >> 
> >>  As to the question of replacing backends, there is already a 
> ticket (which I cannot find right now, my apologies) which started the 
> process of seeing what doctests would fail if we went to Sympy as default. 
> Presumably something similar could be done with this engine (I don't know 
> if it is more for low-level symbolics or also things like integration).
> >> >>>
> >> >>>
> >> >>> In particular, the (very minimal) documentation (really an API is 
> all) makes it seems more a replacement for things like Ginac (already in 
> C++), not Maxima et al. I don't know if that would provide a noticeable 
> speedup per se, though the SageManifolds ticket mentioned parallelization 
> so perhaps it is better suited for that?
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send an email to sage-devel+...@googlegroups.com.
> >> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/879dd941-95a0-4f2f-b5ac-96f60439f80dn%40googlegroups.com
> .
> >
> > --
> > You recei

[sage-devel] Re: Unable to build develop branch

[Zachary Scherr]

#31166 is already merged into the latest develop branch so you shouldn't 
have to merge that.  Scipy should build with #31183 so maybe try again and 
post the log file.  If you need scipy to build you can also do:

MACOSX_DEPLOYMENT_TARGET=11.0 make scipy

which should fix the problem you are seeing.

On Friday, January 22, 2021 at 2:30:57 PM UTC-5 dwb...@gmail.com wrote:

> Thanks!
>
> But it didn't fix it for me. For me the u/jhpalmieri/scipy-big-sur 
> 
>  fails 
> in numpy and
> doesn't get to scipy. So I merged the change in #31166 (addressing numpy) 
> into
> the scipy-big-sur branch and that fails to build in scipy again.
>
> Dan
>
> On Thursday, January 21, 2021 at 8:09:14 PM UTC-8 John H Palmieri wrote:
>
>> Ticket 31183 (https://trac.sagemath.org/ticket/31183) should fix that. 
>> Merging that into the develop branch works for me.
>>
>> -- 
>> John
>>
>>
>> On Thursday, January 21, 2021 at 8:03:55 PM UTC-8 dwb...@gmail.com wrote:
>>
>>> I'm unable to build the develop branch since upgrading my iMac to Big 
>>> Sur. I have python3 and scipy installed through homebrew. In /usr/local/bin 
>>> I have a symbolic link from python to python3.
>>>
>>> Although I have scipy through homebrew, Sage insists on installing the 
>>> spkg. In previous build attempts (in late December) the build failed in 
>>> numpy.
>>>
>>> I'm attaching my scipy.1.5.4.log. I would appreciate any suggestions.
>>>
>>> Thank you,
>>> Daniel Bump
>>>
>>>
>>>

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

[sage-devel] Re: Unable to build develop branch

[John H Palmieri]

I literally meant "merge that [the branch from #31183] into the develop 
branch" (or vice versa), not just use the branch from #31183. The develop 
branch has some crucial pieces for building Sage in Big Sur.

  John

On Friday, January 22, 2021 at 11:30:57 AM UTC-8 dwb...@gmail.com wrote:

> Thanks!
>
> But it didn't fix it for me. For me the u/jhpalmieri/scipy-big-sur 
> 
>  fails 
> in numpy and
> doesn't get to scipy. So I merged the change in #31166 (addressing numpy) 
> into
> the scipy-big-sur branch and that fails to build in scipy again.
>
> Dan
>
> On Thursday, January 21, 2021 at 8:09:14 PM UTC-8 John H Palmieri wrote:
>
>> Ticket 31183 (https://trac.sagemath.org/ticket/31183) should fix that. 
>> Merging that into the develop branch works for me.
>>
>> -- 
>> John
>>
>>
>> On Thursday, January 21, 2021 at 8:03:55 PM UTC-8 dwb...@gmail.com wrote:
>>
>>> I'm unable to build the develop branch since upgrading my iMac to Big 
>>> Sur. I have python3 and scipy installed through homebrew. In /usr/local/bin 
>>> I have a symbolic link from python to python3.
>>>
>>> Although I have scipy through homebrew, Sage insists on installing the 
>>> spkg. In previous build attempts (in late December) the build failed in 
>>> numpy.
>>>
>>> I'm attaching my scipy.1.5.4.log. I would appreciate any suggestions.
>>>
>>> Thank you,
>>> Daniel Bump
>>>
>>>
>>>

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

[sage-devel] Re: Unable to build develop branch

[dwb...@gmail.com]

Contrary to my previous message, Ticket 31183 does fix the problem and I 
can now build sage.

Thanks,
Dan
On Friday, January 22, 2021 at 3:21:10 PM UTC-8 John H Palmieri wrote:

> I literally meant "merge that [the branch from #31183] into the develop 
> branch" (or vice versa), not just use the branch from #31183. The develop 
> branch has some crucial pieces for building Sage in Big Sur.
>
>   John
>
> On Friday, January 22, 2021 at 11:30:57 AM UTC-8 dwb...@gmail.com wrote:
>
>> Thanks!
>>
>> But it didn't fix it for me. For me the u/jhpalmieri/scipy-big-sur 
>> 
>>  fails 
>> in numpy and
>> doesn't get to scipy. So I merged the change in #31166 (addressing numpy) 
>> into
>> the scipy-big-sur branch and that fails to build in scipy again.
>>
>> Dan
>>
>> On Thursday, January 21, 2021 at 8:09:14 PM UTC-8 John H Palmieri wrote:
>>
>>> Ticket 31183 (https://trac.sagemath.org/ticket/31183) should fix that. 
>>> Merging that into the develop branch works for me.
>>>
>>> -- 
>>> John
>>>
>>>
>>> On Thursday, January 21, 2021 at 8:03:55 PM UTC-8 dwb...@gmail.com 
>>> wrote:
>>>
 I'm unable to build the develop branch since upgrading my iMac to Big 
 Sur. I have python3 and scipy installed through homebrew. In 
 /usr/local/bin 
 I have a symbolic link from python to python3.

 Although I have scipy through homebrew, Sage insists on installing the 
 spkg. In previous build attempts (in late December) the build failed in 
 numpy.

 I'm attaching my scipy.1.5.4.log. I would appreciate any suggestions.

 Thank you,
 Daniel Bump




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

[sage-devel] Re: Unable to build develop branch

[John H Palmieri]

Great, I'm glad to hear it!

Have you run doctests? If so, are there many failures?


On Friday, January 22, 2021 at 4:45:59 PM UTC-8 dwb...@gmail.com wrote:

>
> Contrary to my previous message, Ticket 31183 does fix the problem and I 
> can now build sage.
>
> Thanks,
> Dan
> On Friday, January 22, 2021 at 3:21:10 PM UTC-8 John H Palmieri wrote:
>
>> I literally meant "merge that [the branch from #31183] into the develop 
>> branch" (or vice versa), not just use the branch from #31183. The develop 
>> branch has some crucial pieces for building Sage in Big Sur.
>>
>>   John
>>
>> On Friday, January 22, 2021 at 11:30:57 AM UTC-8 dwb...@gmail.com wrote:
>>
>>> Thanks!
>>>
>>> But it didn't fix it for me. For me the u/jhpalmieri/scipy-big-sur 
>>> 
>>>  fails 
>>> in numpy and
>>> doesn't get to scipy. So I merged the change in #31166 (addressing 
>>> numpy) into
>>> the scipy-big-sur branch and that fails to build in scipy again.
>>>
>>> Dan
>>>
>>> On Thursday, January 21, 2021 at 8:09:14 PM UTC-8 John H Palmieri wrote:
>>>
 Ticket 31183 (https://trac.sagemath.org/ticket/31183) should fix that. 
 Merging that into the develop branch works for me.

 -- 
 John


 On Thursday, January 21, 2021 at 8:03:55 PM UTC-8 dwb...@gmail.com 
 wrote:

> I'm unable to build the develop branch since upgrading my iMac to Big 
> Sur. I have python3 and scipy installed through homebrew. In 
> /usr/local/bin 
> I have a symbolic link from python to python3.
>
> Although I have scipy through homebrew, Sage insists on installing the 
> spkg. In previous build attempts (in late December) the build failed in 
> numpy.
>
> I'm attaching my scipy.1.5.4.log. I would appreciate any suggestions.
>
> Thank you,
> Daniel Bump
>
>
>

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