Re: [sage-devel] random_element and randtest_element

[Travis Scrimshaw]

I agree with Thierry and also Jeroen: If there are corner cases, you should 
just test them all outright in a TESTS section and/or via some_elements() 
and/or passing them explicitly as TestSuite(foo).run(elements=bar).

Heisenfailures are very difficult to debug: One run, doctests fail. You 
make a small tweak (one that changes the random seed), which you think 
fixes the issue, and then tests pass. However, if it is a random test, then 
you have no idea if you have fixed the problem or not.

Best,
Travis


On Wednesday, June 6, 2018 at 4:14:51 AM UTC+10, Thierry 
(sage-googlesucks@xxx) wrote:
>
> Hi, 
>
> On Tue, Jun 05, 2018 at 10:31:38AM -0700, Samuel Lelievre wrote: 
> > How about adding an optional argument "distribution" 
> > defaulting to None, and for polynomials having say, 
> > if distribution == 'for_testing', then, 
> > 
> > - with probability 1/4, 
> >   select at random among R.some_elements() 
> > - with probability 1/4, 
> >   return random polynomial of density 1 
> > - with probability 1/4, 
> >   return random polynomial of density 1/2 
> > - with probability 1/4, 
> >   return random polynomial of <= 3 monomials 
>
> This will make the code of random_element overloaded hence less readable. 
> If those four tests are interesting, we should just add them to the TEST 
> section. 
>
> Ciao, 
> Thierry 
>
>
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-devel+...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
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 for the SageMath website

['Bill Hart' via sage-devel]

I just mean so it appears below the part visible in standard desktop 
browsers, i.e. so it is not the first thing you see when you load the page. 
"Below the fold" is my terminology for something that requires an action to 
read it, such as was required on this ancient IBM ThinkPad:

http://www.acontinuouslean.com/2009/10/01/the-original-ibm-thinkpad/

On side note: Is there any problem with alphabetical order if the whole 
list is there?

On Wednesday, 6 June 2018 17:31:32 UTC+2, Vincent Klein wrote:
>
> Le mercredi 6 juin 2018 17:06:45 UTC+2, Bill Hart a écrit :
>>
>> I would personally put it on the lower part of the page, so that it is 
>> "below the fold" on most browsers (due to its scrolly nature). But maybe 
>> others prefer it higher up. 
>>
> "below the fold", you mean under library and search button ? 
>
> Side Note : The package list in the prototype is in alphabetical order, i 
> keep in mind to randomize the list if we keep this solution.
>

-- 
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] Patching policy

[Timo Kaufmann]

I have recently re-written the nixpkgs sage package to use system 
packages[1]
(not merged yet). While doing that I noticed that while sage patches a lot 
of
its dependencies (81 out of 276 packages have a `patches` folder).

There are more or less 3 categories of patches:

1. sage-the-distribution specific patches

  These patch paths, makefiles, wrappers etc. to make packages work with 
other
  spkgs. Thats pretty much what every distro does, too.

2. essential patches

  Patches that are absolutely needed for sage to work. I consider the 
python2
  `re_match_index-issue_27177.patch` an example of this category, because
  
  - it is needed for a basic sage function (regex matching)
  
  - there is no reasonable way to work around it (`re` cannot be monkey 
patched).
I'm not entirely sure why sage needs to overwrite the python integer, 
but
I'm sure there is a good reason for it.

3. small fixes / opinionated patches / issues that could be worked around 
within
   sage

  Examples for this:

  - fixing a formatting failure in `backports.shutil_get_terminal_size` by
patching the spkg. That could instead be fixed by patching the sage 
tests
(#25354).

  - patch python to fix python bug 5755 instead of either adjusting the 
doctests
or monkey-patching instead (#25316).

  - patch pari to remove a warning instead of dismissing that warning within
sage or adapting the doctests (#25312)

  - patch python to add path security checks (#25358)

There is no way around (1) and those patches don't really hurt anything 
(except
it might be nice to clearly mark them as sage-the-distribution specific
patches). There is no way around the (2) patches and including applying 
them is
usually a good idea, independent of sage.

(3) is the issue. Those patches are usually included because they fix the
problem in an easier or cleaner way than working around it within sage, 
which is
reasonable. Those patches make packaging sage very hard though. 
Distributions
have to either include these patches (there are good reasons to be reluctant
against new patches and you'll usually have to convince a maintainer of 
their
value) or add patches to sage to work around the issue.

I would propose to make it a policy to only include sage patches when
*absolutely necessary*. If ugly workarounds or even monkey-patching is 
necessary
for that, that sucks. But distributions will usually come up with even 
uglier
workarounds (since they don't know the code) anyways, just resulting in
duplication of effort.

Of course I don't mean to accuse anybody that added those examples in the 
past.
I understand the reasoning behind it ("cleaner" solutions). I just want to 
raise
awareness about the problems this causes downstream, especially for new sage
packages (most of those issues can be forgotten once they're "solved" for 
your
distribution, but the next distribution will have to solve them all over 
again).

[1] https://github.com/NixOS/nixpkgs/pull/39981

-- 
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 for the SageMath website

[Vincent Klein]

Le mercredi 6 juin 2018 17:06:45 UTC+2, Bill Hart a écrit :
>
> I would personally put it on the lower part of the page, so that it is 
> "below the fold" on most browsers (due to its scrolly nature). But maybe 
> others prefer it higher up. 
>
"below the fold", you mean under library and search button ? 

Side Note : The package list in the prototype is in alphabetical order, i 
keep in mind to randomize the list if we keep this solution.

-- 
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 for the SageMath website

[Vincent Klein]

Le mercredi 6 juin 2018 17:06:45 UTC+2, Bill Hart a écrit :
>
> I would personally put it on the lower part of the page, so that it is 
> "below the fold" on most browsers (due to its scrolly nature). But maybe 
> others prefer it higher up. 
>
"below the fold", you man under library and search button ? 

Side Note : The package list in the prototype is in alphabetical order, i 
keep in mind to randomize the list if we keep this solution.

-- 
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 for the SageMath website

['Bill Hart' via sage-devel]

On Wednesday, 6 June 2018 16:36:44 UTC+2, Vincent Klein wrote:
>
> Another alternative is to display all the packages in a slow scrolling 
> horizontal list ScrollingPackagePrototype.html 
> 
> . 
> Im not sure if the move is too disturbing for the reader or not. 
>

That's actually exactly what I had in mind when I made my suggestion. I 
would personally put it on the lower part of the page, so that it is "below 
the fold" on most browsers (due to its scrolly nature). But maybe others 
prefer it higher up. 

-- 
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 for the SageMath website

[Vincent Klein]

Another alternative is to display all the packages in a slow scrolling 
horizontal list ScrollingPackagePrototype.html 

. 
Im not sure if the move is too disturbing for the reader or not. 

Le vendredi 1 juin 2018 14:46:52 UTC+2, Bill Hart a écrit :
>
> Hi all,
>
> I've been aware for a while that some libraries are not happy that their 
> package is not explicitly mentioned by name on the sagemath.org home page 
> and that you have to click through to the "and many more" to see their 
> package credited.
>
> I have a suggestion how this could be made more equitable for the many 
> dependencies of Sage. The home page could randomly rotate the names of 
> external dependencies that are listed on the main page so they all get 
> equal exposure. It could even say, "Here is a selection updated randomly: 
> ... but there are many _more_". (My apologies if this is already the 
> case, but after a number of refreshes, the list doesn't appear to change, 
> presently.)
>
> Obviously, the intention of this suggestion is to bring more prominent 
> credit to authors of those other packages, which they deserve. As such, I'd 
> prefer if we could avoid discussions to justify listing only certain 
> packages on the main page (other than technical considerations, such as 
> limited space on the main page), as this would have the opposite of the 
> intended effect, which is to prominently recognize their work, which is 
> well-deserved. 
>
> I'm aware there may be other technical considerations, such as static vs 
> dynamic nature of the html, SEO optimisation considerations related to 
> regular changes to the page, etc. I guess those need to be considered. But 
> I also believe this is a very important social issue, or I wouldn't raise 
> it.
>
> (The alternative, of course, would be to remove the short list on the main 
> page and only have the very long list on the "and many more" page.)
>
> Sorry it's taken me so long to get around to mentioning this, after it had 
> been repeatedly brought to my attention by various people over the years.
>
> Bill.
>
>

-- 
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: random_element and randtest_element

[Samuel Lelievre]

Wed 2018-06-06 01:09:27 UTC, Kwankyu Lee:
>
> Vincent Delecroix:
>>
>> What do you think? Does the name randtest_element look ok? 
>
> How about "_random_test_element", as this method needs
> not to be revealed to users, unlike "random_element" and
> "some_elements".

This is better than what I suggested.

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

Re: [sage-devel] Re: Severe regression in construction of matrices

[Jeroen Demeyer]

On 2018-06-06 00:39, Nils Bruin wrote:

Would it be a problem to splice in a cdef class somewhere that provides
cdef attributes for _nrows and _ncols and then provides python-level
methods to access these values from python?


One thing which could work is to create an abstract base class for 
MatrixSpace providing that.


Then the inheritance structure would be like

cdef class MatrixSpace_base(Parent)

cdef class MatrixSpace(UniqueRepresentation, MatrixSpace_base)

This shouldn't be too hard, but I'd like to finish some other 
matrix-related tickets first.


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

Re: [sage-devel] Re: Severe regression in construction of matrices

[Jeroen Demeyer]

On 2018-06-06 02:51, Travis Scrimshaw wrote:

Multiple inheritance


Cython allows multiple inheritance (in limited ways), so that's not the 
issue.



UniqueRepresentation


This is the *real* issue. As far as I know, this doesn't work for Cython 
classes.


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