[sage-devel] Re: Outdated instructions in "git the hard way"

[Simon King]

Hi Dima,

On 2021-09-09, Dima Pasechnik  wrote:
> I think that 'git trac' is mainly used by the release manager - I
> won't recommend it to newcomers.

No, I'm not a release manager, but I find it very practical to be able
to do "git trac pull 12345" instead of doing a series of commands that
I simply don't manage to memorise.

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/shg8p9%2445p%241%40ciao.gmane.io.

[sage-devel] Re: Help needed with adding user packages as optional/experimental packages

[Simon King]

Hi Thierry,

On 2021-02-08, Thierry  wrote:
> We should notice that, contrary to other packages, those packages should
> be considered as downstream (not upstream), and this should be reflected
> in our release process.
>
> Indeed, their code get adapted after Sage changes, see e.g. (randomly
> chosen examples):
>
> https://github.com/mkauers/ore_algebra/commit/2d71b50ebad81e62432482facfe3f78cc4961c4f
> https://github.com/mkauers/ore_algebra/commit/8c678f9c70aee8df211c04211dd2f7e230a4770f

Then, I think, p_group_cohomology should be considered downstream, too.
Most of its latest releases were triggered by changes in Sage.

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/s1dd0u%2477a%241%40ciao.gmane.io.

[sage-devel] Re: Rounding in Sage

[Simon King]

Hi Samuel,

thank you for the interesting sources!

Best regards,
Simon

On 2020-04-08, Samuel Lelievre  wrote:
> About Sage and floating-point numbers, if I remember correctly,
>
> - IEEE 754 is not a complete specification, some details are left
>   up to the implementation and therefore IEEE 754 compliant
>   computations can vary from machine to machine (depending
>   on processor or OS)
> - in Sage, `RDF` and `float` use machine floats and so follow IEEE 754
> - by contrast RR and RealField are specified more tightly so as to
>   give the same computations on any machine
> - the range of exponents in RR is a lot wider than in RDF
> - RDF is a lot faster than RR
>
> Two excellent sources on real and floating-point numbers in Sage
>
> - The many ways of computing with real numbers
>   Talk by Vincent Delecroix at Sage Days 88 in IMA, U Minnesota, 2017
>   https://www.ima.umn.edu/2017-2018.2/W8.21-25.17/26308
>
> - What are the different real numbers in Sage
>   https://ask.sagemath.org/question/9950
>
> Related Sage Trac tickets
>
> - Deprecate is_RealField / is_RealNumber
>   https://trac.sagemath.org/ticket/24525
>
> - rename RealField/RealNumber
>   https://trac.sagemath.org/ticket/24524
>
> - Modernize sage.rings.real_mpfr
>   https://trac.sagemath.org/ticket/24457
>
> - Thematic tutorial about real and complex numbers in Sage
>   https://trac.sagemath.org/ticket/15944
>
> - Deprecate global RealNumber() and ComplexNumber()
>   https://trac.sagemath.org/ticket/13110
>

-- 
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/r6metq%242sph%241%40ciao.gmane.io.

[sage-devel] Re: Rounding in Sage

[Simon King]

Hi!

On 2020-04-07, Thierry  wrote:
> By the way, an excellent ressource to teach those kind of things and
> check carefully what happens is the sign_mantissa_exponent method:
>
> sage: a = RR(1.1)
> sage: a
> 1.10
> sage: a.sign_mantissa_exponent()
> (1, 4953959590107546, -52)

Nice, I didn't know about that method. Thank you for the hint!
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/r6i8km%243a13%242%40ciao.gmane.io.

[sage-devel] Re: Rounding in Sage

[Simon King]

On 2020-04-07, Thierry  wrote:
> An appropriate place seems to be : https://ask.sagemath.org/questions/

I will never prefer ask.sagemath over sage-support.

-- 
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/r6i8hi%243a13%241%40ciao.gmane.io.

[sage-devel] Rounding in Sage

[Simon King]

Hi!

A few days ago, I asked on sage-support about rounding in Sage. But
since there was no answer and since it is relevant to my teaching in the
upcoming semester, let me repost here (with modifications).

According to IEEE 754, the default rounding mode for floating-point
operations is "round half to even". However, in examples it seems that
the rounding roule in RR is: "round half away from zero if the total
number of decimal digits in the result is odd and towards zero if the
total number of decimal digits of the result is even". Does that conform
to an established standard?

For teaching, it would be nice to have a customisable rounding function
that in particular allows rounding for different bases (binary, decimal,
etc), and allows to chose different rules (always round to 0, always
round away from 0, always round to +infty, always round to -infty,
round half to 0, round half away from 0, round half to +infty, round
half to -infty, round half to even, round half to odd, round half
alternatingly to 0 and away from 0, do the rounding in RR, ...).

Is there such function in Sage? Otherwise I would just write a custom
function for my course.

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/r6i1kk%24371d%241%40ciao.gmane.io.

[sage-devel] Re: Inherit Method but keep Documentation?

[Simon King]

Hi Michael,

perhaps the code in src/sage/docs/instancedoc.pyx is helpful for you?

I see several problems:
1. It is possible to override the __doc__ of an anbound method, but this
would override the __doc__ also in the parent class:

  sage: class A:
  : def my_method(self):
  : "Some doc"
  : pass
  : 
  sage: class B(A): pass
  sage: B.my_method.__doc__ = "Some other doc"
  sage: A.my_method.__doc__
  'Some other doc'

2. It is impossible (without Cython, at least) to override the __doc__
of a bound method:

  sage: a = A()
  sage: a.my_method.__doc__ = "Some more doc"
  ...
  AttributeError: attribute '__doc__' of 'method' objects is not writable

3. I thought a potential solution would be to create a subclass
FlexibleDocMethodType of types.MethodType that uses the instancedoc
decorator, say by accessing some attribute of the_method.__self__ that
holds the new doc. "Usual" methods would then (via some decorator) be
replaced by instances of FlexibleDocMethodType. But unfortunately it
seems that types.MethodTypes cannot be subclassed:

  sage: from types import MethodType
  sage: class FlexibleDocMethodType(MethodType):
  : pass
  : 
  ...
  TypeError: type 'method' is not an acceptable base type

Best regards,
Simon

On 2020-03-18, Michael Jung  wrote:
> Dear developers,
> to reduce redundancies in the SageManifolds code, we plan to inherit most 
> methods and classes from a (mathematically) more general setup. 
> Still, the current documentation is mandatory. Is it possible to establish 
> new documentations for inherited methods?
>
> An example:
>
> class Mother(SageObject):
> def my_method(self):
> r"""
> Some Documentation.
> 
> return 'Bam!'
>
> class Daughter(Mother):
> pass
>
> For the class "Daughter", the method "my_method" shall have a separate 
> self-containing documentation.
>
> Best regards
> Michael
>

-- 
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/r4vsbf%243tql%241%40ciao.gmane.io.

[sage-devel] Re: Inherit Method but keep Documentation?

[Simon King]

Hi!

On 2020-03-19, John H Palmieri  wrote:
> What about
>
> my_method = Mother.my_method
> my_method.__doc__ = "new docstring"
>
>
> Does that do what you want?

Probably not. Wouldn't that be the same as
   Mother.my_method.__doc__ = "new docstring"
?

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/r4v82j%241d2%241%40ciao.gmane.io.

[sage-devel] Re: yanking sage doctests in vim

[Simon King]

Hi Sébastien, hi Marc,

On 2020-03-12, Sébastien Labbé  wrote:
> You may not be using the good register. You may see what is in the current 
> registers by writing:
>
>:registers
>
> To yank in the register +, you do "+y or "+\Y to yank with Marc's code. The 
> register + is the clipboard on my machine (Linux). On OSX, the register + 
> was not the clipboard...

By some duckduckgo search, I found
https://stackoverflow.com/questions/3961859/how-to-copy-to-clipboard-in-vim,
from which I learned two things:

1. To access the OS's clipboard, one either needs to compile vim with the
   +clipboard flag, or (easier) "sudo apt-get install vim-gnome"
   (or perhaps installing vim-gtk will work, too)
2. In Windows, the registers + and * are equivalent. For X11 systems,
   though, they differ. For X11 systems, * is the selection, and + is
   the cut buffer (like clipboard).

After installing vim-gnome and opening a Sage source file in vim, I
hit V, moved down a few lines (marking a doctest) including the expected
output, then hit "*\Y and went to Sage, hit -insrt, et voilà: The
expected output and the prompts were removed and the test correctly
evaluated.

Caveat: It was treated as a single block of code, i.e. it was
not evaluated line by line, i.e. the original doctest was not recreated.
For example, the test from the file

sage: M = MatrixSpace(GF(25,'z'),2,3)([1,2,3,4,5,6])
sage: print(M)
[1 2 3]
[4 0 1]
sage: type(M) # optional: meataxe


eventually became

sage: M = MatrixSpace(GF(25,'z'),2,3)([1,2,3,4,5,6])
: print(M)
: type(M) # optional: meataxe
: 
[1 2 3]
[4 0 1]


in Sage command line after pasting.

In spite of the caveat, I think it is a quite useful addition!

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/r4df2d%242jm7%241%40ciao.gmane.io.

[sage-devel] Re: yanking sage doctests in vim

[Simon King]

Hi Marc,

On Wednesday, March 11, 2020 at 12:50:07 PM UTC+1, Marc Mezzarobba wrote:
>
> Sébastien Labbé wrote: 
> > But I am not getting errors, maybe my vim is too old (7.4.1689). I 
> > need to update my machine but I am always postponing this to tomorro 
>
> Indeed, it looks like I'm using features that appeared with vim 8. 
>

I opened a Sage source file in vim, marked a doctest in visual mode, and 
hit \Y. In the status line, vim shows the text
:call YankSageTest(visualmode(), 1)
So, apparently it did something.

But when I then go to Sage command line and hit -insert (which 
usually inserts what was previously copied), nothing happens (resp. some 
text was inserted that I have copied previously). This is with vim version 
8.2.343

What am I doing wrong? 

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/47eed341-75ea-4886-a9e9-6effcf9597e8%40googlegroups.com.

[sage-devel] Re: yanking sage doctests in vim

[Simon King]

Hi Marc,

sorry, I still don't get what *exactly* one needs to do in order to achieve 
*what*.

In your original mail, you wrote that it is "for copy-pasting examples and 
doctests to the sage repl".

If I understand correctly, repl is abbreviation for read-eval-print-loop. I 
guess that' what I call "command line version of Sage". That makes me 
wonder two things:
- By "copy-pasting doctests to the sage repl", do you mean that you mark 
the doctest including the expected output, and when you paste it to Sage 
then the expected output is automatically stripped, which is of course 
useful because it is Sage's job to compute that output?
- How is vim involved in my interaction with Sage? Do you mean the 
following: Open some file in vim that contains doctests, mark a doctest in 
vim, then go to the Sage command linel and paste what you've copied?

Best regards,
Simon

On Monday, March 9, 2020 at 4:08:20 PM UTC+1, Marc Mezzarobba wrote:
>
> Sébastien Labbé wrote: 
> > Should I understand that it filters out the output? Can you tell how 
> > you use it? 
>
> It only works linewise, and is mapped to Y, which is 
> probably something like \Y depending on your setup. You can use it 
> either by selecting some text in visual mode and typing \Y, or typing \Y 
> followed by a motion (e.g. \Yap). It will keep the input lines only and 
> strip the sage: and : markers. 
>
> -- 
> Marc 
>
>

-- 
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/50fb1c9d-d1ea-4662-b243-87e3a132783b%40googlegroups.com.

[sage-combinat-devel] Re: Image of a permutation

[Simon King]

On 2020-03-08, David Joyner  wrote:
> On a tangential matter, I'd like to add that
> according to Dan Bump's notes "Group Representation
> Theory" (http://sporadic.stanford.edu/bump/group/gr1_4.html),
> this set of elements that the permutations does not
> fix is called the support.

Exactly.

> If that is true then the SageMath
> support does not seem to be implemented correctly:
>
> sage: G = SymmetricGroup(10)
> sage: g = G.random_element(); g
> (1,3,6,7,4)(5,8,9)
> sage: g.support()
> {1, 2, 3, 4, 5, 6, 7, 8}

Oops. Certainly 2 is fixed, so, doesn't belong to the support.

Deserves a ticket, IMHO.

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-combinat-devel/r42jc7%24387h%242%40ciao.gmane.io.

[sage-combinat-devel] Re: Image of a permutation

[Simon King]

On 2020-03-08, David Joyner  wrote:
> I agree with Michael O, a permutation is a bijection,
> so the image is the domain is the codomain.

+1

> For a patch to "define the image of a permutation
> to be the set of elements that it does not fix" is a
> mistake, IMHO. Maybe the set computed could be
> called  "moved_points" or something like that?

Isn't that called the "support" of the permutation?

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-combinat-devel/r42j8j%24387h%241%40ciao.gmane.io.

[sage-devel] Re: Tip: easy input of math/unicode symbols

[Simon King]

On 2020-02-22, Emmanuel Charpentier  wrote:
> Le samedi 22 février 2020 14:35:49 UTC+1, Eric Gourgoulhon a écrit :
>> A solution here is to declare explicitly the LaTeX name of the symbolic 
>> variable at creation, as we did when using only ASCII names:
>>
>
> Of course. but this somehow defeats the purpose of "easy use of Unicode 
> characters"...

And that's why I believe it makes sense to exploit what IPython has to
offer concerning automatic transition between latex and unicode. Some
typical cases would work out of the box, one wouldn't reinvent the wheel
(because it makes use of existing functionality), and for those cases
that still don't work the user can provide the latex name explicitly.

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/r2s9lu%242n0h%241%40ciao.gmane.io.

[sage-devel] Re: Tip: easy input of math/unicode symbols

[Simon King]

On 2020-02-21, Simon King  wrote:
> Hi Emmanuel,
>
> On 2020-02-21, Emmanuel Charpentier  wrote:
>> sage: latex(λ^2)
>> λ^{2}
>
> Couldn't we modify the latex() function, by exploiting
> IPython.core.completer.reverse_latex_symbol, to automatically translate
> all unicode symbols that aren't understood by pdflatex?

Such as:
 sage: import IPython
 sage: from IPython.core.completer import reverse_latex_symbol
 sage: def replfunc(match):
 : return reverse_latex_symbol[match.group(0)]
 : 
 sage: import re
 sage: regex = re.compile('|'.join(re.escape(x) for x in reverse_latex_symbol))
 sage: f(λ) = sin(λ)
 sage: latex(f)
 λ \ {\mapsto}\ \sin\left(λ\right)
 sage: print(regex.sub(replfunc,latex(f)))
 \lambda \ {\mapsto}\ \sin\left(\lambda\right)

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/r2pj45%24q7v%241%40ciao.gmane.io.

[sage-devel] Re: Tip: easy input of math/unicode symbols

[Simon King]

Hi Emmanuel,

On 2020-02-21, Emmanuel Charpentier  wrote:
> sage: latex(λ^2)
> λ^{2}

Couldn't we modify the latex() function, by exploiting
IPython.core.completer.reverse_latex_symbol, to automatically translate
all unicode symbols that aren't understood by pdflatex?

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/r2phul%24v6u%241%40ciao.gmane.io.

[sage-combinat-devel] Re: fast vector partitions algorithm

[Simon King]

PS:

Sorry, I just notice that you did answer my question: It is 60 lines of
python code. That shouldn't be a problem to include in the Sage library
(i.e., in relevant parts of src/sage/..., maybe in the same location
than the current implementation.

Do you have a trac account?

Best regards,
Simon

On 2020-02-13, Simon King  wrote:
> Hi Denis,
>
> in the past, sage-combinat-devel was a very active list and certainly
> the topic of your post fits well, but it seems to me that it would be a
> good idea to re-post on sage-devel.
>
> Did you read the developer's guide?
>  
> Certainly people could help you contributing the code. In particular if
> the code is written in Python or Cython, it would probably be easy to
> fit it into src/sage/...
>
> Or is it an external package? Then it would of course be nice to have
> code in the sage library that makes use of the external package. Note
> that at least in the beginning, a new package would be optional.
>
> Concerning the "min" option: At least for now, the old code in Sage
> would not be removed. So, even with your package installed, one could
> easily make it so that the old code is used when the user requests the
> "min" option.
>
> Best regards,
> Simon
>
> On 2020-02-10, Denis Sunko  wrote:
>> I have translated the Haskell code for vector partitions by M. C. Err, The 
>> Computer Journal, Vol. 31, 1988, 283-284, into Python (2 or 3, stand-alone 
>> file with 60 lines total).
>>
>> The code works significantly faster than the Sage implementation:
>>
>> ┌┐
>> │ SageMath version 9.0, Release Date: 2020-01-01 │
>> │ Using Python 3.7.3. Type "help()" for help.│
>> └┘
>> sage: import vpartitions
>> sage: %time myvparts=vpartitions.vPartitionso([6,6,6])
>> CPU times: user 9.13 s, sys: 89.8 ms, total: 9.22 s
>> Wall time: 9.22 s
>> sage: %time sagevparts=list(VectorPartitions([6,6,6]))
>> CPU times: user 2min 10s, sys: 177 ms, total: 2min 10s
>> Wall time: 2min 10s
>> sage: myvparts[::-1]==sagevparts
>> True
>>
>> If someone would take over the job of contributing this code to Sage, I 
>> would be glad to help. There are a few caveats:
>>
>> 1) the code is recursive;
>> 2) there is no "min" option like in the Sage implementation.
>>
>> I do not know how difficult (or necessary) it would be to address these 
>> points.
>>
>> Of course, anyone can take it up straight from Err's paper instead, I won't 
>> be jealous:)
>>
>> Cheers,
>>
>> Denis
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-combinat-devel/r23999%24ph9%241%40ciao.gmane.io.

[sage-combinat-devel] Re: fast vector partitions algorithm

[Simon King]

Hi Denis,

in the past, sage-combinat-devel was a very active list and certainly
the topic of your post fits well, but it seems to me that it would be a
good idea to re-post on sage-devel.

Did you read the developer's guide?
 
Certainly people could help you contributing the code. In particular if
the code is written in Python or Cython, it would probably be easy to
fit it into src/sage/...

Or is it an external package? Then it would of course be nice to have
code in the sage library that makes use of the external package. Note
that at least in the beginning, a new package would be optional.

Concerning the "min" option: At least for now, the old code in Sage
would not be removed. So, even with your package installed, one could
easily make it so that the old code is used when the user requests the
"min" option.

Best regards,
Simon

On 2020-02-10, Denis Sunko  wrote:
> I have translated the Haskell code for vector partitions by M. C. Err, The 
> Computer Journal, Vol. 31, 1988, 283-284, into Python (2 or 3, stand-alone 
> file with 60 lines total).
>
> The code works significantly faster than the Sage implementation:
>
> ┌┐
> │ SageMath version 9.0, Release Date: 2020-01-01 │
> │ Using Python 3.7.3. Type "help()" for help.│
> └┘
> sage: import vpartitions
> sage: %time myvparts=vpartitions.vPartitionso([6,6,6])
> CPU times: user 9.13 s, sys: 89.8 ms, total: 9.22 s
> Wall time: 9.22 s
> sage: %time sagevparts=list(VectorPartitions([6,6,6]))
> CPU times: user 2min 10s, sys: 177 ms, total: 2min 10s
> Wall time: 2min 10s
> sage: myvparts[::-1]==sagevparts
> True
>
> If someone would take over the job of contributing this code to Sage, I 
> would be glad to help. There are a few caveats:
>
> 1) the code is recursive;
> 2) there is no "min" option like in the Sage implementation.
>
> I do not know how difficult (or necessary) it would be to address these 
> points.
>
> Of course, anyone can take it up straight from Err's paper instead, I won't 
> be jealous:)
>
> Cheers,
>
> Denis
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-combinat-devel/r23952%243jri%241%40ciao.gmane.io.

[sage-devel] Re: Poll: make giacpy_sage a standard package

[Simon King]

Hi Frederic,

On 2020-02-07, Han Frederic  wrote:
> It is indeed rare for an spkg to be linked to the sage library...

... but it is not the only one. p_group_cohomology is similar in that
regard.

> We need one of the following
> (to not lose any features) either giacpy_sage is an external package linked 
> to the sage library
> or a part of giacpy_sage (or all of it, because it is just few files) is 
> inside sage.

If giacpy_sage became standard, it indeed sounded reasonable to me to put
all Cython files into the SageMath library and only keep any non-cython
bits into a (standard) spkg.

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/r1jklj%241nc1%241%40ciao.gmane.io.

[sage-devel] Re: Poll: make giacpy_sage a standard package

[Simon King]

On 2020-02-04, Markus Wageringel  wrote:
> Giacpy_sage provides C-bindings for Giac which is already a standard 
> package. So making Giacpy_sage a standard package as well would allow to 
> replace pexpect calls to Giac by C-calls, which is the overarching goal of 
> #16688. Giac is currently used as fallback for symbolic integration where 
> this change would be useful (see also #28913). In addition, Gröbner basis 
> computations already use Giacpy_sage as alternative backend, so this would 
> become more accessible if the package type is changed to standard.

As Giac is standard, it totally makes sense to me to make its C-bindings
standard, too.

So, +1 from me.

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/r1bb28%242onl%241%40ciao.gmane.io.

[sage-devel] Re: Poll: make giacpy_sage a standard package

[Simon King]

Hi Samuel,

On 2020-02-03, Samuel Lelievre  wrote:
> Please vote for making giacpy_sage a standard package.

Could you elaborate what giacpy is about, i.e., what functionality would
it add to SageMath resp. improve in SageMath? That question isn't
addressed on the ticket yet.

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/r1avlg%243vp8%241%40ciao.gmane.io.

[sage-devel] Re: Unable to build sage after git trac config

[Simon King]

Hi Dima,

On 2020-01-30, Dima Pasechnik  wrote:
> I think git-trac should not be mentioned in the manual as the preferred way
> to use git.

OK. Stating that "being able to use plain git is a useful skill" is
fine, and of course elaborating how to use plain git to work with trac
is fine, too. But please do not remove the customised scripts or their
documentation.

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/r0ut4p%24mle%241%40ciao.gmane.io.

[sage-devel] Re: Unable to build sage after git trac config

[Simon King]

Hi Eric,

On 2020-01-30, Eric Gourgoulhon  wrote:
> I would even vote for removing the git-trac section from the developer 
> manual. 

-1

I do use "git trac".

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/r0uihu%24c5e%241%40ciao.gmane.io.

[sage-devel] Re: Python 2->3 incompatibility in unpickling

[Simon King]

Hi Nils,

yes, that's exactly the same problem! Thank you for reminding me. I've
totally forgotten how the "correct" encoding was called.

Best regards,
Simon

On 2020-01-22, Nils Bruin  wrote:
> On Wednesday, January 22, 2020 at 1:35:16 PM UTC-8, Simon King wrote:
>>
>> Here is an example: 
>> Unpickling the data initially results in a string, s: 
>>   sage: s = '\x80\x1f' 
>> I want it to be interpreted as the following bytes, b: 
>>   sage: b = b'\x80\x1f' 
>>
>> How can I efficiently transform s into b? The following works, but I 
>>
>
> This is exactly what we encountered on #28444, where we found that "latin1" 
> decoding has a left-inverse (if decoding acts on the left) of "latin1" 
> encoding. It looks like the encoding Py3 used for your py2-string was 
> "latin1" (that's what we decided was the smart thing to do most of the time 
> for possibly binary data), so
>
> s.encode(encoding="latin1")
>
> should do the trick. That should be pretty efficient.
>
>  
>
>> doubt that it is very efficient: 
>>   sage: import struct 
>>   sage: struct.pack('{}B'.format(len(s)),*(ord(_) for _ in s)) == b 
>>   True 
>>
>> Note that sage.cpython.string.str_to_bytes does't do what I need: 
>>   sage: sage.cpython.string.str_to_bytes(s) 
>>   b'\xc2\x80\x1f' 
>>
>> 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/r0ak7q%243884%241%40ciao.gmane.io.

[sage-devel] Python 2->3 incompatibility in unpickling

[Simon King]

Hi!

I have (Sage-related) data pickled with Python-2. Part of the data is
binary data put into a Python-2 str.

Now, with Python-3, the binary data is put into bytes.

Consequently, when unpickling my old data with Python-3, I want the
Python-2 str to be interpreted as bytes. However, Python-3 insists on
misinterpreting it as str, and I have trouble to turn that str into an
appropriate bytes.

Here is an example:
Unpickling the data initially results in a string, s:
  sage: s = '\x80\x1f'
I want it to be interpreted as the following bytes, b:
  sage: b = b'\x80\x1f'

How can I efficiently transform s into b? The following works, but I
doubt that it is very efficient:
  sage: import struct
  sage: struct.pack('{}B'.format(len(s)),*(ord(_) for _ in s)) == b
  True

Note that sage.cpython.string.str_to_bytes does't do what I need:
  sage: sage.cpython.string.str_to_bytes(s)
  b'\xc2\x80\x1f'

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/r0af6d%24mmj%241%40ciao.gmane.io.

[sage-devel] Re: Problem reading this list with slrn

[Simon King]

Dear Dima,

Indeed it now works. I didn't change anything, just tried again.

So, problem solved...

Thank you!
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/c0138de5-d1bd-4563-a165-03565650a398%40googlegroups.com.

Re: [sage-devel] Problem reading this list with slrn

[Simon King]

Hi Dima,

On Thursday, January 16, 2020 at 9:08:54 PM UTC+1, Dima Pasechnik wrote:
>
> the story is here, in fact:
>
> https://lars.ingebrigtsen.no/2020/01/06/whatever-happened-to-news-gmane-org/
>

 Thank you!

As it seems, the only mentioning of "news.gmane" in my home directory in a 
file whose name starts with "." is in .bashrc. However, changing
  export NNTPSERVER="news.gmane.org"
to
  export NNTPSERVER="news.gmane.io"
and sourcing .bashrc did not solve the problem. I still get "Failed to 
initialize server." --- but indeed it mentions news.gmane.io instead of 
news.gmane.org.

So, what else can I do?

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/58f885d7-95a1-47c0-8c4d-ffab6672f543%40googlegroups.com.

[sage-devel] Problem reading this list with slrn

[Simon King]

Hi!

I prefer reading all SageMath-related groups with slrn, via news.gmane.org. 
However, since a few days, I always get this:
king@klap:~$ slrn
slrn 1.0.2

Loading /usr/share/slrn/slang/slrn.sl
Reading startup file /etc/news/slrn.rc.
Reading startup file /home/king/.slrnrc.
Loading /usr/share/slrn/slang/mime.sl***Warning: Unable to find a unique 
fully-qualified host name.
slrn will not generate any Message-IDs.
Please note that the "hostname" setting does not affect this;
see the "slrn reference manual" for details.

Using newsrc file /home/king/.jnewsrc for server news.gmane.org.
Connecting to host news.gmane.org ...
Unable to make connection. Giving up.

Run-Time Error
slrn fatal error:
Failed to initialize server.

Do you happen to know whether I can solve that problem on my end? Or 
whether the list administrator can do something about it? Or is 
news.gmane.org simply dead?

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/25d3dd5b-2e56-4c31-b09b-8712e14760ec%40googlegroups.com.

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

[Simon King]

Hi Nils,

On 2020-01-06, Nils Bruin  wrote:
> In fact, I think it would make a lot of sense to make 9.1 the last release 
> to support py2 and therefore make 9.1 more a bugfix release: concentrate on 
> fixes of issues that arise as a result of 9.0 and fix them, so that there's 
> a relatively reliable point in the history of sage to run on py2. That 
> would automatically target significant new features for 9.2.

Having a bugfix release as the last py-2-supporting release sounds like
a good plan to me. So, +1 to this.

Also I think that the additional burden to average developers will be
small: If (on top of bug fixes) there would be new code in v9.1, then
making it work with py-2 would basically involve some "from __future__
import", isn't it?

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/quv67d%2478qv%241%40blaine.gmane.org.

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

[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/qs5jmj%242oo5%241%40blaine.gmane.org.

[sage-devel] Re: Package installation/uninstallation confusion

[Simon King]

Dear Erik,

On 2019-11-12, E. Madison Bray  wrote:
> On Fri, Nov 8, 2019 at 11:06 PM Simon King  wrote:
>> While we are at it: Currently, for building the package's documentation,
>> I use "$MAKE html" followed by some "cp -r" to copy the resulting html
>> files to $SAGE_SHARE/doc/p_group_cohomology. I guess this needs to be
>> fixed (in the sense of "rather use sdh_*) as well
>
> You can also use sdh_install which is a (partial) replacement for the
> "install" program, which does a few things in addition to just "cp -r"
> and tries to take care of platform-specific differences, if any.

Concerning "$MAKE html": Is "sdh_make html" the right thing, or did I
miss something? And I'll have a look into sdh_install.

Thank you!
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/qqek1e%2454e%241%40blaine.gmane.org.

[sage-devel] Re: Package installation/uninstallation confusion

[Simon King]

Hi Erik,

On 2019-11-08, E. Madison Bray  wrote:
> Just to clarify, once more (and please reread my earlier message in
> this thread regarding what a "DESTDIR install" is and why that is
> used),

This does not clarify it to me at all, I'm afraid. To start with,
in my very simple mind, I can not intuitively grasp that an
spkg-install script can possibly support a DESTDIR install if the
word "DESTDIR" does not appear in the spkg-install script.

> ...  This allows sage-spkg, the script that actually
> handles building/installing SPKGs, to look in the $SAGE_DESTDIR
> directory that is created as a temporary installation root for the
> package, and generate a list of files that is installed by the package
> [2].

Do I understand correctly that sage-spkg creates a temporary directory
and assigns the environment variable DESTDIR to it, then spkg-install
does its job, and *if* all installation steps done in spkg-install take
the DESTDIR environment variable into account then the installation
is correctly staged there before it is transferred from there to its
final destination? And the content of the json file is obtained from
the contents of the stage area before it is erased?

If that's the case then I'm confident that it should work to replace "$MAKE
install" with "sdh_make_install".

While we are at it: Currently, for building the package's documentation,
I use "$MAKE html" followed by some "cp -r" to copy the resulting html
files to $SAGE_SHARE/doc/p_group_cohomology. I guess this needs to be
fixed (in the sense of "rather use sdh_*) as well

I opened #28711 for it.

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/qq4ot1%2462r3%241%40blaine.gmane.org.

[sage-devel] Re: Package installation/uninstallation confusion

[Simon King]

Hi Dima,

On 2019-11-06, Dima Pasechnik  wrote:
> sdh_install installs a json file into
> SAGE_LOCAL/var/lib/sage/installed/
> which are then used by unistallaller
> ...
> I guess sdh_pip_install does not do this, I don't know.

No, I just checked: Those files of p_group_cohomology that got installed
by sdh_pip_install are listed in the json file. Those installed by
"$MAKE install" of course aren't.

> Anyhow, it would make perfect sense to split the package into two, as
> you propose.

If sdh_make_install and sdh_pip_install can share a single json file,
then there would be no need to split the package. I.e., the question is
whether "sdh_pip_install" will override the json file created by
"sdh_make_install", or whether it will append to it.

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/qq1k35%245jm3%241%40blaine.gmane.org.

[sage-devel] Re: Package installation/uninstallation confusion

[Simon King]

Hi John,

thank you!

So, I'll try sdh_make_install (sdh_install just copies some files), keep
using sdh_pip_install, and check what jason file results.

Best regards,
Simon

On 2019-11-07, John H Palmieri  wrote:
> These shell functions are defined and documented in 
> SAGE_ROOT/build/bin/sage-dist-helpers. In my opinion they should also be 
> documented in the developer's guide, but they don't seem to be.
>
>
> On Thursday, November 7, 2019 at 6:35:05 AM UTC-8, Simon King wrote:
>>
>> Hi Dima, 
>>
>> On 2019-11-06, Dima Pasechnik > wrote: 
>> > if you look at its spkg-install, you'd see that shd_install is not 
>> > used at some place, instead 
>> > 
>> > make install 
>> > 
>> > is done, something that won't write any JSON files, IMHO... 
>>
>> Good that I leave comments in my code... 
>>
>> The comment says that I used $MAKE install, because "sdh_make install 
>> got broken by trac ticket #24106". 
>>
>> However, I was unaware that apparently "sdh_make install" ought to be 
>> replaced by "sdh_install". So, I guess I should test this. 
>>
>> Or not? I see that far more packages use sdh_make_install (note the 
>> difference: What got broken apparently was sdh_make install with a blank 
>> space) than sdh_install. 
>>
>> Can you point me to man pages, where sdh_install versus 
>> sdh_make_install is discussed? 
>>
>> 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/qq1hv5%2413u7%241%40blaine.gmane.org.

[sage-devel] Re: Package installation/uninstallation confusion

[Simon King]

Hi Dima,

On 2019-11-06, Dima Pasechnik  wrote:
> if you look at its spkg-install, you'd see that shd_install is not
> used at some place, instead
>
> make install
>
> is done, something that won't write any JSON files, IMHO...

Good that I leave comments in my code...

The comment says that I used $MAKE install, because "sdh_make install
got broken by trac ticket #24106".

However, I was unaware that apparently "sdh_make install" ought to be
replaced by "sdh_install". So, I guess I should test this.

Or not? I see that far more packages use sdh_make_install (note the
difference: What got broken apparently was sdh_make install with a blank
space) than sdh_install.

Can you point me to man pages, where sdh_install versus
sdh_make_install is discussed?

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/qq1a2f%24865l%241%40blaine.gmane.org.

[sage-devel] Re: Package installation/uninstallation confusion

[Simon King]

Hi Eric,

On 2019-11-06, E. Madison Bray  wrote:
>> However, I heard rumours that in order to make a Sage optional package
>> uninstallable, one needs some new script analogous to spkg-install.
>>
>> Can someone give me a pointer on what should be done in that script and
>> what tools (sdh_*) are available for it?
>
> That's not quite accurate.  In general you do *not* need any
> additional scripts, with some exception.
> These packaging guidelines still need better documentation, but
> essentially you need to make sure the package is built for what is
> referred in GNU standards as a "DESTDIR install" [1].  This means that
> the package is built for installation to some particular prefix (e.g.
> `./configure --prefix=$SAGE_LOCAL` in autoconf terms), but can then be
> *installed* with some additional path (the "DESTDIR") prepended to the
> prefix.  This is similar to providing an alternate root (e.g. prefix
> is appended to DESTDIR instead of just "/").

Then what to do with p_group_cohomology? Its spkg-install script
installs two sub-packages. Each of them, I think, follows the above
scheme. However, Sage has no way of knowing that uninstalling
p_group_cohomology means uninstalling two sub-packages.

Perhaps one possibility is to split the current p_group_cohomology-3.3
into its two sub-packages, and make the first (which is autotoolized)
a dependency for the second (which is a bunch of cython and python
modules linked against the first sub-package.

Say:
- p_group_cohomology-3.4 shall only comprise what currently is the
  p/cython part of p_group_cohomology-3.3, and have modular_resolution
  as a dependency.
- modular_resolution-1.0 shall only comprise what currently is the
  autotoolized c-library part of p_group_cohomology-3.3

Advantage: "make p_group_cohomology" would also install the dependency,
hence, both packages get installed. And both packages can also be
un-installed, I suppose.

Disadvantage: The only purpose of modular_resolution-1.0 would be to
serve as a dependency, it is (to my knowledge at least) of no
independent use.

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/qpuqe5%247598%241%40blaine.gmane.org.

[sage-devel] Re: Package installation/uninstallation confusion

[Simon King]

On 2019-11-05, E. Madison Bray  wrote:
> The generated file `build/make/Makefile` is output by the
> `./configure` script.  In fact, that's its main purpose.  When
> switching branches in this case the best thing to do is to re-run
> `./configure`.

Concerning the original question how to uninstall stuff: In principle it
should be possible to cleanly uninstall p_group_cohomology, because it
consists of one autotoolized and one pip-installed sub-package.

However, I heard rumours that in order to make a Sage optional package
uninstallable, one needs some new script analogous to spkg-install.

Can someone give me a pointer on what should be done in that script and
what tools (sdh_*) are available for it?

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/qptqu0%2410hh%241%40blaine.gmane.org.

[sage-devel] Re: Gram-Schmidt Procedure for Symbolic Ring

[Simon King]

Hi Vincent,

On 2019-10-27, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> This was an easy one. The following shows that SR is just
> broken pi is rational!
>
> sage: q = continued_fraction(pi).convergent(100)
> sage: q
> 8736149038303113005348154524599771853409352442745266/2780802606066896232581239559281727773240004199722661
> sage: bool(pi == q)
> True

Nice!

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/qp4jg7%24mui%241%40blaine.gmane.org.

[sage-devel] Re: Gram-Schmidt Procedure for Symbolic Ring

[Simon King]

Hi Emmanuel,

On 2019-10-24, Emmanuel Charpentier  wrote:
> Writing *correctly* this decomposition is, IIRC, a numerical analysis 
> bitch... You are, IIRC, led to compute differences of large products, where 
> underflows can easily slip into... Definitely not an amateur's problem.
>
> While I agree in principle with Simon, actually *doing* it isn't easy.

Indeed. I had teaching in mind when I suggested to have an option to
force "numerically evil" methods, as the students tend to not believe
that a method they learned in the first year can be problematic.

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/qot3uj%242i8m%241%40blaine.gmane.org.

[sage-devel] Re: Gram-Schmidt Procedure for Symbolic Ring

[Simon King]

On 2019-10-24, Michael Jung  wrote:
> Do you have an example where SR fails to be exact?

One can convert a float to SR. The result is in SR, but still behaves
like a float:
  sage: a = SR(2.)^(1/500)
  sage: a^500
  2.05
  sage: a.parent()
  Symbolic Ring

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/qosktv%242qqp%241%40blaine.gmane.org.

[sage-devel] Re: Gram-Schmidt Procedure for Symbolic Ring

[Simon King]

Hi Michael,

On 2019-10-24, Michael Jung  wrote:
> Maybe, I did get something wrong. But what's the problem about Gram-Schmidt 
> on SR? There are just sums and divisions (and probably roots to normalize) 
> in Gram-Schmidt which should not lead to problems in SR.
>
> By the way, what does "exact" actually mean?

It means that arithmetics is not affected by rounding/approximations.
And some methods (apparently Gram-Schmidt is one of them) is only "safe"
when no rounding occurs.

That said, I'd appreciate to add an option that forces such methods
even in an inexact ring.

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/qosj0b%2463va%241%40blaine.gmane.org.

[sage-devel] Re: Question about deprecation warnings: when do they appear in doctests vs. real life?

[Simon King]

Hi David,

On 2019-10-19, David Roe  wrote:
> I think the idea is that if a user's typing interactively then they don't
> need a deprecation warning (since the behavior currently works).  It's more
> important to show a user a warning if they have the deprecated behavior in
> a function they've written.

I don't like that idea. If they write code, I suppose many people
test their code in an interactive session while writing it. So, it would
be fair to show them during the interactive session that the code
they're about to write is deprecated.

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/qoh6qq%2439ev%241%40blaine.gmane.org.

[sage-devel] Re: How to recover from total git screwup?

[Simon King]

On 2019-10-02, Kwankyu Lee  wrote:
> Hera:sage-dev$ g version
> git version 2.23.0 

$ git version
git version 2.7.4

May that be the problem, then?

In any case, git checkout -f  did work, and apparently did
no harm. So, I'm back at work...

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/qn1luj%243bqv%241%40blaine.gmane.org.

[sage-devel] Re: How to recover from total git screwup?

[Simon King]

On 2019-09-28, Simon King  wrote:
> I wonder what's different. I am still reluctant to do "git checkout -f
>", but perhaps that would be my best bet.

I tried, and it seemed to work.

However, someone who knows about git (i.e., not I) should report the bug
that git allows deletion of a branch that is checked out in another
worktree.

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/qmv0tl%246eqo%241%40blaine.gmane.org.

[sage-devel] Re: How to recover from total git screwup?

[Simon King]

Here is how to reproduce the git problem at least to some extent:

king@klap:~$ mkdir gittest
king@klap:~$ cd gittest
king@klap:~/gittest$ mkdir A
king@klap:~/gittest$ cd A
king@klap:~/gittest/A$ git init
Initialized empty Git repository in /home/king/gittest/A/.git/
king@klap:~/gittest/A$ touch file1
king@klap:~/gittest/A$ git add file1
king@klap:~/gittest/A$ git commit -m "First"
[master (root-commit) 64e0df0] First
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file1
king@klap:~/gittest/A$ git worktree add -b foobar ../B master
Preparing ../B (identifier B)
HEAD is now at 64e0df0 First
king@klap:~/gittest/A$ touch file2
king@klap:~/gittest/A$ git add file 2
fatal: pathspec 'file' did not match any files
king@klap:~/gittest/A$ git add file2
king@klap:~/gittest/A$ git commit -m "Second"
[master abd4169] Second
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file2
king@klap:~/gittest/A$ git branch -d foobar
Deleted branch foobar (was 64e0df0).
king@klap:~/gittest/A$ cd ../B
king@klap:~/gittest/B$ git log
fatal: your current branch 'foobar' does not have any commits yet
king@klap:~/gittest/B$ git status
On branch foobar

Initial commit

Changes to be committed:
  (use "git rm --cached ..." to unstage)

new file:   file1

king@klap:~/gittest/B$ ls
file1


I believe it is a bug that git allowed me the "git branch -d foobar"
operation. If someone knowing where to report a git bug agrees that it
is a bug, please go ahead.

But now comes a surprise:
king@klap:~/gittest/B$ git checkout -b new_foobar master
Switched to a new branch 'new_foobar'
king@klap:~/gittest/B$ git status
On branch new_foobar
nothing to commit, working directory clean
king@klap:~/gittest/B$ ls
file1  file2

That's really a surprise. So, I tried the same in my Sage git repository.
Unfortunately it was not successful:
  $ git checkout -b t/28414/p_group_cohomology_in_PY3 
t/28414/p_group_cohomology_in_py_3
  ...  ...
  Please, commit your changes or stash them before you can switch branches.
  Aborting

I wonder what's different. I am still reluctant to do "git checkout -f
", but perhaps that would be my best bet.

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/qmnepk%245cg8%241%40blaine.gmane.org.

[sage-devel] Re: How to recover from total git screwup?

[Simon King]

Hi Kwankyu,

On 2019-09-27, Kwankyu Lee  wrote:
>> I am not totally sure if that's what was happening. Would git really 
>> allow the "git branch -d" operation when another worktree is on that 
>> branch? 
>>
>
> If you were at foobar in py3 worktree and at develop in py2 worktree, no.

Then what else has happened? According to my bash history, this is
basically what I did:

- I was on foobar branch in my py3 worktree. Foobar is in fact
  the same as the branch from trac ticket #28444.
- I went to my py2 worktree and checked out "develop". After "git pull",
  I realised that "foobar" already is merged in "develop".
- Still in the py2 worktree, I went to some branch "baz", which is
  a few commits ahead of foobar, and at that point was the branch of
  trac ticket #28414.
- Since foobar was in develop, I did "git branch -d foobar", still in the
  py2 worktree. It worked without complaints. Note: It was "-d",
  not "-D".
- Still in py2 worktree, I rebased "baz" on top of "develop", and
  force-pushed it to trac ticket #28414.
- I went to my py3 worktree, did "git status", got some hundreds of
  pages of output, although I didn't edit any file since my last visit
  of the py3 worktree. I tried "git checkout develop", which failed, because
  git told me to first commit or stash my changes. I did "git log",
  which told me that there were absolutely no commits yet.

>> Can you please tell me how to recover from that mess? 
>
>
> Why not just add a new shiny py3 worktree and move your untracked files 
> from the old py3 worktree to the new one?

My hope was that I can somehow recover from the mess without rebuilding
all of sage-on-py3. Plus, in "reality" (from my perspective, "reality"
is the opposite to "git history") there are no untracked files. The
files in my py3 worktree are physically the same as those from the git
branch from #28444, that is still available in my py2 worktree.

That's why I thought "git checkout -f develop" in the py3 worktree might
help. But perhaps after that I'd need to rebuild Sage from scratch, too?
Anyway, before trying a forced operation: Would it potentially create
even more mess?

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/qmmucg%244e2a%241%40blaine.gmane.org.

[sage-devel] Re: How to recover from total git screwup?

[Simon King]

On 2019-09-27, Simon King  wrote:
> Indeed, all files in the Sage tree are untracked, in the py3 worktree.
> And that's why "git checkout develop" won't work (it tells me to commit
> are stash first).
>
> Can you please tell me how to recover from that mess?

Perhaps "git checkout -f " in the py3 worktree? Or would
that do more harm than good? Certainly "git stash" is not a serious
option, as this would be a copy of the whole Sage sources (namely the
diff between a branch with an empty commit history and the Sage
sources).

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/qmlsne%24316%241%40blaine.gmane.org.

[sage-devel] How to recover from total git screwup?

[Simon King]

Hi!

At some point I was advised to use "git worktree" to have one py2 and
one py3 installation sharing the same git repository. Till one hour ago,
it worked fine.

Now, if I understand correctly, in my py2 worktree, I was on the develop
branch. There was one branch "foobar" (not its real name) that meanwhile
is fully merged, so that I thought it was safe to do "git branch -d foobar".
However, it seems that my py3 worktree was on that now deleted branch.

I am not totally sure if that's what was happening. Would git really
allow the "git branch -d" operation when another worktree is on that
branch?

In any case, my bash history shows that at some point I did
"git branch -d foobar", and when I am in the py3 worktree, I now get
  $ git log
  fatal: your current branch 'foobar' does not have any commits yet

Indeed, all files in the Sage tree are untracked, in the py3 worktree.
And that's why "git checkout develop" won't work (it tells me to commit
are stash first).

Can you please tell me how to recover from that mess?

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/qmljo4%245v23%241%40blaine.gmane.org.

[sage-devel] NEWOBJ isn't a type object

[Simon King]

Hi!

Trying to make my group cohomology package work in both py2 and py3, I
already thought it was done, but I found that a pickle created with py3
cannot be read by py2. It would of course be possible to argue that people
are unlikely to unpickle a py3 pickle with py2, and since unpickling a
py2 pickle with py3 seems to work, we shouldn't care.

But just in case I wanted to ask if you know of an easy fix.

According to explain_pickle, the following happens:

sage: pg_RESL_sparse_unpickle_class =
unpickle_global('pGroupCohomology.resolution', 'RESL_sparse_unpickle_class')
sage: si1 = unpickle_newobj(pg_RESL_sparse_unpickle_class, ())
Traceback (most recent call last):
...
UnpicklingError: NEWOBJ class argument isn't a type object

What does that error mean? In fact, the class IS a type:

sage: from pGroupCohomology.resolution import RESL_sparse_unpickle_class
sage: isinstance(_, type)
True

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/qmko8k%24jhk%241%40blaine.gmane.org.

[sage-devel] Re: Coexistence of py2 and py3

[Simon King]

Hi Dima,

On 2019-09-24, Dima Pasechnik  wrote:
> I'm surprised that *.c files created by Cython for pyX may be used for
> py(5-X) without many problems.
> I'd expect this to break down totally...

Indeed. It is surprising that I only got two kinds of spurious errors:
In one place, a pickle of a dictionary was unpickled apparently as a
string, and sometimes  was identical to . But not much
else.

Anyway, first tests seem to indicate that the problems vanish when
changing setup.py so that creation of .c files takes place in different
folders for different python versions.

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/qmdrkr%242g0s%241%40blaine.gmane.org.

[sage-devel] Re: Coexistence of py2 and py3

[Simon King]

Hi Dima,

On 2019-09-24, Dima Pasechnik  wrote:
> Shouldn't coexisting installations like this have different --prefix ?

Of course. But if I understand correctly, this only affects where stuff
is installed, not where it is built. The situation is as follows:

- the .c files are created in the source directory, i.e., where the
  corresponding .pyx files live. Therefore the .c files are only
  re-generated when the .pyx file is touched, but not when the language
  level changes.
- the .so files are created in build/lib.linux-x86_64-2.7 resp. -3.7,
  hence, the paths do take into account the language level. This is of
  course a good idea, but not enough (because of the .c files).
- eventually the .so files are installed in --prefix.

The .c file can very well depend on the language level. E.g., in the Sage
library, compile time variables are used to tell Cython what code to
use for py2 and what code for py3.

Hence, IMHO it is clearly a bug that the .c files are not by default
created in a path that depends on the language level.

But I don't know where that bug should be reported.

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/qmdiei%2479ou%241%40blaine.gmane.org.

[sage-devel] Re: Coexistence of py2 and py3

[Simon King]

Hi Vincent,

On 2019-09-24, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> Are you sure that the problem comes from the C files? If you erase
> them between the two installations what do you get?

That's what I'm testing now.

BTW, meanwhile I found that I can prescribe in my setup.py where to
create the .c files (the question in my post was how to do it):
  cythonize(...,
  build_dir=os.path.join("build","c_files-{}.{}".format(version_info.major,
  version_info.minor)))

With this in setup.py, the .c files will be in build/c_files-2.7 resp.
in build/c_files-3.7, whereas (as before) the .so files are in
build/lib.linux-x86_64-2.7 resp. ... -3.7.

I will see if this is enough to solve the problem.

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/qmdhoe%244633%241%40blaine.gmane.org.

[sage-devel] Coexistence of py2 and py3

[Simon King]

Hi!

At #28414, I'm trying to upgrade my group cohomology package so that it
works both on sage-with-py2 and sage-with-py3.

On the laptop where I work on the new package version (I didn't publish
the code yet), I have a py2 and a py3 installation of Sage. To build the
package without the hassle of recompiling everything, I build the
development version of my package by opening a Sage shell in the
package's src folder, and then run
   sage -python setup.py build
   sage -pip install . --upgrade

However, when I do the above in both versions of Sage (py2 and py3),
then in the py2 version strange things happen. Namely: In some Cython
modules of my package, one has str==unicode, which means that an
explicit cast to str results in a unicode, which results in errors when
passing it to functions from other modules expecting a str.

Dima said on the ticket that he met similar confusions about str and
unicode in the past, and he had the impression that it had to do with
both Sage versions sharing the same $DOT_SAGE folder. However, the
problem persists when I remove $DOT_SAGE.

Although `sage -python setup.py build` does create the .so files in
different folders for different python versions (namely
build/temp.linux-x86_64-2.7 and build/temp.linux-x86_64-3.7), it creates
the .c files in THE SAME directory (namely where it finds the corresponding
.pyx files).

My theory is that the confusion is caused by having the .c files in the
same directory. But a duckduckgo search didn't tell me how to prescribe
a different directory for the .c files (resp. the solutions I found,
such as "python setup.py build --build-lib " didn't
seem to work).

Can you tell me how to prescribe a folder for the .c files?

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/qmd97s%2425hp%241%40blaine.gmane.org.

[sage-devel] Recommended way to implement division for RingElement

[Simon King]

Hi!

Let R be a ring that is an F-vector space, for some field F.
Let x,y be elements of R and c be an element of F.

If I understand correctly, in order to implement x/y, one should provide
a single underscore method x._div_. But what should one provide for x/c?
It seems that the default behaviour is to replace x/c by x*(~c), but
for efficiency I don't want that c is inverted in F before letting it
act on x.

Moreover, in my use case, R is not an integral domain (thus, has no fraction
field), and actually I don't want division in R at all. So, what do I
need to do in order to make x/y NOT work (and fail with a TypeError)?

In the above situation, is it recommended to override double underscore
__div__? Then what about Py3? Would it then be needed to override
__div__, __truediv__ and __floordiv__?

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/qm4nsn%245e4%241%40blaine.gmane.org.

[sage-devel] Re: The opportunity of Python 3 migration

[Simon King]

Hi!

Although late...

On 2019-09-01, mmarco  wrote:
> ...
>
> Do you think it is reasonable to do these deep changes in this short time? 
> If it is , then i definitely vote for it.
>
> If it is not, then I would propose to leave it as a longer term goal 
> (hopefully not much longer), and once we have a fully python3 bases sage,  
> write the guidelines you gave down in the development guide so the new code 
> follows this approach.

I think those things should definitely be in some written the guidelines!

Since I am currently migrating my main Sage project from python-2 to
python-"2 and 3", I know that not all parts of the change of user code
are trivial.
I'd find it helpful to have some documents explaining the state of the
art in Sage (similar to some documents we have for our coercion
framework).

I have a question on Cython, though: When functions/methods will more
often return an iterator instead of a list/tuple, what is the "cdef"
type of an iterator? I.e., how can one tell Cython that a particular
object is an iterator, so that Cython can produce faster code for it?

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/qm2h9d%245gsi%241%40blaine.gmane.org.

[sage-devel] Using travis-ci on Sage with both py2 and py3

[Simon King]

Hi!

During recent the Sage workshop in Bonn, I started using travis-ci for
my optional Sage package on group cohomology. I am now basically done to
make the package work both in py2 and py3 --- on my laptop at least.

What is needed to do to let both language levels be considered in
travis-ci?

Currently, my .travis.yml starts with
services:
  - docker

before_install:
  - docker pull sagemath/sagemath-dev:develop

What is the name of the corresponding docker image for the Sage py3
development version, and how must I modify the .travis.yml to let BOTH
versions be tested?

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/qlvomo%2419mk%241%40blaine.gmane.org.

[sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3

[Simon King]

PS:

On 2019-09-03, Simon King  wrote:
> - Without `encoding='bytes'`, Python-3 can in general not unpickle any
>   pickle created with Python-2 that contains strings.

Stated differently:
Ostensibly, Python-2 str corresponds to Python-3 bytes, and Python-2
unicode corresponds to Python-3 str. But Python-3 tries to unpickle the
pickle of a Python-2 str as a Python-3 str, NOT as a Python-3 bytes. And
that's an annoying oddity (or indeed a bug?) in Python, IMHO.

Cheers,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qkl2ne%24uo5%241%40blaine.gmane.org.

[sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3

[Simon King]

Hi!

On 2019-09-02, Simon King  wrote:
> The problem apparently boils down to the following:
> - Pickle the string  '\x80\x1f' in Python-2
> - Try to load that pickle in Python-3 (it fails).
>
> Bummer!

Nils Bruin pointed me to
https://stackoverflow.com/questions/28218466/unpickling-a-python-2-object-with-python-3

The proposed solution there is to use pickle.load(,
encoding='bytes'). The encoding keyword only exist in Python-3.
If I undestand correctly (and some basic tests confirm the following
statements):
- Python-2 can unpickle both pickles created with Python-2 and pickles created
  with Python-3 can be read with Python-3
- Without `encoding='bytes'`, Python-3 can in general not unpickle any
  pickle created with Python-2 that contains strings.
- With `encoding='bytes'`, Python-3 *can* unpickle a pickle created with
  Python-2 containing strings, and it doesn't interfere with unpickling
  a pickle created with Python-3.

So, I suggest that at #28444 we change sage.misc.persist so that it uses
pickle.load() with the `encoding` keyword in Python-3 and withou that
keyword in Python-2. Do the Python-3 experts agree that that approach
makes sense? Given that a Python-2 string corresponds to a Python-3
bytes, I think it does, but I am not an expert.

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/qkl1dv%247bpp%241%40blaine.gmane.org.

[sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3

[Simon King]

On Monday, September 2, 2019 at 6:22:24 PM UTC+2, Simon King wrote:
>
> Also, if I understand the error message "UnicodeDecodeError: 'ascii' 
> codec can't decode byte 0x80 in position 0: ordinal not in range(128)" 
> correctly, it is an error in unpickling a string. And this, I believe, 
> can and must be totally absolutely backwards compatible. 
>

The problem apparently boils down to the following:
- Pickle the string  '\x80\x1f' in Python-2
- Try to load that pickle in Python-3 (it fails).

Bummer!

AFAIK, what I need to unpickle my old data is a way to tell Python-3 that 
it shall (at least temporarily) unpickle all strings as bytes, in the sense 
that the pickled string  '\x80\x1f' should be understood as b'\x80\x1f'. Is 
there a way?

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/c209a82e-b914-4e02-bfae-52130d02c954%40googlegroups.com.

[sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3

[Simon King]

On 2019-09-02, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> As discussed in
>
>   https://groups.google.com/forum/#!topic/sage-devel/JuKzzgxDlmA
>
> Pickling/unpickling is not supposed to work accross Sage versions
> (including the Python version you use).
>
> Is this what you are trying to make work?

The pickle that I posted at #28444 is of course not more than a small
example and is a matter of seconds to reconstruct in Python-3. However,
losing data that are the result of several months of computation would
be hard to swallow.

Also, if I understand the error message "UnicodeDecodeError: 'ascii'
codec can't decode byte 0x80 in position 0: ordinal not in range(128)"
correctly, it is an error in unpickling a string. And this, I believe,
can and must be totally absolutely backwards compatible.

Cheers,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qkjfjm%241r9o%241%40blaine.gmane.org.

[sage-devel] Re: Unpickling problem (backwards incompatibility) in Python 3

[Simon King]

On 2019-09-02, Simon King  wrote:
> Strangely, when I read the pickle as a string
>open('path/to/file.sobj').read()
> then it fails with a (different?) UnicodeError in Python-3.

That's not the problem. However, I am not able to track down the problem
myself. So, I'd appreciate help.

I think I can show that the unpickling problem is NOT related with an
optional package. I believe being unable to read a pickle is a blocker
for the transition to Python-3. Therefore, I opened #28444.

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/qkje1o%24743i%241%40blaine.gmane.org.

[sage-devel] Unpickling problem (backwards incompatibility) in Python 3

[Simon King]

Hi!

I have a pickle that I can unpickle in Sage-with-Python-2, but it fails
to unpickle in Sage-with-Python-3, because of some UnicodeError.
Strangely, when I read the pickle as a string
   open('path/to/file.sobj').read()
then it fails with a (different?) UnicodeError in Python-3.

The details (namely the pickle and the steps to read it in Python-2) can
be found in https://trac.sagemath.org/ticket/28414#comment:36
Can some expert please tell me how to unpickle the pickle in Python-3?

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/qkhni5%2457f7%241%40blaine.gmane.org.

[sage-devel] Re: Wrong python in Sage shell?

[Simon King]

Hi Dima,

On 2019-08-29, Dima Pasechnik  wrote:
> is  this python2 from your OS, or from Sage's installation?

>From Sage's installation (apparently Sage-with-py-3 also builds
python-2):

  (sage-sh) king@klap:~$ which python
  /home/king/Sage/git/py3/local/bin/python
  (sage-sh) king@klap:~$ which python3
  /home/king/Sage/git/py3/local/bin/python3

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/qk89pp%243oho%241%40blaine.gmane.org.

[sage-devel] Wrong python in Sage shell?

[Simon King]

Hi!

The following happens with a Py-3 build of Sage: I open a sage-shell,
and then I get
  (sage-sh) king@klap:src$ sage --python --version
  Python 3.7.3
  (sage-sh) king@klap:src$ python --version
  Python 2.7.15

Is it expected that the default python version in a py-3 install is a
py-2?

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/qk87o9%2478oi%241%40blaine.gmane.org.

[sage-devel] Re: inconsistency in computation of differential of a map between manifolds

[Simon King]

Hi Eric,

On 2019-08-27, Eric Gourgoulhon  wrote:
>  To avoid such mistake, you can run set_inverse() with the option 
> verbose=True. Then the provided inverse transform is checked.

Is the option really called "verbose=True"? Not "check=True", like in
most other cases?

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/qk525b%247ims%241%40blaine.gmane.org.

[sage-devel] Re: slowness in copy of integer sparse matrices

[Simon King]

Hi all,

did someone open a ticket for that issue?

Best regards,
Simon


On 2019-08-24, Nils Bruin  wrote:
> It seems to be spending a lot of time in cython code, so "%crun" might give 
> the best idea. This is part of the profile obtained by running the "copy" 
> command 20 times:
>
>0   0.0%   1.3% 2575  98.2% 
> __pyx_pw_4sage_6matrix_21matrix_integer_sparse_21Matrix_integer_sparse_5__init__
>   27   1.0%   2.4% 2271  86.6% 
> __pyx_f_4sage_7modules_21vector_integer_sparse_mpz_vector_set_entry
>0   0.0%   2.4% 1719  65.6% PyRun_FileExFlags
>   24   0.9%   3.3% 1290  49.2% 
> __pyx_f_4sage_7modules_21vector_integer_sparse_allocate_mpz_vector
>  213   8.1%  11.4% 1201  45.8% sig_malloc (inline)
>0   0.0%  11.4% 1193  45.5% PyRun_SimpleFileExFlags
>   27   1.0%  12.4%  957  36.5% __gmpz_init
>   38   1.4%  13.9%  930  35.5% 
> __pyx_f_4sage_3ext_6memory_sage_sig_malloc
>  316  12.1%  25.9%  828  31.6% __GI___libc_malloc
>  163   6.2%  32.2%  751  28.7% sig_free (inline)
>5   0.2%  32.4%  733  28.0% 
> __pyx_f_4sage_3ext_6memory_sage_sig_free
>0   0.0%  32.4%  705  26.9% Py_Main
>  323  12.3%  44.7%  512  19.5% _int_malloc
>  336  12.8%  57.5%  340  13.0% _int_free
>  334  12.7%  70.2%  334  12.7% sig_unblock (inline)
>
>  There's no obvious culprit to my eye. It looks like a lot of time is spent 
> in memory allocation and in setting of entries. Using a boolean matrix 
> could be much more efficient.
>
> On Saturday, August 24, 2019 at 3:47:25 AM UTC-7, Frédéric Chapoton wrote:
>>
>> Hello,
>>
>> With sage 8.9.b7 under py3, I get
>>
>> sage: P = posets.TamariLattice(8)
>> sage: H = P._hasse_diagram
>> sage: L = H.lequal_matrix()
>> sage: %time copy(L)
>> CPU times: user 2.71 s, sys: 4.01 ms, total: 2.71 s
>> Wall time: 2.71 s
>> 1430 x 1430 sparse matrix over Integer Ring (use the '.str()' method to 
>> see the entries)
>>
>> And this seems to me to be a bit too much. But maybe I am wrong ? This 
>> comes from here:
>>
>> sage: ms = L.parent()
>> sage: ec = ms.element_class
>> sage: d = L.dict()
>> sage: %timeit ec(ms, entries=d, coerce=False, copy=False)
>> 1 loop, best of 5: 2.63 s per loop
>>
>> Any idea on what is happening ? on how to improve the situation ?
>>
>> cheers,
>> Frédéric
>>
>

-- 
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/qk08pt%242u0j%241%40blaine.gmane.org.

[sage-devel] Re: doctest a single function or class

[Simon King]

Hi,

I am sorry for the late answer (and I am a bit surprised that nobody
else answered before).

I believe it is somehow useful to have such a feature when developing a
large piece of new code (so that one can do a relevant subset of tests
quickly). However, I am not so sure how that feature would be used once
the piece of code is published. I.e., I cannot see how that feature
would be useful in the Sage test suites, but I see potential use in
development.

Is that the use case you had in mind?

Best regards,
Simon

On 2019-07-09, TB  wrote:
> Dear list,
>
> Is there a way to test a single docstring of a function/method, or all 
> the docstrings in a specific class, and not an entire module?
>
> This is useful when testing a long file, without copying the needed 
> docstring to a new file. This is also different than 
> TestSuite(obj).run(). Currently I could only find the run_doctests() 
> functions that accepts modules, but not objects. Should I open a ticket 
> to add support for objects, or a flag to the TestSuite to run the 
> doctest (but not recursively)?
>
> The command-line interface of the built-in unittest module in Python 
> supports this usecase:
> $ python -m unittest test_module.TestClass.test_method
> to test a specific method.
>
> Regards,
> TB
>
> [1] https://docs.python.org/3/library/unittest.html#command-line-interface
>

-- 
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/qiu3ch%2430iu%241%40blaine.gmane.org.

[sage-devel] Re: save/loads and the pickle jar

[Simon King]

Hi,

On 2019-08-02, E. Madison Bray  wrote:
> Sage's use of pickle for save()/load() is a mis-feature IMO.  One that
> made sense at a time, for lack of a better choice.  And that's still
> useful as a means of saving/restoring some objects between sessions.
> But I don't think you can always guarantee it to be stable.

What better format do you suggest?

I am surprised that you see a fundamental problem with Sage's pickling: If
code or even the data structures change, then it is still possible to
fit old data (pickles) into the new data format. Evidently, when you
decide to change the data structures in your algorithms, you *have* to
write a function that translates old data into the new format - but
on the positive side, you *can* write such a function.

Is there a different approach that allows to change your code over time
(evidently that's absolutely needed for a project that isn't dead!)
while still being able to read data that you have stored with your old
code?

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/qi13nj%2425kk%241%40blaine.gmane.org.

[sage-devel] Re: Possible to use current Sage version in travis-ci?

[Simon King]

Hi Markus,

apparently our posts crossed.

On 2019-08-01, Markus Wageringel  wrote:
> Usually, the latest beta should be available as sagemath/sagemath:develop 
> at DockerHub. However, for some reason this tag has not been updated in a 
> while, so it still points to 8.8.beta5. See also 
> https://groups.google.com/forum/#!topic/sage-devel/hHWlOluXtos.
>
> It is also possible to use the docker image 
> registry.gitlab.com/sagemath/dev/trac/sagemath:develop from gitlab which is 
> up-to-date with the latest beta. Though, I am not sure whether this is 
> officially supported.

Indeed it seems that "docker pull sagemath/sagemath-dev:develop" works (note:
sagemath-dev:develop, not sagemath:develop).

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/qhuh0f%247nh0%241%40blaine.gmane.org.

[sage-devel] Re: Possible to use current Sage version in travis-ci?

[Simon King]

Hi Nathan,

On 2019-08-01, Nathan Dunfield  wrote:
> Docker images with beta versions of Sage are available:
>
> https://hub.docker.com/r/sagemath/sagemath/tags

Great, thank you! When applying a patch (from some closed-but-not-merged
ticket) to the latest beta tag then things work fine, which probably means
that in the near future I can say more about my software than "it works
on my laptop" ;-)

Is it possible to automatically go to the latest available tag?

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/qhug9d%246353%241%40blaine.gmane.org.

[sage-devel] Possible to use current Sage version in travis-ci?

[Simon King]

Hi!

Last week at SageDays100, I got an introduction to travis-ci, and with
help from this list and a lot of duckduckgo-search I now have a version
of my group cohomology software that on github with travis-ci successfully
installs in a Sage docker image.

Problem: It does install, but it wouldn't pass tests in the docker
image, since it uses features that are only in the latest beta.

Question: Is it (reasonably) possible to use a sage beta version in
travis-ci? How?

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/qht1ep%24325u%242%40blaine.gmane.org.

[sage-devel] Re: How to use spkg-install in a travis-ci script?

[Simon King]

Hi Markus,

On 2019-07-31, Markus Wageringel  wrote:
> I think it would be good to keep the install script for Travis-CI as close 
> as possible to what you would normally do to install a package in Sage, 
> that is, create an updated tarball of your repository and copy it to 
> upstream/, update the checksums and then install it with sage -i.

Thank you for encouraging me to do this. Before, I created that tarball
and updated checksums etc. *manually*. Now, I wrote scripts for it, and in
fact installation now works on travis-ci.

I have a follow-up, though, but I guess that belongs to a new thread.

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/qht111%24325u%241%40blaine.gmane.org.

[sage-devel] Re: How to use spkg-install in a travis-ci script?

[Simon King]

Hi Markus,

On 2019-07-31, Markus Wageringel  wrote:
> I think it would be good to keep the install script for Travis-CI as close 
> as possible to what you would normally do to install a package in Sage, 
> that is, create an updated tarball of your repository and copy it to 
> upstream/, update the checksums and then install it with sage -i. This way, 
> Sage will handle the details of running the spkg-install script. You can 
> set a custom docker entrypoint to avoid running everything inside a Sage 
> subshell, see for example here 
>,
> 
> though I used pip for installing the package.

That sounds very reasonable. Will definitely do so in future, when I'm
done experimenting with docker and travis-ci, turning towards actual
production.

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/qhsbke%242aob%241%40blaine.gmane.org.

[sage-devel] Re: How to use spkg-install in a travis-ci script?

[Simon King]

On 2019-07-30, Simon King  wrote:
> Perhaps I found a solution.

Yes and no.

Yes, it does work with the sage version on my laptop

No, it does not work on travis-ci with a sage docker image.

Namely, sage-dist-helpers cannot be found in $SAGE_ROOT/build/bin in the
docker image:

ls $SAGE_ROOT/build/bin
sage-apply-patches
sage-download-file
sage-flock
sage-logger
sage-package
sage-pip-install
sage-python23
sage-spkg
sage-spkg-uninstall
sage-system-python
sage-uncompress-spkg

I guess simply the version in the docker image (which is "latest") is
too old. What can I replace "source $SAGE_ROOT/build/bin/sage-dist-helpers"
with, in the docker image?

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/qhq9mv%242fkc%241%40blaine.gmane.org.

[sage-devel] Re: How to use spkg-install in a travis-ci script?

[Simon King]

Perhaps I found a solution.

Apparently the sdh_* shell functions are defined in
$SAGE_ROOT/build/bin/sage-dist-helpers. Sourcing, so it seems, makes the
spkg-install script work.

Best regards,
Simon

On 2019-07-30, Simon King  wrote:
> Hi Dima,
>
> On 2019-07-30, Dima Pasechnik  wrote:
>> just fix the PATH, no?
>>
>> It should include SAGE_ROOT/src/bin, SAGE_ROOT/build/bin, etc
>
> Apparently sage -sh is fixing the path:
>
> $ ~/Sage/git/sage/sage -sh -c 'echo $PATH'
> /home/king/Sage/git/sage/local/libexec/ccache:/home/king/Sage/git/sage/build/bin:/home/king/Sage/git/sage/src/bin:/home/king/Sage/git/sage/local/bin:/home/king/bin:/home/king/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
> $ echo $PATH
> /home/king/bin:/home/king/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
>
> If I understand correctly, the sdh_* thingies aren't executables (but I
> don't know what they are instead -- macros for the shell language?).
> I guess that's why the path is not enough.
>
> 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/qhq85b%2474l4%241%40blaine.gmane.org.

[sage-devel] Re: How to use spkg-install in a travis-ci script?

[Simon King]

Hi Dima,

On 2019-07-30, Dima Pasechnik  wrote:
> just fix the PATH, no?
>
> It should include SAGE_ROOT/src/bin, SAGE_ROOT/build/bin, etc

Apparently sage -sh is fixing the path:

$ ~/Sage/git/sage/sage -sh -c 'echo $PATH'
/home/king/Sage/git/sage/local/libexec/ccache:/home/king/Sage/git/sage/build/bin:/home/king/Sage/git/sage/src/bin:/home/king/Sage/git/sage/local/bin:/home/king/bin:/home/king/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
$ echo $PATH
/home/king/bin:/home/king/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

If I understand correctly, the sdh_* thingies aren't executables (but I
don't know what they are instead -- macros for the shell language?).
I guess that's why the path is not enough.

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/qhq7pp%245ut4%241%40blaine.gmane.org.

[sage-devel] How to use spkg-install in a travis-ci script?

[Simon King]

Hi!

I learned at Sage Days 100 how to post the code for my cohomology spkg
on github, and learned basics about travis-ci.

Meanwhile I found out how to start a docker container and install the
prerequisites of my spkg.

Current problem: How to launch the package's spkg-install?

Of course(?) the spkg-install script is run in a sage shell, but
apparently this is not enough, as
  sage -sh "/full/path/to/spkg-install"
fails because it cannot find sdh_make, sdh_die etc.

So, what can I do to make the Sage distribution helpers (is that the
meaning of "sdh"?) available to spkg-install?

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/qhq2jm%242pk6%241%40blaine.gmane.org.

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

[Simon King]

Hi!

If we say that Sage Integers and Rationals should comply with Python's
requirements, then for consistency, the same should hold for elements of
integral domains respectively of their fraction fields.

In particular, the required element methods of QuotientFields() should
be removed and instead one should require numerator and denominator
element proporties (if that's possible) for IntegralDomains().

Inside the Sage library, either solution is doable with a different
amount of effort. The questions are:
 - To what extent each solution breaks external code?
 - Are these backwards incompatibilities acceptable?

Currently a modification of Mark's suggestion 3. (perhaps including 2.)
makes most sense to me:
 - Change numerator and denominator of *all* integral domain elements
   (not just integers and rationals) into properties, also taking into
   account the stuff required by categories.
 - Make integers and rationals callable, returning themselves and
   raising a deprecation warning.
 - (Perhaps) add numer and denom methods.

Rationale: In external code, I guess the most common use case of
numerator and denominator methods is for rationals. Hence, the damage to
external code would be minimised by preserving backwards compatibility
for Rationals. And after some deprecation period we would achieve a
consistent behaviour for all kindes of fraction field elements compliant
with python numbers.

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/qhmv26%247qm2%241%40blaine.gmane.org.

[sage-devel] Re: signature missing in introspection some of the time

[Simon King]

On 2019-07-21, Travis Scrimshaw  wrote:
> Maybe a difference between Python and Cython classes?

If I recall correctly, Cython can be made to embed information
into the docstring, because otherwise that information wouldn't be
accessible. And with Python classes that information is directly
available from the class, no need to embed the information.

The stuff in sage.misc.sageinspect relies on it (and strips the
embedded information, if I recall correctly, when doing "stuff?").

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/qh18nd%243bl6%241%40blaine.gmane.org.

[sage-devel] Re: Matrix Inverse for Arbitrary Rings

[Simon King]

Hi Michael,

On 2019-07-13, Michael Jung  wrote:
> You could try something like
> try:
> is_field = R.is_field()
> except TypeError:
> is_field = (R in Rings())
> as a compromise? Would that make the code faster?

I think today the preferred way to test if something is a ring or
integral domain or field is via categories ("R in Fields()").

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qgcifp%24vmg%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: No access to trac via git-trac ?

[Simon King]

Hi Dima,

On 2019-07-10, Dima Pasechnik  wrote:
> IMHO "git trac" can create trac tickets for you, but if one created a
> ticket  by hand then, unless there is a branch already, "git trac checkout"
> may get confused...

Normally, I create the ticket manually and then do "git trac checkout",
and it works.

Cheers,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qg5rau%248mc%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: How do you close a trac ticket?

[Simon King]

Hi Isuru,

On 2019-07-09, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> The usual procedure is to set the milestone to "won't fix/duplicate" and
> then "needs review".

To elaborate a bit more (because in the past at some point I had the
same problem):

A ticket can only be *closed* by someone with particular privileges on
trac, such as the release manager. Other users can only *suggest* a
particular resolution of a ticket.

Therefore the milestone should be set as Vincent said. But in addition
to that, the ticket shouldn't just be set to "needs review", but someone
(perhaps you) should indicate in a comment why this ticket is a
duplicate ("This is a duplicate of #1."), should insert his/her name
into the "Reviewer" field, and change the ticket to "positive review".

If I understand correctly, the release manager will look at the tickets
with positive review and take action on them (either merging them or
closing them or pointing out problems that the reviewer didn't notice,
etc.)

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qg2qu0%249mj%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Issue with Sage's Hilbert polynomial algorithm

[Simon King]

Hi Grayson,

On 2019-07-03, Grayson Jorgenson  wrote:
> Check that :trac:`27483` is fixed::
>
> sage: P. = PolynomialRing(QQ)
> sage: I = Ideal([x^3, x*y^2, y^4, x^2*y*z, y^3*z, x^2*z^2, x*y*z^2, 
> x*z^3])
> sage: I.hilbert_polynomial(algorithm='singular')
> 3
>
> Was this meant to be a test of Sage's algorithm instead?

Yes.

But to make this clear: The problem we are having here has not been
introduced by 27483. As Volker has mentioned on the new ticket, it seems
to be a problem with normalisation of a rational function (whether its
numerator is made monic or not).

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qfkg51%244a70%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Issue with Sage's Hilbert polynomial algorithm

[Simon King]

Hi Grayson,

On 2019-07-03, Grayson Jorgenson  wrote:
> I found ticket 27483 which seems to be dealing with a similar bug, but I'm 
> using Sage 8.9 beta1 and their changes seem to be present in my version so 
> it seems the fixes there do not address this issue (I think this ticket was 
> merged in 8.8). Additionally the example cited in that ticket 
>
> P. = PolynomialRing(QQ)
> I = Ideal([x^3, x*y^2, y^4, x^2*y*z, y^3*z, x^2*z^2, x*y*z^2, x*z^3])
> I.hilbert_polynomial()
>
> dies for me in the same manner but works using singular's algorithm. The 
> test that was added by 27483 into the hilbert_polynomial function to cover 
> this example actually uses singular's algorithm

Does it? OK, that was not intended, because the fix in #27483 has (if I
recall correctly) nothing to do with Singular.

> (i.e. there's no test that 
> the default Sage algorithm is actually working).

That's not true. There are various tests (introduced together with the
default algorithm in #26243 and #20145), including some tests in which
Singular fails (which is tested as well).

> Is this a current bug in Sage, or am I just missing some changes in my Sage 
> version which would fix this?

It seems to be a new bug. I have created #28110 for it.

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qfj280%24epr%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: A question on pickling cached methods

[Simon King]

Hi!

Is it a Python object?

A cached method (if that hasn't changed since I last looked at the code)
stores the cached values in some dict stored as an attribute, and when
you pickle the object (at least when no __reduce__ method interferes),
it should automatically store that attribute.

But you say that the method is called "genus". So, probably it has not
function arguments, right? It could be that the cache is stored
differently in that case.

I think if pickling doesn't preserve the content of the cached method
then it is a bug.

Best regards,
Simon

On 2019-06-27, Kwankyu Lee  wrote:
>
>
> On Thursday, June 27, 2019 at 4:41:30 PM UTC+9, John Cremona wrote:
>>
>> I think this is one disadvantage of using the cached_method decorator, 
>> instead of the clumsier way of actually storing the result in the object, 
>> eg. by setting X._genus.  In your example I cannot think of a reason why we 
>> would not want to store the genus as an attribute after computing it.
>>
>
> I thought the same. I expected the cached_method decorator could make a 
> (pseudo) attribute attached to the object magically somehow if I cast the 
> right spell...
>

-- 
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/qf2dpe%247rp9%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: regression between 8.7 and 8.8.rc1 with operations on polygons with vertices in a quadratic field

[Simon King]

Hi Dima,

On 2019-06-21, Dima Pasechnik  wrote:
> Basically, this is a great illustration that pexpect interface (what's
> topcom using)
> is slow...

Question: Is that slowness OS dependent? I recall that when I was using
openSuse on my laptop, a couple of years ago, I needed to patch the OS
because otherwise the pexpect interface became extremely slow.

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qeijjh%247fpq%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: issues (memory leak + slowness) with multivariate polynomials

[Simon King]

Hi!

On 2019-06-16, Dima Pasechnik  wrote:
> libsingular interface is a mess, cf e.g.
> https://trac.sagemath.org/ticket/27508

Singular uses a peculiar memory manager that is optimized for Gröbner
basis computations. If that memory manager is replaced by ordinary
malloc (which makes sense for debugging) then everything becomes a lot
slower. Does libsingular use the same memory manager than Singular?

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qe7hcm%24mvj%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: testing for equality in new ring

[Simon King]

Hi Daniel,

I'd be interested in that topic as well. I do not try to answer your
question myself, because I remember (hopefully correctly) that the
recommended way to do equality testing has changed because of the
switch to Python3.

So, hopefully someone else can chime in...

Best regards,
Simon

On 2019-06-03, Daniel Krenn  wrote:
> I have implemented a new ring (parent/element structure) and now want to
> do equality testing. I use the code below, which seems to me somehow
> canonical for rings and equality testing (using coercions properly).
> For short, the difference between self and other is built and then
> compared for zero.
> Note that there is no meaningful _lt_ etc. in this ring, so I am not
> sure if richcmp is to be used here (but I just might be too unskilled
> with richcmp).
>
> What is the "best way" to do so? Are there any Sage-built-in shortcuts?
>
> ad shortcuts: for richcmp there is
> sage.structure.richcmp.richcmp_by_eq_and_lt.
>
> Best,
>
> Daniel
>
> Here the relevant code of the element:
>
> def __bool__(self):
> return bool(self.polynomial) or bool(self.rhs)
>
> __nonzero__ = __bool__
>
> def __eq__(self, other):
> if other is None:
> return False
> try:
> return not bool(self - other)
> except (TypeError, ValueError):
> return False
>
> def __ne__(self, other):
> return not self == other
>

-- 
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/qd7ufk%245dbi%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: direct sums, products and other categorical constructions

[Simon King]

Hi Simon,

On 2019-05-27, Simon Brandhorst  wrote:
> I would agree that I want unique representation with simple "ambient" 
> objects (usually constructed from an integer and maybe a ring). Then with 
> complicated objects I am not so sure anymore. Say subgroups of a group and 
> submodules of a module. There it might cause more trouble than benefit. 
> Plus it is quite common to create 
> (hundred) thousands of subgroups/submodules during a computation.

If you do not keep a reference chain to said hundred thousands of
different subgroups, then they would be automatically removed from the
"UniqueRepresentation" cache. If not, it's a bug (admittedly we had
instances of that bug quite often).

So, at least at first, one could think that equipping the result of a
universal construction with (co)projections wouldn't interfere with
UniqueRepresentation's weak cache. That's where my original suggestion
came from.

However, each map such as a projection or coprojection does involve 
references to domain or codomain. One of them can be weak (that's what we
do for coercion maps), but nonetheless adding the projections as attribute
to the constructed object X increases the likelyhood that X cannot be
garbage collected.

>From that point of view, keeping the (co)projections or deleting them
should be in the decision of the user, they shouldn't be automatically
stored as attribute of the object X.

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qcm06h%24hr6%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: direct sums, products and other categorical constructions

[Simon King]

Hi Simon,

On 2019-05-23, Simon Brandhorst  wrote:
> I can live with (V, projections, coprojections) 
> but I dislike hiding everything in lists (or lists of lists, or lists of 
> lists of lists..).
> Being able to type VW.projections(1) would just be so much nicer.

+1.

But how? I think we do want unique parents. How do we want to
distinguish between "the same" object that was constructed in two different
universal ways?

There would be one possibility that would work without creating a
wrapper: An object X that was constructed by some construction functor F
applied to some more basic objects B1,...,Bn should be able to tell its
construction (there is X.construction()). So, if we want to distinguish,
say, $Q^4$ from $Q^3\oplus Q$, then we could simply use the pair
  (CoproductFunctor, (Q^3,Q))
as key in the UniqueRepresentation cache.

Best regards,
Simon

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qc8n62%24q04%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: direct sums, products and other categorical constructions

[Simon King]

Hi Vincent,

On 2019-05-22, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> I am not a big fan of bundling everything into a single
> bigger object. What about returning a triple
> (V, projections, coprojections)?

I tend to argue that in the first place, SageMath is a maths software.
And mathematically, universal constructions do come "with batteries"
included. Hence, the projections and coprojections are part of the
construction and it makes sense to let them be part of the constructed
objects.

Here is a similar situation: When applying a construction functor, then
often a natural homomorphism is involved that is turned into a coercion
map and is thus part of the constructed object (a polynomial ring knows
the coercion map from its base ring).

I could imagine the following model:
- We do want unique parents. I.e., QQ^4 is unique.
- We want that the direct sum of QQ and QQ^3 yields different
  coprojections than the direct sum of QQ^2 and QQ^2, even though the
  constructed vector space is in both cases the same object, namely
  QQ^4.
- Hence, a universal construction should be a wrapper. QQ^2+QQ^2 and
  QQ+QQ^3 would be two different wrappers of the same object, each
  providing different coprojections.

Perhaps the "Facade" framework can be used to implement it?

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qc3m49%247ams%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: show() method for all sage objects

[Simon King]

Hi Eric,

On 2019-05-22, Eric Gourgoulhon  wrote:
> According to 
> https://ipython.readthedocs.io/en/stable/config/integrating.html
> if _repr_latex_() returns None then it falls back to repr(). So a strategy 
> could be to implement _repr_latex_ in SageObject (I guess all Cython 
> objects are inhereting from it) as follows:
>
> def _repr_latex_(self):
> from sage.misc.latex import latex
> if not hasattr(self, '_latex_'):
> return None
> return '$' + str(latex(self)) + '$'

That sounds reasonable to me, and is basically what we do with Python's
magical (double underscore) methods (namely: provide a reasonable
default that shouldn't be overridden).

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qc3lan%244di2%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: show() method for all sage objects

[Simon King]

Hi Eric,

On 2019-05-21, Eric Gourgoulhon  wrote:
> Le lundi 20 mai 2019 07:55:30 UTC+2, Kwankyu Lee a écrit :
>>
>> . Moreover many sage objects currently are displayed broken if typeset. 
>>
>
> In that case, a solution could be to introduce a new class, 
> TypesetSageObject, say, to implement _repr_latex_() in it and to make Sage 
> objects that can be correctly typeset inheritate from it.
> For instance, this could be done for all manifold objects and for symbolic 
> expressions (class Expression). 

A lot of Sage objects are written in Cython. So, a potential problem of
that approach would be multiple inheritance.

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qc2stk%244l8r%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Report on global function fields in Sage

[Simon King]

Hi Kwankyu,

On 2019-05-10, Kwankyu Lee  wrote:
> There is no ticket. It seems bad to create a ticket before you have a 
> specific goal and a means to achieve it. 

Why? You have specific examples. That should be enough for a ticket,
IMHO. If while working on the ticket it turns out that the slowness has
several distinct reasons, one can make it a meta-ticket and create
several smaller tickets, each addressing one issue.

>
> I suspect that the overall poor performance is mainly due to slow linear 
> algebra over polynomial rings (over finite fields). For example, I observed 
> determinant computation is generally slow and for some cases terribly slow.

That's something one could start with...

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qb3gvr%2433fe%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Report on global function fields in Sage

[Simon King]

Dear Kwankyu,

thank you for your contribution and your report!

On 2019-05-10, Kwankyu Lee  wrote:
> 1. It is very, but not terribly, slow compared with Magma. One may want to 
> improve the speed.

Is there a ticket for it, which also points out what examples are slow and
how it compares with Magma? I cannot give a promise at this point, but
generally I like to try and tweak code.

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/qb37p5%2450i8%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Adding doctest

[Simon King]

Hi Bea,

On 2019-04-23, Bea Galiana  wrote:
> I've been reading the general conventions about writing tests but I'm not
> really sure about where should I add it. I did take a look at others
> scripts where doctests have been added before and it seems I should I write
> it as a comment, so I thought I would just write it as a comment starting
> with something like this

To avoid a potential confusion: The tests should NOT be in a comment in
the Python or Cython code, (which would be a line starting with the
letter "#"). It should be in the docstring of a function/method/class/module.

But I guess that's what you mean anyway.

Best regards,
Simon

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

[sage-devel] Re: Adding Turing Machines

[Simon King]

PS:

On 2019-04-01, Simon King  wrote:
> I suppose that (coming from school) your implementation is not "for
> speed", but for education.
>
> There are a couple of implementations in Sage that have educational
> purpose (e.g., toy implementations of Buchberger's algorithm for the
> computation of Gröbner bases). So, I expected there would be a folder
> $SAGE_ROOT/src/sage/education. But there is no such folder yet.

Alternatively, it would make sense to put it into src/sage/combinat.
After all, we already have sage.combinat.finite_state_machine, and thus
you could create src/sage/combinat/turing.py, perhaps even re-use parts
of finite_state_machine.

Best regards,
Simon

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

[sage-devel] Re: Adding Turing Machines

[Simon King]

Hi Quentin, hi all,

On 2019-04-01, Quentin Hillebrand  wrote:
> Hello,
>
> For a school project, me and some classmates have implemented in Sage 
> functions for the printing of Turing Machines along with the execution.
> We were wondering in what way those could be incorporated to Sage and if 
> anyone has any suggestion on the requiered functions for a submission to 
> Sage.

I suppose that (coming from school) your implementation is not "for
speed", but for education.

There are a couple of implementations in Sage that have educational
purpose (e.g., toy implementations of Buchberger's algorithm for the
computation of Gröbner bases). So, I expected there would be a folder
$SAGE_ROOT/src/sage/education. But there is no such folder yet.

Question to all: Do you agree with me that such folder should be
created, so that Quentin's contribution as well as both existing
and future "educational" implementations can be put there?

Quentin, for the required form of a submission, you may find the
developer guide http://doc.sagemath.org/html/en/developer/index.html
useful.

Best regards,
Simon

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

[sage-devel] Re: Suggestion to speed up nauty_geng()?

[Simon King]

Hi David,

On 2019-03-22, David Coudert  wrote:
> Our interface to nauty geng is in Python, but the difficulty is not here.
>
>- It takes time to build graphs from graph6 strings, and also to build 
>Sandpiles (12 for each graph)
>- The number of biconnected graphs with 12 nodes is huge:  153.620.333.545 
>  
>See https://oeis.org/A002218
>
> Some parallelism could certainly help here, but there will be no miracle.

If I understand correctly, this thread is about how to create an
iterator for these graphs that does not try to generate all of them
at once (and if I understand correctly, nauty/geng provides such
iterator, it just isn't wrapped, but could easily be, since the output
of geng, which is a stand-alone executable, can be read as a string [by
a wrapper in Sage] and then translated into a graph).

The miracle would be that in a doc test you could probably iterate over
the first 10 graphs, demonstrating that you do not need to create the
remaining 153,620,333,535.

Best regards,
Simon

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

[sage-devel] Re: Suggestion to speed up nauty_geng()?

[Simon King]

Hi!

Does either of you plan to open a ticket and make the functionality
available, that according to Jori is present in nauty but according
to Ai isn't wrapped in Sage?

Best regards,
Simon

On 2019-03-21, Jori Mäntysalo  wrote:
> On Thu, 21 Mar 2019, Ai Bo wrote:
>
>> Is there a way to "random access"? For example, access the nth element 
>> in the "generator", instead of one by one?
>
> Kind of. As a most time is propably spent by creating Python data 
> structures for SageMath, you can use nautygen directly to generate huge 
> number of graphs.
>
> As an example, it takes below 5 seconds to generate all biconnected graphs 
> on 10 vertices, and I took third last one:
>
> $ nauty26r7/geng 10 -C | tail -3 | head -1
>>A /home/jm58660/lat-koe/nauty26r7/geng -Cd2D9 n=10 e=10-45
>>Z 9743542 graphs generated in 4.59 sec
> I]~~w
>
> and now
>
> sage: g = Graph('I]~~w', format='graph6')
> sage: g.is_biconnected()
> True
>
>
> -- 
> Jori Mäntysalo
>
> Tampereen yliopisto - Ihminen ratkaisee
>

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