Re: [sage-devel] Doubts about correctness of `integrate(floor(x)^2,x)`
On Fri, Jan 20, 2023 at 07:16:14PM +0200, Georgi Guninski wrote:
> I have theoretical reasons to doubt the correctness
> of integrals involving `floor`.
>
> The smallest testcases:
>
> sage: integrate(floor(x)^2,x)
> // Giac share root-directory:/usr/share/giac/
> // Giac share root-directory:/usr/share/giac/
> Added 0 synonyms
> x*floor(x)^2
>
> sage: integrate(2**floor(x),x)
> 2^floor(x)*x
>
> Would someone check with another CAS or prove/disprove by hand?
Maple reports the same result for your first testcase:
tux% maple
|\^/| Maple 2022 (X86 64 LINUX)
._|\| |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2022
\ MAPLE / All rights reserved. Maple is a trademark of
< > Waterloo Maple Inc.
| Type ? for help.
> int(floor(x)^2, x);
2
floor(x) x
>
But, I think Maple and Sage/Giac are both wrong: consider the *definite*
integral (latex notation) $I = \int_0^{3/2} \lfloor x \rfloor^2 \, dx$:
Then the Sage/Giac indefinite integral implies that
$I = \left. x \lfloor x \rfloor^2 \right|^{3/2}_0
= (3/2) \lfloor (3/2) \rfloor^2 - 0 \lfloor 0 \rfloor^2
= 3/2$
But it seems to me that the correct result should be
$I = \int_0^{3/2} \lfloor x \rfloor^2 \, dx$
= \int_0^1 \lfloor x \rfloor^2 \, dx
+ \int_1^{3/2} \lfloor x \rfloor^2 \, dx
= \int_0^1 0 \, dx + \int_1^{3/2} 1 \, dx
= 0 + 1/2
= 1/2$
--
-- "Jonathan Thornburg [remove -color to reply]"
on the west coast of Canada
"Now back when I worked in banking, if someone went to Barclays,
pretended to be me, borrowed UKP10,000 and legged it, that was
`impersonation', and it was the bank's money that had been stolen,
not my identity. How did things change?" -- Ross Anderson
--
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/Y8uJnv8gVWO8DeHI%40gold.bkis-orchard.net.
Re: [sage-devel] Re: Democratic issue: rushing decisions
On Thu, Oct 6, 2022 at 8:45 AM John H Palmieri wrote: > There is nothing in our department's bylaws to provide for a delay of > voting, but we have a chair and we have an executive committee, and the > hope is that they care not only about the particular issue at hand, but > also about the atmosphere in the department. So if someone asked for a > delay, probably the executive committee would consider it and make a > decision. That would not likely result in a vote on whether to delay, but > just a decision to delay the vote, and probably to schedule some meetings > for discussion. On Thu, Oct 06, 2022 at 09:25:26AM -0700, William Stein wrote: > Thanks! So it's basically this model that you already described: > "Alternatively, we have a steering committee that steps in to make > decisions, for example about the timing of votes, when there is > disagreement." Having an elected steering committee is common in > other software projects I pay attention to (e.g., Python and Jupyter). As another data point, in section 12.8 of his book "The Design and Evolution of C++", Bjarne Stroustrup describes an invocation of a "delay a vote to the next meeting" rule in the ANSI/ISO C++ standards committee (which at the time typically met about 3 times per year): [[a proposal for extending the C++ language]] was presented at the standards meeting in Seattle in July 1990. There appeared to be a massive majority for making this the first non-mandated extension to C++. At that point, Beth Crockett from Apple stopped the committee dead in its tracks by invoking what is known as the "two week rule:" Any member can postpone voting on a proposal that has not been in the hands of the members at least two weeks before the meeting until the following meeting. This rule protects people against being rushed into things they don't understand and ensures that there will always be time to consult with colleagues. As you might imagine, Beth didn't gain instant popularity by that veto. However, her caution was well founded, and she saved us from making a bad mistake. Thanks! As we reexamined the problem after the meeting, Doug McIlroy [[found a better solution]] -- -- "Jonathan Thornburg [remove -color to reply]" currently on the west coast of Canada "Why would we install sewers in London? Everyone keeps getting cholera again and again so there's obviously no reason to install sewers. We just need to get used to this as the new normal." -- 2022-Jul-25 tweet by "Neoliberal John Snow" -- 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/Yz8qqM4YuOVtYNJI%40iron.bkis-orchard.net.
Re: [sage-devel] Re: spherical harmonics still broken in 9.5.beta8
Hi Eric, On Mon, Mar 14, 2022 at 12:58:26PM -0700, Eric Gourgoulhon wrote: > The branch of the ticket https://trac.sagemath.org/ticket/33117 has been > merged in Sage 9.6.beta5, so in Sage 9.6 spherical harmonics will agree > with those of SymPy, SciPy, Mathematica and Wikipedia, and will have > correct derivatives. There remains the issue of simplifying some > sqrt(sin(theta)^2) terms which appear for odd orders m. This is now > https://trac.sagemath.org/ticket/33501. This is a big improvement already -- thanks a lot for all your efforts on this (and SageManifolds in general)! All the best, keep safe and COVID-free, -- Jonathan -- 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/YjA700OWMUb6WEAr%40gold.bkis-orchard.net.
[sage-devel] Solved Re: ECL out of memory error
In <https://groups.google.com/g/sage-devel/c/k414Ctfj42o/m/4xM0c0OhBAAJ> I wrote: > A Sage program of mine recently aborted with an error traceback > (given in full below) ending with > > > TypeError: ECL says: Memory limit reached. Please jump to an outer pointer, > > quit > > program and enlarge the > > memory limits before executing the program again. > > How is the ECL memory limit configured? (From looking around with 'ps' > and 'top' while Sage is running, I don't think I'm hitting any OS-level > process-size limit.) [[...]] For the archives: On further investigation it's clear I was wrong. I was indeed hitting an OS-level process-size limit, and increasing that limit resolved my problems. I'm sorry for the false problem report. -- -- "Jonathan Thornburg [remove color- to reply]" on the west coast of Canada, eh? "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time." -- George Orwell, "1984" -- 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/YeDfL6vuBtLXSzjV%40gold.bkis-orchard.net.
[sage-devel] ECL out of memory error
f): /usr/local/sage/sage-9.5.beta8/local/var/lib/sage/venv-python3.7/lib/python3.7/site-packages/sage/interfaces/interface.py in function_call(self, function, args, kwds) 611[s.name() for s in args], 612['%s=%s'%(key,value.name()) for key, value in kwds.items()]) --> 613 return self.new(s) 614 615 def _function_call_string(self, function, args, kwds): /usr/local/sage/sage-9.5.beta8/local/var/lib/sage/venv-python3.7/lib/python3.7/site-packages/sage/interfaces/interface.py in new(self, code) 380 381 def new(self, code): --> 382 return self(code) 383 384 ### /usr/local/sage/sage-9.5.beta8/local/var/lib/sage/venv-python3.7/lib/python3.7/site-packages/sage/interfaces/interface.py in __call__(self, x, name) 293 294 if isinstance(x, str): --> 295 return cls(self, x, name=name) 296 try: 297 # Special methods do not and should not have an option to /usr/local/sage/sage-9.5.beta8/local/var/lib/sage/venv-python3.7/lib/python3.7/site-packages/sage/interfaces/interface.py in __init__(self, parent, value, is_name, name) 732 self._name = parent._create(value, name=name) 733 except (TypeError, RuntimeError, ValueError) as x: --> 734 raise TypeError(x) 735 736 def _latex_(self): TypeError: ECL says: Memory limit reached. Please jump to an outer pointer, quit program and enlarge the memory limits before executing the program again. sage: Exiting Sage (CPU time 90m12.99s, Wall time 90m16.79s). --- end full error traceback --- thanks, keep safe and COVID-free, -- -- "Jonathan Thornburg [remove color- to reply]" on the west coast of Canada, eh? "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time." -- George Orwell, "1984" -- 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/YdqRkbICfAZLr4QH%40gold.bkis-orchard.net.
Re: [sage-devel] Python-level error messages don't give the source file name
I wrote:
> I've noticed that some (many) Python-level error messages (e.g., syntax
> errors) from Sage 9.5.beta8 fail to give the name of the source file
> in which the error occured. [[...]]
On Sat, Jan 08, 2022 at 10:24:07PM -0500, Michael Orlitzky replied:
> I think the load() method has been superseded by whatever magic ipython
> offers. I'm not an expert, but I think
>
> sage: %run
>
> will give you a better error message.
Thanks for the suggestion. A bit of poking around shows that the sage
input
sage: run 'file-name'
will work nicely. (There's no initial '%' sign -- the sage preparser
adds that back on.)
Alas, this is ONLY valid at the top-level ipython/sage REPL. Inside
a 'run-ed' file, the run command doesn't work (it's a syntax error
regardless of whether it's spelled 'run' or '%run').
More generally, suppose I have a bunch of Sage assignments-to-globals
and function definitions in several files, say
foo.sage
bar.sage
baz.sage
what's the idiomatic way for some other piece of Sage source code to
execute the contents of all of those files? What I've been doing is
to create another file (say 'setup.sage') which contains the lines
load('foo.sage')
load('bar.sage')
load('baz.sage')
so that
load('setup.sage')
(either at the interactive Sage prompt or in another source file) loads
all the individual files. This works fine apart from the un-helpful
error messages when (not if, *when*) I have bugs in my code. Is there
a more idiomatic way?
--
-- "Jonathan Thornburg [remove color- to reply]"
on the west coast of Canada, eh?
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
--
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/YdqOcqD%2B85Lcc4Rn%40gold.bkis-orchard.net.
[sage-devel] Python-level error messages don't give the source file name
I've noticed that some (many) Python-level error messages (e.g., syntax
errors) from Sage 9.5.beta8 fail to give the name of the source file
in which the error occured. For example, a few minutes ago I got this
error message from a Sage code I'm working on:
> Traceback (most recent call last):
>
> File
> "/usr/local/sage/sage-9.5.beta8/local/var/lib/sage/venv-python3.7/lib/python3.7/site-packages/IPython/core/interactiveshell.py",
> line 3441, in run_code
> exec(code_obj, self.user_global_ns, self.user_ns)
>
> File "", line 1, in
> load('setup.sage')
>
> File "sage/misc/persist.pyx", line 173, in sage.misc.persist.load
> (build/cythonized/sage/misc/persist.c:2578)
> sage.repl.load.load(filename, globals())
>
> File
> "/usr/local/sage/sage-9.5.beta8/local/var/lib/sage/venv-python3.7/lib/python3.7/site-packages/sage/repl/load.py",
> line 272, in load
> exec(preparse_file(f.read()) + "\n", globals)
>
> File "", line 8, in
>
> File "sage/misc/persist.pyx", line 173, in sage.misc.persist.load
> (build/cythonized/sage/misc/persist.c:2578)
> sage.repl.load.load(filename, globals())
>
> File
> "/usr/local/sage/sage-9.5.beta8/local/var/lib/sage/venv-python3.7/lib/python3.7/site-packages/sage/repl/load.py",
> line 272, in load
> exec(preparse_file(f.read()) + "\n", globals)
>
> File "", line 66
> P_xx[a,b] = simplify_expression(
>^
> IndentationError: expected an indented block
>
> sage:
Notice that the traceback entries mentioning Sage internal files all
include the file name and line number, but the traceback errors for my
own code just say 'File ""', with no useful information about
which of my source-code files the error occured in.
I'm not sure how much of this is Python's fault and how much is Sage's,
but the user experience is not good.
To reproduce this problem, create the following 2 files:
% head error*
==> error1.sage <==
load('error2.sage')
print bad_function(2, 3)
==> error2.sage <==
def bad_function(x,y)
"""
Note the missing ':' at the end of the first line of this file.
This will produce a Sage/python syntax error when this file
is loaded.
"""
return x+y
%
and type
load('error1.sage')
at the sage command prompt.
stay safe and COVID-free,
--
-- "Jonathan Thornburg [remove color- to reply]"
on the west coast of Canada, eh?
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
--
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/YdpOjoVjfSJAO5qq%40gold.bkis-orchard.net.
Re: [sage-devel] Re: spherical harmonics still broken in 9.5.beta8
On Wed, Jan 05, 2022 at 12:14:23AM -0800, Eric Gourgoulhon wrote: > The other difference in the above example is a lack of simplification of > sqrt(sin(theta)^2). I think this problem is worse than "just" a lack of simplification: if sin(theta) < 0 then sqrt(sin(theta)^2 != sin(theta), i.e., the theta dependence is wrong, not "just" not-fully-simplified. Should we have another ticket this? Eric also wrote: > Actually, the difference between the two results is essentially due to a > different convention in the Condon-Shortley phase > (cf. > https://en.wikipedia.org/wiki/Spherical_harmonics#Condon%E2%80%93Shortley_phase > ), > which makes Sage's spherical harmonics Y_l^m differ from Wikipedia and > Mathematica ones by a factor (-1)^m. [[...]] > I would vote for including the Condon-Shortley phase in Sage's spherical > harmonics, since this is standard in quantum mechanics and this would make > Sage agree with Wikipedia and Mathematica. +1 on this. > I've opened > https://trac.sagemath.org/ticket/33117 > for this. -- -- "Jonathan Thornburg [remove color- to reply]" on the west coast of Canada, eh? "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time." -- George Orwell, "1984" -- 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/YdZ3W6iYQDLa7EaA%40gold.bkis-orchard.net.
[sage-devel] spherical harmonics still broken in 9.5.beta8
Sage has long had problems with spherical harmonics, e.g., this thread
from June 2019:
https://groups.google.com/g/sage-support/c/I_d_meMxRbM/m/Esxo5UO2BAAJ
As of 9.5.beta8, spherical harmonics are (still) broken for some arguments,
with the test case noted in that earlier thread still giving the same
(wrong) result:
sage: theta,phi = var('theta,phi')
sage: spherical_harmonic(1,1,theta,phi)
1/4*sqrt(3)*sqrt(2)*sqrt(sin(theta)^2)*e^(I*phi)/sqrt(pi)
The correct result would be
-1/4*sqrt(6)*e^(I*phi)*sin(theta)/sqrt(pi)
(see, e.g., https://en.wikipedia.org/wiki/Table_of_spherical_harmonics).
In that earlier thread, Eric Gourgoulhon noted that the problem was related
to
https://trac.sagemath.org/ticket/25034
Unfortunately, even though that ticket is now marked "closed defect (fixed)",
spherical harmonics are still broken.
Eric suggested a workaround, using the spin-weighted spherical harmonics
from the /kerrgeodesics_gw/ package, which for spin 0 should reduce to
the standard spherical harmonics.
This works if ell and emm are specific integers, but it can't handle the
case where they are generic variables. E.g., this works with Sage's
native spherical harmonics
sage: ell,emm = var('ell,emm')
sage: theta,phi = var('theta,phi')
sage: diff(spherical_harmonic(ell,emm, theta,phi), theta)
but the analogous
sage: from kerrgeodesic_gw import spin_weighted_spherical_harmonic
sage: diff(spin_weighted_spherical_harmonic(0, ell,emm, theta,phi), theta)
fails.
--
-- "Jonathan Thornburg [remove color- to reply]"
on the west coast of Canada, eh?
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
--
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/YdTZEHWuPGRnsh9c%40gold.bkis-orchard.net.
[sage-devel] spherical harmonics still broken in 9.3.rc2
There have been longstanding issues with spherical harmonics in SageMath,
notably as described in
https://groups.google.com/g/sage-support/c/I_d_meMxRbM/m/Esxo5UO2BAAJ
In that the latter thread, Eric Gourgoulhon's message of 2019-06-15 gives
a simple test case:
from sage.functions.special import SphericalHarmonic
theta,phi = var('theta phi')
spherical_harmonic(1,1, theta,phi)
producing the (wrong) result
-1/4*sqrt(3)*sqrt(2)*sqrt(-sin(theta)^2)*e^(I*phi)/sqrt(pi)
whereas the correct result would be
-1/4*sqrt(6)*e^(I*phi)*sin(theta)/sqrt(pi)
Eric also noted that this problem was apparently a consequence of
https://trac.sagemath.org/ticket/25034
and suggested a workaround, using the spin-weighted spherical harmonics
from the SageMath /kerrgeodesics_gw/ package.
An update:
* As of 9.3.rc2, SageMath's builting spherical harmonics are still broken
(same result as above for Eric's test case).
* As of 9.3.rc2, the /kerrgeodesics_gw/ package fails to load (it worked
fine for me in 9.2.). I'll report that error to the bhptoolkit.org
issue tracker.
And a question:
Given that the underlying problem
https://trac.sagemath.org/ticket/25034
is unlikely to be fixed for 9.3, should we perhaps put a note in the
documentation for 9.3 that spherical harmonics are unreliable at present?
--
-- "Jonathan Thornburg [remove -animal to reply]"
Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
currently on the west coast of Canada
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
--
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/20210408175352.GA10913%40iron.bkis-orchard.net.
