I think the List vs Iterables item is totally doable on time. The rest
is maybe more complicated, but even if it's only 50% done it's ok.
Luca
On Sun, Sep 1, 2019 at 11:50 PM Nils Bruin wrote:
>
> On Sunday, September 1, 2019 at 12:14:51 PM UTC-7, Thierry
> (sage-googlesucks@xxx) wrote:
>>
>>
+1 to this!
On Sun, Sep 1, 2019 at 9:14 PM Thierry wrote:
>
> Hi,
>
> it seems to me that Python 3 migration should not only be a syntax
> adaptation (like print('blah')), unicode, or the mitigation of issues
> related to the fact that different objects are not always comparable.
>
> It should
Impact on privacy can be minimized with the attributes
See : https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script
Security could be improved with subresource integry. See
> I guess that 50 simultaneous connection will be the maximum. The use might
> be, for example, a course on graph theory having mandatory but trivial
> exercise about SageMath graph functions.
That's a reasonable load.
--
You received this message because you are subscribed to the Google Groups
> How fast will new SageMath versions be packaged? I suppose that fast
> enought, and those needing the bleeding edge version can compile it
> themself.
I agree. Ubuntu bionic has 8.1, cosmic has 8.3.
Unless we screw up and make Sage impossible to package (see mail by
Samuel on Debian freeze),
> I am trying to marry SageMath and Jupyterhub. I think I got them engaged,
> but the wedding night has a problem:
This is not a Sage + JupyterHub problem as much as a Sage + system Jupyter one.
Packagers have already solved it for various distributions, so, if you
don't need a Sage version
> No problem. And this was a mistake *I* made. This is a side-effect I
> did not consider and might want to think more about how to prevent...
GitHub forbids using an ssh key twice. It seems the only reasonable thing to do.
--
You received this message because you are subscribed to the Google
> We have already seen that before, in the last month I think. Your version
> of make is compiled with guile support.
> The compilation breaks because “make" itself breaks. flint and R use
> LD_LIBRARY_PATH in their build system and make loses touch with some
> of the libraries it has been
Serving over https is very easy nowadays, thanks to letsencrypt.
Nonetheless, it may take some time for all mirrors to switch to it.
Switching to sha-256 hashes is a much more trivial change, which can
be rolled out almost overnight.
In the same vein, on the download page only md5 hashes are
> That is totally not what I said. We don't care about collision resistance,
> but we still need preimage resistance. That is still fine for SHA1 (even MD5
> as far as I know).
If that's your point, an attacker can produce two colliding packages:
a perfectly sound mathematical package and a
>> There you go for something crippled! https://shattered.io/
>
>
> I don't think that this is actually relevant. This attack would only work if
> an attacker is able to provide a specially manufactured source tarball and
> get it accepted by SageMath. At that point, the attacker could instead
Thanks everyone for the discussion.
I opened https://trac.sagemath.org/ticket/24071 to improve the
docstring of reduce().
It's ready for review, let's continue the discussion there.
> In Singular's implementation p' does not depend on the order of the
> polynomials in I because it starts with
|X| Yes, we should fully support OpenSSL now, and clarify the
licensing issue.
> the way our
> "package manager" works allows to install an optional package without
> having to rely on openssl (no https), we only rely on the computation of
> sha1
There you go for something crippled!
> I agree that Sage devs don't (need to) know what *exact* algorithm is
> used. But at least it is clear that the .reduce() method does polynomial
> reductions and continues till no further reduction is possible; all this
> for a fixed monomial ordering (determined by the polynomial ring), in
>
Hi Simon,
I hate to sound snarky, but...
> When reading `normal form` and `Groebner basis` in the same sentence,
> the meaning should be clear to anybody who took a course in commutative
> algebra. So, the question is: Whom should documentation be addressed to?
>
> I do *not* think that
> The algorithm in question is described in “Ideals, Varieties, and
> Algorithms” by David Cox, John Little and Donal O’Shea in Section "§3 A
> Division Algorithm in k[x_1 , … , x_n]".
It is not:
sage: A. = PolynomialRing(QQ, order="lex")
sage: (x*y^2 + 1).reduce([x*y + 1, y+1])
> +1 for doing something.
>
> What about the following fix: When the input is a list/tuple, we check
> if it is a Groebner basis or not. If it is, do the computation, if not,
> print a warning or raise an error.
Sounds reasonable.
Other options would be:
- Just refuse list input.
- Always
> It takes I as the generators of the ideal and uses that as the reduction
> set.
That's not a definition. I'm in front of a class asking what this
function does, and I'm unable to give a mathematical definition of
what Sage means by "reduction" modulo something that's not a Groebner
basis.
>
On Mon, Oct 16, 2017 at 7:35 PM, 'Martin R. Albrecht' via sage-devel
wrote:
> Hi there,
>
> this is already documented:
>
> “ Return the normal form of self w.r.t. "I", i.e. return the
> remainder of this polynomial with respect to the polynomials in
> "I". If the
Hi everyone,
Here's a Sage session:
sage: A. = QQ[]
sage: (x+y).reduce([(x-y), (x+y)])
0
sage: (x-y).reduce([(x-y), (x+y)])
-2*y
The docstring says reduce computes "the normal form of self w.r.t. I,
i.e. [...] the remainder of this polynomial with respect to the
> In summary, I'll withdraw my vote for (1).
Interesting and funny situation!
If there's no more opposition, I may give positive review to #22470
tomorrow, after all. If you're wondering, #22470 keeps support for
_pari_, but deprecates it in favour of __pari__.
Luca
--
You received this
Hello,
Discussion on this matter seems to have stalled, with no clear
consensus. There is an open ticket (#22470, only affecting _pari_)
that we would like to close by the end of SD85.
Let me summarize the discussion. From what I've read, the only two
options that seem to have gained some
The "activate" button DOES appear in local installations, if they are
served by the local HTTP server (through the jupyter notebook). Try
it, it's cool.
It does not appear if you browse the files through the file:/// scheme
in your browser. Because of this line:
> It is not a bug, but a by product of wanted (with documentation) of the
> UniqueRepresentation and the coercion system in Sage. More below.
This is a bug.
The fact that it is a consequence of wanted and documented behaviour
just shows that the wanted behaviour was badly designed (regardless of
<jori.mantys...@uta.fi> wrote:
> On Sun, 23 Oct 2016, Luca De Feo wrote:
>
>> When I want to share a notebook with the students, I share a static
>> .ipynb file via gist, and visualize it via nbviewer. e.g.:
>>
>> http://nbviewer.jupyter.org/gist/defeo/4adb727f7608df
> Some other things: Is it possible to run plain R (or GAP or...) from
> Jupyter? Can I change worksheet type, for example test what "10/4" will
> output as a plain Python2?
>
> Both are possible with SageNB.
You can change the kernel via the "Kernel" menu (there are kernels for
R, GAP, PARI/GP,
I have no experience with the LDAP authenticator. It is probably best
to ask your questions on :
https://groups.google.com/forum/#!forum/jupyter
Luca
On Wed, Oct 26, 2016 at 12:40 PM, Jori Mäntysalo wrote:
> More progress, but now I am stuck. Last time I ended on
>
>>
> Can you give me some kind of Hello world! -example of Jupyter? ./sage
> --notebook=jupyter will open a server to port --- how to change the
> port or, more general, is there some help file? First I would like to see a
> way to have two local user using Sage and not seeing each other files.
> As far as I know, Jupyter(hub) does not have such a feature since it
> completely relies on the OS for access checks.
That's not correct. JupyterHub supports arbitrary authenticators:
https://jupyterhub.readthedocs.io/en/latest/authenticators.html
In particular, there is an LDAP
> make -B makes all targets (including distclean etc)
> For even more fun, try "sudo rm -f /" next time ;-)
I don't think that's what was happening on my side. Here's what I
have, make repeatedly tries to build build/make/Makefile :
$ ./sage --version
SageMath version 7.4.beta5, Release Date:
I just tried `make -B` inside a source install. I recommend it :)
Luca
P.S.: Seriously, I am not a Makefile expert, I don't know what's
happening here, but infinite recursion feels bad.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
> Should we start a process of nominating/electing moderators?
Before that, we should decide what the process is. That's something
that might be complicated to do via email (remember what happened with
the code of conduct).
In my opinion, a Sage Days completely dedicated to this kind of issues
> I deleted it as flame bait. I'm sick of people using sage-devel as a
> forum to attack others
I'm sick of it too. But this kind of unilateral actions only fuels the
flame, it does not extinguish it.
Especially given your position as a CEO of a for profit company, William.
Even though you
> But if we want to migrate to using system libs why not let gd use whatever it
> wants!
Well, in that case we should use system gd, shouldn't we?
On Tue, Aug 16, 2016 at 4:35 PM, Luca De Feo <de...@lix.polytechnique.fr> wrote:
> After a system upgrade my built-from-source sage
After a system upgrade my built-from-source sage install started
crashing with the log message
ImportError: libvpx.so.3: cannot open shared object file: No such
file or directory
and indeed my system update updated libvpx from 3.x to 4.x, while I
can't find any trace of it in the sage/
>
> Can you also ask him about the license?
>
You can read here http://www-polsys.lip6.fr/~jcf/FGb/Maple/tutorial-fgb.pdf
that "FGb is freely distributed for academic use only". The question has
been asked often: publishing the sources is out of question.
--
Luca
--
You received this
I was also thinking about writing an interface to FGb. Maple uses this
library via the C API to compute Gröbner bases. As far as I know Magma uses
an older version of this code too. So it must be doable.
I spoke to the author, and he is positive about an interface into Sage. If
we find
Let me share some more thoughts on the interplay between modularization and
the review process. I'm afraid I'm going to be long... TL;DR:
modularization is good to keep Sage going forward.
Our review process discourages patchbombs, and for a reason. For one, no
one wants to review patchbombs.
> I merely said that this appears to work. I never said that everything
should go there.
Sorry for misunderstanding you.
> On the other hand, you mention a core Magma library that helps it beat
Sage on benchmarks, I imagine such a library would be a nice fit into core
Sage.
It would be
> How often do you feel that changes in Sage breaks your code?
Looking at my log (this project
https://github.com/defeo/ss-isogeny-software)
- Sage 6.2: module renamed in Pari/GP interface (without deprecation, as
far as I recall)
- Sage 6.4: frankly, I don't know, but possibly a change in
> if research developers 1) don't care enough about their own code to
polish it enough for going through our review process
I don't agree with Dima that putting their code into Sage is what
researchers should do, no matter what.
I do care a lot about my research code, and I know some of it
> This thread is first and foremost about reducing the friction involved in
making code that depends on the Sage distribution available to the world.
> Based on feedback I get from users, this friction is a very, very
significant problem to the growth of Sage.
Let me recall something that
I guess this is relevant:
https://blog.docker.com/2016/03/docker-for-mac-windows-beta/
Shall we sign up for the private beta?
Luca
--
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
[X ] Yes -- adopt the code of conduct stated below (*)
Luca
--
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
I'm not sure multimethods alone are enough to solve issues with Sage's
type system (e.g. coercion, where the result of a+b may happen in a
completely new domain) but they could certainly help.
I purposedly said many, and not all, nor even most. The most
important feature to a CAS missing in
I guess these two posts by G. Hoare (creator of the Rust language) are
of interest to the community:
http://graydon2.dreamwidth.org/3186.html
http://graydon2.dreamwidth.org/189377.html
See also the presentation linked therein:
Hi deprecation experts,
The current way to deprecate a function that has changed name is:
old_func = deprecated_function_alias(new_func, Sage version)
which, upon calling old_func, takes care of printing a deprecation message
(Since Sage version) old_func is deprecated. Please
47 matches
Mail list logo