Re: [sage-devel] Coercions of polynomials

[Vincent Delecroix]

Maybe you want

sage: T(S.flattening_morphism()(f))
a*x + b*x + a*y + b*y


Le 14/01/2020 à 08:22, Travis Scrimshaw a écrit :

Hi everyone,
I wanted to know if this is a deliberate behavior or a bug:

sage: R. = ZZ[]
sage: S. = R[]
sage: T = ZZ['a,b,x,y']
sage: f = (x+y)*(a+b)
sage: T(f)
...
TypeError: not a constant polynomial

I understand that there should not be a coercion from S to T, but I feel
like we should be able to have conversions (anytime the variables of S are
a subset of those of T). I have a vague recollection that this used to
work, but I wouldn't know the last version I tried to do this. What do you
think?

Thanks,
Travis




--
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/d8edc2b6-4732-f523-ba1c-71001a3aac99%40gmail.com.

[sage-devel] Coercions of polynomials

[Travis Scrimshaw]

Hi everyone,
   I wanted to know if this is a deliberate behavior or a bug:

sage: R. = ZZ[]
sage: S. = R[]
sage: T = ZZ['a,b,x,y']
sage: f = (x+y)*(a+b)
sage: T(f)
...
TypeError: not a constant polynomial

I understand that there should not be a coercion from S to T, but I feel 
like we should be able to have conversions (anytime the variables of S are 
a subset of those of T). I have a vague recollection that this used to 
work, but I wouldn't know the last version I tried to do this. What do you 
think?

Thanks,
Travis


-- 
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/37164a09-09e5-4e01-b5bb-7eeb8b6e5c7e%40googlegroups.com.

Re: [sage-devel] Removing reverse graph from CGraph

[Vincent Delecroix]

Dear Jonathan,

The implementation of SparseGraph has many problems. One definitely
has to go through backward incompatible changes in the data structure.
The alternative would be to make a copy of the files with a class
SparseGraphNew. But this sounds completely silly.

People who do not want code to break should not rely on (semi-)private
methods or attributes. In that sense, it is safe to make the thing you
suggest. The behavior of no public method of graphs will change, right?

Thanks for working on this!

Best
Vincent

Le 07/01/2020 à 22:42, 'Jonathan Kliem' via sage-devel a écrit :

Dear all,

currently the sparse graph backend keeps a reversed copy of the graph.

However, the SparseGraph itself does not have access to it and thus the
reversed structure should be moved there for obvious optimizations. See
#28904 .

As the sparse graph backend is the only backend actually using the reversed
structure, it would make sense to remove this.

However, it is very well possible that people use the unsafe methods of
SparseGraph directly and code will break.
E.g. in graphs/trees.py the undirected trees are generated by manually
adding an arc in each direction.

I think, if we remove the reversed graph attribute in CGraph altogether,
people are more likely to catch on that something changed.
But in an undirected graph it can very well happen that they add two edges
instead of one (as they used to add one arc for each direction).

Any thoughts?

Jonathan



--
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/43b2636a-567a-3275-7f95-9e81c53cb301%40gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Sat, Jan 11, 2020 at 9:24 AM Antonio Rojas  wrote:
>
> El viernes, 10 de enero de 2020, 14:54:24 (UTC+1), E. Madison Bray escribió:
>>
>> That seems like the obvious approach to me.  As it is I've long felt
>> that Sage should be more flexible in its dependencies where
>> possible/necessary.  With most Python packages it's easy as most have
>> a .__version__ and its not so hard to define some variable
>> like IS_RPY_2 and just have two separate branches.  I have things like
>> that all over the place in other packages to support e.g. different
>> Numpy versions or work around version-specific bugs.
>
>
> I've opened https://trac.sagemath.org/ticket/28988 for rpy. But at this point 
> the major issues are python 3.8 and ipython 7, and I don't see how one could 
> support several versions of them without forking hundreds of doctests. Both 
> updates require multi-thousand-lines patches, due to changes in dict sorting 
> and hashes.

That remains a fault of over-reliance on doctests.  I don't think
downstream packaging is a good enough reason to push sage to rush
things in such a way that is not well-communicated to the user
community.  If you need to have a multi-thousand-line patch then so be
it.  A patch is 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAOTD34YdyANvYbS-M3cQqM-h0aA4a8us3wu4XDq2wMoX%2BGmECA%40mail.gmail.com.

Re: [sage-devel] Adopting orphaned math packages

[E. Madison Bray]

On Sat, Jan 11, 2020 at 5:36 AM Michael Orlitzky  wrote:
>
> We wound up targeting symmetrica-3.0.0 now, since it turns out every
> distro had moved the public def.h and macro.h headers, and that's a
> breaking change if we adopt it upstream. My personal TODO list is mostly
> done. I'm going to add some more stuff to the README, but probably won't
> make any more code changes before v3 unless someone points out an issue.
>
>
> On 1/9/20 6:27 AM, E. Madison Bray wrote:
> >
> > Great, I'll give it a try.  It's nice they were able to help you add a
> > proper autoconf-based build system.  I'm going to test it out on
> > Cygwin.
>
> I'll wait to hear if this worked first, though. There are some questions
> about Windows support in issues #2 and #6 that I think I've answered,
> but who knows.

It seems to work fine.  Those issues seem to pertain specifically to
native Windows builds for conda--it's not relevant to Cygwin.

-- 
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/CAOTD34b%2BJ8x6XVOHqTkhk_8BSEk79tf25POH9Bd7F%2BKBNEFU5A%40mail.gmail.com.

Re: [sage-devel] optional tag for sage versions (doctest)

[E. Madison Bray]

On Fri, Jan 10, 2020 at 7:16 PM Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
>
> Dear all,
>
> I do maintain Python libraries that depend on Sage and uses the
> Sage doctest framework. I do my best so that the libraries
> install and work on older versions of Sage. However, some features
> are only working with recent enough versions of Sage. But I still
> want them to pass the test suite with older Sage versions.
>
> I thought that having a tag looking like
>
>sage: my_computation()   # optional: sage >= 9.0
>
> would help me a lot.
>
> - Any alternative suggestion?
>
> - Can I do that with the current doctest framework? It would
>be nice to be able to specify optional tags on the fly.
>
> - Any vote pro or against such a tag? I think that if we go
>for it, everybody should agree so that it becomes a standard
>and gets specified in the SageMath documentation.
>
> Of course such a tag would be useless for the Sage library itself.

I think it's a reasonable request, although I think doctests are not a
great format for this kind of test that is very system-specific.  I
don't know if I would use # optional: for this, but maybe a new
directive such as "# version".

Feel free to open a ticket.

-- 
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/CAOTD34Y2we%2Bk7vVXCGBBPhOtDvJ%2BrvoBak_GSurg2cOPhasu%2Bg%40mail.gmail.com.

Re: [sage-devel] Re: Porting .sage files to sage-9.0

[E. Madison Bray]

On Fri, Jan 10, 2020 at 3:21 PM kcrisman  wrote:
>
>
>
> On Thursday, January 9, 2020 at 6:45:50 PM UTC-5, David Roe wrote:
>>
>> I had a recent discussion asking if there are any good tools for porting 
>> Sage code to Python 3.  Given the recent discussion about how long we 
>> support Python 2, it seems like one concrete step we can take to help users 
>> is to provide some documentation for doing so.
>>
>> The first step would seem to be to update our FAQ to reflect the current 
>> status (and probably the outcome of the discussion about how long we support 
>> Python 2), with a pointer to the relevant wiki pages.  But I don't see any 
>> discussion on those pages about using any of the tools for porting from 
>> Python 2 to Python 3 on .sage files.  Has anyone tried this yet?
>
>
> I've been doing a set of files by hand, and think it would be helpful for 
> there to be info on where to look for guidance on some of the more subtle 
> porting issues beyond print statements.  Two examples I hit just now:
> * Any backslash LaTeX in strings intended for consumption elsewhere in Sage 
> (via printing or MathJax, presumably) needs to be in a raw string, 
> apparently.  E.g. r"$5\equiv 2 (\text{mod }3)$" whereas before "$5\equiv 2 
> (\\text{mod }3)$" worked.

Indeed; technically the latter was always sort of incorrect, and one
should have always used raw string for latex (or double-backslashes)
since not doing so could lead to subtle bugs in your latex if, for
example, Python added a new escaped character.  Python 2 used to just
be more forgiving about this, but there has been a gradual move
towards making invalid backslash escapes an error, in order to prevent
this kind of problem in the future.  Perhaps this should be mentioned
in the Sage manual somewhere, if it isn't already (it's so vast that
maybe it is in there, but very easy to miss...)

> * I had one usage of "map" which was wrong from a Python 3 point of view in 
> the two ways not mentioned in the usual guides, e.g. see 
> https://stackoverflow.com/questions/12015521/python-3-vs-python-2-map-behavior
>
> So this would be a good service to provide, as well as what can't be handled 
> automatically with ease.  Also note that such porting tools might possibly 
> gag on some Sage non-Python syntax, e.g. f(x)=x^2 ?  Just guessing there.

Yep, that's the main problem...  none of the existing Python 2->3
porting tools will work on Sage-specific syntax unless it's been run
through the pre-parser first :(

-- 
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/CAOTD34YTaA4UkcOf-Q1XD_5EVVNBbB5n-jLVcvKRLvBun5JuQw%40mail.gmail.com.

Re: [sage-devel] 9.1.beta0 build failure on Arch

[Dima Pasechnik]

On Sat, Jan 11, 2020 at 11:35 AM arojas  wrote:
>
> El sábado, 11 de enero de 2020, 11:23:32 (UTC+1), Dima Pasechnik escribió:
>>
>>
>>
>> On Sat, 11 Jan 2020, 10:19 arojas,  wrote:
>>>
>>> I suspect this may be due to our openblas package only providing libblas.so 
>>> (not libcblas.so or liblapack.so, which in our case come from the netlib 
>>> blas).
>>
>>
>> Are you saying that your libopenblas.so does not provide everything that is 
>> in openblas by default?
>>
>> This is largely defeating its purpose.
>> Sage's openblas does provide the cblas and lapack capabilities.
>
>
>  In that case, openblas' spkg-configure should check whether cblas symbols 
> are provided by the system openblas, and if not it should compile sage's one. 
> It shouldn't unconditionally assume that that's always the case.

I maintain that it's a bug in Arch, that libopenblas cannot be used as
a replacement of cblas and lapack, for it defeats its purpose.
Most uses of BLAS routines are either via LAPACK, or from C/C++, via cblas.



>
> --
> 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/a1516e56-ab25-410e-be0f-75a7a6713466%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/CAAWYfq31Y0-wgCUysZjgk5h4jsmnfuc%3D_M9H4RPG3iHeZD%3D6BA%40mail.gmail.com.

Re: [sage-devel] 9.1.beta0: build problem using Homebrew's openblas

[Dima Pasechnik]

On Sun, Jan 12, 2020 at 1:37 PM Markus Wageringel
 wrote:
>
> I manually set those CVXOPT_... variables in the spkg-install file for now 
> and building cvxopt then succeeded.
>
> Building Sage now almost completes, but the file src/sage/libs/readline.pyx 
> fails to compile with these errors:
>
>
> [1/1] gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG 
> -g -fwrapv -O3 -Wall -Wno-unused -I./sage/cpython -Isage/cpython 
> -I/Applications/SageMath/local/include -I/Applications/SageMath/src 
> -I/Applications/SageMath/src/sage/ext 
> -I/Applications/SageMath/local/include/python3.7m 
> -I/Applications/SageMath/local/lib/python3.7/site-packages/numpy/core/include 
> -Ibuild/cythonized -I/Applications/SageMath/local/include/python3.7m -c 
> build/cythonized/sage/libs/readline.c -o 
> build/temp.macosx-10.9-x86_64-3.7/build/cythonized/sage/libs/readline.o 
> -fno-strict-aliasing -DCYTHON_CLINE_IN_TRACEBACK=1 -std=c99
> build/cythonized/sage/libs/readline.c:1446:36: error: use of undeclared 
> identifier 'rl_catch_signals'
>   __pyx_t_1 = __Pyx_PyInt_From_int(rl_catch_signals); if 
> (unlikely(!__pyx_t_1)) __PYX_ERR(0, 87, __pyx_L1_error)
>^
> build/cythonized/sage/libs/readline.c:1468:36: error: use of undeclared 
> identifier 'rl_catch_sigwinch'
>   __pyx_t_1 = __Pyx_PyInt_From_int(rl_catch_sigwinch); if 
> (unlikely(!__pyx_t_1)) __PYX_ERR(0, 88, __pyx_L1_error)
>^
> build/cythonized/sage/libs/readline.c:1542:36: warning: implicit 
> declaration of function 'rl_set_signals' is invalid in C99 
> [-Wimplicit-function-declaration]
>   __pyx_t_1 = __Pyx_PyInt_From_int(rl_set_signals()); if 
> (unlikely(!__pyx_t_1)) __PYX_ERR(0, 104, __pyx_L1_error)
>^
> build/cythonized/sage/libs/readline.c:1604:36: warning: implicit 
> declaration of function 'rl_clear_signals' is invalid in C99 
> [-Wimplicit-function-declaration]
>   __pyx_t_1 = __Pyx_PyInt_From_int(rl_clear_signals()); if 
> (unlikely(!__pyx_t_1)) __PYX_ERR(0, 120, __pyx_L1_error)
>^
> build/cythonized/sage/libs/readline.c:1849:36: error: passing 'void' to 
> parameter of incompatible type 'int'
>   __pyx_t_1 = __Pyx_PyInt_From_int(rl_forced_update_display()); if 
> (unlikely(!__pyx_t_1)) __PYX_ERR(0, 190, __pyx_L1_error)
>^~
> ...
>
>
> The Homebrew readline is version 8.0.1. In particular, the header file 
> `/usr/local/opt/readline/include/readline/readline.h` does contain 
> `rl_catch_signals`, `rl_catch_sigwinch` and `rl_clear_signals`.
>
> The system readline in `/usr/include/readline/readline.h` does not contain 
> these though, so it looks like that is used instead.

One may overrule Homebrew to actually force it to install readline in /usr/local
Otherwise, it's indeed a problem.
I've opened https://trac.sagemath.org/ticket/29000 to deal with this.

>
>
> Am 12.01.2020 um 10:58 schrieb Dima Pasechnik :
>
> On Sun, Jan 12, 2020 at 12:10 AM Markus Wageringel
>  wrote:
>
>
> On macOS 10.13.6, trying to make use of #27870 using Homebrew's openblas, the 
> build fails for me at cvxopt:
>
>gcc -bundle -undefined dynamic_lookup -L/Applications/SageMath/local/lib 
> -Wl,-rpath,/Applications/SageMath/local/lib -L/usr/local/opt/openssl/lib -L. 
> -L/Applications/SageMath/local/lib 
> -Wl,-rpath,/Applications/SageMath/local/lib -L/usr/local/opt/openssl/lib 
> -L/Applications/SageMath/local/lib 
> -Wl,-rpath,/Applications/SageMath/local/lib 
> build/temp.macosx-10.9-x86_64-3.7/src/C/gsl.o -L/Applications/SageMath/local 
> -L/Applications/SageMath/local -L/Applications/SageMath/local/lib -lm -lgsl 
> -lopenblas -o 
> build/lib.macosx-10.9-x86_64-3.7/cvxopt/gsl.cpython-37m-darwin.so
>ld: library not found for -lopenblas
>clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>error: command 'gcc' failed with exit status 1
>Running setup.py install for cvxopt: finished with status 'error'
>
> As openblas and readline are keg-only, I ran configure as
>
>./configure \
>  LDFLAGS="-L/usr/local/opt/readline/lib -L/usr/local/opt/openblas/lib 
> -L/usr/local/opt/mpfr/lib" \
>  CPPFLAGS="-I/usr/local/opt/readline/include 
> -I/usr/local/opt/openblas/include" \
>  
> PKG_CONFIG_PATH="/usr/local/opt/readline/lib/pkgconfig:/usr/local/opt/openblas/lib/pkgconfig"
>
> but cvxopt does not seem to use this.
>
>
> cvxopt really needs env.vars CVXOPT_BLAS_LIB_DIR, CVXOPT_BLAS_LIB,
> CVXOPT_LAPACK_LIB set, it does not use pkgconf.
> (but it should).
> We can propose an upstream fix for this, and meanwhile set these vars
> in spkg-install
>
>
> --
> 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