from:"'Jonathan Kliem' via sage\-devel"

Re: [sage-devel] Re: cysignals/sig_on...sig_off

2023-04-30 Thread 'Jonathan Kliem' via sage-devel

Sorry about that. It is pip installable of course. However, it uses some
non standard setup.

I've been too long out of the topic. I just noticed that there is no active
development. This might be fine. But I'm not sure.

On Sun, Apr 30, 2023, 19:27 Matthias Koeppe 
wrote:

> I would suggest looping in the Cython community (cython-users list) on
> these questions.
>
> Could you elaborate on "cysignals is not pip-installable"? We are even
> building platform wheels - https://pypi.org/project/cysignals/#files
>
> On Sunday, April 30, 2023 at 7:49:44 AM UTC-7 jonatha...@googlemail.com
> wrote:
>
>> Hi,
>>
>> it's been over a year since the last activity on
>> https://github.com/sagemath/cysignals.
>>
>> This could well be, because it is a good shape, but looking at the
>> issues, I'm not too sure about that. Here are some issues, I know of:
>>
>> - sig_on/sig_off is poorly maintained and not thread safe
>> - cysignals is not pip installable and highly platform dependent (and on
>> a platform even depends very much on the compiler).
>> - Memory: Interrupting sig_on...sig_off will not clean up the heap.
>>
>> I would argue:
>>
>> -  To my knowledge, `sig_check` is pretty much equivalent to `
>> PyErr_CheckSignals` (https://github.com/sagemath/cysignals/issues/145)
>> - Instead of using `sig_on...sig_off` for our own functions, we should
>> check for signals at reasonable places.
>> - External calls should be interrupted with standard tools and not our
>> own custom tool.
>>
>> While the action on the first item is quite obvious (I didn't even check
>> if anything needs to be done here), I have not done my research on the
>> second point and what the alternatives are.
>>
>> Before I dig into possible options of replacing `sig_on...sig_off`, I
>> would like to gather your opinions:
>>
>> Does cysignals get enough support to keep going or do we want to try a
>> different approach? This different approach will for sure not be as
>> efficient, but will probably need less effort to maintain.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/MYV3wDR83m4/unsubscribe.
> To unsubscribe from this group and all its topics, 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/dfe10ff3-aa4b-4587-8e60-4ff60769a9edn%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/CAOOXL%2BoUubXTJSuyzXnSLxDn9sjaAYTBJoXm7ks8Dx05%2BHPn9Q%40mail.gmail.com.

Re: [sage-devel] Re: Memory leak with matrices and finite fields

2021-05-14 Thread 'Jonathan Kliem' via sage-devel

Its the same code in the Main line. Sorry for the confusion.

I googled it and that is how I found the exact place where this is defined.

What I linked is how it looks now accounting for changes in gmp 6.2. Flint 
2.6.3 has it but not 2.5.2.On May 14, 2021 10:31 PM, Dima Pasechnik 
 wrote:
>
> On Fri, May 14, 2021 at 4:03 PM 'jonatha...@googlemail.com' via 
> sage-devel  wrote: 
> > 
> > I think I tracked it down. 
> > 
> > https://github.com/BrianGladman/flint/blob/trunk/gmpcompat.h 
>
> this is a fork, dealing with Windows support of Flint. 
> We should  be working with 
> https://github.com/wbhart/flint2 
> which is the mainline of Flint. 
>
> > 
> > In there you see that `flint_mpz_set_si` is modified to work with GMP 6.2 
> > I'm assuming this one is picked up from your system? 
> > 
> > `sage --standard | grep gmp` 
> > 
> > This code is not present yet in flint 2.5.2, which is installed from sage 
> > in your case, I guess: 
> > 
> > `sage --standard | grep flint` 
> > 
> > Hopefully this should resolve itself if you update to sage 9.3 (flint 
> > 2.6.3), because this flint does account for the changes made in GMP 6.2 
> > 
> > Jonathan 
> > Freddie Manners schrieb am Samstag, 8. Mai 2021 um 00:25:52 UTC+2: 
> >> 
> >> Dear all, 
> >> 
> >> Sorry for the delay getting back to you -- this was waiting in the 
> >> moderation queue for a bit (me being new) and then I dropped the ball. 
> >> 
> >> > run the underlying functions 
> >> > 
> >> > M = identity_matrix(n) 
> >> > L = M.list() 
> >> > MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000, 1000, 
> >> > sparse=False) 
> >> > mat = MS(L, coerce=True, copy=False) 
> >> > 
> >> > Maybe repeatedly running the first line causes leakage already? 
> >> 
> >> It appears that the first *two* lines cause the leak, whereas the first 
> >> line by itself does not.  Not sure if that narrows it down, but possibly 
> >> strengthens the 31340 hypothesis below. 
> >> 
> >> > This might be a bug with flint. What flint are you using? 
> >> 
> >> To the best of my knowledge I don't have a system copy of flint, so 
> >> presumably I am using whatever is bundled in sage-9.2/upstream which seems 
> >> to be 2.5.2. 
> >> 
> >> > https://trac.sagemath.org/ticket/31340 
> >> 
> >> I can confirm that the original code on that trac also memory leaks for my 
> >> system (31MB) so it could very plausibly be the same issue.  I have not 
> >> yet read that bug in detail. 
> >> 
> >> Thanks for the feedback. 
> >> 
> >> Best 
> >> Freddie 
> >> On Wednesday, May 5, 2021 at 1:01:39 AM UTC-7 dim...@gmail.com wrote: 
> >>> 
> >>> we've fixed a memory leak in matrices recently (this fix will be in 
> >>> 9.3), not sure if this is related 
> >>> https://trac.sagemath.org/ticket/31340 
> >>> 
> >>> On Wed, May 5, 2021 at 8:45 AM 'jonatha...@googlemail.com' via 
> >>> sage-devel  wrote: 
> >>> > 
> >>> > Dear Freddie, 
> >>> > 
> >>> > thank you for the report. 
> >>> > 
> >>> > Fortunatly or unfortunately, I can't reproduce this on sage 9.2 or on 
> >>> > the develop branch (on ubuntu focal with libflint-2.5.2 and debian 
> >>> > buster with sage's flint 2.6.3). 
> >>> > 
> >>> > This might be a bug with flint. What flint are you using? 
> >>> > 
> >>> > You can go into detail, to see, what exactly is causing the problem and 
> >>> > instead of 
> >>> > 
> >>> > _ = identity_matrix(n).change_ring(GF(101)) 
> >>> > 
> >>> > run the underlying functions 
> >>> > 
> >>> > M = identity_matrix(n) 
> >>> > L = M.list() 
> >>> > MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000, 1000, 
> >>> > sparse=False) 
> >>> > mat = MS(L, coerce=True, copy=False) 
> >>> > 
> >>> > Maybe repeatedly running the first line causes leakage already? 
> >>> > 
> >>> > Jonathan 
> >>> > 
> >>> > Freddie Manners schrieb am Mittwoch, 5. Mai 2021 um 03:02:04 UTC+2: 
> >>> >> 
> >>> >> Dear all 
> >>> >> 
> >>> >> [I attempted to post this a few days ago but seemingly failed, so this 
> >>> >> is a repost; apologies if duplicate.] 
> >>> >> 
> >>> >> The following program appears to consume all the memory on my machine: 
> >>> >> 
> >>> >> n = 1000 
> >>> >> for i in range(0, 100): 
> >>> >> _ = identity_matrix(n).change_ring(GF(101)) 
> >>> >> print(get_memory_usage()) 
> >>> >> 
> >>> >> I am running Sage 9.2 on a 64-bit gentoo linux box (kernel 
> >>> >> 5.4.97-gentoo, gcc version 10.2.0). 
> >>> >> 
> >>> >> I couldn't find any related open bugs. I have worked around the issue 
> >>> >> (solution: don't create intermediate integer matrices and then coerce 
> >>> >> them to finite fields; obviously it's less explicit in my original 
> >>> >> code) but either way this seems to be a new bug. 
> >>> >> 
> >>> >> Best 
> >>> >> Freddie 
> >>> > 
> >>> > -- 
> >>> > 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.

Re: [sage-devel] Re: Memory leak with matrices and finite fields

2021-05-14 Thread 'Jonathan Kliem' via sage-devel

Thanks Freddie for reporting this.

I'm glad it resolves so easily. Yes, that is a mistake in our 9.2 
configure. One can fix this by passing `--with-system-gmp=no` to 
configure, but it should have rejected gmp 6.2 as long as flint 2.5.2 is 
the install candidate.

So you can update sage or rebuilt (large) parts of it by reconfiguring. 
Either way the issue goes hopefully away.

Jonathan

On 14.05.21 22:05, 'Freddie Manners' via sage-devel wrote:

Awesome, many thanks for running this down.

`sage --standard | grep gmp`
>> gmp.6.1.2 (not_installed)
`equery --quiet list gmp`
>> dev-libs/gmp-6.2.1-r1

`sage --standard | grep flint`
>> flint...2.5.2.p5 (2.5.2.p5)

So yes, that checks out, I am using system GMP 6.2 with Sage's flint 
2.5.2.

Not sure if something should have complained somewhere or whatever, 
but I look forward to seeing the problem disappear at the next upgrade.

Best
Freddie
On Friday, May 14, 2021 at 8:03:13 AM UTC-7 jonatha...@googlemail.com 
wrote:

I think I tracked it down.

https://github.com/BrianGladman/flint/blob/trunk/gmpcompat.h

In there you see that `flint_mpz_set_si` is modified to work with
GMP 6.2 I'm assuming this one is picked up from your system?

`sage --standard | grep gmp`

This code is not present yet in flint 2.5.2, which is installed
from sage in your case, I guess:

`sage --standard | grep flint`

Hopefully this should resolve itself if you update to sage 9.3
(flint 2.6.3), because this flint does account for the changes
made in GMP 6.2

Jonathan
Freddie Manners schrieb am Samstag, 8. Mai 2021 um 00:25:52 UTC+2:

Dear all,

Sorry for the delay getting back to you -- this was waiting in
the moderation queue for a bit (me being new) and then I
dropped the ball.

> run the underlying functions
>
> M = identity_matrix(n)
> L = M.list()
> MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000,
1000, sparse=False)
> mat = MS(L, coerce=True, copy=False)
>
> Maybe repeatedly running the first line causes leakage already?

It appears that the first *two* lines cause the leak, whereas
the first line by itself does not.  Not sure if that narrows
it down, but possibly strengthens the 31340 hypothesis below.

> This might be a bug with flint. What flint are you using?

To the best of my knowledge I don't have a system copy of
flint, so presumably I am using whatever is bundled in
sage-9.2/upstream which seems to be 2.5.2.

> https://trac.sagemath.org/ticket/31340

I can confirm that the original code on that trac also memory
leaks for my system (31MB) so it could very plausibly be the
same issue.  I have not yet read that bug in detail.

Thanks for the feedback.

Best
Freddie
On Wednesday, May 5, 2021 at 1:01:39 AM UTC-7 dim...@gmail.com
wrote:

we've fixed a memory leak in matrices recently (this fix
will be in
9.3), not sure if this is related
https://trac.sagemath.org/ticket/31340

On Wed, May 5, 2021 at 8:45 AM 'jonatha...@googlemail.com'
via
sage-devel  wrote:
>
> Dear Freddie,
>
> thank you for the report.
>
> Fortunatly or unfortunately, I can't reproduce this on
sage 9.2 or on the develop branch (on ubuntu focal with
libflint-2.5.2 and debian buster with sage's flint 2.6.3).
>
> This might be a bug with flint. What flint are you using?
>
> You can go into detail, to see, what exactly is causing
the problem and instead of
>
> _ = identity_matrix(n).change_ring(GF(101))
>
> run the underlying functions
>
> M = identity_matrix(n)
> L = M.list()
> MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000,
1000, sparse=False)
> mat = MS(L, coerce=True, copy=False)
>
> Maybe repeatedly running the first line causes leakage
already?
>
> Jonathan
>
> Freddie Manners schrieb am Mittwoch, 5. Mai 2021 um
03:02:04 UTC+2:
>>
>> Dear all
>>
>> [I attempted to post this a few days ago but seemingly
failed, so this is a repost; apologies if duplicate.]
>>
>> The following program appears to consume all the memory
on my machine:

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

2021-03-29 Thread 'Jonathan Kliem' via sage-devel

On 29.03.21 21:53, Matthias Koeppe wrote:
On Monday, March 29, 2021 at 12:08:36 PM UTC-7
jonatha...@googlemail.com wrote:

I think in case of a pxd files things are a bit different. If
someone uses cysignals and memory_allocator in the same place, e.g.

cdef MemoryAllocator mem = MemoryAllocator()
sig_on()
foo = mem.malloc(1000)
sig_off()

this would have to recompile the corresponding pxd file. So one
could check in that pxd file, whether cysignals is present or not.
So I think this could be set up, such that any project cimporting
from memory_allocator that requires cysignals has memory_allocator
with cysignals support.

Right. If an importing project declares both memory_allocator and
cysignals as "build-system requires" in pyproject.toml, then it can
make use of both; so conditionalization memoryallocator.pxd based on
cython_compile_time_env does make sense.

I didn't figure this out until after you showed me the reference.

conditionalization based on cython_compile_time_env might be hard
though. There is no such thing as

try:
from cysignals.signals cimport sig_on, sig_off
except:
from .signals_backup cimport sig_on, sig_off

One thing that one may try is basically the following:

cdef void (*sig_block_pt)()
cdef void (*sig_unblock_pt)()

if has_cysignals:
# replace sig_block, sig_unblock properly
else:
# replace by pass-functions

However, this probably needs an update of cysignals, as we need a way to
access the addresses of sig_block/sig_unblock on runtime (which is the
cython_compile_time_env).

The question remains, is it worth it? Do we need/want
sig_block/sig_unblock for MemoryAllocator?

--
You received this message because you are subscribed to a topic in the
Google Groups "sage-devel" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/sage-devel/6u1VuXJE7wE/unsubscribe
.
To unsubscribe from this group and all its topics, 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/f619d534-43b8-4fc9-aaaf-91d2db52a4b6n%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/d987abef-830c-66b8-33a8-aee631ac3b90%40gmail.com.

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

2021-03-29 Thread 'Jonathan Kliem' via sage-devel

I propose removing the sig_block / sig_unblock from MemoryAllocator 
alltogether.


I think it is really bad practice to put an extension class method into 
sig_on / sig_off and this would be the only use case that this is good 
for anyway (I doubt that this is safe in the first place -- 
MemoryAllocator does not use sig_block / sig_unblock to assure that the 
memory pointers are stored properly). I think the cysignals allocation 
functions are mostly used, because they check, whether the allocation 
was successful (and raise an error if not).


On 29.03.21 18:29, Matthias Koeppe wrote:
On Monday, March 29, 2021 at 9:21:05 AM UTC-7 
jonatha...@googlemail.com wrote:


On Mar 29, 2021 5:26 PM, Matthias Koeppe 
wrote:

> This suggestion is not compatible with modern Python packaging
(PEP-517/518). There is no such thing as an "optional build
dependency".

Is it acceptable to build different versions depending on whether
a package is found?

You don't find an installed package at build time. Build isolation 
provides a fixed set of packages -- that you define in pyproject.toml 
[build-system] requires. See e.g. 
https://snarky.ca/what-the-heck-is-pyproject-toml/


Thank you for providing the reference.

I think in case of a pxd files things are a bit different. If someone 
uses cysignals and memory_allocator in the same place, e.g.


cdef MemoryAllocator mem = MemoryAllocator()
sig_on()
foo = mem.malloc(1000)
sig_off()

this would have to recompile the corresponding pxd file. So one could 
check in that pxd file, whether cysignals is present or not. So I think 
this could be set up, such that any project cimporting from 
memory_allocator that requires cysignals has memory_allocator with 
cysignals support. As noted above, I would vote for dropping the 
sig_block / sig_unblock in MemoryAllocator alltogether.





--
You received this message because you are subscribed to a topic in the 
Google Groups "sage-devel" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/sage-devel/6u1VuXJE7wE/unsubscribe 
.
To unsubscribe from this group and all its topics, 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/c3abeea5-8413-479b-8303-74c5cbf0159cn%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/db52fd96-94f6-9ea4-fdeb-3431d6490247%40gmail.com.

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

2021-03-29 Thread 'Jonathan Kliem' via sage-devel


On Mar 29, 2021 5:26 PM, Matthias Koeppe  wrote:
>
> On Monday, March 29, 2021 at 6:25:28 AM UTC-7 vdelecroix wrote:
>>
>> I think it is desirable to have the possibility to enable or disable 
>> cysignals manually. In other words 
>> enable + "no cysignals present" -> error 
>> enable + "cysignals present" -> compilation with sigs 
>> disable + "whatever" -> compilation without sigs
I misunderstood this.
>
>
> This suggestion is not compatible with modern Python packaging (PEP-517/518). There is no such thing as an "optional build dependency".
>
Is it acceptable to build different versions depending on whether a package is found?
In the end the sig_block/sig_unblock is a bit of overkill anyway for MemoryAllocator. I wouldn't consider it clean to allocate memory with it inside of  sig_on / sig_off.
>  
>
> -- 
> You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/6u1VuXJE7wE/unsubscribe.
> To unsubscribe from this group and all its topics, 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/c8cff2c8-6c9c-46e7-a9e8-9d5cf390aac8n%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/6061fe6d.1c69fb81.dd754.767a%40mx.google.com.

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

2021-03-29 Thread 'Jonathan Kliem' via sage-devel



On Mar 29, 2021 3:23 PM, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
>
> +1 for having it inside https://github.com/sagemath 
>
> I think it is desirable to have the possibility to enable or disable 
> cysignals manually. In other words 
>    enable + "no cysignals present" -> error 
>    enable + "cysignals present" -> compilation with sigs 
>    disable + "whatever" -> compilation without sigs 

I agree that this would be nice. However, I don't know how to achieve this. One 
thing that one could try, is to add python functions to cysignals that typecast 
the addresses of sig_block/sig_unblock to a python int. It's definitely not 
clean, but it might work. E.g. you can check for the presence of cysignals in 
__init__.pxd with try … except this way.

>
> I thought cysignals would be Windows compatible after 
>
> https://github.com/sagemath/cysignals/pull/104 
>
> Though the project seems to be abandoned. What a shame. 

I've seen it, but I haven't taken the time to understand this. I agree that it 
would be best to have cysignals installable on windows without cygwin.

However, if you want the memory allocator and don't have cysignals installed 
already, you probably don't have a use case for it.

>
> Vincent 
>
> Le 29/03/2021 à 15:06, 'jonatha...@googlemail.com' via sage-devel a écrit : 
> > https://github.com/kliem/memory_allocator 
> > 
> > I started MemoryAllocator as a seperate project. I think it is almost ready 
> > to push to PyPI. Any opinions? Do I need permission to publish it like 
> > this? Should this be moved into a different repository? (E.g. 
> > https://github.com/sagemath/memory_allocator). 
> > 
> > It symlinks `cysignals/src/cysignals/memory.pxd`. Thus it only depends on 
> > `sig_block`/`sig_unblock` from cysignals. This will be used, if cysignals 
> > is found at time of setup. Otherwise, `sig_block`/`sig_unblock` will be 
> > replaced by functions doing nothing. Using `sig_block`/`sig_unblock` only 
> > seems to make sense, if you have cysignals anyway. 
> > 
> > Disadvantage of this approach is of course, that you need to make sure that 
> > you install cysignals before memory_allocator manually. 
> > 
> > jonatha...@googlemail.com schrieb am Donnerstag, 11. März 2021 um 10:33:35 
> > UTC+1: 
> > 
> >> This approach might not be pretty, but it seems to work fine. 
> >> 
> >> I can use cysignals on cygwin, linux, mac and not use it on windows 
> >> without cygwin. 
> >> 
> >> However, it would be much nicer to allow pip installing cysignals on 
> >> windows without cygwin in the first place. This would simplify this a lot. 
> >> 
> >> jonatha...@googlemail.com schrieb am Mittwoch, 10. März 2021 um 17:44:05 
> >> UTC+1: 
> >> 
> >>> Here is my project (I just made the repository public): 
> >>> https://github.com/kliem/PyKPartiteKClique/tree/main/ 
> >>> 
> >>> The source folder is kpkc 
> >>> 
> >>> As you can see, I completely copied memory_allocator* 
> >>> 
> >>> This should be moved to its own project eventually. 
> >>> 
> >>> Instead of cimporting directly from cysignals (which may fail, if not 
> >>> present), I cimport from kpkc.cysignals 
> >>> 
> >>> There are two files for this. kpkc/cysignals.pyx which is a plain 
> >>> wrapper about the cysignals functions (just cimporting did not work). 
> >>> 
> >>> If cysignals is not present, I instead compile kpkc/cysignals_backup.pyx 
> >>> as module kpkc.cysignals. 
> >>> 
> >>> Of course, you need to reinstall the project, if you install cysignals 
> >>> afterwards. 
> >>> 
> >>> On 10.03.21 16:07, E. Madison Bray wrote: 
> >>>> On Wed, Mar 10, 2021 at 3:51 PM 'Jonathan Kliem' via sage-devel 
> >>>>  wrote: 
> >>>>> What I'm struggling with is the following: 
> >>>>> 
> >>>>> How do I cimport from different sources (runtime dependent probably 
> >>>>> won't work, but compile time dependent would already be nice). At the 
> >>>>> moment my package just pulls in cysignals during pip install and if 
> >>> this 
> >>>>> does not work it replaces those functions by standard allocation 
> >>> functions. 
> >>>>> 
> >>>>> Is there a better solution to do this? 
> >>>> What do you mean by "cimport from different sources"? If you are 
>

Re: [sage-devel] Linking libraries with spkg-install.in

2021-03-19 Thread 'Jonathan Kliem' via sage-devel

On 19.03.21 11:13, François Bissey wrote:

On 19/03/2021, at 23:05, 'jonatha...@googlemail.com' via sage-devel
wrote:

We configure libaries with e.g. `--with-zlib="$SAGE_LOCAL"` unconditionally.
Why would this succeed, if we use the systems `zlib`?

It depends a bit on whether you use a properly written configure script or not.
Autotools tests and finds things by trying to compile things. If there is no
lib in SAGE_LOCAL it will not prevent a compilation against a system zlib to
fail.
gcc -o test -I$SAGE_LOCAL/include -L$SAGE_LOCAL/lib test.c -lz
will look first in the SAGE_LOCAL locations but will still use the standard
location
if nothing is found in the custom ones.

Where it will fail, is with custom scripts that work by trying to find a file
explicitly.
Like checking whether $SAGE_LOCAL/lib/libz.so exists. Those are bad tests in
the first
place.

François

I see. What we do is definitely against the instructions of libgd's
configure ("where to find the zlib library"). But checking the actual
code, $SAGE_LOCAL is completely ignored in this specific case.

So this really is a cdd specific problem (because I want to set the
preference according to the path and not according to which of
`setoper.h`, `cdd/setoper.h`, `cddlib/setoper.h` works).

And I guess we usually just wait until this leads to problems somewhere
(e.g. for iml we specify `-with-gmp-include="$SAGE_GMP_INCLUDE").

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

2021-03-10 Thread 'Jonathan Kliem' via sage-devel

Here is my project (I just made the repository public):
https://github.com/kliem/PyKPartiteKClique/tree/main/

The source folder is kpkc

As you can see, I completely copied memory_allocator*

This should be moved to its own project eventually.

Instead of cimporting directly from cysignals (which may fail, if not
present), I cimport from kpkc.cysignals

There are two files for this. kpkc/cysignals.pyx which is a plain
wrapper about the cysignals functions (just cimporting did not work).

If cysignals is not present, I instead compile kpkc/cysignals_backup.pyx
as module kpkc.cysignals.

Of course, you need to reinstall the project, if you install cysignals
afterwards.

On 10.03.21 16:07, E. Madison Bray wrote:

On Wed, Mar 10, 2021 at 3:51 PM 'Jonathan Kliem' via sage-devel
wrote:

What I'm struggling with is the following:

How do I cimport from different sources (runtime dependent probably
won't work, but compile time dependent would already be nice). At the
moment my package just pulls in cysignals during pip install and if this
does not work it replaces those functions by standard allocation functions.

Is there a better solution to do this?

What do you mean by "cimport from different sources"? If you are
already working on this could you link to the source?

If this is about my idea to make the memory allocation functions
"pluggable" that would be done by setting some function pointers to
them, which would be done by third-party Cython code using
MemoryAllocator (there would need to be a C method for setting them).

On 10.03.21 15:27, E. Madison Bray wrote:

On Sat, Feb 13, 2021 at 2:16 AM Matthias Koeppe
wrote:

On Friday, February 12, 2021 at 2:35:45 PM UTC-8 vdelecroix wrote:

Why make it part of cysignals? The purpose of the memory allocator
is quite distinct from cysignals. Merging them look artificial to me.

Really? MemoryAllocator is just a wrapper class around cysignals.memory

Was there ever any action on this? MemoryAllocator does seem like a
useful thing to have as an independent package. It's basically a more
sophisticated version of the SomeMemory recipe given in the Cython
docs:
https://cython.readthedocs.io/en/latest/src/tutorial/memory_allocation.html

I agree that it's distinct from cysignals. It doesn't necessarily
have to depend on cysignals, and could have a hook interface to allow
different memory allocation functions. It just happens to use the
ones from cysignals since Sage already uses cysignals, and its memory
functions have the advantage of being interrupt-safe.

I would continue using cysignals by default for an initial
implementation, but if anyone had a need for it, it would be possible
to make this work with cysignals as an optional dependency as well.

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

2021-03-10 Thread 'Jonathan Kliem' via sage-devel


What I'm struggling with is the following:

How do I cimport from different sources (runtime dependent probably 
won't work, but compile time dependent would already be nice). At the 
moment my package just pulls in cysignals during pip install and if this 
does not work it replaces those functions by standard allocation functions.


Is there a better solution to do this?

On 10.03.21 15:27, E. Madison Bray wrote:

On Sat, Feb 13, 2021 at 2:16 AM Matthias Koeppe
 wrote:

On Friday, February 12, 2021 at 2:35:45 PM UTC-8 vdelecroix wrote:

Why make it part of cysignals? The purpose of the memory allocator
is quite distinct from cysignals. Merging them look artificial to me.


Really? MemoryAllocator is just a wrapper class around cysignals.memory

Was there ever any action on this?  MemoryAllocator does seem like a
useful thing to have as an independent package.  It's basically a more
sophisticated version of the SomeMemory recipe given in the Cython
docs: 
https://cython.readthedocs.io/en/latest/src/tutorial/memory_allocation.html

I agree that it's distinct from cysignals.  It doesn't necessarily
have to depend on cysignals, and could have a hook interface to allow
different memory allocation functions.  It just happens to use the
ones from cysignals since Sage already uses cysignals, and its memory
functions have the advantage of being interrupt-safe.

I would continue using cysignals by default for an initial
implementation, but if anyone had a need for it, it would be possible
to make this work with cysignals as an optional dependency as well.



--
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/58a5c332-7331-8433-941e-b73f7090d608%40gmail.com.

Re: [sage-devel] Move MemoryAllocator to PyPI?

2021-02-10 Thread 'Jonathan Kliem' via sage-devel

Or maybe once the modularization has processed
(https://trac.sagemath.org/ticket/29705) this really boils down to a
tiny ticket?

On 10.02.21 13:43, 'jonatha...@googlemail.com' via sage-devel wrote:
Dear all, I have two little projects that I want to put onto PyPI
soon. Both of them use MemoryAllocator, because I find it very nice to
just allocate memory and let pythons garbage collector take care of
it. MemoryAllocator only depends on cysignals, so it would make sense
to make it pip installable by itself (or as part of cysignals).

Any opinions on this?

Of course it takes almost no effort just rewrite MemoryAllocator.
However, it also makes sense to avoid code duplications.

--
You received this message because you are subscribed to a topic in the
Google Groups "sage-devel" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/sage-devel/6u1VuXJE7wE/unsubscribe.
To unsubscribe from this group and all its topics, 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/27836ec2-c5ce-412d-95e5-73363be65c71n%40googlegroups.com
.

Re: [sage-devel] AttributeError: module 'sage.sandpiles.all' has no attribute 'absolute_import'

2021-02-10 Thread 'Jonathan Kliem' via sage-devel

A ipython upgrade solves this (somewhat). Jedi upgrade makes the 
traceback a bit nicer then.


After upgrading I still get an error message, but the sessions recovers 
itself.


Upgrading ipython and jedi is subject to 
https://trac.sagemath.org/ticket/31373#comment:1


Here is the remaining traceback, still strange, but only a bit annoying, 
as at least the session is kept active:


Traceback (most recent call last):
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/cache.py", 
line 110, in wrapper

    return dct[key]
KeyError: (('get_signature_params',), frozenset())

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/IPython/terminal/ptutils.py", 
line 115, in get_completions
    yield from self._get_completions(body, offset, cursor_position, 
self.ipy_completer)
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/IPython/terminal/ptutils.py", 
line 131, in _get_completions

    for c in completions:
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/IPython/core/completer.py", 
line 438, in _deduplicate_completions

    completions = list(completions)
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/IPython/core/completer.py", 
line 1827, in completions
    for c in self._completions(text, offset, 
_timeout=self.jedi_compute_type_timeout/1000):
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/IPython/core/completer.py", 
line 1884, in _completions

    signature = _make_signature(jm)
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/IPython/core/completer.py", 
line 998, in _make_signature

    return '('+c0.to_string().split('(', maxsplit=1)[1]
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/api/classes.py", 
line 814, in to_string

    return self._signature.to_string()
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/inference/signature.py", 
line 31, in to_string

    s = self.name.string_name + '(' + ', '.join(param_strings()) + ')'
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/inference/signature.py", 
line 13, in param_strings

    for n in self.get_param_names(resolve_stars=True):
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/inference/signature.py", 
line 52, in get_param_names

    param_names = self._function_value.get_param_names()
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/inference/utils.py", 
line 16, in wrapper

    return list(func(*args, **kwargs))
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/inference/compiled/value.py", 
line 121, in get_param_names

    signature_params = self.access_handle.get_signature_params()
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/inference/compiled/subprocess/__init__.py", 
line 386, in _workaround

    return self._cached_results(name, *args, **kwargs)
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/cache.py", 
line 112, in wrapper

    result = method(self, *args, **kwargs)
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/inference/compiled/subprocess/__init__.py", 
line 390, in _cached_results
    return self._subprocess.get_compiled_method_return(self.id, name, 
*args, **kwargs)
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/inference/compiled/subprocess/functions.py", 
line 27, in get_compiled_method_return

    return getattr(handle.access, attribute)(*args, **kwargs)
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/inference/compiled/access.py", 
line 482, in get_signature_params

    ) for p in self._get_signature().parameters.values()
  File 
"/srv/public/kliem/sage/local/lib/python3.7/site-packages/jedi/inference/compiled/access.py", 
line 488, in _get_signature

    return inspect.signature(obj)
  File "/usr/lib/python3.7/inspect.py", line 3083, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
  File "/usr/lib/python3.7/inspect.py", line 2833, in from_callable
    follow_wrapper_chains=follow_wrapped)
  File "/usr/lib/python3.7/inspect.py", line 2288, in 
_signature_from_callable

    skip_bound_arg=skip_bound_arg)
  File "/usr/lib/python3.7/inspect.py", line 2112, in 
_signature_from_builtin

    raise ValueError("no signature found for builtin {!r}".format(func))
  File "sage/misc/lazy_import.pyx", line 375, in 
sage.misc.lazy_import.LazyImport.__repr__ 
(build/cythonized/sage/misc/lazy_import.c:4134)

    obj = self.get_object()
  File "sage/misc/lazy_import.pyx", line 190, in 
sage.misc.lazy_import.LazyImport.get_object 
(build/cythonized/sage/misc/lazy_import.c:2436)

    return self._get_object()
  File "sage/misc/lazy_import.pyx", line 223, in 
sage.misc.lazy_import.LazyImport._get_object

Re: [sage-devel] How to review a ticket?

2021-01-19 Thread 'Jonathan Kliem' via sage-devel

Ah. Reading your message closely, I think I see the problem. What you 
are trying to do, is not possible.

If you want to give some comments about the code, you need to leave a 
comment on the corresponding trac ticket.

You can parse code in comments using curly brackets:

{{{
def foo(a, b):
    return a + b
}}}

One can also see the diff file nicely:

{{{#!diff
--- a/src/doc/en/reference/homology/index.rst 

+++ b/src/doc/en/reference/homology/index.rst 

@@ -35,6 +35,7 @@ cell complexes.
sage/homology/algebraic_topological_model
sage/homology/homology_morphism
sage/homology/matrix_utils
+ sage/homology/finite_topological_spaces
sage/interfaces/chomp
}}}

It is also common to propose changes via a proposed diff:
(in this case propose to give a more descriptive name to a function.

{{{#!diff
- def foo(a, b):
+ def add(a, b):
 return a + b
}}}

Then it is rather easy to figure out for the author, what you are 
refering to.

The styling is mostly markdown, I guess. I learnt most things by 
pressing reply to a comment. Then, I can see the source code of what 
they wrote.

I hope that helps,

Jonathan

On 19.01.21 17:01, Siddharth Bhat wrote:
Strange, I am logged in. Even so, I don't seem to be able to see the 
edit options? What exactly ought I edit?

Thanks a lot,
~Siddharth

On Tue, Jan 19, 2021 at 9:26 PM 'jonatha...@googlemail.com 
' via sage-devel 
mailto:sage-devel@googlegroups.com>> wrote:

You need to login somehow.

You have previously logged in with your github account `gh-bollu`.
This works as well. After you log in, the edit options will appear.

Of course you can also create a sage account, which also lets you
edit https://wiki.sagemath.org/ and maybe you prefer not to link
your activities with your github account.

Anyway, for reviewing tickets etc, both options work. However,
most people decide on one account, so that people don't get confused.

Thierry (sage-googlesucks@xxx) schrieb am Dienstag, 19. Januar
2021 um 16:46:52 UTC+1:

Hi,

you could ask for a trac acount as explained in the developer
guide:

https://doc.sagemath.org/html/en/developer/trac.html#obtaining-an-account

Ciao,
Thierry

On Tue, Jan 19, 2021 at 06:55:33AM -0800, Siddharth Bhat wrote:
> Hey all,
>
> I'm trying to learn how to review Trac tickets,and am
unfortunately failing
> at it.
>
> I want to leave some comments on this file:
>

https://git.sagemath.org/sage.git/diff/src/sage/homology/finite_topological_spaces.py?id=fc4c726665c7bf25c83a7fae6f04420e19086d69

>
> which corresponds to this trac ticket:
> https://trac.sagemath.org/ticket/30400#no3
>
> but I can't find anything in the interface that lets me do
so. I see that
> the others have posted comments, such as this:
>
> https://trac.sagemath.org/ticket/30400#comment:15
>
> How do I post such a comment?
>
> Best,
> ~Siddharth
>
> --
> 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/65051530-b717-44eb-bd6d-10b1793f9141n%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/3d49e559-447c-4d8d-89bc-fb97b95577bcn%40googlegroups.com

.

--
https://bollu.github.io/
--
You received this message because you are subscribed to a topic in the 
Google Groups "sage-devel" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/sage-devel/hOwMXPMx99k/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPipc%3D1rMWjWt6nWJNcF9poy%3D%2BFqthpj2CsAjx4G%3DYNQ55t%2B0w%40mail.gmail.com

[sage-devel] Re: Meaningful error messages for coercion failure

2020-08-16 Thread 'Jonathan Kliem' via sage-devel

Thanks for your feedback.

I'll close that ticket then as invalid.

You're right that the error message contains usually everything you need to 
know to solve your problem.

Am Samstag, 15. August 2020 23:12:33 UTC+2 schrieb Nils Bruin:
>
> On Saturday, August 15, 2020 at 11:38:17 AM UTC-7, Jonathan Kliem wrote:
>>
>> Could we have meaningful error messages somehow for coercion failure?
>>
> [...] 
>
>> TypeError: unsupported operand parent(s) for +: 'Number Field in sqrt5 
>> with defining polynomial x^2 - 5 with sqrt5 = 2.236067977499790?' and 
>> 'Algebraic 
>> Real Field'
>>
>  [...]
>
>> Maybe a user could get some hint that number fields can be specified with 
>> fixed embedding and that conversion works either way.
>>
>  
> I think the message is very meaningful: it exactly describes what goes 
> wrong. The fact that the message follows a fixed pattern is actually 
> helpful in recognizing the problem for people with some experience with 
> sage.
>
> It may be the case that there is room for generating helpful suggestions 
> for inexperienced users. Basically, something that matches traceback/imput 
> patterns to FAQ items. WIth the current state of machine learning and 
> language processing, this might actually be something that can be made to 
> perform to some satisfactory degree, but it would take into account much 
> more than just the place where the error arises. Alternatively, we may be 
> able to get a similar result by writing a really good FAQ and let Google 
> index it, so that we get to borrow their language processing. 
>
> There are places in sage where managing complexity of the error message is 
> worthwhile, and I think the coercion system is one: there are places where 
> sage tries several possibilities and catches the errors. Sage even has 
> specific "lazy" error messages for that, so that the message doesn't get 
> expanded unless the string is actually called for. If I'm not mistaken, 
> this particular message is an example of that. These parent representations 
> can have a real cost to them, so that you don't want to risk generating 
> them in a time-critical part of the code (where the string is thrown away 
> anyway).
>
> So, I suspect that there's a real cost to making coercion error messages 
> more expensive to generate. That gives another argument against doing so.
>

-- 
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/7defdb16-22e0-45d9-bd02-8c77428bbbado%40googlegroups.com.

[sage-devel] Meaningful error messages for coercion failure

2020-08-15 Thread 'Jonathan Kliem' via sage-devel

Could we have meaningful error messages somehow for coercion failure?

E.g. when I couldn't coerce two quadratic number fields, I needed help 
finding the method composite fields.

In https://trac.sagemath.org/ticket/28774 I tried to point the user somehow 
to this method and there might be other places where this might be helpful.

- E.g. when we don't want to coerce, but conversion is nevertheless 
possible.
- Or x acts on y but not from the right. Instead of raising an error 
immediately, we could show this only at coercion failure (and not force 
coercion failure to show the message).

One thing we could do is store coercion warnings somewhere and at a 
coercion failure we hint the user to this thing, e.g. 
`coercion_model.recent_failures()`. This could be useful, but of course 
only if people populate that thing. It would definitely by more useful than

sage: K. = QuadraticField(5) 


sage: sqrt5 + AA(2) 


---
TypeError Traceback (most recent call last)
 in 
> 1 sqrt5 + AA(Integer(2))

~/Applications/sage/local/lib/python3.7/site-packages/sage/structure/element
.pyx in sage.structure.element.Element.__add__ (build/cythonized/sage/
structure/element.c:10980)()
   1230 # Left and right are Sage elements => use coercion model
   1231 if BOTH_ARE_ELEMENT(cl):
-> 1232 return coercion_model.bin_op(left, right, add)
   1233 
   1234 cdef long value

~/Applications/sage/local/lib/python3.7/site-packages/sage/structure/coerce.pyx 
in sage.structure.coerce.CoercionModel.bin_op (build/cythonized/sage/
structure/coerce.c:11304)()
   1246 # We should really include the underlying error.
   1247 # This causes so much headache.
-> 1248 raise bin_op_exception(op, x, y)
   1249 
   1250 cpdef canonical_coercion(self, x, y):

TypeError: unsupported operand parent(s) for +: 'Number Field in sqrt5 with 
defining polynomial x^2 - 5 with sqrt5 = 2.236067977499790?' and 'Algebraic 
Real Field'


Maybe a user could get some hint that number fields can be specified with 
fixed embedding and that conversion works either way.

-- 
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/1f104958-412d-42c5-974f-8c8277c437ebo%40googlegroups.com.

[sage-devel] cython directives for %%cython magic

2020-08-11 Thread 'Jonathan Kliem' via sage-devel

I need some help with https://trac.sagemath.org/ticket/29139

If you load a cython file into a sage session the default cython directives 
are different from the directives on compile time. This might lead to 
different behaviour or errors, e.g. the following fails:

sage: %%cython
: include "sage/data_structures/bitset.pxi"


If I understand correctly the cython directives while building sage are 
located in `src/sage_setup/command/sage_build_cython.py`:

153 self.cython_directives = dict( 
154 auto_pickle=False, 
   
155 autotestdict=False, 
156 cdivision=True, 
  
157 embedsignature=True,   
   
158 fast_getattr=True, 
159 language_level="3str", 
160 preliminary_late_includes_cy28=True,   
   
161 profile=self.profile,   
  
162 )   

The directive when loading into sage are located in 
`src/sage/misc/cython.py`.

317 directives = dict(language_level=sys.version_info[0]) 

The error is caused by `cdivision=True` missing. Is it acceptable to add 
it? Which others should be added?

-- 
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/e1ada1ce-ccce-45d6-a8d5-40e24680b994o%40googlegroups.com.

[sage-devel] Re: Jupyter notebook broken in 9.2.beta4

2020-07-11 Thread 'Jonathan Kliem' via sage-devel

I posted this on sage-release, because I figured, it's due to a recent 
ticket. But I was mistaken because of the following:

What worked for me is running

sage -b

But running

make build

breaks it again. I hope that works for you for now. But it is of course not 
acceptable.

Am Sonntag, 12. Juli 2020 02:26:02 UTC+2 schrieb Paul Masson:
>
> Just built a ticket based on 9.2.beta3 and the same problem occurs.
>
> On Saturday, July 11, 2020 at 4:09:56 PM UTC-7, Paul Masson wrote:
>>
>> After a successful incremental build from 9.2.beta2, trying to start a 
>> new notebook results in the browser console error "Failed to load resource: 
>> the server responded with a status of 404 (Not Found)" when trying to fetch 
>> Mathjax from http://localhost:/nbextensions/mathjax/MathJax.js. Has 
>> anyone other than Dima seen this also?
>>
>> This appears to be a serious server configuration error. I don't see any 
>> ticket in either this beta or the previous one that would cause this. Am I 
>> missing some new configuration step? Sage built and runs just fine.
>>
>

-- 
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/81c0c5fa-fce3-427b-b17f-2f6dab777b0fo%40googlegroups.com.

[sage-devel] testing package upgrades

2020-06-28 Thread 'Jonathan Kliem' via sage-devel

Dear all,

package upgrades can now be tested on multiple platforms easily, see 
https://doc.sagemath.org/html/en/developer/portability_testing.html#automatic-parallel-tox-runs-on-github-actions
.

This is useful, as sometimes package upgrades don't work on all platforms 
(e.g. #30008) . Please use it. It 
is rather easy (to use) and will hopefully avoid many of those posts "I 
can't build sage anymore".

The checksums.ini of your package needs an upstream url as in #29373 
.

Then you can push your branch to a public repository on your github account 
and create a pull request. You can compare the results to 
https://github.com/sagemath/sage/actions (it takes about a day for the 
tests to run).

In many cases, just checking the green checkmarks is a great help. But you 
can also compare how the tests performed.

If everything works, that's it. Otherwise you can easily obtain all the 
logs and even download the generated docker image and run it locally  for 
debugging.

Thank you,

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/7451e6cf-626b-4436-860b-93395b09917fo%40googlegroups.com.

Re: [sage-devel] Turn off consistent randomness in doctests by default?

2020-06-22 Thread 'Jonathan Kliem' via sage-devel

And this design has problems e.g. https://trac.sagemath.org/ticket/28599

Basic story is: The random splitting that is being done to find real roots 
is far from stable. Apparently the doctests don't catch on, because they 
always use the same "random state". In real life, you cannot obtain a 
regular polygon with 20 vertices with this method.

So some doctests claim that sage can do something, which can be totally 
wrong (unless you have your lucky day). Maybe if the doctests would have 
shown some variation, people designing this would have caught on that their 
random choice could be real bad and they would have to accounted for that.

Am Montag, 22. Juni 2020 13:43:39 UTC+2 schrieb Dima Pasechnik:
>
>
>
> On Mon, 22 Jun 2020, 12:35 'Jonathan Kliem' via sage-devel, <
> sage-...@googlegroups.com > wrote:
>
>> Yes there is need. Please go into any file of your choice and print out a 
>> "random" value in a doctest and see what happens.
>>
>
> yes, this is by design. Otherwise one cannot get reproducible doctests.
> To get more randomness you need to pull it out of the random source.
> Randomness is about distributions, not particular values (sorry, I start 
> to sound like I teach a statistics class :-))
>
>
> There is not even a variation as Michael pointed out.
>>
>> If you start sage in a shell, there is variation. But sage in a shell 
>> behaves different than in doctests. E.g. in doctests the dictionaries are 
>> being sorted, in the shell not.
>> And currently in doctests there is no variation at all in random numbers. 
>> You will always get the very same numbers.
>>
>> Am Montag, 22. Juni 2020 13:26:24 UTC+2 schrieb Dima Pasechnik:
>>>
>>>
>>>
>>> On Mon, 22 Jun 2020, 12:18 'Jonathan Kliem' via sage-devel, <
>>> sage-...@googlegroups.com> wrote:
>>>
>>>> Currently, the doctest setup produces the very same random numbers on 
>>>> every instance.
>>>>
>>>> If you call `set_random_seed()` first you will get somewhat different 
>>>> values on every single doctest run. It can still be annoying as not every 
>>>> bot will catch every failure, but it is by far more likely to catch 
>>>> regression eventually.
>>>>
>>>
>>> there is no need to explicitly set the seed in these tests. Because it 
>>> is done as Sage starts up.
>>> By explicitly setting it you just restart the RNG, for no good reason.
>>> There is no guarantee that this would give you "better" randomness.
>>> If you want more random data in your doctest, repeat tests in a loop.
>>>
>>>
>>>> It seems that there are a number of doctests that are supposed to run 
>>>> on different values each time the doctest is run. However, currently 
>>>> exactly one list of values is tested each time.
>>>>
>>>> It's not about getting very good pseudo randomness. It is just about 
>>>> getting some variation of values.
>>>>
>>>> Am Montag, 22. Juni 2020 13:09:55 UTC+2 schrieb Dima Pasechnik:
>>>>>
>>>>>
>>>>>
>>>>> On Mon, 22 Jun 2020, 10:58 'Jonathan Kliem' via sage-devel, <
>>>>> sage-...@googlegroups.com> wrote:
>>>>>
>>>>>> I had a doctest
>>>>>>
>>>>>> sage: ls = [randint(-100,100) for _ in range(4)]
>>>>>> sage: intervals = [[x, x+randint(1,50)] for x in ls]
>>>>>> sage: P = polytopes.hypercube(4, intervals, backend=
>>>>>> 'field')
>>>>>>
>>>>>> which then checked `P` for consistency. However it was somewhat 
>>>>>> meaningless (missing `set_random_seed()`) as all entries in `ls` where 
>>>>>> positive. It never caught a sign error that we introduced  in #28866 
>>>>>> <https://trac.sagemath.org/ticket/28866>.
>>>>>> Adding `set_random_seed` to it, does catch the error.
>>>>>>
>>>>>
>>>>> unless I misunderstand how Sage random numbers are set, by adding an 
>>>>> explicit set_random_seed() call you merely  went with another bunch of 
>>>>> pseudorandom values than these ones you were hitting without it, not that 
>>>>> you were fixing a bug. In other words you just hit a more favourable  
>>>>> bunch 
>>>>> of pseudorandom data.
>>>>>
>>>>> To make such tests more robust, one needs to call th

Re: [sage-devel] Turn off consistent randomness in doctests by default?

2020-06-22 Thread 'Jonathan Kliem' via sage-devel

And in case you want reproducible doctests with values that look random you 
can always do something as `set_random_seed(0)`.

Am Montag, 22. Juni 2020 13:35:16 UTC+2 schrieb Jonathan Kliem:
>
> Yes there is need. Please go into any file of your choice and print out a 
> "random" value in a doctest and see what happens.
> There is not even a variation as Michael pointed out.
>
> If you start sage in a shell, there is variation. But sage in a shell 
> behaves different than in doctests. E.g. in doctests the dictionaries are 
> being sorted, in the shell not.
> And currently in doctests there is no variation at all in random numbers. 
> You will always get the very same numbers.
>
> Am Montag, 22. Juni 2020 13:26:24 UTC+2 schrieb Dima Pasechnik:
>>
>>
>>
>> On Mon, 22 Jun 2020, 12:18 'Jonathan Kliem' via sage-devel, <
>> sage-...@googlegroups.com> wrote:
>>
>>> Currently, the doctest setup produces the very same random numbers on 
>>> every instance.
>>>
>>> If you call `set_random_seed()` first you will get somewhat different 
>>> values on every single doctest run. It can still be annoying as not every 
>>> bot will catch every failure, but it is by far more likely to catch 
>>> regression eventually.
>>>
>>
>> there is no need to explicitly set the seed in these tests. Because it is 
>> done as Sage starts up.
>> By explicitly setting it you just restart the RNG, for no good reason.
>> There is no guarantee that this would give you "better" randomness.
>> If you want more random data in your doctest, repeat tests in a loop.
>>
>>
>>> It seems that there are a number of doctests that are supposed to run on 
>>> different values each time the doctest is run. However, currently exactly 
>>> one list of values is tested each time.
>>>
>>> It's not about getting very good pseudo randomness. It is just about 
>>> getting some variation of values.
>>>
>>> Am Montag, 22. Juni 2020 13:09:55 UTC+2 schrieb Dima Pasechnik:
>>>>
>>>>
>>>>
>>>> On Mon, 22 Jun 2020, 10:58 'Jonathan Kliem' via sage-devel, <
>>>> sage-...@googlegroups.com> wrote:
>>>>
>>>>> I had a doctest
>>>>>
>>>>> sage: ls = [randint(-100,100) for _ in range(4)]
>>>>> sage: intervals = [[x, x+randint(1,50)] for x in ls]
>>>>> sage: P = polytopes.hypercube(4, intervals, backend=
>>>>> 'field')
>>>>>
>>>>> which then checked `P` for consistency. However it was somewhat 
>>>>> meaningless (missing `set_random_seed()`) as all entries in `ls` where 
>>>>> positive. It never caught a sign error that we introduced  in #28866 
>>>>> <https://trac.sagemath.org/ticket/28866>.
>>>>> Adding `set_random_seed` to it, does catch the error.
>>>>>
>>>>
>>>> unless I misunderstand how Sage random numbers are set, by adding an 
>>>> explicit set_random_seed() call you merely  went with another bunch of 
>>>> pseudorandom values than these ones you were hitting without it, not that 
>>>> you were fixing a bug. In other words you just hit a more favourable  
>>>> bunch 
>>>> of pseudorandom data.
>>>>
>>>> To make such tests more robust, one needs to call them in a loop, 
>>>> without resetting the seed. Then you get a bit more of (pseudo) randomness.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Now this check for consistency certainly wasn't very good in the first 
>>>>> place, as two polyhedra might compare equal, even if one is set up 
>>>>> incorrectly (I just noticed this because of your post, thank you). But it 
>>>>> still would have caught the error even randomness was true randomness.
>>>>>
>>>>> You might say, I should have known to add `set_random_seed()` in the 
>>>>> first place, but I'm definitely not the only one who made that mistake 
>>>>> and 
>>>>> there are plenty of doctests that claim to test a random event, but they 
>>>>> really test the same event all over and over.
>>>>>
>>>>> Am Montag, 22. Juni 2020 11:24:59 UTC+2 schrieb Dima Pasechnik:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, 22 Jun 2020, 10:01 'Jonathan

Re: [sage-devel] Turn off consistent randomness in doctests by default?

2020-06-22 Thread 'Jonathan Kliem' via sage-devel

Yes there is need. Please go into any file of your choice and print out a 
"random" value in a doctest and see what happens.
There is not even a variation as Michael pointed out.

If you start sage in a shell, there is variation. But sage in a shell 
behaves different than in doctests. E.g. in doctests the dictionaries are 
being sorted, in the shell not.
And currently in doctests there is no variation at all in random numbers. 
You will always get the very same numbers.

Am Montag, 22. Juni 2020 13:26:24 UTC+2 schrieb Dima Pasechnik:
>
>
>
> On Mon, 22 Jun 2020, 12:18 'Jonathan Kliem' via sage-devel, <
> sage-...@googlegroups.com > wrote:
>
>> Currently, the doctest setup produces the very same random numbers on 
>> every instance.
>>
>> If you call `set_random_seed()` first you will get somewhat different 
>> values on every single doctest run. It can still be annoying as not every 
>> bot will catch every failure, but it is by far more likely to catch 
>> regression eventually.
>>
>
> there is no need to explicitly set the seed in these tests. Because it is 
> done as Sage starts up.
> By explicitly setting it you just restart the RNG, for no good reason.
> There is no guarantee that this would give you "better" randomness.
> If you want more random data in your doctest, repeat tests in a loop.
>
>
>> It seems that there are a number of doctests that are supposed to run on 
>> different values each time the doctest is run. However, currently exactly 
>> one list of values is tested each time.
>>
>> It's not about getting very good pseudo randomness. It is just about 
>> getting some variation of values.
>>
>> Am Montag, 22. Juni 2020 13:09:55 UTC+2 schrieb Dima Pasechnik:
>>>
>>>
>>>
>>> On Mon, 22 Jun 2020, 10:58 'Jonathan Kliem' via sage-devel, <
>>> sage-...@googlegroups.com> wrote:
>>>
>>>> I had a doctest
>>>>
>>>> sage: ls = [randint(-100,100) for _ in range(4)]
>>>> sage: intervals = [[x, x+randint(1,50)] for x in ls]
>>>> sage: P = polytopes.hypercube(4, intervals, backend='field'
>>>> )
>>>>
>>>> which then checked `P` for consistency. However it was somewhat 
>>>> meaningless (missing `set_random_seed()`) as all entries in `ls` where 
>>>> positive. It never caught a sign error that we introduced  in #28866 
>>>> <https://trac.sagemath.org/ticket/28866>.
>>>> Adding `set_random_seed` to it, does catch the error.
>>>>
>>>
>>> unless I misunderstand how Sage random numbers are set, by adding an 
>>> explicit set_random_seed() call you merely  went with another bunch of 
>>> pseudorandom values than these ones you were hitting without it, not that 
>>> you were fixing a bug. In other words you just hit a more favourable  bunch 
>>> of pseudorandom data.
>>>
>>> To make such tests more robust, one needs to call them in a loop, 
>>> without resetting the seed. Then you get a bit more of (pseudo) randomness.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Now this check for consistency certainly wasn't very good in the first 
>>>> place, as two polyhedra might compare equal, even if one is set up 
>>>> incorrectly (I just noticed this because of your post, thank you). But it 
>>>> still would have caught the error even randomness was true randomness.
>>>>
>>>> You might say, I should have known to add `set_random_seed()` in the 
>>>> first place, but I'm definitely not the only one who made that mistake and 
>>>> there are plenty of doctests that claim to test a random event, but they 
>>>> really test the same event all over and over.
>>>>
>>>> Am Montag, 22. Juni 2020 11:24:59 UTC+2 schrieb Dima Pasechnik:
>>>>>
>>>>>
>>>>>
>>>>> On Mon, 22 Jun 2020, 10:01 'Jonathan Kliem' via sage-devel, <
>>>>> sage-...@googlegroups.com> wrote:
>>>>>
>>>>>> Hi. Could we maybe turn off reproducible "randomness" in doctests by 
>>>>>> default. There are probably thousands of meaningless doctests because of 
>>>>>> this.
>>>>>>
>>>>>> E.g. https://trac.sagemath.org/ticket/29904
>>>>>>
>>>>>
>>>>> I don't understand, you say there that it went unnoticed due to a too 
>>>>> easy doctest. I

Re: [sage-devel] Turn off consistent randomness in doctests by default?

2020-06-22 Thread 'Jonathan Kliem' via sage-devel

Currently, the doctest setup produces the very same random numbers on every 
instance.

If you call `set_random_seed()` first you will get somewhat different 
values on every single doctest run. It can still be annoying as not every 
bot will catch every failure, but it is by far more likely to catch 
regression eventually.

It seems that there are a number of doctests that are supposed to run on 
different values each time the doctest is run. However, currently exactly 
one list of values is tested each time.

It's not about getting very good pseudo randomness. It is just about 
getting some variation of values.

Am Montag, 22. Juni 2020 13:09:55 UTC+2 schrieb Dima Pasechnik:
>
>
>
> On Mon, 22 Jun 2020, 10:58 'Jonathan Kliem' via sage-devel, <
> sage-...@googlegroups.com > wrote:
>
>> I had a doctest
>>
>> sage: ls = [randint(-100,100) for _ in range(4)]
>> sage: intervals = [[x, x+randint(1,50)] for x in ls]
>> sage: P = polytopes.hypercube(4, intervals, backend='field')
>>
>> which then checked `P` for consistency. However it was somewhat 
>> meaningless (missing `set_random_seed()`) as all entries in `ls` where 
>> positive. It never caught a sign error that we introduced  in #28866 
>> <https://trac.sagemath.org/ticket/28866>.
>> Adding `set_random_seed` to it, does catch the error.
>>
>
> unless I misunderstand how Sage random numbers are set, by adding an 
> explicit set_random_seed() call you merely  went with another bunch of 
> pseudorandom values than these ones you were hitting without it, not that 
> you were fixing a bug. In other words you just hit a more favourable  bunch 
> of pseudorandom data.
>
> To make such tests more robust, one needs to call them in a loop, without 
> resetting the seed. Then you get a bit more of (pseudo) randomness.
>
>
>
>
>
>
>
>> Now this check for consistency certainly wasn't very good in the first 
>> place, as two polyhedra might compare equal, even if one is set up 
>> incorrectly (I just noticed this because of your post, thank you). But it 
>> still would have caught the error even randomness was true randomness.
>>
>> You might say, I should have known to add `set_random_seed()` in the 
>> first place, but I'm definitely not the only one who made that mistake and 
>> there are plenty of doctests that claim to test a random event, but they 
>> really test the same event all over and over.
>>
>> Am Montag, 22. Juni 2020 11:24:59 UTC+2 schrieb Dima Pasechnik:
>>>
>>>
>>>
>>> On Mon, 22 Jun 2020, 10:01 'Jonathan Kliem' via sage-devel, <
>>> sage-...@googlegroups.com> wrote:
>>>
>>>> Hi. Could we maybe turn off reproducible "randomness" in doctests by 
>>>> default. There are probably thousands of meaningless doctests because of 
>>>> this.
>>>>
>>>> E.g. https://trac.sagemath.org/ticket/29904
>>>>
>>>
>>> I don't understand, you say there that it went unnoticed due to a too 
>>> easy doctest. I don't see how that one had anything to do with randomness.
>>>
>>> Also, could you explain what you mean by "randomness" there.  Doctests 
>>> are either tagged "random" (and do matching of answers skipped),
>>>
>>> or use random inputs. If a doctest with random input produces 
>>> inconsistent results due to not properly set seeds, it would have been 
>>> caught all along.
>>>
>>>
>>>
>>>> or the doctests for the namespace function `bernoulli` or the 
>>>> `number_of_partitions` function also in the namespace.
>>>>
>>>> Alternatively we should add `set_random_seed` to all of those places.
>>>>
>>>> Either way, this might be a huge project, because of possible bugs.
>>>>
>>>> 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-...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/sage-devel/6a5005ec-717e-400c-b253-514f9101bc72o%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/sage-devel/6a5005ec-717e-400c-b253-514f9101bc72o%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>> You received this message

Re: [sage-devel] Turn off consistent randomness in doctests by default?

2020-06-22 Thread 'Jonathan Kliem' via sage-devel

I had a doctest

sage: ls = [randint(-100,100) for _ in range(4)]
sage: intervals = [[x, x+randint(1,50)] for x in ls]
sage: P = polytopes.hypercube(4, intervals, backend='field')

which then checked `P` for consistency. However it was somewhat meaningless 
(missing `set_random_seed()`) as all entries in `ls` where positive. It 
never caught a sign error that we introduced  in #28866 
<https://trac.sagemath.org/ticket/28866>.
Adding `set_random_seed` to it, does catch the error.

Now this check for consistency certainly wasn't very good in the first 
place, as two polyhedra might compare equal, even if one is set up 
incorrectly (I just noticed this because of your post, thank you). But it 
still would have caught the error even randomness was true randomness.

You might say, I should have known to add `set_random_seed()` in the first 
place, but I'm definitely not the only one who made that mistake and there 
are plenty of doctests that claim to test a random event, but they really 
test the same event all over and over.

Am Montag, 22. Juni 2020 11:24:59 UTC+2 schrieb Dima Pasechnik:
>
>
>
> On Mon, 22 Jun 2020, 10:01 'Jonathan Kliem' via sage-devel, <
> sage-...@googlegroups.com > wrote:
>
>> Hi. Could we maybe turn off reproducible "randomness" in doctests by 
>> default. There are probably thousands of meaningless doctests because of 
>> this.
>>
>> E.g. https://trac.sagemath.org/ticket/29904
>>
>
> I don't understand, you say there that it went unnoticed due to a too easy 
> doctest. I don't see how that one had anything to do with randomness.
>
> Also, could you explain what you mean by "randomness" there.  Doctests are 
> either tagged "random" (and do matching of answers skipped),
>
> or use random inputs. If a doctest with random input produces inconsistent 
> results due to not properly set seeds, it would have been caught all along.
>
>
>
>> or the doctests for the namespace function `bernoulli` or the 
>> `number_of_partitions` function also in the namespace.
>>
>> Alternatively we should add `set_random_seed` to all of those places.
>>
>> Either way, this might be a huge project, because of possible bugs.
>>
>> 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-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/6a5005ec-717e-400c-b253-514f9101bc72o%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/6a5005ec-717e-400c-b253-514f9101bc72o%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/fcc3910a-e851-4f58-9a26-4eaf3dced699o%40googlegroups.com.

[sage-devel] Turn off consistent randomness in doctests by default?

2020-06-22 Thread 'Jonathan Kliem' via sage-devel

Hi. Could we maybe turn off reproducible "randomness" in doctests by 
default. There are probably thousands of meaningless doctests because of 
this.

E.g. https://trac.sagemath.org/ticket/29904

or the doctests for the namespace function `bernoulli` or the 
`number_of_partitions` function also in the namespace.

Alternatively we should add `set_random_seed` to all of those places.

Either way, this might be a huge project, because of possible bugs.

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/6a5005ec-717e-400c-b253-514f9101bc72o%40googlegroups.com.

Re: [sage-devel] AlarmInterrupt causes Sage to crash hard

2020-06-17 Thread 'Jonathan Kliem' via sage-devel

As we are doing the IPython update now, I thought of this thing again and I 
totally forgot how complex this is.

One way to solve this, is to cancel any alarm after evaluating input. That 
should solve the problem, but I have no idea if this is acceptable or not.

I didn't find a way to see, if an alarm is scheduled (it would be nicer if 
one could actually raise the correct error "alarm escaped interact").

Am Donnerstag, 7. Februar 2019 17:23:18 UTC+1 schrieb E. Madison Bray:
>
> On Thu, Feb 7, 2019 at 5:05 PM E. Madison Bray  > wrote: 
> > 
> > On Thu, Feb 7, 2019 at 4:53 PM Jeroen Demeyer  > wrote: 
> > > 
> > > On 2019-02-07 16:45, E. Madison Bray wrote: 
> > > > Apparently Jeroen argued about this with the IPython developers some 
> > > > time ago: https://github.com/ipython/ipython/pull/9867 
> > > 
> > > Indeed. Your post did seem familiar to me, but I actually forgot about 
> > > that discussion. 
> > 
> > FWIW we are on a rather old prompt_toolkit (1.0.9), whereas the 
> > current version is 2.0.7.  Newer versions of IPython have also 
> > upgraded to depend on prompt_toolkit >= 2.0.  It's possible then that 
> > this situation has been improved already, but I am not sure.  Sage 
> > still uses IPython 5.x since it is an LTS release. 
>
> Alas, I tried IPython 7 in a virtualenv and the situation is no 
> better.  The logic for handling the KeyboardInterrupt isn't even 
> right: It catches the KeyboardInterrupt, then calls 
> self._eventloop.stop(), but then rather than break out of IPython's 
> mainloop function it just continues the loop and tries to call 
> self.interact() with a no longer functioning prompt, and then crashes. 
> As a bonus, leaving my terminal in an extremely broken state. 
>
> This stuff is hard to get right, but still, no bueno... :( 
>

-- 
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/d5e5eede-c9a9-4fe1-a858-f7c7b1d0b6f1o%40googlegroups.com.

Re: [sage-devel] How to obtain zero entries of matrix fast

2020-06-10 Thread 'Jonathan Kliem' via sage-devel

Thank you.

I think I have figured out something that fits my needs.


https://trac.sagemath.org/ticket/29839

Am Mittwoch, 10. Juni 2020 12:28:18 UTC+2 schrieb Dima Pasechnik:
>
> On Wed, Jun 10, 2020 at 11:23 AM 'Jonathan Kliem' via sage-devel 
> > wrote: 
> > 
> > Given a matrix, I want to obtain a 0/1-matrix with 1 if and only if the 
> corresponding entry was 0. 
> > 
> > What is the fastest way of doing this? 
>
> I suppose it depends on what kind of matrix your slack_matrix is. 
> Does it allow fast C-level access methods? 
> Then write a cython code to create incidence_matrix from it. 
>
> > 
> > This is how I currently do it: 
> > 
> >R = ZZ 
> >zero = R(0) 
> >one = R(1) 
> > 
> > def is_zero(x): 
> >if x: 
> >return zero 
> >else: 
> >return one 
> > 
> > incidence_matrix = slack_matrix.apply_map(is_zero, R=R) 
> > 
> > Strangely, this takes up a lot of time. With 
> https://trac.sagemath.org/ticket/29837 this appears to be the bottle neck 
> of computing the incidence matrix for polyhedra, which would be strange. 
> > 
> > Can somebody help? Thank you. 
> > 
> > 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-...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/bdf6b005-fb90-4fc1-80e1-82218c562e3fo%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/3246d1f4-30d5-43f6-845d-9719d97cf4a7o%40googlegroups.com.

[sage-devel] How to obtain zero entries of matrix fast

2020-06-10 Thread 'Jonathan Kliem' via sage-devel

Given a matrix, I want to obtain a 0/1-matrix with 1 if and only if the 
corresponding entry was 0.

What is the fastest way of doing this?

This is how I currently do it:

   R = ZZ
   zero = R(0)
   one = R(1)

def is_zero(x):
   if x:
   return zero
   else:
   return one

incidence_matrix = slack_matrix.apply_map(is_zero, R=R)

Strangely, this takes up a lot of time. With 
https://trac.sagemath.org/ticket/29837 this appears to be the bottle neck 
of computing the incidence matrix for polyhedra, which would be strange.

Can somebody help? Thank you.

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/bdf6b005-fb90-4fc1-80e1-82218c562e3fo%40googlegroups.com.

[sage-devel] `_acted_upon_` computes result twice

2020-06-09 Thread 'Jonathan Kliem' via sage-devel

If I act upon a polyhedron, the result is computed twice. Why does this 
happen, how can one avoid this?

Currently, in `Polyhedron_base` (the element class) the method 
`_acted_upon_` is defined, which is where the action is discovered.

In the following example, I try to act on a polyhedron with a matrix. If I 
first discover the action, I'm much faster than when I just plainly 
multiply.

The reason is that for discovering action manually, the method `an_element` 
of parent is used. Very smart, because this is an almost trivial element 
just to make things work.

However, if I just plainly multiply, it is not done this way. Instead it 
computes the result twice. Why?

Thank you,

Jonathan

sage: P = polytopes.permutahedron(6)
sage: M = matrix(P.base_ring(), P.dim(), P.ambient_dim(),
: [v.vector() - P.an_affine_basis()[0].vector() 
for v in P.an_affine_basis()[1:]])
sage: %time coercion_model.analyse(M, P)
CPU times: user 18.5 ms, sys: 0 ns, total: 18.5 ms
Wall time: 17.5 ms
(['Action discovered.',
  Left action by Full MatrixSpace of 5 by 6 dense matrices over Integer Ring 
on Polyhedra in ZZ^6],
 Polyhedra in ZZ^5)
sage: %time M*P
CPU times: user 137 ms, sys: 3.39 ms, total: 141 ms
Wall time: 140 ms
A 5-dimensional polyhedron in ZZ^5 defined as the convex hull of 720 
vertices


sage: coercion_model.reset_cache()
sage: %time M*P
CPU times: user 256 ms, sys: 3.53 ms, total: 260 ms
Wall time: 259 ms
A 5-dimensional polyhedron in ZZ^5 defined as the convex hull of 720 
vertices

-- 
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/c6169b79-06e0-480d-89fc-80efa3ae1e90o%40googlegroups.com.

[sage-devel] Re: New Python version requirement for Sage?

2020-06-01 Thread 'Jonathan Kliem' via sage-devel

At the moment we are guessing that kucalc buildbot runs with ./configure 
--with-python=2, because this will lead to exactly this error message (and 
it really is the only way that this error message makes sense, because this 
module is present in python 3.5.2 and the import error doesn't make any 
sense).

Can someone verify/change that or contact someone who will do so?

Am Freitag, 29. Mai 2020 01:22:54 UTC+2 schrieb Matthias Koeppe:
>
> On Thursday, May 28, 2020 at 12:15:33 PM UTC-7, Volker Braun wrote:
>>
>> Another datapoint is that the kucalc buildbot runs on Ubuntu 16.04 LTS 
>> which has Python 3.5.2
>>
>
> I see you opened a ticket for a https://trac.sagemath.org/ticket/29753 
>
> It would be good if you could provide substantially more information about 
> that build.
>
>
>

-- 
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/926a4d53-c0de-4585-8d5e-b302497a9ea5%40googlegroups.com.

[sage-devel] Re: Online SageDays on the occasion of the 9.1 release?

2020-05-06 Thread 'Jonathan Kliem' via sage-devel

I would be interested.

Am Mittwoch, 6. Mai 2020 02:30:17 UTC+2 schrieb Matthias Koeppe:
>
> On Tuesday, May 5, 2020 at 12:49:33 PM UTC-7, Matthias Koeppe wrote:
>>
>> Would people be interested in some [online video] SageDays on the 
>> occasion of the upcoming 9.1 release?
>>
>
> Let me expand a little bit on what I would like to see:
>
> Video tutorials aimed at new Sage users
> Video tutorials on particular Sage components
> Video presentations on new features in 9.1
> Video breakout sessions for developers
>
> Given that in-person meetings --- which have been very important for 
> energizing Sage development in the past --- do not seem feasible for some 
> time, the video conferencing component seems crucial.  
>
> All video presentations would be given live and recorded for later use.
>
> I appreciate the discussion regarding suitable technical platforms for 
> this that has already started. But I would suggest to discuss the format, 
> contents, and timeline first.
>
> Matthias
>

-- 
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/92992cfc-658f-4283-8d1a-7ba5d43c3408%40googlegroups.com.

[sage-devel] How to obtain a meaningful log for documentation build

2020-05-04 Thread 'Jonathan Kliem' via sage-devel

Hello, does someone know what to do to obtain a meaningful log of the 
documentation build?

Antonio Rojas mentioned here 
https://groups.google.com/d/msg/sage-packaging/VU4h8IWGFLA/rU-8NCPjBgAJ 
that he had to downgrade sage to obtain this.

I'm trying to build sage with -march=native in #27122 
. However this causes a 
segmentation fault on several platforms similiar to #28800 
.

Instead of wasting tons of computation hours and guessing what package 
might cause this it would be nice to have a traceback so that I can 
accurately fix this.

At the moment this is my traceback

[combinat ] building [inventory]: targets for 368 source files that are out of 
date
[combinat ] updating environment: 368 added, 0 changed, 0 removed
Error building the documentation.
Traceback (most recent call last):
  File "/sage/local/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/sage/local/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File 
"/sage/local/lib/python3.7/site-packages/sage_setup/docbuild/__main__.py", line 
2, in 
main()
  File 
"/sage/local/lib/python3.7/site-packages/sage_setup/docbuild/__init__.py", line 
1720, in main
builder()
  File 
"/sage/local/lib/python3.7/site-packages/sage_setup/docbuild/__init__.py", line 
327, in _wrapper
getattr(get_builder(document), 'inventory')(*args, **kwds)
  File 
"/sage/local/lib/python3.7/site-packages/sage_setup/docbuild/__init__.py", line 
552, in _wrapper
self._build_everything_except_bibliography(lang, format, *args, **kwds)
  File 
"/sage/local/lib/python3.7/site-packages/sage_setup/docbuild/__init__.py", line 
538, in _build_everything_except_bibliography
build_many(build_ref_doc, non_references)
  File 
"/sage/local/lib/python3.7/site-packages/sage_setup/docbuild/__init__.py", line 
280, in build_many
_build_many(target, args, processes=NUM_THREADS)
  File "/sage/local/lib/python3.7/site-packages/sage_setup/docbuild/utils.py", 
line 283, in build_many
raise worker_exc.original_exception
Exception: ('Non-exception during docbuild: Segmentation fault', 
SignalError('Segmentation fault'))


Instead I would llike to obtain something as Antonio Rojas:

Traceback (most recent call last): 
  File "/usr/lib/python2.7/b
multiprocessing/process.py", line 267, in _bootstrap 
self.run() 
  File "/usr/lib/python2.7/multiprocessing/process.py", line 114, in run 
self._target(*self._args, **self._kwargs) 
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 113, in worker 
result = (True, func(*args, **kwds)) 
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 65, in mapstar 
return map(*args) 
  File 
"/build/sagemath-doc/src/sage-8.0/local-python/sage_setup/docbuild/__init__.py",
 
line 70, in build_ref_doc 
getattr(ReferenceSubBuilder(doc, lang), format)(*args, **kwds) 
  File 
"/build/sagemath-doc/src/sage-8.0/local-python/sage_setup/docbuild/__init__.py",
 
line 720, in _wrapper 
getattr(DocBuilder, build_type)(self, *args, **kwds) 
  File 
"/build/sagemath-doc/src/sage-8.0/local-python/sage_setup/docbuild/__init__.py",
 
line 104, in f 
runsphinx() 
  File 
"/build/sagemath-doc/src/sage-8.0/local-python/sage_setup/docbuild/sphinxbuild.py",
 
line 207, in runsphinx 
sphinx.cmdline.main(sys.argv) 
  File "/usr/lib/python2.7/site-packages/sphinx/cmdline.py", line 296, in 
main 
app.build(opts.force_all, filenames) 
  File "/usr/lib/python2.7/site-packages/sphinx/application.py", line 333, 
in build 
self.builder.build_update() 
  File "/usr/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 
251, in build_update 
'out of date' % len(to_build)) 
  File "/usr/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 
265, in build 
self.doctreedir, self.app)) 
  File "/usr/lib/python2.7/site-packages/sphinx/environment/__init__.py", 
line 549, in update 
self._read_serial(docnames, app) 
  File "/usr/lib/python2.7/site-packages/sphinx/environment/__init__.py", 
line 569, in _read_serial 
self.read_doc(docname, app) 
  File "/usr/lib/python2.7/site-packages/sphinx/environment/__init__.py", 
line 677, in read_doc 
pub.publish() 
  File "/usr/lib/python2.7/site-packages/docutils/core.py", line 217, in 
publish 
self.settings) 
  File "/usr/lib/python2.7/site-packages/sphinx/io.py", line 55, in read 
self.parse() 
  File "/usr/lib/python2.7/site-packages/docutils/readers/__init__.py", 
line 78, in parse 
self.parser.parse(self.input, document) 
  File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/__init__.py", 
line 191, in parse 
self.statemachine.run(inputlines, document, inliner=self.inliner) 
  File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", 
line 171, in run 
input_source=document['source']) 
  File

Re: [sage-devel] Re: Proposal for Sage 9.2: require "./configure" before "make"

2020-04-19 Thread 'Jonathan Kliem' via sage-devel

+1

-- 
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/759759b5-5e51-49ed-92d5-4e4f7ca13739%40googlegroups.com.

Re: [sage-devel] Re: Proposal for Sage 9.2: require "./configure" before "make"

2020-04-19 Thread 'Jonathan Kliem' via sage-devel

Will this speed up the `make build` or `sage -br` process? It used to be 
really quick, but now it takes much longer and rechecks all the packages.
I really don't want this if I'm just changing a line of code to see, if 
this fixes my problem.

Am Sonntag, 19. April 2020 01:48:23 UTC+2 schrieb Dima Pasechnik:
>
> On Sun, Apr 19, 2020 at 5:11 AM Nils Bruin > 
> wrote: 
> > 
> > On Saturday, April 18, 2020 at 1:51:29 PM UTC-7, John H Palmieri wrote: 
> >> 
> >> 
> >> Some disadvantages: 
> >> 
> >> - It adds one step or a least requires the typing of some extra 
> characters 
> >> - It's not what we're used to doing to build Sage. 
> >> 
> > 
> > Isn't it possible to have a make target "make configure"? 
> > 
> > Wouldn't it be possible to make this part of a "make cleanall", or 
> whatever an appropriate metatarget is? 
> > 
> > Is there some way to detect when  ./confiugre absolutely needs to be 
> run, and make that part of some metatarget? 
> > 
> > What I envision is that we can have both: 
> > 
> >  * running ./configure; make works (and doesn't do way too much work) 
> >  * running "make", or perhaps some target "make confbuild" works and 
> runs configure. 
> > 
> > There is of course the issue that make already runs loads of submakes of 
> packages, that in turn must run ./configure, so in the sage build process, 
> "./configure" is already commonly triggered by make. I don't think we'd 
> want to change that, so it seems to me it makes sense to have "./configure" 
> run under control of make for sage as well (under certain conditions). 
>
> make should not trigger the "normal" run of main ./configure, as this 
> leads to various chicken vs egg problems, which can only be cured by 
> repeatedly triggering ./configure runs 
> all the time, As out ./configure is slow, this is a waste of time to have 
> this. 
> We can of course create a special target that will trigger 
> ./configure, but why defviate from the usual commonmy known 
> ./configure && make ? 
>
> > 
> > -- 
> > 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-...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/74a8fed6-eb02-492e-9e9e-5d7e28857b0a%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/3da8c90b-7a0f-4d29-8f3c-4f1c5456c1bf%40googlegroups.com.

[sage-devel] Re: Optional packages that need fixing for 9.1

2020-04-19 Thread 'Jonathan Kliem' via sage-devel

*primecount*:

primecount requires at least gcc 5.0:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350

*latte_int*

I'm guessing it needs to be configured with extra flag -std=c++11 added to 
CXX (in this specific case).

NTL version 5.4 or greater is required for LattE to compile. Please 
make sure NTL is installed and specify its location with the option 
--with-ntl= when running configure. 
Hint: If NTL was configured in C++11 mode, then LattE needs to 
be configured with a compiler in C++11 mode as well by passing 
CXX="g++ -std=c++11" or similar.

Am Sonntag, 19. April 2020 07:46:58 UTC+2 schrieb Matthias Koeppe:
>
> See https://github.com/mkoeppe/sage/actions/runs/81669565 for full logs
>
> *primecount*
> - on ubuntu-trusty and debian-jessie, centos-7
>
> [ 12%] Building CXX object 
> lib/primesieve/CMakeFiles/libprimesieve.dir/src/PrintPrimes.cpp.o
> cd /sage/local/var/tmp/sage/build/primecount-5.1/src/lib/primesieve && 
> /usr/bin/g++  -std=gnu++11  -Dlibprimesieve_EXPORTS 
> -I/sage/local/var/tmp/sage/build/primecount-5.1/src/lib/primesieve/include  
> -O3 -DNDEBUG -fPIC   -std=gnu++11 -o 
> CMakeFiles/libprimesieve.dir/src/PrintPrimes.cpp.o -c 
> /sage/local/var/tmp/sage/build/primecount-5.1/src/lib/primesieve/src/PrintPrimes.cpp
> /sage/local/var/tmp/sage/build/primecount-5.1/src/lib/primesieve/src/MemoryPool.cpp:
>  
> In member function 'void primesieve::MemoryPool::allocateBuckets()':
> /sage/local/var/tmp/sage/build/primecount-5.1/src/lib/primesieve/src/MemoryPool.cpp:77:8:
>  
> error: 'align' is not a member of 'std'
>if (!std::align(sizeof(Bucket), sizeof(Bucket), ptr, bytes))
> ^
> *perl_cpan_polymake_prereq*
> - on fedora-{28,29,30,31}, centos-7, ubuntu-bionic-i386
>
> *sage_numerical_backends_coin*
> - on conda-forge-macos
>
> *lrslib*
> - on fedora-{30,31} and archlinux
>
> *qepcad*
> - on slackware
>
> *openssl*
> - on ubuntu-bionic-i386, debian-buster-i386
>
> *latte_int*
> - on conda-forge-macos
>
> No tests of optional packages on cygwin so far
>
>
>

-- 
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/08bdf3d7-9af6-4d16-8307-850814a31e47%40googlegroups.com.

Re: [sage-devel] Renaming `affine_hull` for polyhedra

2020-03-13 Thread 'Jonathan Kliem' via sage-devel



Am Freitag, 13. März 2020 17:52:37 UTC+1 schrieb vdelecroix:
>
>
>
> Le 13/03/2020 à 17:49, Dima Pasechnik a écrit : 
> > On Fri, 13 Mar 2020, 16:46 'Jonathan Kliem' via sage-devel, < 
> > sage-...@googlegroups.com > wrote: 
> > 
> >> Currently, the method `affine_hull` returns a polyhedron projected into 
> >> its affine hull. 
> >> However, the affine hull of a polyhedron is the smallest affine set 
> >> containing it. 
> >> 
> >> Therefore, I propose to rename the method: 
> >> 
> >> affine_hull -> in_affine_hull 
> >> 
> >> in #29326. <https://trac.sagemath.org/ticket/29326> 
> >> 
> >> Do you have thoughts about it? Does anyone have a better name? Opinions 
> >> are welcome. 
> >> 
> > 
> > affine_hull_projection 
>
> This is indeed much better. 
>

I agree.

-- 
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/6753396d-2dc5-417e-b2cb-a319b582d339%40googlegroups.com.

[sage-devel] Renaming `affine_hull` for polyhedra

2020-03-13 Thread 'Jonathan Kliem' via sage-devel

Currently, the method `affine_hull` returns a polyhedron projected into its 
affine hull.
However, the affine hull of a polyhedron is the smallest affine set 
containing it.

Therefore, I propose to rename the method:

affine_hull -> in_affine_hull

in #29326. 

Do you have thoughts about it? Does anyone have a better name? Opinions are 
welcome.

Thanks,

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/36c4dbc3-c428-4617-8407-b1b8e3e77c59%40googlegroups.com.

[sage-devel] Error building sage while installing r-3.6.2

2020-01-28 Thread 'Jonathan Kliem' via sage-devel

Hello,

I'm having trouble installing R with the newest beta on

Ubuntu 18.04.3 LTS, using
gcc 7.4.0

The log file has a bunch of messages of this type

2301 ../../src/include/R_ext/BLAS.h:103:55: error: expected declaration 
specifiers or '...' before ')' token
2302const double *beta, double *y, const int *incy FCLEN);

I attached the log file.

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/97b00f2d-cc09-47cf-8bd1-9a9c34094089%40googlegroups.com.
Found local metadata for r-3.6.2
Attempting to download package R-3.6.2.tar.gz from mirrors
https://mirror.koddos.net/sagemath/spkg/upstream/r/R-3.6.2.tar.gz
[..]
r-3.6.2

Setting up build directory for r-3.6.2
Finished extraction
Applying patches from ../patches...
Applying ../patches/autoconf_verb_dash.patch
patching file configure
Hunk #1 succeeded at 24966 with fuzz 2 (offset 129 lines).
Hunk #2 succeeded at 25323 (offset 130 lines).
Applying ../patches/cygwin_build_support.patch
patching file configure
Hunk #1 succeeded at 27637 (offset -86 lines).
Hunk #2 succeeded at 27879 (offset -117 lines).
Hunk #3 succeeded at 27892 (offset -117 lines).
Hunk #4 succeeded at 27905 (offset -117 lines).
patching file configure.ac
Hunk #1 succeeded at 1280 (offset -14 lines).
Hunk #2 succeeded at 1537 (offset -14 lines).
Hunk #3 succeeded at 1549 (offset -14 lines).
Hunk #4 succeeded at 1561 (offset -14 lines).
patching file src/library/tools/R/install.R
Hunk #1 succeeded at 1215 (offset 374 lines).
Applying ../patches/hardcoded_dirs.patch
patching file src/scripts/Makefile.in
Hunk #1 succeeded at 87 (offset -2 lines).
patching file src/scripts/R.sh.in
Applying ../patches/libcurl_https_support.patch
patching file configure
Hunk #1 succeeded at 42943 (offset 1874 lines).
Hunk #2 succeeded at 42952 (offset 1874 lines).
patching file m4/R.m4
Hunk #1 succeeded at 4181 (offset -24 lines).
Applying ../patches/link_all_shared_libs.patch
patching file etc/Makeconf.in
Hunk #1 succeeded at 159 with fuzz 2 (offset 9 lines).
Applying ../patches/m4_macro_bug.patch
patching file configure
Hunk #1 succeeded at 42543 (offset 1744 lines).
Hunk #2 succeeded at 42587 with fuzz 2 (offset 1744 lines).
patching file m4/R.m4
Hunk #1 succeeded at 3100 (offset -90 lines).
Hunk #2 succeeded at 3122 with fuzz 2 (offset -90 lines).
Applying ../patches/rcmd_exec.patch
patching file src/scripts/Rcmd.in

Host system:
Linux kliem-ThinkPad-L570 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1) 

Warning: No files to uninstall for 'r'
Uninstalling existing 'r'
Removing stamp file 
'/home/jonathan/Applications/sage/local/var/lib/sage/installed/r-3.6.1'
R_CONFIGURE_BLAS=--with-blas=-L/home/jonathan/Applications/sage/local/lib 
-lopenblas
R_CONFIGURE_LAPACK=--with-lapack=-L/home/jonathan/Applications/sage/local/lib 
-lopenblas
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
loading site script './config.site'
loading build-specific script './config.site'
checking for pwd... /bin/pwd
checking whether builddir is srcdir... yes
checking whether ln -s

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

2020-01-24 Thread 'Jonathan Kliem' via sage-devel

Dear Vincent,

thanks for the reply.

So I guess, it makes sense to remove _cg_rev from CGraphBackend then. This 
also a step towards unifying the different backends and putting common 
methods in CGraph instead for a copy in each backend.

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/ea94aa96-4fac-4365-96b4-733772e3992e%40googlegroups.com.

[sage-devel] Removing reverse graph from CGraph

2020-01-07 Thread 'Jonathan Kliem' via sage-devel

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/2964eb6e-e5d1-433e-9105-59952169c2db%40googlegroups.com.

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

2020-01-07 Thread 'Jonathan Kliem' via sage-devel

Just a silly question. How do we know that the code remains python2 
compatible in the first place?

As far as I can see all the patchbots run python3 so it is very easy to 
break something. 9.0 is supposed to be fully python2 compatible, but are 
the doctests being tested for that?

If we don't test the upcoming tickets for python2 compatibility, we have de 
facto stopped supporting python2 already.

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/e1faa06c-4935-4080-9895-96ae955948bc%40googlegroups.com.

Re: [sage-devel] Re: NotImplementedError for immutable graphs

2019-12-12 Thread 'Jonathan Kliem' via sage-devel

Ok. I opened a ticket for it.

https://trac.sagemath.org/ticket/28874

> On Dec 12, 2019, at 7:08 AM, Travis Scrimshaw  wrote:
> 
> I always think more meaningful messages are good (with the correct type of 
> error too). So +1 on opening a ticket.
> 
> Best,
> Travis
> 
> 
>> On Thursday, December 12, 2019 at 3:54:13 PM UTC+10, Jonathan Kliem wrote:
>> The point is exactly that the error message should be more meaningful. If a 
>> user doesn't expect an immutable object, it could be tuff to figure out the 
>> problem.
>> 
>> For example vectors give a more meaningful message, which I would just copy 
>> for matrices:
>> 
>> ValueError: vector is immutable; please change a copy instead (use copy())
>> 
>> As I'm not into graphs very much, I wanted to have some feedback before I 
>> just go along and open a ticket for this.
>> 
>> Am Donnerstag, 12. Dezember 2019 01:49:57 UTC+1 schrieb Travis Scrimshaw:
>>> 
>>> Sorry, I think I misinterpreted the question. The solution I am proposing 
>>> is correct in some sense, but the better (or just another?) thing to do 
>>> would be to have the corresponding mutation methods of the immutable 
>>> backends raise a more appropriate error.
>>> 
>>> Best,
>>> Travis
>>> 
>>> 
 On Thursday, December 12, 2019 at 10:47:26 AM UTC+10, Travis Scrimshaw 
 wrote:
 Hi Jonathan,
You are trying to mutate an immutable graph (the default is 
 inplace=True), so it is not surprising that it is throwing an error IMO. 
 However, the error message and type should be improved; in particular 
 reverse_edge() should raise an error if inplace=True and the graph is 
 immutable.
 
 Best,
 Travis
 
 
> On Wednesday, December 11, 2019 at 9:58:05 PM UTC+10, Jonathan Kliem 
> wrote:
> Dear all,
> 
> when a graph is immutable, there are meaningless error messages that make 
> it hard for the user to guess what is going on (see below).
> 
> When I create graphs like this, I know perfectly well what is going on. 
> However, when this is done in a cached method, it is hard for the user to 
> figure out the problem, isn't it?
> 
> I'm currently working on #28828 and returning an immutable graph seems to 
> leave the user clueless about why the code breaks. Of course one could 
> just cache a private method and return a copy or manually cache it, but 
> that seems to be against the point of @cached_method.
> 
> Any suggestion for a good fix? Am I missing something?
> 
> Thanks,
> 
> Jonathan
> 
> sage: G = Graph(immutable=True)
> sage: G.add_edge([0,1])
> ---
> NotImplementedError   Traceback (most recent call 
> last)
>  in ()
> > 1 G.add_edge([Integer(0),Integer(1)])
> 
> /home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/graphs/generic_graph.py
>  in add_edge(self, u, v, label)
>   10816 pass
>   10817 
> > 10818 self._backend.add_edge(u, v, label, self._directed)
>   10819 
>   10820 def add_edges(self, edges, loops=True):
> 
> /home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/graphs/base/graph_backends.pyx
>  in sage.graphs.base.graph_backends.GenericGraphBackend.add_edge 
> (build/cythonized/sage/graphs/base/graph_backends.c:1694)()
> 100 NotImplementedError
> 101  """
> --> 102 raise NotImplementedError()
> 103 
> 104 def add_edges(self, edges, directed):
> 
> NotImplementedError: 
> 
> 
> sage: G = DiGraph([[0,1]], immutable=True)
> sage: G.reverse_edges(G.edges())
> ---
> NotImplementedError   Traceback (most recent call 
> last)
>  in ()
> > 1 G.reverse_edges(G.edges())
> 
> /home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/graphs/digraph.py
>  in reverse_edges(self, edges, inplace, multiedges)
>2074 tempG = self if inplace else copy(self)
>2075 for e in edges:
> -> 2076 
> tempG.reverse_edge(e,inplace=True,multiedges=multiedges)
>2077 if not inplace:
>2078 return tempG
> 
> /home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/graphs/digraph.py
>  in reverse_edge(self, u, v, label, inplace, multiedges)
>1968  "multiedges is True or False.")
>1969 else:
> -> 1970 tempG.delete_edge(u, v, label)
>1971 tempG.add_edge(v, u, label)
>1972 
> 
> /home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/graphs/generic_graph.py
>  in

[sage-devel] Re: NotImplementedError for immutable graphs

2019-12-11 Thread 'Jonathan Kliem' via sage-devel

The point is exactly that the error message should be more meaningful. If a 
user doesn't expect an immutable object, it could be tuff to figure out the 
problem.

For example vectors give a more meaningful message, which I would just copy 
for matrices:

ValueError: vector is immutable; please change a copy instead (use copy())

As I'm not into graphs very much, I wanted to have some feedback before I 
just go along and open a ticket for this.

Am Donnerstag, 12. Dezember 2019 01:49:57 UTC+1 schrieb Travis Scrimshaw:
>
> Sorry, I think I misinterpreted the question. The solution I am proposing 
> is correct in some sense, but the better (or just another?) thing to do 
> would be to have the corresponding mutation methods of the immutable 
> backends raise a more appropriate error.
>
> Best,
> Travis
>
>
> On Thursday, December 12, 2019 at 10:47:26 AM UTC+10, Travis Scrimshaw 
> wrote:
>>
>> Hi Jonathan,
>>You are trying to mutate an immutable graph (the default is 
>> inplace=True), so it is not surprising that it is throwing an error IMO. 
>> However, the error message and type should be improved; in particular 
>> reverse_edge() should raise an error if inplace=True and the graph is 
>> immutable.
>>
>> Best,
>> Travis
>>
>>
>> On Wednesday, December 11, 2019 at 9:58:05 PM UTC+10, Jonathan Kliem 
>> wrote:
>>>
>>> Dear all,
>>>
>>> when a graph is immutable, there are meaningless error messages that 
>>> make it hard for the user to guess what is going on (see below).
>>>
>>> When I create graphs like this, I know perfectly well what is going on. 
>>> However, when this is done in a cached method, it is hard for the user to 
>>> figure out the problem, isn't it?
>>>
>>> I'm currently working on #28828  
>>> and returning an immutable graph seems to leave the user clueless about why 
>>> the code breaks. Of course one could just cache a private method and return 
>>> a copy or manually cache it, but that seems to be against the point of 
>>> @cached_method.
>>>
>>> Any suggestion for a good fix? Am I missing something?
>>>
>>> Thanks,
>>>
>>> Jonathan
>>>
>>> sage: G = Graph(immutable=True)
>>> sage: G.add_edge([0,1])
>>>
>>> ---
>>> NotImplementedError   Traceback (most recent call 
>>> last)
>>>  in ()
>>> > 1 G.add_edge([Integer(0),Integer(1)])
>>>
>>> /home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/
>>> graphs/generic_graph.py in add_edge(self, u, v, label)
>>>   10816 pass
>>>   10817 
>>> > 10818 self._backend.add_edge(u, v, label, self._directed)
>>>   10819 
>>>   10820 def add_edges(self, edges, loops=True):
>>>
>>> /home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/
>>> graphs/base/graph_backends.pyx in sage.graphs.base.graph_backends.
>>> GenericGraphBackend.add_edge (build/cythonized/sage/graphs/base/
>>> graph_backends.c:1694)()
>>> 100 NotImplementedError
>>> 101  """
>>> --> 102 raise NotImplementedError()
>>> 103 
>>> 104 def add_edges(self, edges, directed):
>>>
>>> NotImplementedError: 
>>>
>>>
>>> sage: G = DiGraph([[0,1]], immutable=True)
>>> sage: G.reverse_edges(G.edges())
>>>
>>> ---
>>> NotImplementedError   Traceback (most recent call 
>>> last)
>>>  in ()
>>> > 1 G.reverse_edges(G.edges())
>>>
>>> /home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/
>>> graphs/digraph.py in reverse_edges(self, edges, inplace, multiedges)
>>>2074 tempG = self if inplace else copy(self)
>>>2075 for e in edges:
>>> -> 2076 tempG.reverse_edge(e,inplace=True,multiedges=
>>> multiedges)
>>>2077 if not inplace:
>>>2078 return tempG
>>>
>>> /home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/
>>> graphs/digraph.py in reverse_edge(self, u, v, label, inplace, multiedges
>>> )
>>>1968  "multiedges is True or False.")
>>>1969 else:
>>> -> 1970 tempG.delete_edge(u, v, label)
>>>1971 tempG.add_edge(v, u, label)
>>>1972 
>>>
>>> /home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/
>>> graphs/generic_graph.py in delete_edge(self, u, v, label)
>>>   11130 u, v = u
>>>   11131 label = None
>>> > 11132 self._backend.del_edge(u, v, label, self._directed)
>>>   11133 
>>>   11134 def delete_edges(self, edges):
>>>
>>> /home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/
>>> graphs/base/graph_backends.pyx in sage.graphs.base.graph_backends.
>>> GenericGraphBackend.del_edge (build/cythonized/sage/graphs/base/
>>> graph_backends.c:2273)()
>>> 248 NotImplementedError
>>> 249

[sage-devel] NotImplementedError for immutable graphs

2019-12-11 Thread 'Jonathan Kliem' via sage-devel

Dear all,

when a graph is immutable, there are meaningless error messages that make 
it hard for the user to guess what is going on (see below).

When I create graphs like this, I know perfectly well what is going on. 
However, when this is done in a cached method, it is hard for the user to 
figure out the problem, isn't it?

I'm currently working on #28828  
and returning an immutable graph seems to leave the user clueless about why 
the code breaks. Of course one could just cache a private method and return 
a copy or manually cache it, but that seems to be against the point of 
@cached_method.

Any suggestion for a good fix? Am I missing something?

Thanks,

Jonathan

sage: G = Graph(immutable=True)
sage: G.add_edge([0,1])
---
NotImplementedError   Traceback (most recent call last)
 in ()
> 1 G.add_edge([Integer(0),Integer(1)])

/home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/
graphs/generic_graph.py in add_edge(self, u, v, label)
  10816 pass
  10817 
> 10818 self._backend.add_edge(u, v, label, self._directed)
  10819 
  10820 def add_edges(self, edges, loops=True):

/home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/
graphs/base/graph_backends.pyx in sage.graphs.base.graph_backends.
GenericGraphBackend.add_edge (build/cythonized/sage/graphs/base/
graph_backends.c:1694)()
100 NotImplementedError
101  """
--> 102 raise NotImplementedError()
103 
104 def add_edges(self, edges, directed):

NotImplementedError: 


sage: G = DiGraph([[0,1]], immutable=True)
sage: G.reverse_edges(G.edges())
---
NotImplementedError   Traceback (most recent call last)
 in ()
> 1 G.reverse_edges(G.edges())

/home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/
graphs/digraph.py in reverse_edges(self, edges, inplace, multiedges)
   2074 tempG = self if inplace else copy(self)
   2075 for e in edges:
-> 2076 tempG.reverse_edge(e,inplace=True,multiedges=multiedges)
   2077 if not inplace:
   2078 return tempG

/home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/
graphs/digraph.py in reverse_edge(self, u, v, label, inplace, multiedges)
   1968  "multiedges is True or False.")
   1969 else:
-> 1970 tempG.delete_edge(u, v, label)
   1971 tempG.add_edge(v, u, label)
   1972 

/home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/
graphs/generic_graph.py in delete_edge(self, u, v, label)
  11130 u, v = u
  11131 label = None
> 11132 self._backend.del_edge(u, v, label, self._directed)
  11133 
  11134 def delete_edges(self, edges):

/home/jonathan/Applications/sage/local/lib/python3.7/site-packages/sage/
graphs/base/graph_backends.pyx in sage.graphs.base.graph_backends.
GenericGraphBackend.del_edge (build/cythonized/sage/graphs/base/
graph_backends.c:2273)()
248 NotImplementedError
249 """
--> 250 raise NotImplementedError()
251 
252 def del_vertex(self, v):

NotImplementedError: 


-- 
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/34c6ccdf-1ca6-4831-a986-2446b3b705f9%40googlegroups.com.

[sage-devel] Re: Coercion between quadratic fields fails (by default)

2019-12-05 Thread 'Jonathan Kliem' via sage-devel

According to the above discussion I marked 
https://trac.sagemath.org/ticket/28774 as wontfix, please review.

Am Dienstag, 3. Dezember 2019 13:16:30 UTC+1 schrieb Simon King:
>
> Hi Nils, 
>
> On 2019-12-02, Nils Bruin > wrote: 
> > On Monday, December 2, 2019 at 3:18:20 PM UTC-8, Michael Orlitzky wrote: 
> >> 
> >> Who do I have to make a campaign donation to if I want this to be the 
> >> default? 
> >> 
> > 
> > The Society for the Prevention of Predictable Performance would be a 
> good 
> > place to start. 
> > 
> > Trying to find a radical expression for an algebraic number can be 
> pretty 
> > expensive and, of course, may fail: 
> > 
> > sage: QQbar.options.display_format="radical" 
> > sage: QQbar['x'](x^5+x+3).roots() 
> > [(-1.132997565885066?, 1), 
> >  (-0.4753807566695497? - 1.129701725095409?*I, 1), 
> >  (-0.4753807566695497? + 1.129701725095409?*I, 1), 
> >  (1.041879539612083? - 0.822870338109958?*I, 1), 
> >  (1.041879539612083? + 0.822870338109958?*I, 1)] 
> > 
> > so I don't think it will ever be a default. 
>
> Hang on, does that mean that with display_format="radical", Sage will 
> show a radical expression when it finds one, and will show numerical 
> noise when it finds none (i.e., it does not simply raise an error)? 
>
> Indeed: 
>   sage: QQbar['x'](((x^2+3)*(x^2-3)*(x^2+15)).expand()).roots() 
>   [(-sqrt(3), 1), 
>(sqrt(3), 1), 
>(-I*sqrt(15), 1), 
>(-I*sqrt(3), 1), 
>(I*sqrt(3), 1), 
>(I*sqrt(15), 1)] 
>
> That's actually quite nice! So, it would be a good default -- if 
> performance wouldn't be a problem. 
>
> Anyway, thank you for pointing to this option, because I wasn't aware 
> that it exists and would have liked to use it from time to time. 
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/62431e94-b92b-4179-a3c5-2cccb97f8957%40googlegroups.com.

[sage-devel] Re: Coercion between quadratic fields fails (by default)

2019-11-30 Thread 'Jonathan Kliem' via sage-devel

Thanks for the comment.

Am Freitag, 29. November 2019 22:47:13 UTC+1 schrieb Nils Bruin:
>
>
>
> On Friday, November 29, 2019 at 12:45:45 PM UTC-8, Jonathan Kliem wrote:
>>
>> The following leads to a TypeError:
>>
>> sage: K2. = QuadraticField(2)
>> sage: K3. = QuadraticField(3)
>> sage: sqrt2 + sqrt3
>>
>> Both of them are real embedded by default, so coercion should work (at least 
>> this is my opinion).
>>
>> This can be fixed by specifying that both of them are embedded into the 
>> algebraic reals (at the moment RLF is default).
>>
>>
> Embedding into RLF is really meant to be "embedding into real floats, with 
> yet-to-be-specified precision". Float arithmetic has very different 
> properties from AA/QQbar: it's reliably quick, but imprecise and with no 
> equality test., whereas AA/QQbar is unpredictable in computation speed and 
> possibly VERY expensive (but reliable) equality test. 
>

> I don't know if the choice of RLF was appropriate for a default embedding, 
> but I'd be wary of embedding in AA/QQbar by default, because they are so 
> unpredictable in their performance. Generally, you should NOT be computing 
> in them except for exploratory work. It's usually possible to be more 
> specific about the desired field with a bit of analysis and then you'll get 
> much better and reliable performance.
>

So is the current setup is meant to tell the user to think and figure out a 
good conversion him/herself?

I mean there is composite field and one can always convert to that and work 
there. Or convert to the reals, if one looks for a numerical solution.

Still conversion to AA and QQbar should work without numerical noise. But 
that is a different topic.


> Also casting sqrt2 to AA does not work at the moment (at least not without 
> numerical noise).
>>
>> Is it reasonable to apply this by default (i.e. embed quadratic fields into 
>> AA/QQbar)?
>> This would lead to failing doctests for mostly two reasons:
>>
>>
>>- numerical approximation works differently for AA and RLF
>>- cyclotomic should be standard embedded into QQbar then
>>
>> Are there specific reasons, that they are embedded into RLF resp. CLF at 
>> the moment?
>>
>> I opened a 28774  for this.
>>
>> My motivation: It seems very natural to construct a polyhedron over 
>> quadratic fields. However, coercion of those polyhedra does not work. See 
>> 28776 
>>
>

-- 
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/929277c9-c038-424b-b456-0d788b4db853%40googlegroups.com.

[sage-devel] Coercion between quadratic fields fails (by default)

2019-11-29 Thread 'Jonathan Kliem' via sage-devel



The following leads to a TypeError:

sage: K2. = QuadraticField(2)
sage: K3. = QuadraticField(3)
sage: sqrt2 + sqrt3

Both of them are real embedded by default, so coercion should work (at least 
this is my opinion).

This can be fixed by specifying that both of them are embedded into the 
algebraic reals (at the moment RLF is default).
Also casting sqrt2 to AA does not work at the moment (at least not without 
numerical noise).

Is it reasonable to apply this by default (i.e. embed quadratic fields into 
AA/QQbar)?
This would lead to failing doctests for mostly two reasons:


   - numerical approximation works differently for AA and RLF
   - cyclotomic should be standard embedded into QQbar then

Are there specific reasons, that they are embedded into RLF resp. CLF at 
the moment?

I opened a 28774  for this.

My motivation: It seems very natural to construct a polyhedron over 
quadratic fields. However, coercion of those polyhedra does not work. See 
28776 

-- 
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/735ec8d8-742b-4db0-9606-5a20b7b32a28%40googlegroups.com.

[sage-devel] Re: Why does FiniteLatticePoset sometimes makes copies?

2019-10-30 Thread 'Jonathan Kliem' via sage-devel

Ok, thanks again. Using the construction parameters is definitely an option 
and I will change it soon.

Am Mittwoch, 30. Oktober 2019 22:59:34 UTC+1 schrieb Nils Bruin:
>
> On Wednesday, October 30, 2019 at 2:31:37 PM UTC-7, Jonathan Kliem wrote:
>>
>> Basically, I can just do it like this. Now, if I understand it correctly:
>>
>> Face lattice as it is, should not be cached. Instead its probably fine to 
>> store the version with indices and convert on each call. Or the DiGraph. 
>> Just not the FiniteLatticePoset with labels that point to self.
>>
>
> As a rule, a function that returns a UniqueRepresentation object should 
> NOT be a cached method. The UniqueRepresentation constructor is already 
> cached: it uses the construction parameters as a key into the cache, and 
> this is a global cache.
>
> What you can do is cache the construction keys themselves (provided they 
> are not UniqueRepresentation objects), so that you can call 
> UniqueRepresentation quickly. If that doesn't meet your performance 
> requirements then you shouldn't be using a UniqueRepresentation object.
>
> The reason why caching UniqueRepresentation objects VERY easily leads to 
> memory leaks is documented in many places, see e.g. 
> https://groups.google.com/forum/#!msg/sage-devel/q5uy_lI11jg/CB15fcRmE4cJ 
> (coincidentally also about FinitePoset).
>
> It is possible to cache a reference to a UniqueRepresentation object A on 
> an object B, but then you must make absolutely sure that there is NO 
> reference path from A to B. Generally, mathematical objects hold references 
> to the objects they are constructed from (possibly indirectly), so 
> generally this is not an option. This is a fundamental design weakness of 
> UniqueRepresentation that people get caught by again and again. Making 
> objects UniqueRepresentation is a very costly thing to do and therefore 
> very undesirable, even if it may seem like a nice property to have 
> superficially. It's just a requirement for participating in some of the 
> more advanced  coercion discovery, because there "is" is used rather than 
> "==" for performance reasons.
>
>
>
>
>

-- 
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/82afedba-ff0b-4e9f-bdf8-29c51c353929%40googlegroups.com.

[sage-devel] Re: Why does FiniteLatticePoset sometimes makes copies?

2019-10-30 Thread 'Jonathan Kliem' via sage-devel

Thanks. I think I have it figured out now.

The current construction passes to the face lattice the ID of self as a 
key. This is why F1 and F2 are not identical.

Basically, I can just do it like this. Now, if I understand it correctly:

Face lattice as it is, should not be cached. Instead its probably fine to 
store the version with indices and convert on each call. Or the DiGraph. 
Just not the FiniteLatticePoset with labels that point to self.

Am Mittwoch, 30. Oktober 2019 21:11:54 UTC+1 schrieb Nils Bruin:
>
> I haven't dug very deep into this, but the following looks suspicious:
>
> sage: o1 = lattice_polytope.cross_polytope(3)
> sage: o2 = lattice_polytope.cross_polytope(3)
> sage: o1==o2
> True
> sage: o1 is o2
> False
>
> This in itself isn't a problem, but o1.face_lattice() is a 
> UniqueRepresentation object. That means that if you create two 
> face_lattice() structures with arguments that are *equal* you'll get back 
> *identical* lattices. That means you get:
>
> sage: o1 = lattice_polytope.cross_polytope(3)
> sage: F1 = o.face_lattice()
> sage: G1 = F1.relabel(F1._elements)
> sage: o2 = lattice_polytope.cross_polytope(3)
> sage: F2 = o2.face_lattice()
> sage: G2 = F2.relabel(F2._elements)
> sage: G1 is G2
> True
>
> Interestingly:
>
> sage: F1 is F2
> False
>
> so something is sufficiently different between the construction parameters 
> of F1 and F2 to return different structures.
>
> Because the unique representation cache will store G1, the construction of 
> G2 will get you back G1. That's as designed. UniqueRepresentation structure 
> have (A == B) iff (A is B).
>
> It's always questionable to derive UniqueRepresentation objects from 
> non-unique ones, although this particular example for F1 and F2 isn't 
> exhibiting problematic behaviour right here (yet? perhaps it's just the 
> order or accidental labelling that happens to introduce sufficient 
> differences?)
>
> Additionally, "o2.face_lattice()" is cached. If any of the construction 
> parameters of F2 reference back to o2 -- which it seems to do via "ambient" 
> there's a memory leak there of the classic "UniqueRepresentation 
> weak-caching-but-with-value-keeping-keys-alive" kind. Never cache a 
> UniqueRepresentation object on one of the objects involved in its 
> construction.
>
>
>

-- 
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/584b2552-b92a-4b31-b23b-deccc2c3b647%40googlegroups.com.

[sage-devel] Why does FiniteLatticePoset sometimes makes copies?

2019-10-30 Thread 'Jonathan Kliem' via sage-devel

Can anyone help me explain this

sage: o = lattice_polytope.cross_polytope(3)
sage: F = o.face_lattice()
sage: G = F.relabel(F._elements)
sage: G[0].ambient() is o
True
sage: o = lattice_polytope.cross_polytope(3)
sage: F = o.face_lattice()
sage: G = F.relabel(F._elements)
sage: G[0].ambient() is o
False
sage: G[0].ambient() is G[1].ambient()
True

More importantly, I am interested in a work around, such that relabeling 
does not create copies.

It works once with every lattice polytope and the second time it fails. The 
only thing that helps is to quit sage and restart it.

Currently, I'm working on using CombinatorialPolyhedron to obtain the face 
lattice for lattice polytopes. It works nicely, but that the faces do not 
know the ambient polytope (exactly) anymore, which makes the doctests fail.
Somehow the current setup works, but I'm puzzled on why.

-- 
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/830b6ca7-32c7-4ad4-86b5-df8fa2736c39%40googlegroups.com.

[sage-devel] Re: Need help testing #27122 and #27103

2019-10-28 Thread 'Jonathan Kliem' via sage-devel

When I posted it, I had only tested it on one machine.

Now, we have successful tests on:

   - Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz (64-bit),  Debian GNU/Linux 10 
   (buster) 
   - Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz (32-bit), Ubunty 14.04 LTS
   - Intel(R) Core(TM) i7-4650U CPU @ 1.70GH (64-bit),  OS X 10.14.6  
   (#27103 only)
   - Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz (64-bit), Ubuntu 18.04.3 LTS
   - Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (64-bit), Debian GNU/Linux 
   bullseye/sid

So anything that is different would be good. I don't know if anyone has an 
AMD processor, also more tests on OS X would be good (especially #27122).

Anything old is also great. So far we have only tested rather new 
processors.

Am Sonntag, 27. Oktober 2019 12:44:11 UTC+1 schrieb jplab:
>
> Which platforms need testing precisely? and which platforms were tested?
>
> J-P
>
> Le vendredi 25 octobre 2019 22:28:03 UTC+2, Jonathan Kliem a écrit :
>>
>> Hi, I would appreciate some help testing #27122 
>>  and possibly on top of that 
>> #27103 .
>>
>> Both tickets have instructions for testing in their description, which 
>> are hopefully helpful. The first ticket adds a compile argument to optimize 
>> sage for the current machine (unless SAGE_FAT_BINARIES is set).
>> Naturally, the behavior depends very much on the machine and we need a 
>> variety of tests, to see if it is ok. The compile argument `-march=native` 
>> is supposed to change things only for the better, but who knows what will 
>> or can happen.
>>
>> The second ticket makes use of the first and is also very much platform 
>> dependent.
>>
>> Thank you,
>>
>> 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/802d502a-5cbe-4f96-bfce-b1b7fa53bcab%40googlegroups.com.

[sage-devel] Need help testing #27122 and #27103

2019-10-25 Thread 'Jonathan Kliem' via sage-devel

Hi, I would appreciate some help testing #27122 
 and possibly on top of that #27103 
.

Both tickets have instructions for testing in their description, which are 
hopefully helpful. The first ticket adds a compile argument to optimize 
sage for the current machine (unless SAGE_FAT_BINARIES is set).
Naturally, the behavior depends very much on the machine and we need a 
variety of tests, to see if it is ok. The compile argument `-march=native` 
is supposed to change things only for the better, but who knows what will 
or can happen.

The second ticket makes use of the first and is also very much platform 
dependent.

Thank you,

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/5df62639-a0fc-4ea7-a20b-91a08b784338%40googlegroups.com.

Re: [sage-devel] Compile sage with `-march=native` as a default

2019-10-23 Thread 'Jonathan Kliem' via sage-devel

Thanks for your replies.

I wasn't aware of `CFLAGS` and it works great.

I think it makes sense to enable the SIMD-instructions with #27103 
 no matter if all of sage is 
compiled with `-march=native` by default.
All it really takes to get the intrinsics working is to recompile the 
sources for CombinatorialPolyhedron.
I think one could mention this option in the docstring of those function, 
which profit from it and hope that users who really want the performance 
read the docstring.

Is it acceptable to change the setup file to compile with `-march=native` 
as a default
e.g. if GCC >= 5.1 or clang >= 6.0 (and of course SAGE_FAT_BINARIES is not 
set)?
(GCC 5.1 fixed a bug, so this is important,
clang 6.0 is a wild guess, I have no clue when clang added march=native and 
if they ever fixed an important bug).

I added a branch with my very naive approach of doing it in setup.py to 
#27122 .

Am Dienstag, 22. Oktober 2019 13:55:18 UTC+2 schrieb Michael Orlitzky:
>
> On 10/22/19 7:41 AM, Dima Pasechnik wrote: 
> >> 
> >> Set CFLAGS="-march=native" in your shell before running "make", and 
> then 
> >> pray that the sage packages respect that variable. 
> > 
> > many packages would ignore it, and C++ and Fortran modules won't be 
> > affected by this, either. 
>
> Well there's also CXXFLAGS and FCFLAGS for those. 
>
> If packages don't respect them, then it's an upstream or sage bug, but 
> we're all probably better off concentrating on getting sage to use our 
> distro packages where we've already fixed those bugs. 
>

-- 
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/caec034f-d3c9-4c42-8248-44a33727eda9%40googlegroups.com.

[sage-devel] Compile sage with `-march=native` as a default

2019-10-22 Thread 'Jonathan Kliem' via sage-devel

I was wondering, if it was possible to compile sage (or parts of it) with 
`-march=native` or something similar (unless SAGE_FAT_BINARIES is set).
Some time ago I created #27122  for 
this.


Why do I care about it? (I was told that many parts of sage could profit 
from it, but I personally do not know other examples.)

Starting with the next develop, polyhedra will use a new algorithm to 
calculate the f_vector (see #28625 
).

In many instances we can speed up the actual face iterator by a factor of 
2, when using intrinsics (subject of #27103 
).
Among others, this will do subset checks much faster, which is the bottle 
neck of it all.

Concretely, the class CombinatorialPolyhedron would profit from any of 
POPCNT, AVX, or SSE4.1.

-- 
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/1358e041-8ab0-4ab7-9a54-0f271315c38c%40googlegroups.com.

[sage-devel] Re: what is the correct defintion of a vertex graph for polyhedra with lines?

2019-10-19 Thread 'Jonathan Kliem' via sage-devel

Let me try again. This is the current behaviour:

sage: P = Polyhedron(vertices=[[-1,0],[1,0]],lines=[[0,1]]); P
A 2-dimensional polyhedron in QQ^2 defined as the convex hull of 2 vertices 
and 1 line
sage: P.vertex_graph()
Graph on 2 vertices
sage: P.faces(0)
()

Let P be a polyhedron defined by vertices/rays/lines. The vertex graph of P 
returns basically the vertex graph for Q, where Q is defined by the same 
vertices and rays, but not lines.

So
sage: P = Polyhedron(vertices=my_vertices, rays=my_rays, lines=my_lines)
sage: Q = Polyhedron(vertices=my_vertices, rays=my_rays)

have vertex graphs that are canonically isomorphic.

I don't think this is the way it should be and the vertex graph in the 
first case should be empty. If no one disagrees I will apply this change in 
#28626. 

However, the current behaviour is somewhat fixed by a doctest.

As I understand it, the mentioned doctest tries to make a point about

sage: P.combinatorial_automorphism_group(vertex_graph_only=True)


In this case it is stated that the automorphism group can only interchange 
vertices with vertices, rays with rays and lines with lines. Strictly 
speaking, this is correct. But an automorphism group obtained from this 
will never interchange rays with rays or lines with lines.

Even worse, it will completely ignore the rays and lines, so that
sage: P = Polyhedron(vertices=[[0,0,0],[0,1,1],[1,0,1],[-1,-1,1]],rays=[[0,0
,1]]); P
A 3-dimensional polyhedron in QQ^3 defined as the convex hull of 4 vertices 
and 1 ray
sage: len(P.combinatorial_automorphism_group(vertex_graph_only=True))
24

This is why I consider the doctest strange.

To me it does not make sense to use the vertex graph to obtain the 
automorphism group.

Btw (and really not the point of this post), I'm not sure that the 
automorphism group of the vertex-facet graph is what one should consider 
for the automorphism group of an unbounded polyhedron. At least in 
dimension higher than 4 this might behave differently than at least I would 
define it. I would instead consider the vertex-facet-graph with an extra 
marked vertex at infinity.

Am Samstag, 19. Oktober 2019 11:52:24 UTC+2 schrieb jplab:
>
> Hi Jonathan,
>
> Could you be more precise with what you mean with "projection"?
>
> What is the status quo? (Please provide a minimal reproducible working 
> example that shows the contrast along with the proposed wished change that 
> you have in mind, otherwise we are left to guess what you mean and that is 
> leaving the door open to a lot of misunderstanding)
>
> What is the proposed changed?
>
> What is the assumption in the mentioned doctest?
>
> For computational aid, when no vertices exists (i.e. there is a lineality 
> space) the current implementation creates an appropriate vertex. I guess we 
> have to deal with this eventhough the object does not have a 0-dimensional 
> face in reality. This is to have consistency between H- and 
> V-representations. In order to have a consistent V-representation, you need 
> an anchor point, otherwise just having rays and lines does not determine 
> uniquely the object.
>
> That said, if you are interested in making a vertex-graph for unbounded 
> polyhedra, then, edges should have two vertices.
>
> One way is to ask to keep only bounded edges in the definition, and the 
> default behavior gives the vertex graph on bounded edges. If one wants the 
> full graph with a point at infinity that compactifies the full vertex 
> graph, then one could do so by adding an optional parameter 
> "unbounded=False/True". Where the default would be False and return only 
> compact edges and True would return one more vertex "the vertex at 
> infinity".
>
> To me this seems to be the most reasonable behavior. I don't know if this 
> answer your question.
>
> Le vendredi 18 octobre 2019 12:09:53 UTC+2, Jonathan Kliem a écrit :
>>
>> In #28626  I want to use 
>> `CombinatorialPolyhedron` to obtain the vertex graph of polyhedra.
>>
>> However, I seem to have a different opinion of a vertex graph than is 
>> currently implemented in sage.
>>
>> Should the vertex graph of an unpointed polyhedron return the vertex 
>> graph of the projection or should it be empty?
>>
>> As of now the method `vertices` returns the defining vertices, which are 
>> the proper vertices except for unpointed polyhedra.
>>
>> I don't think this ambiguous meaning of vertex should continue for the 
>> vertex graph.
>>
>> However the current behavior is at the moment assumed in a strange 
>> doctest of `combinatorial_automorphism_group`.
>> (E.g. the order of the combinatorial automorphism group does not change 
>> when you add lines.)
>>
>

-- 
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] what is the correct defintion of a vertex graph for polyhedra with lines?

2019-10-18 Thread 'Jonathan Kliem' via sage-devel

In #28626  I want to use 
`CombinatorialPolyhedron` to obtain the vertex graph of polyhedra.

However, I seem to have a different opinion of a vertex graph than is 
currently implemented in sage.

Should the vertex graph of an unpointed polyhedron return the vertex graph 
of the projection or should it be empty?

As of now the method `vertices` returns the defining vertices, which are 
the proper vertices except for unpointed polyhedra.

I don't think this ambiguous meaning of vertex should continue for the 
vertex graph.

However the current behavior is at the moment assumed in a strange doctest 
of `combinatorial_automorphism_group`.
(E.g. the order of the combinatorial automorphism group does not change 
when you add lines.)

-- 
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/6c0fea16-e5cc-4ce2-87fc-6e3a953cb929%40googlegroups.com.

[sage-devel] Re: patchbot security

2019-07-06 Thread 'Jonathan Kliem' via sage-devel

Thanks, I have to see what I can do about it (I went through all the 
tickets I tested and it looks things are fine).

Am Samstag, 6. Juli 2019 14:50:51 UTC+2 schrieb Volker Braun:
>
> The patchbot configuration has some options for trusting specific user 
> accounts.
>
> Having said that, you are correct in that it executes code submitted by 
> strangers over the internet. At the very least make a separate user account 
> for running the patchbot. You might want to add an additional container / 
> vm layer.
>
 
Could you (or someone else) add this info to 
https://wiki.sagemath.org/patchbot.


>
>
> On Saturday, July 6, 2019 at 4:20:09 AM UTC-4, Jonathan Kliem wrote:
>>
>> Hi,
>>
>> I'm wondering what safety measures are taken for distributing code to the 
>> patchbot clients.
>>
>> E.g. if I where to register a new github account and create a ticket that 
>> uploads all files from the user to a server of my choice (maybe via a 
>> malicous doctest), is that ticket still going to be distributed to patchbot 
>> clients?
>>
>> I guess the underlying question is, what security measures are 
>> recommended before running a patchbot. On 
>> https://wiki.sagemath.org/patchbot I cannot find anything.
>>
>> 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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d67196d2-6b2f-450c-aabc-54266311556c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] patchbot security

2019-07-06 Thread 'Jonathan Kliem' via sage-devel

Hi,

I'm wondering what safety measures are taken for distributing code to the 
patchbot clients.

E.g. if I where to register a new github account and create a ticket that 
uploads all files from the user to a server of my choice (maybe via a 
malicous doctest), is that ticket still going to be distributed to patchbot 
clients?

I guess the underlying question is, what security measures are recommended 
before running a patchbot. On https://wiki.sagemath.org/patchbot I cannot 
find anything.

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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/928b6679-16ec-4f85-b737-2a8c10c19155%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: patchbot server down

2019-07-06 Thread 'Jonathan Kliem' via sage-devel

In my case it crashed (might have been because I tried to start it during 
downtime).

By looking at https://patchbot.sagemath.org/machines I'm having the 
impression that I'm not the only one, where this happened.

Am Samstag, 6. Juli 2019 07:46:41 UTC+2 schrieb Frédéric Chapoton:
>
> No. No need to restart any patchbot client.
>
> F
>
> Le samedi 6 juillet 2019 07:17:59 UTC+2, Jonathan Kliem a écrit :
>>
>> Great,
>>
>> so I guess all patchbots have to be restarted (if not already done so).
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d246455b-9cb3-4466-a75a-3b17c0bf73e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: patchbot server down

2019-07-05 Thread 'Jonathan Kliem' via sage-devel

Great,

so I guess all patchbots have to be restarted (if not already done so).

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/bb4b5adb-cdeb-4e1c-9afc-5c391859faa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] patchbot server down

2019-07-05 Thread 'Jonathan Kliem' via sage-devel

https://patchbot.sagemath.org/ displays an

Internal Server Error

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a48bf171-b5cc-46f8-8286-dc487848586f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Installation gets stuck when it tries to download zeromq-4.2.5.tar.gz

2019-06-19 Thread 'Jonathan Kliem' via sage-devel

You're right. I just ran `./sage -i polymake` and indeed the warning 
message is somewhere way up before installing requirements (bliss, ninja, 
lrslib-062+autotools-2017-03-03.p0).

I don't like it, but this explains the behavior.

Am Mittwoch, 19. Juni 2019 17:17:27 UTC+2 schrieb Dima Pasechnik:
>
>  in a scenario where an experimental package is upgraded during a rebuild, 
> it is not always the case that you see the corresponding prompt, as you 
> typically build in parallel, and messages from a number of threads are 
> being printed in a semirandom order.
>
> On Wed, 19 Jun 2019 16:05 'Jonathan Kliem' via sage-devel, <
> sage-...@googlegroups.com > wrote:
>
>> The installation stopped after download in my case and pressing enter 
>> solved the problem. This was not the confirmation for experimental packages 
>> (where the terminal tells you to do something). It looked pretty much like 
>> the above screen shots.
>>
>> I figured it's a bug, but as I said, never gave it any thought, as it 
>> didn't bother 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-...@googlegroups.com .
>> To post to this group, send email to sage-...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/sage-devel.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/e10c135f-4ade-4756-9a73-a7711ecff84e%40googlegroups.com
>> .
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/866079ec-e80f-49b7-90d4-74eae7a2c964%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Installation gets stuck when it tries to download zeromq-4.2.5.tar.gz

2019-06-19 Thread 'Jonathan Kliem' via sage-devel

The installation stopped after download in my case and pressing enter solved 
the problem. This was not the confirmation for experimental packages (where the 
terminal tells you to do something). It looked pretty much like the above 
screen shots.

I figured it's a bug, but as I said, never gave it any thought, as it didn't 
bother 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e10c135f-4ade-4756-9a73-a7711ecff84e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Installation gets stuck when it tries to download zeromq-4.2.5.tar.gz

2019-06-19 Thread 'Jonathan Kliem' via sage-devel

The installation stopped, just like in your case. Once I pressed enter it 
resumed. This has always solved it for me and thus I never gave it much thought.

I think it happened during the install of polymake, but might have been 
normaliz (or pynormaliz) as well. Not sure but I have encountered it a few 
times already.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/88f56a43-a175-4398-91cf-7efc37831bcb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Installation gets stuck when it tries to download zeromq-4.2.5.tar.gz

2019-06-18 Thread 'Jonathan Kliem' via sage-devel

Just to make sure: Did you try pressing enter once you got stuck?

It happens to me as well that I stop at this exact point (installing some 
optional package), but pressing enter will make it resume.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0e808cb3-e418-47ff-93c7-fcb593b60e5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Polyhedron -- make constructions respect backend

2019-06-04 Thread 'Jonathan Kliem' via sage-devel

I have started #27926.

I think I leave the base ring business as it is for now. I belive it is 
taken care of in many (if not all) places, where the base ring of the 
vertices might differ.

Am Dienstag, 4. Juni 2019 11:20:07 UTC+2 schrieb jplab:
>
> Hi Jonathan,
>
> Le lundi 3 juin 2019 23:31:29 UTC+2, vdelecroix a écrit :
>>
>> To my mind: 
>>
>>   * backend and base ring should be preserved by default. Of course 
>> it should make sense: a translation by sqrt(2) would break the 
>> base ring QQ. 
>>
>
> +1
>
>
>>   * no need to create one ticket for each method if this is mostly 
>> the same action to be done for each of them. If some method needs 
>> special care or give rise to discussions, a specific ticket could 
>> be open. 
>>
>
> +1
>
>
> Le 03/06/2019 à 23:25, 'Jonathan Kliem' via sage-devel a écrit : 
>> > At the moment the backend setting is lost, when constructing a pyramid 
>> of a 
>> > Polyhedron. 
>> > 
>> > Same holds for all other constructions. 
>>
>
> If you are ready to go through the construction to make them consistent 
> with the above convention: great!
>
> > Any thoughts on this? 
>> > 
>> > Also I think the base ring should be respected as well (as is done in 
>> > Polyhedron.translation). 
>> > At the moment it can happen, that the base ring shrinks, when 
>> constructing 
>> > a pyramid for example 
>> > (if the user forced base ring QQ, there might have been good reason for 
>> > doing so, and I would say it is not nice, if one has to change base 
>> ring 
>> > again along the way). 
>>
>
> It is hard to make sense of "If the user forced base ring QQ" after the 
> object got created. 
> How should we know if that keyword was given when looking at the object?
>
> The reason I ask this question is because I do not believe that the usage 
> of the keyword 
> "base_ring" is "to force the base ring used", but rather to help the 
> constructor to build the 
> desired object in a specific base ring: the input is converted in that 
> base ring (if possible) 
> once things are constructed. Then, as Vincent mentioned, and I agree, the 
> base ring 
> should be kept as long as it is possible.
> good
> On the other hand, a user "forcing QQ"  can be thought as a peculiar thing 
> to do. Every 
> rational polyhedron has an integer H-representation, so if one looks at 
> the H-representation, 
> QQ is not necessary to write the H-representation. The distinction comes 
> from the 
> V-representation and has consequences on the related objects (Ehrhart 
> quasi-polynomial 
> vs Ehrhart polynomial and any method that makes use of integer 
> arithmetic...). So, yes 
> there should be a distinction between the two base rings ZZ and QQ. That 
> said, I believe that internally, 
> it should always try to take the "simplest" base ring possible. If the 
> user then wants a 
> different ring, then Sage will give the object back in that one, but may 
> do computations with a 
> different ring. So now again, does "forcing a base ring" makes sense?
>
> That said, as explained in the tutorial
>
>
> http://doc.sagemath.org/html/en/thematic_tutorials/geometry/polyhedra_tutorial.html
>
> A clean way to work with polyhedron is to have the objects already be in a 
> common base ring already.
> If this is not possible and one gives different types in the input, then 
> it will go on and figure out a 
> proper base ring. But, since this might take a while, the keyword "base 
> ring" helps in this regards.
>
> So, one should be careful in using this keyword... For example, after 
> #25097 is merged, this will become possible:
>
> sage: sqrt_2s = sqrt(2)
> sage: cbrt_2s = 2^(1/3)
> sage: P1 = Polyhedron(vertices = [[sqrt_2s, 0], [0, cbrt_2s]]);P1
> Traceback (most recent call last):
> ...
> ValueError: no appropriate backend for computations with Symbolic Ring
>
> sage: P2 = Polyhedron(vertices = [[sqrt_2s, 0], [0, cbrt_2s]],backend=
> 'normaliz');P2
> A 1-dimensional polyhedron in (Symbolic Ring)^2 defined as the convex 
> hull of 2 vertices
>
> sage: Polyhedron(vertices = [[sqrt_2s, 0], [0, cbrt_2s]],backend='field')
> Traceback (most recent call last):
> ...
> ValueError: the 'field' backend for polyhedron can not be used with non-exact 
> fields
>
> The object P2's base ring is the Symbolic Ring, but the computations are 
> done in the normaliz field accessible with the method `_normaliz_field`.  
>
> J-P
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/621e22a5-2ed3-4e40-8b28-4575700b516a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Polyhedron -- make constructions respect backend

2019-06-04 Thread 'Jonathan Kliem' via sage-devel

Actually, base ring is preserved already. Just assumed it gets lost as well.

The backend is lost though.

Something as

sage: polytopes.dodecahedron(backend='normaliz').pyramid()

will create a polyhedron with backend 'field'.

Am Montag, 3. Juni 2019 23:31:29 UTC+2 schrieb vdelecroix:
>
> To my mind: 
>
>   * backend and base ring should be preserved by default. Of course 
> it should make sense: a translation by sqrt(2) would break the 
> base ring QQ. 
>
>   * no need to create one ticket for each method if this is mostly 
> the same action to be done for each of them. If some method needs 
> special care or give rise to discussions, a specific ticket could 
> be open. 
>
> Vincent 
>
> Le 03/06/2019 à 23:25, 'Jonathan Kliem' via sage-devel a écrit : 
> > At the moment the backend setting is lost, when constructing a pyramid 
> of a 
> > Polyhedron. 
> > 
> > Same holds for all other constructions. 
> > 
> > I think that all constructions should respect the backend of self. I 
> intend 
> > to create tickets (one by one) for each construction in Polyhedron_base 
> > (that gives a new Polyhedron). 
> > 
> > Any thoughts on this? 
> > 
> > Also I think the base ring should be respected as well (as is done in 
> > Polyhedron.translation). 
> > At the moment it can happen, that the base ring shrinks, when 
> constructing 
> > a pyramid for example 
> > (if the user forced base ring QQ, there might have been good reason for 
> > doing so, and I would say it is not nice, if one has to change base ring 
> > again along the way). 
> > 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3c1cc8c8-0980-4e70-aad0-d7e842e7f702%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Polyhedron -- make constructions respect backend

2019-06-03 Thread 'Jonathan Kliem' via sage-devel

At the moment the backend setting is lost, when constructing a pyramid of a 
Polyhedron.

Same holds for all other constructions.

I think that all constructions should respect the backend of self. I intend 
to create tickets (one by one) for each construction in Polyhedron_base 
(that gives a new Polyhedron).

Any thoughts on this?

Also I think the base ring should be respected as well (as is done in 
Polyhedron.translation).
At the moment it can happen, that the base ring shrinks, when constructing 
a pyramid for example
(if the user forced base ring QQ, there might have been good reason for 
doing so, and I would say it is not nice, if one has to change base ring 
again along the way).

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/518818c3-75af-4283-ba10-755cfc760242%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

67 matches

Mail list logo