Mon 2017-09-11 16:59:48 UTC, Maarten Derickx:
> p.s. Tips on how to search for tickets on trac are welcome!
Trac has both a search feature and a (much more powerful) query feature:
- https://trac.sagemath.org/search
- https://trac.sagemath.org/query
See some examples of using the query feature
On Mon, Sep 11, 2017 at 12:59 PM, Maarten Derickx <
m.derickx.stud...@gmail.com> wrote:
> Hi all,
>
> During the recent writing of new code and reviewing I got annoyed that it
> costs really a lot of effort for me to see if there was already a ticket
> for a certain patchbot failure. I therefore d
What are the places GC is used in Sage, apart from ECL and (optional)
libhomfly?
On #22679 I have a bug ECL people attribute to a second GC instance kicking
in and causing ECL's death...
Thanks
Dima
--
You received this message because you are subscribed to the Google Groups
"sage-devel" grou
Hi all,
During the recent writing of new code and reviewing I got annoyed that it
costs really a lot of effort for me to see if there was already a ticket
for a certain patchbot failure. I therefore decided to create a metaticket
that should serve as an overview of all currently known patchbot
Mon 2017-09-11 10:07:01 UTC-5, Martin R:
> Is there a recommended (fast) way to turn input
> into a (square) matrix (with entries in ZZ)?
> Currently I do "corner = matrix(corner)"
Suppose you defined
m_list = [[0, 1, 2], [3, 4, 5], [6, 7, 8]]
and you want to turn m_list into a 3 by 3 matri
Thank you! Is there a recommended (fast) way to turn input into a (square)
matrix (with entries in ZZ)?
currently I do "corner = matrix(corner)"
Thanks again,
Martin
Am Montag, 11. September 2017 17:00:20 UTC+2 schrieb Samuel Lelievre:
>
> Mon 2017-09-11, 9:38:45 (UTC-5), Martin R:
> > Appa
Mon 2017-09-11, 9:38:45 (UTC-5), Martin R:
> Apparently, corner[i,j] is a lot faster than corner[i][j].
Yes: if m is a matrix, m[i, j] accesses the element (i, j) of m, while
m[i][j] first extracts line i of m, stores it as a vector, then extracts
element j of that vector. This explains the speed
On Saturday, September 9, 2017 at 6:54:38 PM UTC-4, Enrique Artal wrote:
>
> It is a server with 8 cores and 32GB of RAM, but with several other sagenb
> processes and twenty users on jupyterhub plus 60 on the sagenb instances
> cause no performance issue (usually)
>
Oh yeah, 32 GB would be pl
Well done!
--
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.co
Apparently, corner[i,j] is a lot faster than corner[i][j]. With this
modification, the two versions are roughly equally fast. I don't get it,
though, because the second version should be doing a lot more work.
Martin
Am Montag, 11. September 2017 16:23:07 UTC+2 schrieb Martin R:
>
> I don't u
I don't understand the following timings:
sage: A = AlternatingSignMatrices(6)
sage: lC = [a.corner_sum_matrix() for a in A]
sage: timeit("[from_corner_sum_1(corner) for corner in lC]", number=1,
repeat=1)
1 loops, best of 1: 63 s per loop
sage: timeit("[from_corner_sum_2(corner) for corner in lC
On Monday, September 11, 2017 at 3:40:41 PM UTC+2, Maarten Derickx wrote:
>
> On Mon, 11 Sep 2017 at 10:30 Jean-Pierre Flori > wrote:
>
>>
>> I've made a pull request at
>> https://github.com/mmasdeu/sage_package_template/pull/3 with some
>> changes and info to skip some of the requirements wh
Hey Martin,
Jori would probably want this to be improved too. Basically, it is at a
(local?) minimum and the issue is defining the UniqueRepresentation (as a
way to preserve the memory footprint). Now it would be great if we could
remove at least one of those digraph constructions, but IIRC,
On Mon, 11 Sep 2017 at 10:30 Jean-Pierre Flori wrote:
>
> I've made a pull request at
> https://github.com/mmasdeu/sage_package_template/pull/3 with some changes
> and info to skip some of the requirements when using it.
>
I don't have write acces to that repository so I can't accept your pull
r
On Mon, 11 Sep 2017 at 10:30 Jean-Pierre Flori wrote:
>
> I've made a pull request at
> https://github.com/mmasdeu/sage_package_template/pull/3 with some changes
> and info to skip some of the requirements when using it.
>
I don't have write acces to that repository so I can't accept your pull
r
On Monday, September 11, 2017 at 12:00:15 PM UTC+2, Marc Mezzarobba wrote:
>
> IMO, fix embedded number fields so that they coerce into QQbar.
Great, thanks. So it's an algebra bug after all, and I can now mark the
fails as "known bug" instead of trying to find a feeble workaround.
--
You rec
Ralf Stephan wrote:
> Now, in an existing doctest `sin(QQbar(I))` gives an error
> because number field I and QQbar I are in the same arithmetic
> operation. If one expects something non-crashing resulting from
> `sin(QQbar(I))`, what should we do?
IMO, fix embedded number fields so that they coer
Hello,
The unresolved issue of different types of "complex I" continues to make
things difficult.
For example with pynac-0.7.11 `sin(I)` simplifies to `I*sinh(1)` because
Pynac recognizes a multiple of (number field) `I` as argument to `sin` and
divides by number field `I` to get the argument o
On Sunday, September 10, 2017 at 1:54:44 PM UTC+2, Maarten Derickx wrote:
>
> Changed the subject to not clutter Davids thread.
>
>
>
> On Sunday, 10 September 2017 12:01:51 UTC+2, Jeroen Demeyer wrote:
>>
>> On 2017-09-10 06:09, Maarten Derickx wrote:
>> > I plan to work on https://github.com/s
19 matches
Mail list logo
