is a program, which can find relations between the
generating functions of the sequences in the OEIS.)
In kind 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 f
On Mon, 2021-01-25 at 23:19 -0800, Siddharth Bhat wrote:
> Hey all,
>
> I'm very new here, so I'm unsure how this works;
> I submitted a patch on saturday that implements chokesly
> decomposition for
> sparse matrices by calling out to cvxopt.cholmod:
> https://trac.sagemath.org/ticket/13674
>
On Mon, 2021-01-25 at 13:35 +0100, Vincent Delecroix wrote:
> What did you expect? You have
>
> sage: ((x + x^2) / x).is_polynomial(x)
> False
> sage: ((x + x^2) / x).expand().is_polynomial(x)
> True
>
> I don't think there is any bug... maybe a lack of specifications.
>
>
The use of
On Mon, 2021-01-25 at 12:08 +0100, Vincent Delecroix wrote:
> Shouldn't it be
>
> (- (* a d) (* b c))
>
> and
>
> (- (* b b) (* 4 a c)))
>
>
The unary "negate" operation and the binary "subtract" operation are
usually distinguished by context, i.e. by whether prefix or infix
notation is
Hi,
so, what's the punch line now? I totally lost track because we digressed
too much. Is the representation change still wanted or not? And if so, what
shall be it? I would like to conclude
https://trac.sagemath.org/ticket/24523.
Best,
Michael
emanuel.c...@gmail.com schrieb am Samstag, 24
On 12/18/20 9:53 AM, Dima Pasechnik wrote:
isn't pynac/ginac used a lot?
At least for symbolic integration, the current list in
symbolic/integration/integral.py is,
self.integrators = [external.maxima_integrator,
external.giac_integrator,
On 12/18/20 2:55 AM, Sébastien Labbé wrote:
Why do we use maxima first as opposed to giac/sympy? Is it because it is
faster than giac/sympy? Is it because it returns answers that are
correct but for which giac/sympy returns incorrect results?
I personally have never tried it because I'm
On 3/18/20 11:48 AM, Michael Jung wrote:
Dear fellow developers,
I've encountered a really strange result in Sage while using Maxima.
|
sage:f(x,y)=(x^2-y^2)/(x^2+y^2)^2
sage:integrate(integrate(abs(f(x,y)),x,0,1),y,0,1)
-1/4*pi
|||
This is really weird. At least, the result should
On 12/16/20 3:27 PM, Linden Disney wrote:
Ok I've modified the code to plain sage to make it more useful and I've
copied it below. Given that it's hard to compare the determinants of the
raw matrices, as they are defined in terms of different variables, I
have found the z^2 coefficient in each
On 10/12/20 8:16 AM, Linden Disney wrote:
Attached is a jupyter notebook that runs Sage 9.1, a (slightly more)
minimal example of a problem that I discovered. When calculating the
determinant of a large (in the sense n>=9 I have currently found)
symbolic matrix the answer is not correct
On 10/1/20 6:05 PM, Richard_L wrote:
I get the above message when I ask SageMath 9.1 to swallow a large
expression (attached file). Is anyone else seeing this message?
All variables are declared real. The message did not show up until I
started using 9.1
I tracked this down to a
On 11/4/20 3:37 AM, Adam Larat wrote:
> I would be glad to contribute if you indicate me the procedure to
> follow,
Oh, I just saw this part now. Most of the process is covered by
https://doc.sagemath.org/html/en/developer/index.html
but can be simplified if you're used to contributing to
On 11/4/20 3:37 AM, Adam Larat wrote:
> Hi everyone,
>
> I hope I am posting at the correct place.
>
> There is a minor bug in the verbose output of the small_roots function...
Thanks, this should be a quick fix:
https://trac.sagemath.org/ticket/30921
--
You received this message because you
On 11/4/20 9:49 AM, brucew...@gmail.com wrote:
I have tried to switch to 9,3.beta0 (yes, my OS is essentially Ubuntu 20.10)
This failed and I don't know what went wrong. The end of the log file is:
You have to do "make giac" there when it crashes. There's a ticket open
to fix this with a
,
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.go
On 10/20/20 11:32 AM, Nathan Dunfield wrote:
Yes, I am all too well-aware that all code requires some level of
maintenance. The question is how often and how much, and I don't think
the fact that maintenance is inevitable is a good argument for
increasing the amount required unnecessarily.
and makes the step to a "genuine" real field much more
comprehensible. I don't mind if you don't agree, but I'm curious about your
opinions.
Best,
Michael
dim...@gmail.com schrieb am Dienstag, 20. Oktober 2020 um 16:28:19 UTC+2:
>
>
> On Tue, 20 Oct 2020, 15:1
On 10/16/20 5:25 AM, Samuel Lelièvre wrote:
Le ven. 16 oct. 2020 à 07:50, Vincent Delecroix:
However, they are much more than sets as they come with approximations
of the field operations (+, x, ^-1)
I like your suggestions. I liked the shortness of RealFloats,
but I'm not strongly
On 10/20/20 12:12 AM, Nathan Dunfield wrote:
-1: I don't really care what RealField.__repr__ returns, but cast a
token no vote to object to the logical next move of breaking backwards
compatibility by changing the meaning of RealField and/or RR. I see the
need for a "genuine real field", but
r?
And then similarly for interval arithmetics and ball arithmetics.
Best,
Michael
> However, they are much more than sets as they come with approximations
> of the field operations (+, x, ^-1). Maybe a reasonable terminology
> would be "numerical field"? And in this regard, RealFloa
in their LaTeX newcommands : ZZ, QQ, AA, RR, CC and their
approximations use 3 letters RFF, RBF, RIF, ... (could be RFN, RBN, RIN, or
similar). *
Big +1!
Best,
Michael
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscrib
+1 from my side, too.
vdelecroix schrieb am Mittwoch, 14. Oktober 2020 um 08:28:08 UTC+2:
> Dear all,
>
> I would like to discuss the patchbomb at
>
> https://trac.sagemath.org/ticket/24523
>
> The ticket hopes to change the string representation from
> "Real Field with XX bits of precision" to
On 2020-10-01 04:29, Samuel Lelievre wrote:
>
> I'm not sure how to best deal with that:
>
> [a] ...
>
[d] change our github email address to postmas...@digitalocean.com
(how many real pull requests do we get?)
--
You received this message because you are subscribed to the Google Groups
On 2020-09-23 13:24, David Roe wrote:
> For more online seminars see researchseminars.org
> <http://researchseminars.org>, a site I created this spring with
> colleagues at MIT. There are currently 518 upcoming talks listed in
> math. Michael, if you know the organizers of
Every Thursday, I participate in an optimization seminar hosted by my
alma mater, the University of Maryland Baltimore County (UMBC). The
talks take place at 10am US Eastern time, but have moved online for
obvious reasons. And now that the seminars are online, our audience has
expanded greatly: we
On 2020-09-08 14:34, Samuel Lelievre wrote:
>
> No quiet or silent mode; `-s` is for "save", not "silent".
>
> Conclusion: sorry for all the noise about the quiet.
>
> Bootstrap does not make that much noise anyway.
>
We could pretty easily add a -q (quiet) flag to ./bootstrap if it would
On 2020-08-31 02:58, Emmanuel Charpentier wrote:
>
> What is the recommended way to cope with such surprises ?
>
You just have to rebuild sage; it's a pitfall inherent to any software
not installed with your system's package manager. The package manager
knows to upgrade flint's "reverse
On 2020-08-30 06:05, 'Reimundo Heluani' via sage-devel wrote:
> Good morning, I see that support for Python 3.8.x is about to be merged in
> #27754. I want to add a parallel computation ticket and I was wandering if I
> could use multiprocessing.parent_process() which is only available starting
On 2020-08-28 08:40, 'Reimundo Heluani' via sage-devel wrote:
> On Aug 28, Michael Orlitzky wrote:
>> On 2020-08-28 08:23, 'Reimundo Heluani' via sage-devel wrote:
>>> Thanks, I guess recompilation is unavoidable then, the worst part is that
>>> it was one of my ow
On 2020-08-28 08:23, 'Reimundo Heluani' via sage-devel wrote:
> Thanks, I guess recompilation is unavoidable then, the worst part is that it
> was one of my own tickets :)
>
Dima meant "git fetch" literally. That will pull down the changes, but
won't try to merge them into your local branch
On 2020-08-04 10:21, Dima Pasechnik wrote:
> I've switched trac to send notifications via a host called
> sagemath.openbsd.amsterdam
> (after wasting a lot of time trying to use Google's G-suite, it's hell )
>
> Let me know whether this works for you - I see it working for me
> (sending trac
On 2020-08-25 10:39, 'Reimundo Heluani' via sage-devel wrote:
>>
> That locale seems to be an invention of Debian that Ubuntu started using.
> This
> was closed as wontfix 8 years ago on Arch.
>
> https://bugs.archlinux.org/task/32296
>
> It seems to me that having these test failing and
/3503554560*x^5 + 127/154828800*x^4 - 31/967680*x^3 + 7/5760*x^2 - 1/24*x
+ 1
However, the series command returns a division by zero error:
sage: a.series(x, 10)
Traceback (most recent call last):
...
ValueError: power::eval(): division by zero
This is not supposed to happen right?
Best,
Michael
On 2020-08-05 15:49, NicoJG wrote:
> @rjf Isn't the square root defined to be positive?
> Sure: x^2=y <=> x=+/-sqrt(y)
> But I think you would never consider f(x):=sqrt(x) to have the codomain
> of all negative numbers.
> At least I would expect a CAS to interpret a square root to be positive.
>
On 2020-07-29 08:02, 'Reimundo Heluani' via sage-devel wrote:
>
> I was wandering if anything happened to this. I have been receiving some
> trac e-mails and missing some others silently, some during the same day
> so it does not seem to me that trac is choosing these IPs sequentially.
No, and
Apparently, the makefile in src is missing somehow. But the original build
was successful.
--
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
specified and no makefile found. Stop.
Is something wrong with my machine or has something lately been changed?
Best
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, se
://localhost:/notebooks/Untitled.ipynb
I have built Sage from scratch twice now, but the issue remains.
Best,
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, sen
for tickets
that are related to manifolds because they are mixed up with general
geometry tickets. Has this already been discussed?
Best
Michael
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
On 2020-07-01 09:23, Nicolo' Piazzalunga wrote:
> Thanks.
> I'm puzzled by 'does not support check for system package'/'no suitable
> system package' in config.log
We haven't written the script to detect a system copy of ECL yet. We're
in the middle of upgrading to a new major version of it, and
On 2020-07-01 08:36, Dima Pasechnik wrote:
>
> In building giac, you get even more strange error, a missing gammaf function.
> (something to do with musl?)
Giac upstream probably needs to
#define _GNU_SOURCE
to get the gammaf() function with musl, since it's not standardized.
--
You
On 2020-06-29 18:38, Travis Scholl wrote:
> Hello,
>
> I was hoping someone could review the following two tickets:
>
> https://trac.sagemath.org/ticket/24302
>
> https://trac.sagemath.org/ticket/18863
>
> Is there a standard way to request reviewers besides marking a ticket as
>
On 2020-06-22 20:41, 'Travis Scrimshaw' via sage-devel wrote:
>
> I agree with Nils about this, and I like his proposal. I also think the
> random number might (and should) change if other doctests are changed
> around it. However, having something that consistently fails is better than
>
On 2020-06-22 09:03, Dima Pasechnik wrote:
> On Mon, Jun 22, 2020 at 1:25 PM Dima Pasechnik wrote:
>
> I would prefer this to explicit calling of set_random_seed() in
> doctests (i.e. it'd prefer implicit fuzzing of tests to explicit one).
> I've opened https://trac.sagemath.org/ticket/29935 to
On 2020-06-22 05:01, 'Jonathan Kliem' via sage-devel wrote:
> Hi. Could we maybe turn off reproducible "randomness" in doctests by
> default. There are probably thousands of meaningless doctests because of
> this.
>
> E.g. https://trac.sagemath.org/ticket/29904
>
> or the doctests for the
nk of both involved
forms. This makes it a little bit difficult to figure out a good
parallelization method. On top of that, I have no idea about effective
parallelization yet. Thus, I appreciate any help, feedback or tips that I
can get.
Thank you in advance, and best regards,
Michael
--
Yo
On 2020-06-18 13:47, Nils Bruin wrote:
>
> To compare: magma has function-application-on-the right in the notation x@f
> and map composition f*g (for right action). So with
Off-topic:
For some programming-language design trivia, the explicit syntax for
function application on the right has a
On 2020-06-15 10:58, 'Paul Mercat' via sage-devel wrote:
> Hi !
>
> Sage doesn't compute correctly the matrix of a Permutation:
>
> matrix(Permutation('(1,2,3,4)'))
>
> return a wrong answer: it returns the inverse of the correct result.
> The product of matrices of permutations must be equal
On 6/2/20 9:52 AM, Volker Braun wrote:
> I'm with Linus in that the 80 characters limit is an anachronism thats
> too restrictive in a time and age where large high-resolution displays
> are ubiqitous. There certainly is a "too long" somewhere but its more in
> the 100-character region.
>
>
On 5/30/20 9:25 AM, 'Reimundo Heluani' via sage-devel wrote:
>
> Thanks, my question is mainly about output strings, how do you break them
> with
> ellipsis?
>
Oh, I don't know. I break them manually and let the line breaks show up
in the HTML. Users may see wrapped output anyway from either
Ah, interesting. Do you have some literature/references for me?
Am Montag, 1. Juni 2020 01:06:44 UTC+2 schrieb Nils Bruin:
>
> On Sunday, May 31, 2020 at 2:52:21 PM UTC-7, Michael Jung wrote:
>>
>> If I understand this correctly, I'd say this is already the approach of
>>
I should just mention here, that a CPU parallelization on the level of
components already takes place. However, watching the CPU usage one can see
that only single cores are demanded. I am not certain about the reason.
Am Sonntag, 31. Mai 2020 23:52:21 UTC+2 schrieb Michael Jung:
>
>
of the determinant scales quite badly, too.
I already replaced zero-involving computations by simple checks. However,
this is not enough.
Am Sonntag, 31. Mai 2020 22:51:27 UTC+2 schrieb Nils Bruin:
>
> On Sunday, May 31, 2020 at 12:41:52 PM UTC-7, Michael Jung wrote:
>>
>> Tha
ai 2020 22:33:57 UTC+2 schrieb Nils Bruin:
>
> On Saturday, May 30, 2020 at 7:37:43 AM UTC-7, Michael Jung wrote:
>>
>> Mh. Okay. Do you have an idea how to improve the computation, e.g. by
>> using multiple cores?
>>
>> A standard trick is to take a "multimo
Mh. Okay. Do you have an idea how to improve the computation, e.g. by using
multiple cores?
Am Samstag, 30. Mai 2020 11:37:02 UTC+2 schrieb Dima Pasechnik:
>
> On Sat, May 30, 2020 at 8:05 AM Michael Jung > wrote:
> >
> > Thanks for your respond. The entries are eleme
On 5/30/20 8:51 AM, 'Reimundo Heluani' via sage-devel wrote:
>
> I've looked through the code and found numerous instances of long times in
> examples and tests blocks. So my question is: is there a policy about these
> things? My guess is to leave the long lines of output without wrapping.
>
Thanks for your respond. The entries are elements of the mixed form algebra
(https://doc.sagemath.org/html/en/reference/manifolds/sage/manifolds/differentiable/mixed_form_algebra.html).
Whose multiplications are already relatively slow.
--
You received this message because you are subscribed
Sorry, I meant: "especially for the division-free algorithm of the
determinant."
Am Freitag, 29. Mai 2020 23:46:55 UTC+2 schrieb Michael Jung:
>
> Dear Sage Developers,
> is there a mutliprocessing support available for computations with
> matrices of large dimensions? E
Dear Sage Developers,
is there a mutliprocessing support available for computations with matrices
of large dimensions? Especially with respect to the division-free algorithm?
Best wishes
Michael
--
You received this message because you are subscribed to the Google Groups
"sage-devel&q
On 5/28/20 9:07 AM, Eric Gourgoulhon wrote:
> Hi,
>
> During the release of the latest version of the Sage package kerrgeodesic_gw
> https://pypi.org/project/kerrgeodesic-gw/
> early this week, various Ubuntu users have complained that
>
> sage -pip install kerrgeodesic_gw
>
> returns the
On 5/27/20 4:08 PM, Volker Braun wrote:
> Which python versions do we want to be compatible with now? Please separate
>
>
> A)Supported Python versions for building Sage
>
> Note that I'm already seeing f-strings in #29547 so unless a policy is
> formulated real soon the de-facto answer is
On 5/22/20 6:40 PM, AlexGhitza wrote:
> I would also argue that, despite the validity of the arguments regarding
> inexact rings, this is a change in behavior that would have benefited
> from a deprecation warning for a short while.
We were pretty careful not to break anything in the sage
On 5/22/20 3:39 PM, Nils Bruin wrote:
> I think this might need some work:
>
> S=RealBallField(100)
> M=Matrix(S,2,1,[1,1])
> M.solve_right(vector([1,2]))
>
> There's enough information here to conclude there is no solution; or in
> a rather deranged way, perhaps it should give a rather large
On 5/21/20 8:44 PM, AlexGhitza wrote:
> Hi,
>
> I'm observing the following with version 9.1 (but not with 9.0 where the
> behavior is correct):
>
> sage: m = matrix(SR, [0])
> sage: b = vector([1])
> sage: m.solve_right(b)
> (0)
>
> This should of course raise
>
> ValueError: matrix equation
On 5/20/20 6:42 PM, TB wrote:
>
> The _cmp_ method does not appear in
> https://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/complex_double.html
> and makes finding this fact harder for most users (in most cases _cmp_
> and other _methods_ would make the docs harder to read).
On 5/8/20 4:12 PM, Nils Bruin wrote:
> On Thursday, April 30, 2020 at 9:20:00 AM UTC-7, Michael Orlitzky wrote:
>
> I feel the same way about functions like search_src() that badly
> reimplement grep (even if they still work).
>
>
> I'm definitely in favour
On 5/8/20 12:59 PM, John H Palmieri wrote:
>
> As a topologist, I would have to say that the best results are the ones
> for simplicial complexes and simplicial sets, actually.
>
Good news: those are also in my top five results. Bad news (?): Google
probably knows enough about you to put them in
On 5/8/20 12:11 PM, John H Palmieri wrote:
>
> They accomplish different things: one searches the global name space and
> the other searches the source code.
>
> Example: can Sage compute any fundamental groups?
>
Neither approach returns the best result. Putting
site:doc.sagemath.org
On 5/7/20 8:45 AM, kcrisman wrote:
>
> Again, I think it is not necessarily the case that users of
> Sage-the-software - say, in a CoCalc-provided notebook as a student -
> necessarily know how to "search a bunch of files for a string" or even
> know that there is such a thing.
Anyone who wants
On 5/6/20 11:28 PM, John H Palmieri wrote:
>
> And to clarify, this is what you expect users to use instead of
> search_src? ;)
>
It's an improvement to sage-grep. In another message you said, "It was
reimplemented in Python to make it work across platforms... and to make
it faster." It's not
I wonder, if it is faster to compute the complete polynomial directly or go
the way via the free algebra? Anyway, I have to deal with pretty much
variables, hence a nice fast algorithm would be nice.
Best Michael
Am Dienstag, 5. Mai 2020 10:24:39 UTC+2 schrieb Michael Jung:
>
> Hi
Hi Markus,
these are awesome pieces of code. Thank you! Unfortunately, I need this as
the full polynomial since I have to do different computations with each
variable...
Particularly, I have a homogeneous polynomial of matrices and want it to
polarize.
Best wishes
MIchael
Am Dienstag, 28
On 5/3/20 8:09 PM, Matthias Koeppe wrote:
> I propose the following goal for Sage 9.3.
>
> Modularize sagelib so that individual parts of it can be built and run
> with a much smaller set of libraries.
>
A noble goal, but it's going to be difficult given the widespread use of
lazy_import to
On 5/2/20 1:55 PM, John H Palmieri wrote:
>
> OMG, why does "sage -grep" use the "find" command?
>
Others have pointed out that "-r" isn't standard, but "-r" is wrong
anyway. It's only supposed to search through python files. And having
"find" look for those files isn't any slower than having
On 5/2/20 9:20 AM, kcrisman wrote:
>
> Also, search_def is the one I found most useful when learning Sage
> properly, and the GUI manager method requires people to know the "def"
> is the word, not "definition" or even "function" or whatever.
>
Learning the word "def" is no harder than learning
On 5/1/20 1:36 PM, John H Palmieri wrote:
>
> So before deprecating, consider points of view of users from different
> backgrounds. We hope that mathematicians are using Sage, and we
> shouldn't require them to know about "grep". Don't get me wrong, grep is
> great and I use it all the time, but
On 5/1/20 8:45 AM, kcrisman wrote:
>
> I don't know whether python functions can call the ! things but I
> think it would help users to keep search_src(s) as a shorthand for
> !grep -r s $SAGE_ROOT/src and search_def(s) for search_src("def "+s).
>
>
> Thanks for more calmly and
On 5/1/20 3:54 AM, John Cremona wrote:
> I agree with David. I use grep 1000 times a day and I do know how to
> use a computer (and do not appreciate being patronised)
I'm poking fun at the reasoning behind adding these functions to sage,
not the people who use them. I've been on the wrong side
On 4/30/20 3:11 PM, David Roe wrote:
>
> I understand where the criticism is coming from, but I think one of the
> big plusses of search_src and friends is that they're usable from the
> sage command line without switching context to the command line. I
> don't think they should be removed.
On 4/30/20 2:10 PM, John H Palmieri wrote:
>
> They're doctested, and they still work. What makes the implementation
> bad? They use standard Python library tools to walk a directory tree and
> then to do a regexp search on the files there. An advantage to this
> approach is that it is standard
On 4/30/20 11:16 AM, Dima Pasechnik wrote:
>
> I think we should just remove this completely, as ipython nowadays has
> %history magic which certainly can do the same as log_text()
>
+1
I feel the same way about functions like search_src() that badly
reimplement grep (even if they still work).
wonder
whether there are preimplemented algorithms provided in Sage, for instance
via Symmetrica or GAP?
Best wishes
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 fro
Oh yes. You are right. For some reason, my git repo changed back to
`master`. The build has finished now. Thanks for your foresight, Matthias.
Best
Michael
Am 26.04.20 um 19:34 schrieb Matthias Koeppe:
On Sunday, April 26, 2020 at 2:55:51 AM UTC-7, Michael Jung wrote:
still, ecl won't
On 4/26/20 1:40 PM, Matthias Koeppe wrote:
> See https://trac.sagemath.org/ticket/29456
GCC-10 isn't even released yet. Sometimes, if you want to get anything
done, you just have to let people drink bleach.
--
You received this message because you are subscribed to the Google Groups
linked to above says "SendGrid, Mailgun, and Mailjet
> offer a free tier for Compute Engine customers to set up and send email
> through their servers." I have not investigated Mailgun or Mailjet,
> but would love to hear from Michael Orlitzky if either one of those are
> a
Yes, exactly. Thank you Eric.
I could compile pillow now, but still, ecl won't work.
--
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
nux distributor, say. A dedicated server
> would still cost ~100$ per year at least, I guess, something we can
> afford, though)
> And it needs to be set up and maintained.
>
> Any volunteers for this job? Michael?
>
20-40k per month isn't much. SPF and reverse DNS are trivia
Can we please change how our Trac notification emails are sent? SendGrid
is absolutely atrocious. I currently have six of their shared IPs
whitelisted on our mail server to allow these notifications through,
because they would otherwise be blocked by the many many many blacklists
that SendGrid is
This is awesome! Thank you very much, that was really helpful.
Soon, I will open another thread about polarization.
Best
Michael
Am 21.04.2020 um 12:26 schrieb Vincent Delecroix:
The crucial difference is that I don't use .from_polynomial (which
is kind of broken). Given a univariate
Wow, thanks Vincent. This is awesome! Could you shortly explain what the
crucial difference is here?
On this occasion, may I ask you a slightly off-topic question? Is there an
effective way to compute the polarization of homogeneous polynomials in
Sage?
Best
Michael
Am Dienstag, 21. April
: seq_taylor = seq.taylor(*inp, n // 2)
sage: Sym.e().from_polynomial(P(seq_taylor))
This code is to compute Todd numbers up the the 6th degree and takes hours
of computation. Did I do use symmetric functions wrong here?
Regards
Michael
Am Dienstag, 21. April 2020 02:44:19 UTC+2 schrieb Travis
this is a special case they consider, which makes the
computation probably faster.
Kind regards
Michael
Am Dienstag, 21. April 2020 01:52:43 UTC+2 schrieb Travis Scrimshaw:
>
> Hi Michael,
>The process is to take a polynomial, convert it to the monomial sym
>
with `SymmetricFunctions`.
However, the implemented algorithm seems to be very slow. I know that there
are quite efficient algorithms out there, but are they accessible in Sage?
Thanks for your help and best wishes
Michael
--
You received this message because you are subscribed to the Google Groups
"sage-
On 4/18/20 4:51 PM, John H Palmieri wrote:
> Several of us are in favor of requiring that, in order to build Sage,
> people should have to run "./configure" before running "make". I would
> further propose that "make" should not itself then run "configure".
+1 step closer to sanity
--
You
On 4/17/20 9:55 PM, Michael Orlitzky wrote:
> sage: assume(n > 1)
Oops, that should be assume(n > 0), but it doesn't change anything else.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and st
On 4/16/20 7:24 AM, Mihai wrote:
> Hi, I'm very new to Sage, thus it's likely I'm using it wrongly, but is
> this a bug?
>
> Using:
> https://sagecell.sagemath.org/
>
> I entered:
>
> F(x)=1/(1 + exp(-x))
> FN(x,n) = F(x)**n
> assume(n, 'integer')
> assume(log(exp(n)+1) - n > 0)
> fn =
On 4/13/20 7:44 PM, Olivier Guillon wrote:
> Hello
> I had an error while building sage from source. It may just be a timing
> issue but it seems the upstream repo for brial has changed name to
> '.../upstream/sage_brial/' while this change was not yet reflected on
> servers (where the repo is
On 3/19/20 3:47 AM, Simon King wrote:
>
> Probably not. Wouldn't that be the same as
>Mother.my_method.__doc__ = "new docstring"
> ?
>
Yeah, that's what I tried, and it overwrites the parent method's docstring.
--
You received this message because you are subscribed to the Google Groups
Damn it. Then I another question: Would it cause a slow-down if I
overwrite the method with something like
def my_method(self):
r"""
New Documentation
"""
Mother.my_method(self)
Best,
Michael
Am 19.03.2020 um 00:41 schrieb Mich
On 3/18/20 5:04 PM, 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
201 - 300 of 941 matches
Mail list logo
