Re: [sage-devel] Error building the documentation with 8.8.beta5

2019-05-13 Thread François Bissey
It looks like you are using tachyon instead of jmol for rendering some 
3D plots. I think that's what is causing the issues. Your jmol install 
may be broken and tachyon is used as the fallback.


Francois

On 14/05/19 4:22 am, David Coudert wrote:
I already had issues building the doc with 8.8.beta4, so after upgrading 
to 8.8.beta5, I did make doc-clean but it's not enough.


Attached is the log file.

I have not tried a dist-clean, and I hope I can avoid it...

Best,
David.

--
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.com 
.

Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8c8d0f24-77cc-4d1f-99b0-59b4a53b2779%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/40b2bc32-9705-2df5-3982-788c6f109862%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: output form of limits is misleading

2019-05-13 Thread Gregory Grunberg
Hi Emmanuel,

Thank you for your reply.  Given the preliminary declarations

> *x = var("x")*

*h(x) = (x^2 + x + 2)/(x - 4)*,

I've discovered that

*limit(**h**, x=4, dir="right")*

gives the confusing answer

 *x |--> +Infinity* ,

but that by replacing *h* by *h(x)* one obtains the desired answer

*+Infinity*  .

Put differently, the command I want should be written

*limit(**h(x)**, x=4, dir="right")*.

My confusion was caused in part by the S.D.S.U. SageMath Tutorial, but I
was also misled in part by two different styles for writing limits in the
mathematical literature.

Greg Grunberg

>
On Mon, May 13, 2019 at 4:47 AM Emmanuel Charpentier <
emanuel.charpent...@gmail.com> wrote:

> Let's see :
> sage: h(x)=(x^2+x+2)/(x-4)
> sage: h.parent()
> Callable function ring with argument x
> sage: limit(h,x=4,dir="right").parent()
> Callable function ring with argument x
> sage: h(x).parent()
> Symbolic Ring
> sage: limit(h(x),x=4,dir="right").parent()
> Symbolic Ring
> sage: limit(h(x),x=4,dir="right")
> +Infinity
>
> Is that clearer ?
>
> HTH,
>
>
> Le lundi 13 mai 2019 09:39:57 UTC+2, Greg1950 a écrit :
>>
>> I am using SageMath version 8.7, Release Date 2019-03-23, within a
>> Jupyter notebook.  My operating system is Windows 10.
>>
>> I know some elementary Python programming, but am certainly not an
>> expert.  I am essentially a newbie to SageMath.
>>
>> I defined, as per the S.D.S.U. Sage Tutorial, a function
>>
>> h(x) = (x^2 + x - 2)/(x - 4)
>>>
>>
>> Upon asking SageMath 8.7 to compute
>>
>> limit(h, x = 4, dir="right")
>>>
>>
>> I received as answer
>>
>> x |--> Infinity
>>>
>>
>> While the value of the (right-hand) limit is indeed Infinity, the " x
>> |--> " which precedes it in the "Out" cell suggests that the *argument* x
>> of the function h is approaching Infinity, while in fact it is the
>> *value* h(x) of the function which is doing so.  The argument x itself
>> is approaching 4 from the right.
>>
>> So the *form* of the answer is misleading.  It would be better if the
>> answer appeared simply as
>>
>> Infinity
>>>
>>
>> The answers to other limit calculations appear similarly to the above
>> example and may be similarly criticized.
>>
> --
> 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.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/f5c765f9-ffab-4b4b-895c-ecb5453b431b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CA%2BmSTPhvzSpBLb3%2BH51_j_Y_nDBJkrTfJ%3DNzH4ESHvuk%3DWJO%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Dependence of libgd on iconv

2019-05-13 Thread E. Madison Bray
On Mon, May 13, 2019 at 5:43 PM Michael Orlitzky  wrote:
>
> On 5/13/19 10:04 AM, Dima Pasechnik wrote:
> >
> > We should get an spkg-configure.m4 for libgd, it's really silly to
> > build it everywhere...
> > (I guess that's what Michael is working on :-))
> >
>
> I looked at libgd and saw that we have in-progress tickets for its other
> two dependencies, freetype and libpng, but not for iconv. So I began
> looking at iconv, which is going to be a pain in the ass, because there
> are a few different implementations that need to be detected in
> different ways. For example, we probably have to reproduce all of R's
> iconv feature detection to ensure that we get a satisfactory copy.

Hmm, thank you for pointing that out.  It doesn't look too bad and not
*all* of it needs to be reproduced, but some of it yes.

The tricky thing about iconv is that sometimes it's built into libc
and sometimes it's a separate library that needs to be linked with
-liconv.  And furthermore, (especially in the former case) sometimes
iconv is a macro, and sometimes it's a function.

There's actually a standard AM_ICONV that apparently handles all these
cases: https://www.gnu.org/software/gettext/manual/html_node/AM_005fICONV.html
 In fact, looking at the /usr/share/aclocal/iconv.m4 on my system, it
looks like R borrowed its check from this.

The other thing R checks which is more specific to R is that it
requires iconv to support (as most any will these days) UTF-8, ASCII,
latin-1, and UCS-* encodings.  I think we could probably safely just
assume that for any platforms Sage supports, but if you want to be
extra sure I could easily replicate that check as well.

> As a lazy person, that immediately lead me to ask the question: could I
> just... ignore iconv... and work on libgd anyway? The iconv detection in
> libgd is automagic, so we would have to force-disable the iconv support
> somehow, but I don't think libgd would be any worse for it.

Sure! As far as implementing an spkg-configure.m4, at least initially,
it doesn't look like there needs to be a deep interaction here.  If we
do find something later we can add it on.

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAOTD34ZrgYOiOCie_-EeEzXYMkb%3D5jOR%3DWsgM1xQUYz4BozDBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Error building the documentation with 8.8.beta5

2019-05-13 Thread David Coudert
I already had issues building the doc with 8.8.beta4, so after upgrading to 
8.8.beta5, I did make doc-clean but it's not enough.

Attached is the log file.

I have not tried a dist-clean, and I hope I can avoid it...

Best,
David.

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8c8d0f24-77cc-4d1f-99b0-59b4a53b2779%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Building reference manual, first pass.

[manifolds] chargement de l'environnement sérialisé...fait
[manifolds] building [inventory]: targets for 63 source files that are out of 
date
[manifolds] updating environment: 63 added, 0 changed, 0 removed
[manifolds] 
/Users/dcoudert/sage/src/sage_setup/docbuild/ext/sage_autodoc.py:1170: 
RemovedInSphinx20Warning: formatargspec() is now deprecated.  Please use 
sphinx.util.inspect.Signature instead.
[manifolds]   return formatargspec(initmeth, *argspec)
[manifolds] 
/Users/dcoudert/sage/src/sage_setup/docbuild/ext/sage_autodoc.py:1406: 
RemovedInSphinx20Warning: formatargspec() is now deprecated.  Please use 
sphinx.util.inspect.Signature instead.
[manifolds]   args = formatargspec(self.object, *argspec)
[manifolds] 
/Users/dcoudert/sage/src/sage_setup/docbuild/ext/sage_autodoc.py:1072: 
RemovedInSphinx20Warning: formatargspec() is now deprecated.  Please use 
sphinx.util.inspect.Signature instead.
[manifolds]   args = formatargspec(self.object, *argspec)
[manifolds] 
/Users/dcoudert/sage/local/lib/python2.7/site-packages/sage/manifolds/differentiable/integrated_curve.py:docstring
 of 
sage.manifolds.differentiable.integrated_curve.IntegratedAutoparallelCurve:309: 
WARNING: Exception occurred in plotting integrated_curve-3
[manifolds]  from 
/Users/dcoudert/sage/src/doc/en/reference/manifolds/sage/manifolds/differentiable/integrated_curve.rst:
[manifolds] Traceback (most recent call last):
[manifolds]   File 
"/Users/dcoudert/sage/local/lib/python2.7/site-packages/matplotlib/sphinxext/plot_directive.py",
 line 524, in run_code
[manifolds] six.exec_(code, ns)
[manifolds]   File 
"/Users/dcoudert/sage/local/lib/python2.7/site-packages/six.py", line 709, in 
exec_
[manifolds] exec("""exec _code_ in _globs_, _locs_""")
[manifolds]   File "", line 1, in 
[manifolds]   File "", line 34, in 
[manifolds]   File "", line 68, in sphinx_plot
[manifolds]   File "sage/plot/plot3d/base.pyx", line 1621, in 
sage.plot.plot3d.base.Graphics3d.save 
(build/cythonized/sage/plot/plot3d/base.c:20977)
[manifolds] self.save_image(filename, **kwds)
[manifolds]   File "sage/plot/plot3d/base.pyx", line 1550, in 
sage.plot.plot3d.base.Graphics3d.save_image 
(build/cythonized/sage/plot/plot3d/base.c:20535)
[manifolds] self._save_image_png(filename, **kwds)
[manifolds]   File "sage/plot/plot3d/base.pyx", line 1512, in 
sage.plot.plot3d.base.Graphics3d._save_image_png 
(build/cythonized/sage/plot/plot3d/base.c:20172)
[manifolds] scene = self._rich_repr_jmol(**opts)
[manifolds]   File "sage/plot/plot3d/base.pyx", line 264, in 
sage.plot.plot3d.base.Graphics3d._rich_repr_jmol 
(build/cythonized/sage/plot/plot3d/base.c:7182)
[manifolds] tachyon = self._rich_repr_tachyon(OutputImagePng, **opts)
[manifolds]   File "sage/plot/plot3d/base.pyx", line 208, in 
sage.plot.plot3d.base.Graphics3d._rich_repr_tachyon 
(build/cythonized/sage/plot/plot3d/base.c:6180)
[manifolds] tachyon_rt(T.tachyon(), filename, opts['verbosity'],
[manifolds]   File 
"/Users/dcoudert/sage/local/lib/python2.7/site-packages/sage/interfaces/tachyon.py",
 line 162, in __call__
[manifolds] raise RuntimeError(out)
[manifolds] RuntimeError: Tachyon Parallel/Multiprocessor Ray Tracer   Version 
0.98.9
[manifolds] Copyright 1994-2010,John E. Stone 
[manifolds] 
[manifolds] Parse Error:
[manifolds]Encountered a syntax error in file 
/Users/dcoudert/.sage/temp/confetti.inria.fr/82937/tmp_feQXWm.dat
[manifolds]Expected to find V1
[manifolds]Actually found: ,61208
[manifolds]Error occured at or prior to file offset 11659, line 368
[manifolds]Error position is only approximate, but should be close
[manifolds] Parse Error:
[manifolds]Encountered a syntax error in file 
/Users/dcoudert/.sage/temp/confetti.inria.fr/82937/tmp_feQXWm.dat
[manifolds]Expected to find V2
[manifolds]Actually found: ,412589
[manifolds]Error occured at or prior to file offset 11669, line 368
[manifolds]Error position is only approximate, but should be close
[manifolds] Undefined texture ',716998', using default.
[manifolds] Parser failed due to an input file 

[sage-devel] Re: Conversions to/from other symbolics packages

2019-05-13 Thread Nils Bruin
On Monday, May 13, 2019 at 7:46:26 AM UTC-7, Emmanuel Charpentier wrote:
>
> So a systematic revision might be better than a raft of isolated tickets. 
> This might also be used to treat the case of different expressions in 
> different systems of the tsame mathematuic being. Case in point : 
> Mathematica has a few special cases for hypergeometric functions added to 
> the generic case, whereas Sage has only one generic function ; creating the 
> special-case functions would allow back-conversion to Sage of Mathematica 
> results using them.
>
> Advice ? Hints ?
>
> What do you mean by "systematic"? It seems to me that you'll basically be 
checking if a translation dictionary is complete,  correct, and consistent 
(with the dictionary in the opposite direction). The consistency test lends 
itself to automation, but the completeness and correctness just requires a 
human to know/read the language specs and check the dictionary that sage 
uses.

It could be that the dictionary only exists in distributed form for the 
sage-to-other_system translation (as attributes on objects), but the 
translation from other_system to sage must exist as an actual lookup table. 
So perhaps start with reading that and use it to look up the objects that 
store the sage-to-other_system translations.

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f448b061-99a5-4baa-9fbe-d505ad986fce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Dependence of libgd on iconv

2019-05-13 Thread Dima Pasechnik
On Mon, May 13, 2019 at 4:43 PM Michael Orlitzky  wrote:
>
> On 5/13/19 10:04 AM, Dima Pasechnik wrote:
> >
> > We should get an spkg-configure.m4 for libgd, it's really silly to
> > build it everywhere...
> > (I guess that's what Michael is working on :-))
> >
>
> I looked at libgd and saw that we have in-progress tickets for its other
> two dependencies, freetype and libpng, but not for iconv. So I began
> looking at iconv, which is going to be a pain in the ass, because there
> are a few different implementations that need to be detected in
> different ways. For example, we probably have to reproduce all of R's
> iconv feature detection to ensure that we get a satisfactory copy.
>
> As a lazy person, that immediately lead me to ask the question: could I
> just... ignore iconv... and work on libgd anyway? The iconv detection in
> libgd is automagic, so we would have to force-disable the iconv support
> somehow, but I don't think libgd would be any worse for it.

I certainly would try just going for a iconv-less system libgd support
and see if it works.
Libgd is only used in sagelib...


>
> --
> 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.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/164f81c6-87e3-67c9-1d3a-b3b146b5da11%40orlitzky.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq27F-z6GTzP%2B%3DTqS%3Dk0JTYrTJjtzHHqXFvW2kG3notNpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Dependence of libgd on iconv

2019-05-13 Thread Michael Orlitzky
On 5/13/19 10:04 AM, Dima Pasechnik wrote:
>
> We should get an spkg-configure.m4 for libgd, it's really silly to
> build it everywhere...
> (I guess that's what Michael is working on :-))
> 

I looked at libgd and saw that we have in-progress tickets for its other
two dependencies, freetype and libpng, but not for iconv. So I began
looking at iconv, which is going to be a pain in the ass, because there
are a few different implementations that need to be detected in
different ways. For example, we probably have to reproduce all of R's
iconv feature detection to ensure that we get a satisfactory copy.

As a lazy person, that immediately lead me to ask the question: could I
just... ignore iconv... and work on libgd anyway? The iconv detection in
libgd is automagic, so we would have to force-disable the iconv support
somehow, but I don't think libgd would be any worse for it.

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/164f81c6-87e3-67c9-1d3a-b3b146b5da11%40orlitzky.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Dependence of libgd on iconv

2019-05-13 Thread E. Madison Bray
On Mon, May 13, 2019 at 3:53 PM Dima Pasechnik  wrote:
>
> iconv is only installed on Cygwin anyway (apart from surely dead HP
> port, and fallen behind Solaris port,
> which probably no longer needs it anyway).
> So this is a red herring one way or another.

Wow, I haven't worried too much about iconv up to this point as it's a
rather small library and quick to build.

But indeed it's only even installed on Cygwin, HP-UX, and Solaris.
And I strongly doubt it's needed for Cygwin anymore (if it ever was).
Iconv comes standard in Cygwin installations, and the version is
likely quite a bit more recent than 9 years ago when it was first
added as a package for Sage.

I'll also see about adding an spkg-configure.m4 for iconv.  We can
keep the package for now for HP-UX and Solaris in case anyone wants to
pick up work on those ports again.

As for removing it from the list of dependencies for libgd I'm not
sure enough to give a confident answer.

> On Mon, May 13, 2019 at 2:51 PM Michael Orlitzky  wrote:
> >
> > Our libgd package depends on iconv:
> >
> >   $ cat build/pkgs/libgd/dependencies
> >   libpng freetype iconv
> >   ...
> >
> > Does anyone remember why? It's possible to build libgd without iconv as
> > far as I can tell (check CMakeLists.txt), and the only consequence I see
> > is that some functions in libgd's src/gdkanji.c get defined out.

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAOTD34YkEWRvRxa2OOVjNn00DpNRp0QXbtQv_1q5Xrp3TQmjOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Conversions to/from other symbolics packages

2019-05-13 Thread Emmanuel Charpentier
[ Long story: see this ask.sagemath.org question 
, which 
already generated Trac#27816  ].

Consider :

x,y,r0,r1,t=var("x,y,r0,r1,t", domain="real")
assume(r0>0, r1>0, r1<=2*r0)
E0=x^2+y^2==r0^2
E1=(r0-x)^2+y^2==r1^2
with assuming(y>0): foo=E0.solve(y, solution_dict=True)[0].get(y)
Y0(x)=foo
with assuming(y>0): foo=E1.solve(y, solution_dict=True)[0].get(y)
Y1(x)=foo
X=(Y0(x)^2==Y1(x)^2).solve(x, solution_dict=True)[0].get(x)

This works uneventfully. The problem begins with:

sage: foo=integrate(2*Y1(t), t, r0-r1, X, algorithm="giac")
sage: foo.subs([r0==10,r1==10])
100/3*pi*sign(10) - 25*sqrt(3)
sage: foo.subs([r0==10,r1==10]).n()
---
TypeError Traceback (most recent call last)
 in ()
> 1 foo.subs([r0==Integer(10),r1==Integer(10)]).n()

/usr/local/sage-8/local/lib/python2.7/site-packages/sage/structure/element.pyx 
in sage.structure.element.Element.n 
(build/cythonized/sage/structure/element.c:8009)()
859 0.667
860 """
--> 861 return self.numerical_approx(prec, digits, algorithm)
862 
863 def _mpmath_(self, prec=53, rounding=None):

/usr/local/sage-8/local/lib/python2.7/site-packages/sage/symbolic/expression.pyx
 
in sage.symbolic.expression.Expression.numerical_approx 
(build/cythonized/sage/symbolic/expression.cpp:33967)()
   5949 res = x.pyobject()
   5950 else:
-> 5951 raise TypeError("cannot evaluate symbolic expression 
numerically")
   5952 
   5953 # Important -- the  we get might not be a valid output for 
numerical_approx in

TypeError: cannot evaluate symbolic expression numerically

Huh ?

Working my way through the expression, I come up with :

sage: foo.operands()[0].operands()
[pi, r1^2, sign(r1), 1/2]
sage: foo.operands()[0].operands()[2].operator()
sign
sage: foo.operands()[0].operands()[2].operator().parent()

sage: sign.parent()


And, by the way :

sage: sign(r1).subs(r1==10)
1

It seems that the back-conversion from giac to age was unable to fing 
Sage's signe, and created a new symbolic function with the exact same name. 
This seems awfully close to the already fixed (but recent) Trac#27577 
.

By the way, the problem might cause serious and permanent problems :

sage: SR(str(foo.operands()[0].subs(r1=10))).n()
---
TypeError Traceback (most recent call last)
 in ()
> 1 SR(str(foo.operands()[Integer(0)].subs(r1=Integer(10.n()

/usr/local/sage-8/local/lib/python2.7/site-packages/sage/structure/element.pyx 
in sage.structure.element.Element.n 
(build/cythonized/sage/structure/element.c:8009)()
859 0.667
860 """
--> 861 return self.numerical_approx(prec, digits, algorithm)
862 
863 def _mpmath_(self, prec=53, rounding=None):

/usr/local/sage-8/local/lib/python2.7/site-packages/sage/symbolic/expression.pyx
 
in sage.symbolic.expression.Expression.numerical_approx 
(build/cythonized/sage/symbolic/expression.cpp:33967)()
   5949 res = x.pyobject()
   5950 else:
-> 5951 raise TypeError("cannot evaluate symbolic expression 
numerically")
   5952 
   5953 # Important -- the  we get might not be a valid output for 
numerical_approx in

TypeError: cannot evaluate symbolic expression numerically

I can, of course, open a ticket for this and fix it, but I begin to wonder 
if it would not be beneficial to revise all (symbolic) functions for 
convertibility to other symbolic systems. In fact, I have another example 
on hand :

sage: mathematica.D(arctan(x),x)
Derivative[1][Arctan][x]
sage: mathematica("D[ArcTan[x],x]")
(1 + x^2)^(-1)

So a systematic revision might be better than a raft of isolated tickets. 
This might also be used to treat the case of different expressions in 
different systems of the tsame mathematuic being. Case in point : 
Mathematica has a few special cases for hypergeometric functions added to 
the generic case, whereas Sage has only one generic function ; creating the 
special-case functions would allow back-conversion to Sage of Mathematica 
results using them.

Advice ? Hints ?

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e8ead156-0657-4ab8-a6c9-00d605c5a618%40googlegroups.com.
For more options, visit 

Re: [sage-devel] Dependence of libgd on iconv

2019-05-13 Thread Jeroen Demeyer

On 2019-05-13 16:04, Dima Pasechnik wrote:

as Debian does not have iconv in libgd, I assume it's safe to remove
the dependence.


If that's possible, sure.

--
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5CD97BAB.2050906%40UGent.be.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: MacOS 10.14 compiling Sage GSL error

2019-05-13 Thread Markéta Sluková
It was my PATH that was causing issues. I fixed it and now it built 
successfully. Thank you for your help!

On Thursday, 9 May 2019 16:57:13 UTC+2, Markéta Sluková wrote:
>
> Hi,
>
> I have been trying to compile Sage from source code on my Macbook with 
> macOS 10.14.3. However, I get the error  'Error installing package 
> gsl-2.5' I have HomeBrew installed. I have attached the log file as per 
> the error message. Could anyone please help me with fixing this?
>
> Many thanks,
> Marketa
>

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/de178855-6b8e-48e4-b7ce-9e98c93a80f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Dependence of libgd on iconv

2019-05-13 Thread Dima Pasechnik
On Mon, May 13, 2019 at 2:53 PM Jeroen Demeyer  wrote:
>
> On 2019-05-13 15:51, Michael Orlitzky wrote:
> > It's possible to build libgd without iconv as
> > far as I can tell (check CMakeLists.txt)
>
> A dependency is not the same as a requirement. If it's used by the
> package (optional or not), it's almost certainly a dependency.

as Debian does not have iconv in libgd, I assume it's safe to remove
the dependence.
We should get an spkg-configure.m4 for libgd, it's really silly to
build it everywhere...
(I guess that's what Michael is working on :-))

>
> --
> 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.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/5CD976F5.30203%40UGent.be.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0O%2B%3Dh8czF3xce64fXwyScjTn6hxJ1W2rZLYxy4Mgbu1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Dependence of libgd on iconv

2019-05-13 Thread Jeroen Demeyer

On 2019-05-13 15:51, Michael Orlitzky wrote:

It's possible to build libgd without iconv as
far as I can tell (check CMakeLists.txt)


A dependency is not the same as a requirement. If it's used by the 
package (optional or not), it's almost certainly a dependency.


--
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5CD976F5.30203%40UGent.be.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Dependence of libgd on iconv

2019-05-13 Thread Dima Pasechnik
iconv is only installed on Cygwin anyway (apart from surely dead HP
port, and fallen behind Solaris port,
which probably no longer needs it anyway).
So this is a red herring one way or another.

On Mon, May 13, 2019 at 2:51 PM Michael Orlitzky  wrote:
>
> Our libgd package depends on iconv:
>
>   $ cat build/pkgs/libgd/dependencies
>   libpng freetype iconv
>   ...
>
> Does anyone remember why? It's possible to build libgd without iconv as
> far as I can tell (check CMakeLists.txt), and the only consequence I see
> is that some functions in libgd's src/gdkanji.c get defined out.
>
> --
> 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.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/47a2d396-cbff-b4a1-7f1d-f8f83c2d66e6%40orlitzky.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3Re__VmJe7PrmPdf0OVQymKG1qDBUr70LVcZPUdnOUSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Dependence of libgd on iconv

2019-05-13 Thread Michael Orlitzky
Our libgd package depends on iconv:

  $ cat build/pkgs/libgd/dependencies
  libpng freetype iconv
  ...

Does anyone remember why? It's possible to build libgd without iconv as
far as I can tell (check CMakeLists.txt), and the only consequence I see
is that some functions in libgd's src/gdkanji.c get defined out.

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/47a2d396-cbff-b4a1-7f1d-f8f83c2d66e6%40orlitzky.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Question : what are the patchbots suppoed to di when testing a new upstream package ?

2019-05-13 Thread Dima Pasechnik
On Mon, May 13, 2019 at 1:59 PM E. Madison Bray  wrote:
>
> On Mon, May 13, 2019 at 12:24 PM Emmanuel Charpentier
>  wrote:
> >
> > Dear list,
> >
> > I wondered why no one had judged useful to review Trac#27738. I checked the 
> > result of the (numerous) patchbot tests and wondered why ALL of their 
> > shortlogs ended in :
> >
> > tar xf /tmp/tmpjvmgze9t/R-3.6.0.tar.gz -C /tmp/tmpjvmgze9t
> > > Successfully unpacked
> > Sha1 of R-3.6.0.tar.gz is c8a1949e763d22ec3b1dbdd251afcb0f1d2d5c76
> > Traceback (most recent call last):
> >   File 
> > "/home/sage-patchbot/.local/lib/python3.5/site-packages/sage_patchbot/patchbot.py",
> >  line 1082, in test_a_ticket
> > self.check_spkg(spkg)
> >   File 
> > "/home/sage-patchbot/.local/lib/python3.5/site-packages/sage_patchbot/patchbot.py",
> >  line 1311, in check_spkg
> > given_sha = open(path).read().splitlines()[1].split('=')[1]
> > FileNotFoundError: [Errno 2] No such file or directory: 
> > '/home/sage-patchbot/sage/build/pkgs/R/checksums.ini'
> > https://cran.r-project.org/src/base/R-3/R-3.6.0.tar.gz -- 1 seconds
> > Apply -- 5 seconds
> > https://cran.r-project.org/src/base/R-3/R-3.6.0.tar.gz -- 1 seconds
> > 2019-05-12 09:47:16
> > 6 seconds
> >
> >
> >  (modulo the dates and temp directories' names). Is that supposed to happen 
> > ?
>
> Apparently there is some kind of bug/confusion somewhere because in
> '/home/sage-patchbot/sage/build/pkgs/R/checksums.ini' it should be 'r'

the tarball name starts from 'R', the package name starts from 'r'.

> not 'R'.
>
> --
> 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.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAOTD34ZzT7GUE%2BHGALM3Mu-F94mQ5h%2B5qtCMf1J%3D%2BsNAzv8NFg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3PsrG7cLVzK%3Dy%2BAZzD_7tOVhQ8Ph6srB9ZAEdirQiYmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Question : what are the patchbots suppoed to di when testing a new upstream package ?

2019-05-13 Thread E. Madison Bray
On Mon, May 13, 2019 at 12:24 PM Emmanuel Charpentier
 wrote:
>
> Dear list,
>
> I wondered why no one had judged useful to review Trac#27738. I checked the 
> result of the (numerous) patchbot tests and wondered why ALL of their 
> shortlogs ended in :
>
> tar xf /tmp/tmpjvmgze9t/R-3.6.0.tar.gz -C /tmp/tmpjvmgze9t
> > Successfully unpacked
> Sha1 of R-3.6.0.tar.gz is c8a1949e763d22ec3b1dbdd251afcb0f1d2d5c76
> Traceback (most recent call last):
>   File 
> "/home/sage-patchbot/.local/lib/python3.5/site-packages/sage_patchbot/patchbot.py",
>  line 1082, in test_a_ticket
> self.check_spkg(spkg)
>   File 
> "/home/sage-patchbot/.local/lib/python3.5/site-packages/sage_patchbot/patchbot.py",
>  line 1311, in check_spkg
> given_sha = open(path).read().splitlines()[1].split('=')[1]
> FileNotFoundError: [Errno 2] No such file or directory: 
> '/home/sage-patchbot/sage/build/pkgs/R/checksums.ini'
> https://cran.r-project.org/src/base/R-3/R-3.6.0.tar.gz -- 1 seconds
> Apply -- 5 seconds
> https://cran.r-project.org/src/base/R-3/R-3.6.0.tar.gz -- 1 seconds
> 2019-05-12 09:47:16
> 6 seconds
>
>
>  (modulo the dates and temp directories' names). Is that supposed to happen ?

Apparently there is some kind of bug/confusion somewhere because in
'/home/sage-patchbot/sage/build/pkgs/R/checksums.ini' it should be 'r'
not 'R'.

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAOTD34ZzT7GUE%2BHGALM3Mu-F94mQ5h%2B5qtCMf1J%3D%2BsNAzv8NFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Question : what are the patchbots suppoed to di when testing a new upstream package ?

2019-05-13 Thread Emmanuel Charpentier
Dear list,

I wondered why no one had judged useful to review Trac#27738 
. I checked the result of the 
(numerous) patchbot tests and wondered why ALL of their shortlogs ended in :

tar xf /tmp/tmpjvmgze9t/R-3.6.0.tar.gz -C /tmp/tmpjvmgze9t
> Successfully unpacked
Sha1 of R-3.6.0.tar.gz is c8a1949e763d22ec3b1dbdd251afcb0f1d2d5c76
Traceback (most recent call last):
  File 
"/home/sage-patchbot/.local/lib/python3.5/site-packages/sage_patchbot/patchbot.py",
 line 1082, in test_a_ticket
self.check_spkg(spkg)
  File 
"/home/sage-patchbot/.local/lib/python3.5/site-packages/sage_patchbot/patchbot.py",
 line 1311, in check_spkg
given_sha = open(path).read().splitlines()[1].split('=')[1]
FileNotFoundError: [Errno 2] No such file or directory: 
'/home/sage-patchbot/sage/build/pkgs/R/checksums.ini'
https://cran.r-project.org/src/base/R-3/R-3.6.0.tar.gz -- 1 seconds
Apply -- 5 seconds
https://cran.r-project.org/src/base/R-3/R-3.6.0.tar.gz -- 1 seconds
2019-05-12 09:47:16
6 seconds


 (modulo the dates and temp directories' names). Is that supposed to happen ?


-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/fde1d65d-8c07-44fb-ba8a-cf493649ff29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Re: output form of limits is misleading

2019-05-13 Thread Emmanuel Charpentier
Let's see :
sage: h(x)=(x^2+x+2)/(x-4)
sage: h.parent()
Callable function ring with argument x
sage: limit(h,x=4,dir="right").parent()
Callable function ring with argument x
sage: h(x).parent()
Symbolic Ring
sage: limit(h(x),x=4,dir="right").parent()
Symbolic Ring
sage: limit(h(x),x=4,dir="right")
+Infinity

Is that clearer ?

HTH,


Le lundi 13 mai 2019 09:39:57 UTC+2, Greg1950 a écrit :
>
> I am using SageMath version 8.7, Release Date 2019-03-23, within a Jupyter 
> notebook.  My operating system is Windows 10.
>
> I know some elementary Python programming, but am certainly not an 
> expert.  I am essentially a newbie to SageMath. 
>
> I defined, as per the S.D.S.U. Sage Tutorial, a function
>
> h(x) = (x^2 + x - 2)/(x - 4)
>>
>
> Upon asking SageMath 8.7 to compute
>
> limit(h, x = 4, dir="right")
>>
>
> I received as answer
>
> x |--> Infinity
>>
>
> While the value of the (right-hand) limit is indeed Infinity, the " x |--> " 
> which precedes it in the "Out" cell suggests that the *argument* x of the 
> function h is approaching Infinity, while in fact it is the *value* h(x) 
> of the function which is doing so.  The argument x itself is approaching 4 
> from the right.
>
> So the *form* of the answer is misleading.  It would be better if the 
> answer appeared simply as
>
> Infinity
>>
>
> The answers to other limit calculations appear similarly to the above 
> example and may be similarly criticized. 
>

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f5c765f9-ffab-4b4b-895c-ecb5453b431b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] output form of limits is misleading

2019-05-13 Thread Greg1950
I am using SageMath version 8.7, Release Date 2019-03-23, within a Jupyter 
notebook.  My operating system is Windows 10.

I know some elementary Python programming, but am certainly not an expert.  
I am essentially a newbie to SageMath. 

I defined, as per the S.D.S.U. Sage Tutorial, a function

h(x) = (x^2 + x - 2)/(x - 4)
>

Upon asking SageMath 8.7 to compute

limit(h, x = 4, dir="right")
>

I received as answer

x |--> Infinity
>

While the value of the (right-hand) limit is indeed Infinity, the " x |--> " 
which precedes it in the "Out" cell suggests that the *argument* x of the 
function h is approaching Infinity, while in fact it is the *value* h(x) of 
the function which is doing so.  The argument x itself is approaching 4 
from the right.

So the *form* of the answer is misleading.  It would be better if the 
answer appeared simply as

Infinity
>

The answers to other limit calculations appear similarly to the above 
example and may be similarly criticized. 

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/56971e41-6edb-4019-88c1-79ad67024bc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sage-devel] Re: OS X build failure: "Error installing package gfortran-7.2.0"

2019-05-13 Thread Josh Haberman
On Sat, May 11, 2019 at 8:07 AM Dima Pasechnik  wrote:

> On Sat, May 11, 2019 at 4:05 PM Dima Pasechnik  wrote:
> > On Sat, May 11, 2019 at 3:55 PM Josh Haberman 
> wrote:
> > > I tried installing gcc (which includes gfortran) from Homebrew, and
> then I set "export SAGE_INSTALL_GCC=no" but it tried (and failed) building
> gfortran anyway. Maybe I need to unset "SAGE_KEEP_BUILT_SPKGS=yes" so it
> starts over from scratch? Or maybe I need to make the brew "gcc" available
> as "gcc" instead of "gcc-9", which is what it got installed as.
> >
> > You don't need SAGE_INSTALL_GCC - gcc should be recongnised
> > automatically and not installed. Do
> >
> > make distclean
> >
> > and start from scratch.
>
> I always run configure first, as follows:
>
> CC=clang CXX=clang++ ./configure
>
> - this makes sure that gcc C/C++ is not used.
>

That did the trick, thanks!

-- 
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.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAOM7maxRdb8KpEPPD9unm0%3D5Q%2Bs_vYQ%2BwGmvL5N3Yez8ajFedw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.