Re: [sage-devel] Whats the plan for random doctests with floating point numbers?

[Kwankyu Lee]

On Thursday, December 30, 2021 at 8:40:35 AM UTC+9 dmo...@deductivepress.ca 
wrote:

> In the long run, we want to fix the doctests so they always pass (as 
> described in the previous comment).
>
> However, in the short run, I think it is fine to add
>
> set_random_seed(0)  # failed doctest - see  trac ticket n
>

+1. So this is (B). The ticket n is cc'ed to the writer of the failed 
doctests.

-- 
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/cafe0793-7671-45f4-b39e-929fc9fd77b3n%40googlegroups.com.

Re: [sage-devel] Whats the plan for random doctests with floating point numbers?

[dmo...@deductivepress.ca]

In the long run, we want to fix the doctests so they always pass (as 
described in the previous comment).

However, in the short run, I think it is fine to add

set_random_seed(0)  # failed doctest - see  trac ticket n

where the description of ticket n says it is adding `set_random_seed` 
to fix a bunch of failed doctests (and should also have comments that 
specify the `sage -t` calls that produce the failures).  That way, we still 
get doctest coverage, and a search of the source code for `set_random_seed` 
will quickly reveal the problems that were found.  I don't think that 
opening a ticket for each of these failures needs to be the job of the 
person who finds the errors.

PS I'm sorry to hear that the randomization has been causing problems for 
you!

On Wednesday, December 29, 2021 at 4:01:13 PM UTC-7 Michael Orlitzky wrote:

> On Wed, 2021-12-29 at 13:35 -0800, Volker Braun wrote:
> > There are doctests of the form 
> > 
> > sage: x = random_value()
> > sage: abs(floating_point_computation(x) - exact_value(x)) < tolerance
> > True 
> > 
> > but every floating point computation has SOME values where it is 
> > ill-conditioned. I'm finding a steady trickle of test failures due to 
> the 
> > (now) random seeds for each run. Whats the plan for that?
> > 
> > 
>
> I think we have to consider what the point of these tests is. If
> someone picked a tolerance that turned out to be too naive, then either
> the code or the test is wrong, and we should fix whichever one it is.
>
> If the existing tolerance was just someone's pulled-it-out-of-my-butt
> guess, then we can fix it by adding an order of magnitude to the
> tolerance without much thought. But if someone carefully picked a
> tolerance that is actually violated (as in your example), someone
> should probably take a look at it and do the analysis to pick a better
> value.
>
>
>

-- 
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/3990afbe-1ee6-44e3-bf84-275baf5f8d5en%40googlegroups.com.

Re: [sage-devel] Whats the plan for random doctests with floating point numbers?

[Michael Orlitzky]

On Wed, 2021-12-29 at 13:35 -0800, Volker Braun wrote:
> There are doctests of the form 
> 
> sage: x = random_value()
> sage: abs(floating_point_computation(x) - exact_value(x)) < tolerance
> True 
> 
> but every floating point computation has SOME values where it is 
> ill-conditioned. I'm finding a steady trickle of test failures due to the 
> (now) random seeds for each run. Whats the plan for that?
> 
> 

I think we have to consider what the point of these tests is. If
someone picked a tolerance that turned out to be too naive, then either
the code or the test is wrong, and we should fix whichever one it is.

If the existing tolerance was just someone's pulled-it-out-of-my-butt
guess, then we can fix it by adding an order of magnitude to the
tolerance without much thought. But if someone carefully picked a
tolerance that is actually violated (as in your example), someone
should probably take a look at it and do the analysis to pick a better
value.


-- 
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/fa4ccc2a865a641e233cdf281f82de54c996d61f.camel%40orlitzky.com.

[sage-devel] Whats the plan for random doctests with floating point numbers?

[Volker Braun]

There are doctests of the form 

sage: x = random_value()
sage: abs(floating_point_computation(x) - exact_value(x)) < tolerance
True 

but every floating point computation has SOME values where it is 
ill-conditioned. I'm finding a steady trickle of test failures due to the 
(now) random seeds for each run. Whats the plan for that?

A) mark them all as # random

B) identify all such tests and pick a fixed seed for those

C) identify all such tests and do the error analysis to find a tolerance(x) 
that takes the numerical instabilities into account

D) ignore issue and pick a fixed seed for the buildbot, will still randomly 
fail for users


PS: Here is one to illustrate the issue:

sage -t --long --warn-long 50.7 
--random-seed=269711721119345330713403621242624346446 
src/sage/functions/exp_integral.py
**
File "src/sage/functions/exp_integral.py", line 1493, in 
sage.functions.exp_integral.exponential_integral_1
Failed example:
for prec in [20..128]:  # long time (15s on sage.math, 2013)
R = RealField(prec)
S = RealField(prec+64)
a = R.random_element(-15,10).exp()
n = 2^ZZ.random_element(14)
x = exponential_integral_1(a, n)
y = exponential_integral_1(S(a), n)
c = RDF(4 * max(1.0, y[0]))
for i in range(n):
e = float(abs(S(x[i]) - y[i]) << prec)
if e >= c:
print("exponential_integral_1(%s, %s)[%s] with precision %s 
has error of %s >= %s"%(a, n, i, prec, e, c))
Expected nothing
Got:
exponential_integral_1(57.77854062056109797473161078505723378, 1)[0] 
with precision 127 has error of 4.75102130393081 >= 4.0
**
1 item had failures:
   1 of  11 in sage.functions.exp_integral.exponential_integral_1
[275 tests, 1 failure, 7.23 s]
--
sage -t --long --warn-long 50.7 
--random-seed=269711721119345330713403621242624346446 
src/sage/functions/exp_integral.py  # 1 doctest failed
--

-- 
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/6a08eaf8-227a-4340-8e33-a8c96a4ced32n%40googlegroups.com.

[sage-devel] Re: OM representation of ideals in function fields

[Nils Bruin]

I don't think this project resulted in many code commits directly (for one 
thing, no tickets are mentioned), but it did lead to a good evaluation of 
what infrastructure is necessary to support such implementations, and the 
situation for that has improved significantly. I think Magma has since 
grown quite extensive OM-representation: 
https://magma.maths.usyd.edu.au/magma/handbook/text/414 so if you need it 
quickly, that's probably the place to go. If you have resources and/or time 
available to implement it in sage, though, I'm sure it will be met with 
wide appreciation.

-- 
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/6905376f-c148-46fa-b780-c4c226f7a2a0n%40googlegroups.com.

[sage-devel] OM representation of ideals in function fields

[Maxime Bombar]

Hello everyone,

I would be very interested by the implementation of Montes algorithm and 
OM representation of prime ideals in global function fields claimed here 
: https://wiki.sagemath.org/days86.5


Do you know how far has it got ?

Best,

--
Maxime Bombar

--
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/58c26321-787c-8b1f-5c3d-297d9069abe2%40inria.fr.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [sage-devel] Adding LRS Library On SageMath

[Advay Goel]

Regarding the actual library itself, is that already on my system or will I 
have to download lrslib again? 
On Wednesday, December 29, 2021 at 6:58:49 AM UTC-5 dim...@gmail.com wrote:

> On Wed, Dec 29, 2021 at 5:12 AM Advay Goel  wrote:
> >
> > Hi All,
> >
> > I use macOS Big Sur Version 11.1, and need to use the LRS Library for a 
> project:
> >
> > def getVolume(self,eng='lrs'): """ needs Sage 5.9 for 'lrs' engine """ 
> return self.poly.volume(engine=eng)*factorial(self.poly.dim())
> >
> > Currently, whenever I run this function, I get 0, and I believe it is 
> because LRS Library is not properly installed on my system (I checked using 
> this code: link and it said LRS is not present). However, this doesn't make 
> much sense to me as there is an LRS folder in my sage folder. Its location 
> is Applications>SageMath>build>pkgs>lrslib.
> >
> > Regardless, I downloaded LRS again and am trying to build Sage from 
> source.
>
> it appears you are trying to do this using a binary distribution.
> Instead, you should be using a source distribution.
> https://doc.sagemath.org/html/en/installation/source.html
>
>
> > To do that, I am running the following code:
> >
> > make configure ./configure --enable-lrslib -q make -s V=0
> >
> > However, every time I do this, the "make V=0" line fails. Specifically, 
> the package
> > Scipy-1.6.3 fails to install. I attached the error message in the log 
> file to this email and here is the message I get on terminal:
> >
> > [scipy-1.6.3] installing. Log file: 
> /Applications/SageMath/logs/pkgs/scipy-1.6.3.log
> >
> > [scipy-1.6.3] error installing, exit status 1. End of log file:
> >
> > [scipy-1.6.3] Enabled : AVX512F AVX512CD AVX512_KNL AVX512_SKX 
> AVX512_CLX AVX512_CNL AVX512_ICL
> >
> > [scipy-1.6.3] Generated : none
> >
> > [scipy-1.6.3] CCompilerOpt._cache_write[796] : write cache to path -> 
> /private/var/folders/pv/fllpf5t54kx02fh87shrw79wvdtffs/T/pip-req-build-konopatv/build/temp.macosx-11.1-x86_64-3.9/ccompiler_opt_cache_clib.py
> >
> > [scipy-1.6.3] Building wheel for scipy (PEP 517): finished with status 
> 'error'
> >
> > [scipy-1.6.3] ERROR: Failed building wheel for scipy
> >
> > [scipy-1.6.3] Failed to build scipy
> >
> > [scipy-1.6.3] ERROR: Failed to build one or more wheels
> >
> > [scipy-1.6.3] Exception information:
> >
> > [scipy-1.6.3] Traceback (most recent call last):
> >
> > [scipy-1.6.3] File 
> "/Applications/SageMath/local/lib/python3.9/site-packages/pip/_internal/cli/base_command.py",
>  
> line 180, in _main
> >
> > [scipy-1.6.3] status = self.run(options, args)
> >
> > [scipy-1.6.3] File 
> "/Applications/SageMath/local/lib/python3.9/site-packages/pip/_internal/cli/req_command.py",
>  
> line 204, in wrapper
> >
> > [scipy-1.6.3] return func(self, options, args)
> >
> > [scipy-1.6.3] File 
> "/Applications/SageMath/local/lib/python3.9/site-packages/pip/_internal/commands/wheel.py",
>  
> line 174, in run
> >
> > [scipy-1.6.3] raise CommandError(
> >
> > [scipy-1.6.3] pip._internal.exceptions.CommandError: Failed to build one 
> or more wheels
> >
> > [scipy-1.6.3] Removed build tracker: 
> '/private/var/folders/pv/fllpf5t54kx02fh87shrw79wvdtffs/T/pip-req-tracker-my_qdfh8'
> >
> > [scipy-1.6.3] 
> 
> >
> > [scipy-1.6.3] Error building a wheel for scipy-1.6.3
> >
> > [scipy-1.6.3] 
> 
> >
> > [scipy-1.6.3]
> >
> > [scipy-1.6.3] real 4m19.931s
> >
> > [scipy-1.6.3] user 5m43.471s
> >
> > [scipy-1.6.3] sys 0m48.724s
> >
> > [scipy-1.6.3] 
> 
> >
> > [scipy-1.6.3] Error installing package scipy-1.6.3
> >
> > [scipy-1.6.3] 
> 
> >
> > [scipy-1.6.3] Full log file: 
> /Applications/SageMath/logs/pkgs/scipy-1.6.3.log
> >
> > make[4]: *** [scipy-SAGE_VENV-no-deps] Error 1
> >
> > make[3]: *** 
> [/Applications/SageMath/local/var/lib/sage/installed/scipy-1.6.3] Error 2
> >
> > make[2]: *** [all-start] Error 2
> >
> > real 4m46.343s
> >
> > user 5m56.467s
> >
> > sys 0m57.756s
> >
> > ***
> >
> > Error building Sage.
> >
> > The following package(s) may have failed to build (not necessarily
> >
> > during this run of 'make all-start'):
> >
> > * package: scipy-1.6.3
> >
> > last build time: Dec 28 21:25
> >
> > log file: /Applications/SageMath/logs/pkgs/scipy-1.6.3.log
> >
> > build directory: 
> /Applications/SageMath/local/var/tmp/sage/build/scipy-1.6.3
> >
> > It is safe to delete any log files and build directories, but they
> >
> > contain information that is helpful for debugging build problems.
> >
> > WARNING: If you now run 'make' again, the build directory of the
> >
> > same version of the package will, by default, be deleted. Set the
> >
> > environment variable SAGE_KEEP_BUILT

[sage-devel] Re: Demote SageTeX to an optional package?

[mmarco]

FWIW, we are working on a python package that partially overlaps sagetex 
functionality:

https://framagit.org/pang/texsurgery



El lunes, 6 de diciembre de 2021 a las 19:06:47 UTC+1, Matthias Koeppe 
escribió:

> -1 on demoting it from standard. It's tiny, and installing it as part of 
> the distribution is unproblematic. 
>
> -1 on adding a Sage-specific installation procedure for TeX. Actually, we 
> already have one but there is no good reason to use it other than possibly 
> as part of the binary distribution; https://trac.sagemath.org/ticket/31529 
> proposes to remove it.
>
> +1 on exploring and documenting alternatives that are not tied to Sage.
>
>
> On Monday, December 6, 2021 at 1:55:38 AM UTC-8 emanuel.c...@gmail.com 
> wrote:
>
>> Having a *standard* way to integrate Sage’s results in a document is 
>> **crucial*.
>>
>> So -1.
>>
>> Counter-proposal : add a pseudo-package à la tinytex 
>>  (which 
>> tests for a local TeX installation, and install a minimal TeX if necessary).
>>
>> Other possible alternatives : PythonTeX 
>>  (slightly more general, accepts 
>> more languages), codebraid  (a 
>> budding equivalent to PythonTeX using Markdown as a markup language). The 
>> latter may become important, Markdown turning out to be much more popular 
>> than LaTeX nowadays (notwithstanding its severe limitations).
>>
>> Possible addition : professionals mathematicians do not need a LaTeX 
>> introduction, but students and “engineering type” users might benefit from 
>> a “Presenting Sage work” section in our tutorials.
>> ​
>> Le lundi 6 décembre 2021 à 01:02:12 UTC+1, Michael Orlitzky a écrit :
>>
>>> SageTeX was added to sage as a standard package in 
>>>
>>> https://trac.sagemath.org/ticket/7617 
>>>
>>> It's closely tied to sage (can't be used on its own), but is also not 
>>> used by any other part of sage. 
>>>
>>> Can we demote it to an optional package? Realistically this amounts to 
>>> adding "first, run `make sagetex`" at the top of the docs that talk 
>>> about it (warning: requires translators). 
>>>
>>> The benefits are the usual ones: faster installation, less disk usage, 
>>> easier for distros to package a standard "sage". And the downside of 
>>> course is that anyone regularly using sagetex will have to either 
>>> ./configure --enable-sagetex, or run "make sagetex" at some point. 
>>>
>>>
>>>

-- 
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/4a77ffe2-8686-4be7-8d1a-fcebf01fdd6an%40googlegroups.com.

Re: [sage-devel] Adding LRS Library On SageMath

[Dima Pasechnik]

On Wed, Dec 29, 2021 at 5:12 AM Advay Goel  wrote:
>
> Hi All,
>
> I use macOS Big Sur Version 11.1, and need to use the LRS Library for a 
> project:
>
> def getVolume(self,eng='lrs'): """ needs Sage 5.9 for 'lrs' engine """ return 
> self.poly.volume(engine=eng)*factorial(self.poly.dim())
>
> Currently, whenever I run this function, I get 0, and I believe it is because 
> LRS Library is not properly installed on my system (I checked using this 
> code: link and it said LRS is not present). However, this doesn't make much 
> sense to me as there is an LRS folder in my sage folder. Its location is 
> Applications>SageMath>build>pkgs>lrslib.
>
> Regardless, I downloaded LRS again and am trying to build Sage from source.

it appears you are trying to do this using a binary distribution.
Instead, you should be using a source distribution.
https://doc.sagemath.org/html/en/installation/source.html


> To do that, I am running the following code:
>
> make configure ./configure --enable-lrslib -q make -s V=0
>
> However, every time I do this, the "make V=0" line fails. Specifically, the 
> package
> Scipy-1.6.3 fails to install. I attached the error message in the log file to 
> this email and here is the message I get on terminal:
>
> [scipy-1.6.3] installing. Log file: 
> /Applications/SageMath/logs/pkgs/scipy-1.6.3.log
>
>   [scipy-1.6.3] error installing, exit status 1. End of log file:
>
>   [scipy-1.6.3]   Enabled : AVX512F AVX512CD AVX512_KNL AVX512_SKX 
> AVX512_CLX AVX512_CNL AVX512_ICL
>
>   [scipy-1.6.3]   Generated   : none
>
>   [scipy-1.6.3] CCompilerOpt._cache_write[796] : write cache to path -> 
> /private/var/folders/pv/fllpf5t54kx02fh87shrw79wvdtffs/T/pip-req-build-konopatv/build/temp.macosx-11.1-x86_64-3.9/ccompiler_opt_cache_clib.py
>
>   [scipy-1.6.3] Building wheel for scipy (PEP 517): finished with status 
> 'error'
>
>   [scipy-1.6.3] ERROR: Failed building wheel for scipy
>
>   [scipy-1.6.3]   Failed to build scipy
>
>   [scipy-1.6.3]   ERROR: Failed to build one or more wheels
>
>   [scipy-1.6.3]   Exception information:
>
>   [scipy-1.6.3]   Traceback (most recent call last):
>
>   [scipy-1.6.3] File 
> "/Applications/SageMath/local/lib/python3.9/site-packages/pip/_internal/cli/base_command.py",
>  line 180, in _main
>
>   [scipy-1.6.3]   status = self.run(options, args)
>
>   [scipy-1.6.3] File 
> "/Applications/SageMath/local/lib/python3.9/site-packages/pip/_internal/cli/req_command.py",
>  line 204, in wrapper
>
>   [scipy-1.6.3]   return func(self, options, args)
>
>   [scipy-1.6.3] File 
> "/Applications/SageMath/local/lib/python3.9/site-packages/pip/_internal/commands/wheel.py",
>  line 174, in run
>
>   [scipy-1.6.3]   raise CommandError(
>
>   [scipy-1.6.3]   pip._internal.exceptions.CommandError: Failed to build one 
> or more wheels
>
>   [scipy-1.6.3]   Removed build tracker: 
> '/private/var/folders/pv/fllpf5t54kx02fh87shrw79wvdtffs/T/pip-req-tracker-my_qdfh8'
>
>   [scipy-1.6.3]   
> 
>
>   [scipy-1.6.3]   Error building a wheel for scipy-1.6.3
>
>   [scipy-1.6.3]   
> 
>
>   [scipy-1.6.3]
>
>   [scipy-1.6.3]   real 4m19.931s
>
>   [scipy-1.6.3]   user 5m43.471s
>
>   [scipy-1.6.3]   sys 0m48.724s
>
>   [scipy-1.6.3]   
> 
>
>   [scipy-1.6.3]   Error installing package scipy-1.6.3
>
>   [scipy-1.6.3]   
> 
>
>   [scipy-1.6.3] Full log file: 
> /Applications/SageMath/logs/pkgs/scipy-1.6.3.log
>
> make[4]: *** [scipy-SAGE_VENV-no-deps] Error 1
>
> make[3]: *** 
> [/Applications/SageMath/local/var/lib/sage/installed/scipy-1.6.3] Error 2
>
> make[2]: *** [all-start] Error 2
>
> real 4m46.343s
>
> user 5m56.467s
>
> sys 0m57.756s
>
> ***
>
> Error building Sage.
>
> The following package(s) may have failed to build (not necessarily
>
> during this run of 'make all-start'):
>
> * package: scipy-1.6.3
>
>   last build time: Dec 28 21:25
>
>   log file:/Applications/SageMath/logs/pkgs/scipy-1.6.3.log
>
>   build directory: /Applications/SageMath/local/var/tmp/sage/build/scipy-1.6.3
>
> It is safe to delete any log files and build directories, but they
>
> contain information that is helpful for debugging build problems.
>
> WARNING: If you now run 'make' again, the build directory of the
>
> same version of the package will, by default, be deleted. Set the
>
> environment variable SAGE_KEEP_BUILT_SPKGS=yes to prevent this.
>
> make[1]: *** [all-start] Error 1
>
> make: *** [all] Error 2
>
> Does anybody know how to fix this so that I can properly use the LRS engine? 
> Also, after downloading the lrslib file again, is there a specific place I am 
> supposed to p