[sage-devel] Making Integer and Rational compatible with Python Fraction

['Mark Bell' via sage-devel]

During Sage Days 100, I experienced an issue with Sage's Integers and 
Rational not being compatible with Python's built in Fraction class. This 
made me unable to run my Python code within Sage and so I raised ticket 
28234 . For example, in Sage 8.8:

sage: from fractions import Fraction
sage: Fraction(7, 3)
---
TypeError Traceback (most recent call last)
 in ()
> 1 Fraction(Integer(7), Integer(3))


/Applications/SageMath-8.6.app/Contents/Resources/sage/local/lib/python2.7/
fractions.pyc in __new__(cls, numerator, denominator)
152 isinstance(denominator, Rational)):
153 numerator, denominator = (
--> 154 numerator.numerator * denominator.denominator,
155 denominator.numerator * numerator.denominator
156 )


TypeError: unsupported operand type(s) for *: 'builtin_function_or_method' 
and 'builtin_function_or_method'
sage: Fraction(7)
Fraction(, )
sage: Fraction(7 / 3)
Fraction(, )

This issue is because, despite the Integer and Rational class being 
registered as Python's numbers.Integral and numbers.Rational classes, they 
do not implement numerator and denominator *properties* as required by the 
Python specification. Instead they implement numerator and denominator 
*methods*. This issue has been spotted a number of times [1] 
 [2] 
.

During the course of the workshop several solutions were suggested and 
investigated including:

   1. Make Integer and Rational numerator and denominator properties and 
   accept that this would not be backwards compatible within Sage
   2. Make Integer and Rational numerator and denominator properties and 
   add numer and denom methods to classes that have these properties and 
   switch to using these throughout
   3. Make Integer and Rational  numerator and denominator properties and 
   make Integers callable and return themselves
   4. Raise a PEP to change the Python specification to be / include 
   numerator and denominator methods
   5. Do not register Integer and Rational as numbers.Integral and 
   numbers.Rational
   6. Do nothing and so accept that Sage does not perfectly match the 
   Python specification

As part of the workshop, I worked on implementing approach #3 within branch 
28234 
.
 
This implementation is now complete and passes all of Sages doctests 
[although its implementation revealed a bug in sagemath-patchbot which I 
subsequently fixed ]. 
This means that now if, for example, x = 5 then both x.numerator and 
x.numerator() return 5 [in the latter case x.numerator returns 5, and then 
5() returns 5]. Hence not only does this make Sage Integers and Rationals 
compatible with Python Fractions:

sage: from fractions import Fraction
sage: Fraction(7, 3)
Fraction(7, 3)
sage: Fraction(7)
Fraction(7, 1)
sage: Fraction(7/3)
Fraction(7, 3)


but this change is morally backwards compatible with existing Sage code.

However, this approach makes Sage Integers callable and so additional work 
was needed to ensure that the control flow within Sage kernel was not 
affected. I used a short Python script to generate a patch (that was 
applied within branch 28234) that:

   1. Replaced all uses of hasattr(x, '__call__') with callable(x)
   2. Replaced all uses of isinstance(x, collections.Callable) with 
   callable(x)
   3. Replaced all uses of callable(x) with callable(x) and not 
   isinstance(x, numbers.Integral)

Therefore if this branch is merged then users may need to make similar 
changes to their code if they ever rely on the fact that Integers were not 
callable.

Now regarding the other approaches:

   - Approach #1 would be backwards incompatibly and would likely affect a 
   substantially larger number of users (anyone who has ever access a 
   numerator). It would also mean that care would be needed as to use 
   x.numerator or x.numerator() depending on the type of x.
   - Approach #2 was attempted but presented difficulties since numer() 
   methods would also need to be added all external objects (e.g. Pari object) 
   that are available within Sage that implement numerator() methods.
   - Approach #4 was also started and discussion about changing the Python 
   specification from PEP 3141 can be found here 
   . 
   This is likely to also have a knock-on effect on other systems such as 
   numpy.
   - Approach #5 would also result in serious backwards compatibility 
   issues and would still mean that Sage Integers and Rationals would not be 
   compatible with Python Fractions.

[sage-devel] Re: Missing Sage 8.2 binaries

['Mark Bell' via sage-devel]

Excellent, things have started appearing now. Is the 8.2 changelog 
(http://www.sagemath.org/changelogs/index.html) also missing though?

On Tuesday, May 8, 2018 at 11:05:54 PM UTC+1, Volker Braun wrote:
>
> Binaries take a couple of days to build. On the way to the mirrors now...
>
>
>
> On Tuesday, May 8, 2018 at 8:54:42 PM UTC+2, Mark Bell wrote:
>>
>> The main sagemath.org page lists Sage 8.2 as the latest version to 
>> download and the source and git links appear to be tagged as sage-8.2 as of 
>> three days ago. However within the main download page, there don't appear 
>> to be any precompiled versions of 8.2 available. For example here:
>> http://files.sagemath.org/osx/intel/index.html
>> and here:
>> http://files.sagemath.org/linux/64bit/index.html
>> only show up to 8.1. Do I need to just wait longer for these to become 
>> available or are precompiled versions of sage 8.2 available from a 
>> different page now?
>>
>>
>>
>>

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

[sage-devel] Missing Sage 8.2 binaries

['Mark Bell' via sage-devel]

The main sagemath.org page lists Sage 8.2 as the latest version to download 
and the source and git links appear to be tagged as sage-8.2 as of three 
days ago. However within the main download page, there don't appear to be 
any precompiled versions of 8.2 available. For example here:
http://files.sagemath.org/osx/intel/index.html
and here:
http://files.sagemath.org/linux/64bit/index.html
only show up to 8.1. Do I need to just wait longer for these to become 
available or are precompiled versions of sage 8.2 available from a 
different page now?



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

[sage-devel] Typo in trac instructions

['Mark Bell' via sage-devel]

I think there is a minor typo in the *To get an account* instructions at 
https://trac.sagemath.org/. It says that:

the default username is the first letter of the surname followed by the 
> name (i.e. mjohnson for Mike Johnson or tlei for Tan Lei).


Should this not say:

the default username is the first letter of the *first/given name* followed 
> by the *surname* (*for example*, mjohnson for Mike Johnson or tlei for 
> Tan Lei).


instead?



 

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

[sage-devel] _integer_ for QQbar and QQ raise different errors

['Mark Bell' via sage-devel]

The coersion
sage: ZZ(1/2)
fails and (correctly) raises a TypeError while
sage: ZZ(QQbar(sqrt(17)))
fails and (incorrectly) raises a ValueError. 

This has several knock on effects, in particular vector(ZZ, [list of 
algebraic numbers]) all of whoms try / except blocks are set up to catch a 
TypeError in the event that one of the elements fails to be coerced to an 
integer. This in turn causes 
Polyhedron([(AA(sqrt(17)),)]).integral_points() to fail as this ValueError 
is never caught.

Should the _integer_ methods in qqbar.py be changed to raise TypeErrors 
like the other number types in Sage?

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

[sage-devel] Re: Polyhedron.integral_points_count() gives inconsistent answers on slices

['Mark Bell' via sage-devel]

Ah, I see. Is it possible that by doing "sage -i latte_int" I have 
installed a different version of 4ti2 than the one that CoCalc uses? I'm 
still not sure why (without this option) I see different behaviours on my 
machine and on CoCalc. If it matters I have Sage 8.0 running on Mac OS 
Sierra 10.12.6.

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

[sage-devel] Re: Polyhedron.integral_points_count() gives inconsistent answers on slices

['Mark Bell' via sage-devel]

Excellent! Adding the option prevents the crash. So on CoCalc (and locally) 
I can do:
   print(P.integral_points_count(preprocess=False, triangulation='cddlib'))
And it prints out 19958.

Without this extra option this example crashes on CoCalc but runs fine 
locally. What is this this option doing?

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

Re: [sage-devel] Re: Polyhedron.integral_points_count() gives inconsistent answers on slices

['Mark Bell' via sage-devel]

Thanks for the suggestion. That might be the case but if I run 
"/usr/bin/time -v sage error.py" then I get 

Command exited with non-zero status 1
Command being timed: "sage error.py"
User time (seconds): 2.22
System time (seconds): 0.67
Percent of CPU this job got: 86%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:03.35
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 200116
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 81745
Voluntary context switches: 7875
Involuntary context switches: 191
Swaps: 0
File system inputs: 22
File system outputs: 4
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 1

So it appears to be using ~200 MB of the 1000 MB shared RAM memory limit. 
Is there a better way to determine the resources being used / if I am 
hitting this limit?

On Sunday, November 5, 2017 at 2:05:31 AM UTC, William wrote:
>
> On Sat, Nov 4, 2017 at 6:27 PM, Matthias Koeppe 
>  wrote: 
> > Can you show the output of the crash on CoCalc? 
>
> Also, the crash could just be running out of memory... 
>
> > 
> > 
> > On Saturday, November 4, 2017 at 3:46:01 PM UTC-7, Mark Bell wrote: 
> >> 
> >> Thanks! 
> >> 
> >> I'm not sure if this is the right place to add this but the attached 
> >> example also causes LattE to crash, but I only see this behaviour when 
> I run 
> >> this code on CoCalc. When I run the script on my local machine with 
> >> latte_int installed it completes and prints out 19958. Surely this 
> isn't 
> >> being caused by the same bug. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "sage-devel" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to sage-devel+...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> William (http://wstein.org) 
>

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

[sage-devel] Re: Polyhedron.integral_points_count() gives inconsistent answers on slices

['Mark Bell' via sage-devel]

Here is the full CoCalc output when I run "sage error.py" in a terminal, 
either via the web interface or via sshing into the machine:

Traceback (most recent call last):
  File "error.py", line 42, in 
print(P.integral_points_count(preprocess=False))
  File 
"/ext/sage/sage-8.0/local/lib/python2.7/site-packages/sage/geometry/polyhedron/base_QQ.py",
 
line 218, in integral_points_count
**kwds)
  File 
"/ext/sage/sage-8.0/local/lib/python2.7/site-packages/sage/interfaces/latte.py",
 
line 159, in count
raise RuntimeError("LattE integrale program failed (exit code 
{})".format(ret_code) + err.strip())
RuntimeError: LattE integrale program failed (exit code -6):
This is LattE integrale 1.7.3
Available from http://www.math.ucdavis.edu/~latte/
 
Invocation: count '--redundancy-check=none' --cdd /dev/stdin
Warning: Not performing check for empty polytope, because it is 
unimplemented for the CDD-style input format.
size = 22 x 19
Number Type = rational
Ax <= b, given as (b|-A):
=
[-1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
[-1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
[-1 1 0 1 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
[-1 0 1 -1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
[-1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
[-1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0]
[97 -2 -8 -1 -7 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
[-1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
[97 -2 -5 -1 -4 0 -3 0 0 0 0 0 0 0 0 0 0 0 0]

Ax = b, given as (b|-A):

[0 1 0 1 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 -1]
[0 0 1 -1 1 0 0 0 0 0 0 0 0 0 0 0 0 -1 0]
[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0]
[0 0 1 -1 2 0 0 0 0 0 0 0 0 0 0 -1 0 0 0]
[0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0]
[0 0 0 0 0 0 1 0 0 0 0 0 0 -1 0 0 0 0 0]
[-100 2 8 1 7 0 0 0 0 0 0 0 3 0 0 0 0 0 0]
[0 0 1 0 1 0 0 0 0 0 0 -1 0 0 0 0 0 0 0]
[0 0 1 0 1 0 0 0 0 0 -1 0 0 0 0 0 0 0 0]
[0 0 1 1 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0]
[-100 2 5 1 4 0 3 0 3 0 0 0 0 0 0 0 0 0 0]
[-100 2 5 1 4 0 3 3 0 0 0 0 0 0 0 0 0 0 0]
[0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0]

Computing hermitean normal form.
sol:
[0 0 0 0 0 0 -100 0 0 -100 0 0 0 0 0 0 0 0]
Particular solution:
Basis:
New inequalities:
[99 -3 -3 -5 -5 -1 0]
[-101 3 3 5 6 2 0]
[-1 0 0 0 0 1 0]
[-1 0 0 0 1 0 0]
[-1 0 0 1 0 0 0]
[-1 1 0 0 0 0 0]
[-3 3 3 -3 -3 0 0]
[99 -3 -3 -4 -5 -2 0]
[-3 0 3 0 0 0 0]
Time for reading and preprocessing: 0 sec
The polytope has 12 vertices.
Time for computing vertices and supporting cones: 0 sec
Time for dualizing general cones: 0 sec
Dualizing all cones...All cones are now dualized.
Time for dualizing general cones: 0 sec
decomposeCones_Single: Decomposing all cones. (Memory Save on)
12 cones total to be done!decomposeCones_Single: degree = 1
Number of cones: 12
Triangulating cone... done.
count: barvinok/barvinok.cpp:572: int 
barvinokDecomposition_Single(listCone*, Single_Cone_Parameters*): Assertion 
`num_rays == Parameters->Number_of_Variables'
failed.

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

[sage-devel] Re: Polyhedron.integral_points_count() gives inconsistent answers on slices

['Mark Bell' via sage-devel]

Thanks! 

I'm not sure if this is the right place to add this but the attached 
example also causes LattE to crash, but I only see this behaviour when I 
run this code on CoCalc. When I run the script on my local machine with 
latte_int installed it completes and prints out 19958. Surely this isn't 
being caused by the same bug.

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

from sage.all import Polyhedron

eqns = [
[0, 0, 0, 0, 0, 0, 0, 0, 0, -1, 1, 1, 0, 0, 0, -1, 0, 0, 0], 
[0, 0, 0, 0, 0, 0, 0, 0, -1, 0, 0, 1, 1, -1, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, -1, -1, 0, 0, 1, 0 , 1, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, -1, -1, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0],
[0, 0, 0, 0, 0, -1, 0, -1, 1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0],
[0, 0, 0, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, -1, 0],
[0, 0, -1, -1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0],
[0, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1],
[0, -1, 0, -1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[-100, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
[0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0]
]
ieqs = [
[-1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[-1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[50, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
]

P = Polyhedron(eqns=eqns, ieqs=ieqs)
print(P.integral_points_count(preprocess=False))

[sage-devel] Re: Polyhedron.integral_points_count() gives inconsistent answers on slices

['Mark Bell' via sage-devel]

So when k = 19, sage.interfaces.latte.count 

 
and P.integral_points_count() give different answers. This seems to be the 
cause of the difference. Here is some more code showing the difference.

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

from sage.all import Polyhedron
from sage.interfaces.latte import count

eqns = [
[0, -1, 0, 0, 0, 0, -1, 1, 1, 0, 0, 0, 0],
[0, 0, 0, 0, 0, -1, 0, 0, 1, 1, -1, 0, 0],
[0, 0, 0, 0, -1, 0, -1, 1, 0, 1, 0, 0, 0],
[0, 0, 0, -1, 0, 0, 0, 0, 0, 0, 1, 1, -1],
[0, 0, -1, -1, 0, 1, 0, 0, 0, 0, 0, 1, 0],
[0, -1, 1, 0, -1, 0, 0, 0, 0, 0, 0, 0, 1],
[-100, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
[0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0],
[-19, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
]
ieqs = [
[-1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]
]

P = Polyhedron(eqns=eqns, ieqs=ieqs)
print(P.integral_points_count())
print(count(P.cdd_Hrepresentation(), cdd=True))

[sage-devel] Re: Polyhedron.integral_points_count() gives inconsistent answers on slices

['Mark Bell' via sage-devel]

Great suggestion. Could you ask polymake to compute what the number of 
lattice points in each x_0 = k (for k = 1, ..., 100) slice? Does it match:
[84, 84, 84, 81, 81, 81, 75, 75, 75, 66, 66, 66, 54, 54, 54, 39, 39, 
39, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0]

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

[sage-devel] Polyhedron.integral_points_count() gives inconsistent answers on slices

['Mark Bell' via sage-devel]

I want to count the number of integral points inside of a bounded 
polyhedron. The polyhedron is defined by the following system of equations:

> eqns = [
[-100, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
[0, -1, 0, 0, 0, 0, -1, 1, 1, 0, 0, 0, 0],
[0, 0, 0, 0, 0, -1, 0, 0, 1, 1, -1, 0, 0],
[0, 0, 0, 0, -1, 0, -1, 1, 0, 1, 0, 0, 0],
[0, 0, 0, -1, 0, 0, 0, 0, 0, 0, 1, 1, -1],
[0, 0, -1, -1, 0, 1, 0, 0, 0, 0, 0, 1, 0],
[0, -1, 1, 0, -1, 0, 0, 0, 0, 0, 0, 0, 1],
[0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0]
]

and the following system of inequalities:

> ieqs = [
[-1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]
]

And so I did:
> Polyhedron(eqns=eqns, ieqs=ieqs).integral_points_count()
1260

However, if I look at all of the slices obtained by fixing the first 
variable x_0 (which must be 1 <= x_0 <= 100 by the first equation and 
inequality) then I get the following numbers of integral points in each 
slice:

> [Polyhedron(eqns=eqns+[[-k, 1, 0,0,0,0,0,0,0,0,0,0,0]], 
ieqs=ieqs).integral_points_count() for k in range(1, 101)]
[84, 84, 84, , 0, 0, 0]

Which is fewer points in total:

> sum(_)
1197

Can anyone reproduce this? Is this a bug in Sage or LattE?

I'm using Sage 8.0 with LattE installed via "sage -i latte_int" and have 
attached the full example code.

Thanks,
Mark

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

from sage.all import Polyhedron

eqns = [
[0, -1, 0, 0, 0, 0, -1, 1, 1, 0, 0, 0, 0],
[0, 0, 0, 0, 0, -1, 0, 0, 1, 1, -1, 0, 0],
[0, 0, 0, 0, -1, 0, -1, 1, 0, 1, 0, 0, 0],
[0, 0, 0, -1, 0, 0, 0, 0, 0, 0, 1, 1, -1],
[0, 0, -1, -1, 0, 1, 0, 0, 0, 0, 0, 1, 0],
[0, -1, 1, 0, -1, 0, 0, 0, 0, 0, 0, 0, 1],
[-100, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
[0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0]
]
ieqs = [
[-1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0],
[-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]
]

print(Polyhedron(eqns=eqns, ieqs=ieqs).integral_points_count())
print(sum([Polyhedron(eqns=eqns+[[-k, 1, 0,0,0,0,0,0,0,0,0,0,0]], ieqs=ieqs).integral_points_count() for k in range(1, 101)]))

[sage-devel] Testing new graph algorithms

['Mark Bell' via sage-devel]

I've been working on some new algorithms for computing some properties 
(eccentricity, diameter, radius, ...) of (undirected) graphs and I'm 
looking for families to test these on.

I've written a reasonable efficient C extension which implements these 
algorithms and so I've started comparing these against the methods 
available in Sage.
For many of the graphs that I've tried it appears that this new technique 
is faster than Sage. For example, experimentally on:

> G = graphs.RandomGNP(2001, 0.05)

this new technique computes the diameter of G ~30% faster than Sage.


Is there a standard test suite of graphs that I try running these 
procedures on? I think this algorithm should be particularly effective on 
graphs with a large number of vertices and a large diameter. Is there a 
reasonable way of generating graphs of this form?


Even if it does turn out that this technique performs worse than Sage on 
some graphs, is it worth trying to integrate it as an option for users?

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