[sage-devel] Re: sage_mode for emacs has display problem in sage 7.4 beta0

['Martin R' via sage-devel]

This is now https://trac.sagemath.org/ticket/21227
 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Trac notifications again

[Andrey Novoseltsev]

On Wednesday, 27 July 2016 15:35:29 UTC-6, leif wrote:
>
> Orthogonal to that, but also annoying is that we do no longer get 
> notifications when a ticket gets closed. 
>
> Is this a bug or a feature? 
>
>
> -leif 
>
>
Ping? I definitely like getting notifications that a ticket is closed, 
hopefully it can e enabled again. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: sage_mode for emacs has display problem in sage 7.4 beta0

[leif]

'Martin R' via sage-devel wrote:
> Please Help!  I just installed develop, which is currently sage 7.4
> beta0, but this broke my beloved sage_mode.  All in and output except
> the banner is unreadable!
> 
> I cannot live (well, to be honest: work) without emacs and sage_mode :-(

1) I /guess/ it still works in 7.3 => checkout master && make

2) Open a ticket (component sage_mode IIRC) and cc the maintainer/author.

3) Probably disable the color mode.


-leif

> 
> Martin
> 
> ┌┐
> │ SageMath version 7.4.beta0, Release Date: 2016-08-10   │
> │ Type "notebook()" for the browser-based notebook interface.│
> │ Type "help()" for help.│
> └┘
> ┏┓
> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
> ┗┛
> [?12l [?25h1+1
> [J [?7h [?12l [?25h [?2004l [?7h2
> [?12l [?25h


-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Multiple versions of SageMath's documentation online

[Samuel Lelièvre]

Hi sage-combinat-devel!

This post on sage-devel

https://groups.google.com/d/msg/sage-devel/NJSAQTjhIWE/NWbqC8xOAQAJ

has a part (which I'm copying below for convenience) about
SageMath's documentation at combinat.sagemath.org/doc.

Does anybody here have some insight about these questions?

Best, Samuel


- Excerpt from the sage-devel post at
https://groups.google.com/d/msg/sage-devel/NJSAQTjhIWE/NWbqC8xOAQAJ


2. SageMath's developer manual at combinat.sagemath.org/doc/reference

This sage-devel thread

  https://groups.google.com/d/topic/sage-devel/cCGobP2AgwM/discussion

is concerned with the fact that another version of SageMath's
reference manual also lives at

  http://combinat.sagemath.org/doc/reference

and that (given the trouble we are having in getting Google to properly
index the documentation at doc.sagemath.org), queries in Google search
give search engine results at combinat.sagemath.org/doc, rather than
at doc.sagemath.org.

In addition, it seems that the version of the documentation at
combinat.sagemath.org/doc corresponds to SageMath 6.3
, while SageMath is now at 7.3.

Combinat people,

- is there a use for hosting SageMath's documentation at
  combinat.sagemath.org/doc and should it be updated to 7.3?

- does this version have extra stuff from the combinat queue?

- who is in charge?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Multiple versions of SageMath's documentation online

[Samuel Lelièvre]

This post is about the multiple versions of SageMath's documentation online
and the associated problems of its good indexing in search engines and of
people finding up-to-date vs obsolete information on sagemath.org.

It is split into three parts.

1. SageMath's reference manual

currently doc.sagemath.org/html/en/reference
vs formerly www.sagemath.org/doc/reference

2. A "combinat“ version of SageMath's reference manual

at combinat.sagemath.org/doc/reference

3. SageMath's developer guide:

up-to-date doc.sagemath.org/html/en/developer/
vs outdated sagemath.org/git-developer-guide/

Now more detail about each part.

1. SageMath's reference manual

SageMath's reference manual for the latest public version

  - used to live at

  http://sagemath.org/doc/reference/

  - now lives at

  http://doc.sagemath.org/html/en/reference

and Google is having trouble reindexing.

Harald Schilly and Paul Masson are doing their best to sort this, see

  https://github.com/sagemath/website/issues/86

2. SageMath's developer manual at combinat.sagemath.org/doc/reference

This sage-devel thread

  https://groups.google.com/d/topic/sage-devel/cCGobP2AgwM/discussion

is concerned with the fact that another version of SageMath's
reference manual also lives at

  http://combinat.sagemath.org/doc/reference

and that (given the trouble we are having in getting Google to properly
index the documentation at doc.sagemath.org), queries in Google search
give search engine results at combinat.sagemath.org/doc, rather than
at doc.sagemath.org.

In addition, it seems that the version of the documentation at
combinat.sagemath.org/doc corresponds to SageMath 6.3
, while SageMath is now at 7.3.

Combinat people,

- is there a use for hosting SageMath's documentation at
  combinat.sagemath.org/doc and should it be updated to 7.3?

- does this version have extra stuff from the combinat queue?

- who is in charge?

3. In another sage-devel post at

https://groups.google.com/d/msg/sage-devel/6_rBQvKdGPo/I0MbKI5AAQAJ

an issue arises for SageMath's developer guide.

SageMath's developer guide now lives at

doc.sagemath.org/html/en/developer/

but people keep stumbling on an outdated version living at

sagemath.org/git-developer-guide/

which may have been put up there at the time of the migration
from mercurial to git (?).

Does anybody know how it got there, and how to remove it?

Best, Samuel

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] sage_mode for emacs has display problem in sage 7.4 beta0

['Martin R' via sage-devel]

Please Help!  I just installed develop, which is currently sage 7.4 beta0, 
but this broke my beloved sage_mode.  All in and output except the banner 
is unreadable!

I cannot live (well, to be honest: work) without emacs and sage_mode :-(

Martin

┌┐
│ SageMath version 7.4.beta0, Release Date: 2016-08-10   │
│ Type "notebook()" for the browser-based notebook interface.│
│ Type "help()" for help.│
└┘
┏┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗┛
 [?12l [?25h1+1
 [J [?7h [?12l [?25h [?2004l [?7h2
 [?12l [?25h

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: unable to change default milestone on trac

[leif]

leif wrote:
> leif wrote:
>> Vincent Delecroix wrote:
>>> Dear all,
>>>
>>> I wanted to change the default milestone to 7-4 on our trac server
>>
>> Which is "ours"?
>>
>> I already changed it on sage-trac a few days ago.
> 
> Oooops, indeed, now it's 7.3 again.  WTF?
> 
> 
>>> (in
>>> Admin->Milestones). However after clicking on the button "Apply changes"
>>> on the bottom of the page the server does not respond. Anybody can help?
>>
>> When I first tried, trac did hang indefinitely (leaving the connection
>> open), no matter what browser, no change after reload.
>>
>> Perhaps half a day later, I retried, and everything went smooth.
> 
> Now also hangs for me again as it did on first try ~last week.

I seem to once more have succeeded.

Hope it will stay at 7.4 now.


-leif


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Where should binary form reduction live?

[Ben Hutz]

ok, we could put it there. The binary qf version is called reduced_form() 
so we could call this one reduced_form() as well, which has the benefit of 
avoiding the naming conflict.

On Thursday, August 11, 2016 at 2:41:10 PM UTC-5, John Cremona wrote:
>
> On 11 August 2016 at 20:36, Ben Hutz  
> wrote: 
> > Yes, but 'reduce' doesn't really make sense except on homogeneous 2 var 
> > polynomials. So I think under that logic it would better fit in 
> > multivariable polynomials (which we considered). That avoids the whole 
> > binary form class versus qudaratic forms class issue. Would that be 
> > preferable? 
>
> Fine with me -- you'll have to test for the number of variables being 
> 2 and for homogeneity. 
>
> Problem:  elements of ZZ[X,Y] already have a reduce() method for 
> (Grobner-based) reduction modulo an ideal.  So a new name other than 
> reduce() is needed for the function. 
>
> John 
>
> > 
> > On Thursday, August 11, 2016 at 2:26:27 PM UTC-5, John Cremona wrote: 
> >> 
> >> On 11 August 2016 at 20:03, Ben Hutz  wrote: 
> >> > Yes we see that the quadratic form folder contains all the quadratic 
> >> > implementations. inside that there is some specific functionality for 
> >> > binary 
> >> > quadratic forms (binary_qf.py).  However, Lauren's function is for 
> >> > binary 
> >> > forms of *any* degree. As such, it doesn't really belong under the 
> >> > 'quadratic_form' folder. However, there doesn't seem to be a more 
> >> > appropriate place for it.  She could add it to the binary_qf.py file 
> and 
> >> > rename that binary.py, but it is still under the quadratic form code. 
> As 
> >> > you 
> >> > say it seems overkill to restructure things for a single function, 
> but 
> >> > it 
> >> > doesn't really seem to fit anywhere. Suggestions? 
> >> > 
> >> > What do you think of putting a more general binary form class in 
> >> > binary_qf.py and renaming the file to binary.py or binary_forms.py 
> but 
> >> > leaving the directory structure untouched? 
> >> 
> >> An alternative would be to have a .reduce() function on univariate 
> >> polynomials over ZZ or QQ.  The implementation will use the real and 
> >> complex roots anyway, and if the input is really homogeneous in 2 
> >> varaibles one will have to dehomogenise to get to the roots anyway. 
> >> This would also have the advantage of not having to worry about what 
> >> to call a global function whose purpose is to take a binary form and 
> >> reduce it. 
> >> 
> >> John 
> >> 
> >> 
> >> > 
> >> >   Ben 
> >> > 
> >> > 
> >> > On Sunday, August 7, 2016 at 5:15:17 PM UTC-5, Justin C. Walker 
> wrote: 
> >> >> 
> >> >> Hi, Rebecca, 
> >> >> 
> >> >> On Aug 7, 2016, at 14:02 , Rebecca Miller wrote: 
> >> >> 
> >> >> > I am implementing Cremona and Stoll's Binary Form Reduction 
> >> >> > Algorithm. 
> >> >> > I'm just not sure where it should live. I had some houghts but 
> would 
> >> >> > like 
> >> >> > opinions. Currently there is just a Quadratic Forms folder.  I 
> could 
> >> >> > create 
> >> >> > a folder containing just this algorithm, or I could rename the 
> >> >> > quadratic 
> >> >> > form folder and put it in there because binary quadratic forms 
> should 
> >> >> > inherit form this algorithm. Any other ideas? 
> >> >> 
> >> >> Binary forms have two incarnations, both, I think, in the 
> >> >> quadratic_forms 
> >> >> directory.  One is part of the general implementation, but John 
> Hanke 
> >> >> and 
> >> >> others, and one is specific to binary forms.  Check there to see 
> where 
> >> >> your 
> >> >> implementation would best fit. 
> >> >> 
> >> >> Renaming an existing directory is a fairly big step, given what's 
> >> >> there. 
> >> >> If you have implemented a full class for this, you may have gone too 
> >> >> far :-} 
> >> >> 
> >> >> But check what's there.  Write here if you have questions, 
> suggestions, 
> >> >> complaints, brick-bats, ... 
> >> >> 
> >> >> HTH 
> >> >> 
> >> >> Justin 
> >> >> 
> >> >> -- 
> >> >> Justin C. Walker, Curmudgeon at Large 
> >> >> Institute for the Absorption of Federal Funds 
> >> >> --- 
> >> >> If it weren't for carbon-14, I wouldn't date at all. 
> >> >> --- 
> >> >> 
> >> >> 
> >> > -- 
> >> > 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+...@googlegroups.com. 
> >> > To post to this group, send email to sage-...@googlegroups.com. 
> >> > Visit this group at https://groups.google.com/group/sage-devel. 
> >> > 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+...@googlegroups.com . 
> > To post to this 

Re: [sage-devel] Where should binary form reduction live?

[John Cremona]

On 11 August 2016 at 20:36, Ben Hutz  wrote:
> Yes, but 'reduce' doesn't really make sense except on homogeneous 2 var
> polynomials. So I think under that logic it would better fit in
> multivariable polynomials (which we considered). That avoids the whole
> binary form class versus qudaratic forms class issue. Would that be
> preferable?

Fine with me -- you'll have to test for the number of variables being
2 and for homogeneity.

Problem:  elements of ZZ[X,Y] already have a reduce() method for
(Grobner-based) reduction modulo an ideal.  So a new name other than
reduce() is needed for the function.

John

>
> On Thursday, August 11, 2016 at 2:26:27 PM UTC-5, John Cremona wrote:
>>
>> On 11 August 2016 at 20:03, Ben Hutz  wrote:
>> > Yes we see that the quadratic form folder contains all the quadratic
>> > implementations. inside that there is some specific functionality for
>> > binary
>> > quadratic forms (binary_qf.py).  However, Lauren's function is for
>> > binary
>> > forms of *any* degree. As such, it doesn't really belong under the
>> > 'quadratic_form' folder. However, there doesn't seem to be a more
>> > appropriate place for it.  She could add it to the binary_qf.py file and
>> > rename that binary.py, but it is still under the quadratic form code. As
>> > you
>> > say it seems overkill to restructure things for a single function, but
>> > it
>> > doesn't really seem to fit anywhere. Suggestions?
>> >
>> > What do you think of putting a more general binary form class in
>> > binary_qf.py and renaming the file to binary.py or binary_forms.py but
>> > leaving the directory structure untouched?
>>
>> An alternative would be to have a .reduce() function on univariate
>> polynomials over ZZ or QQ.  The implementation will use the real and
>> complex roots anyway, and if the input is really homogeneous in 2
>> varaibles one will have to dehomogenise to get to the roots anyway.
>> This would also have the advantage of not having to worry about what
>> to call a global function whose purpose is to take a binary form and
>> reduce it.
>>
>> John
>>
>>
>> >
>> >   Ben
>> >
>> >
>> > On Sunday, August 7, 2016 at 5:15:17 PM UTC-5, Justin C. Walker wrote:
>> >>
>> >> Hi, Rebecca,
>> >>
>> >> On Aug 7, 2016, at 14:02 , Rebecca Miller wrote:
>> >>
>> >> > I am implementing Cremona and Stoll's Binary Form Reduction
>> >> > Algorithm.
>> >> > I'm just not sure where it should live. I had some houghts but would
>> >> > like
>> >> > opinions. Currently there is just a Quadratic Forms folder.  I could
>> >> > create
>> >> > a folder containing just this algorithm, or I could rename the
>> >> > quadratic
>> >> > form folder and put it in there because binary quadratic forms should
>> >> > inherit form this algorithm. Any other ideas?
>> >>
>> >> Binary forms have two incarnations, both, I think, in the
>> >> quadratic_forms
>> >> directory.  One is part of the general implementation, but John Hanke
>> >> and
>> >> others, and one is specific to binary forms.  Check there to see where
>> >> your
>> >> implementation would best fit.
>> >>
>> >> Renaming an existing directory is a fairly big step, given what's
>> >> there.
>> >> If you have implemented a full class for this, you may have gone too
>> >> far :-}
>> >>
>> >> But check what's there.  Write here if you have questions, suggestions,
>> >> complaints, brick-bats, ...
>> >>
>> >> HTH
>> >>
>> >> Justin
>> >>
>> >> --
>> >> Justin C. Walker, Curmudgeon at Large
>> >> Institute for the Absorption of Federal Funds
>> >> ---
>> >> If it weren't for carbon-14, I wouldn't date at all.
>> >> ---
>> >>
>> >>
>> > --
>> > 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+...@googlegroups.com.
>> > To post to this group, send email to sage-...@googlegroups.com.
>> > Visit this group at https://groups.google.com/group/sage-devel.
>> > 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Where should binary form reduction live?

[Ben Hutz]

Yes, but 'reduce' doesn't really make sense except on homogeneous 2 var 
polynomials. So I think under that logic it would better fit in 
multivariable polynomials (which we considered). That avoids the whole 
binary form class versus qudaratic forms class issue. Would that be 
preferable?

On Thursday, August 11, 2016 at 2:26:27 PM UTC-5, John Cremona wrote:
>
> On 11 August 2016 at 20:03, Ben Hutz  
> wrote: 
> > Yes we see that the quadratic form folder contains all the quadratic 
> > implementations. inside that there is some specific functionality for 
> binary 
> > quadratic forms (binary_qf.py).  However, Lauren's function is for 
> binary 
> > forms of *any* degree. As such, it doesn't really belong under the 
> > 'quadratic_form' folder. However, there doesn't seem to be a more 
> > appropriate place for it.  She could add it to the binary_qf.py file and 
> > rename that binary.py, but it is still under the quadratic form code. As 
> you 
> > say it seems overkill to restructure things for a single function, but 
> it 
> > doesn't really seem to fit anywhere. Suggestions? 
> > 
> > What do you think of putting a more general binary form class in 
> > binary_qf.py and renaming the file to binary.py or binary_forms.py but 
> > leaving the directory structure untouched? 
>
> An alternative would be to have a .reduce() function on univariate 
> polynomials over ZZ or QQ.  The implementation will use the real and 
> complex roots anyway, and if the input is really homogeneous in 2 
> varaibles one will have to dehomogenise to get to the roots anyway. 
> This would also have the advantage of not having to worry about what 
> to call a global function whose purpose is to take a binary form and 
> reduce it. 
>
> John 
>
>
> > 
> >   Ben 
> > 
> > 
> > On Sunday, August 7, 2016 at 5:15:17 PM UTC-5, Justin C. Walker wrote: 
> >> 
> >> Hi, Rebecca, 
> >> 
> >> On Aug 7, 2016, at 14:02 , Rebecca Miller wrote: 
> >> 
> >> > I am implementing Cremona and Stoll's Binary Form Reduction 
> Algorithm. 
> >> > I'm just not sure where it should live. I had some houghts but would 
> like 
> >> > opinions. Currently there is just a Quadratic Forms folder.  I could 
> create 
> >> > a folder containing just this algorithm, or I could rename the 
> quadratic 
> >> > form folder and put it in there because binary quadratic forms should 
> >> > inherit form this algorithm. Any other ideas? 
> >> 
> >> Binary forms have two incarnations, both, I think, in the 
> quadratic_forms 
> >> directory.  One is part of the general implementation, but John Hanke 
> and 
> >> others, and one is specific to binary forms.  Check there to see where 
> your 
> >> implementation would best fit. 
> >> 
> >> Renaming an existing directory is a fairly big step, given what's 
> there. 
> >> If you have implemented a full class for this, you may have gone too 
> far :-} 
> >> 
> >> But check what's there.  Write here if you have questions, suggestions, 
> >> complaints, brick-bats, ... 
> >> 
> >> HTH 
> >> 
> >> Justin 
> >> 
> >> -- 
> >> Justin C. Walker, Curmudgeon at Large 
> >> Institute for the Absorption of Federal Funds 
> >> --- 
> >> If it weren't for carbon-14, I wouldn't date at all. 
> >> --- 
> >> 
> >> 
> > -- 
> > 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+...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > 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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Equations in jupyter notebook jump from centered to left aligned upon rendering

[Bill Page]

See this issue:

https://github.com/ipython/ipython/issues/7827

I have this annoying behavior in a newly install instance of SageMath 7.2.
I would like it to remain centered as in  normal "display math" style.

In the file:

/usr/lib/sagemath/local/lib/python2.7/site-packages/
notebook/static/style/style.min.css

line 9956:

div.output_area .MathJax_Display {
  text-align: left !important;
}

This seems to override any attempt to customize this behavior using for
example

~/.jupyter/custom/custom.css

Getting rid of "!important" seems to resolve the problem.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Where should binary form reduction live?

[John Cremona]

On 11 August 2016 at 20:03, Ben Hutz  wrote:
> Yes we see that the quadratic form folder contains all the quadratic
> implementations. inside that there is some specific functionality for binary
> quadratic forms (binary_qf.py).  However, Lauren's function is for binary
> forms of *any* degree. As such, it doesn't really belong under the
> 'quadratic_form' folder. However, there doesn't seem to be a more
> appropriate place for it.  She could add it to the binary_qf.py file and
> rename that binary.py, but it is still under the quadratic form code. As you
> say it seems overkill to restructure things for a single function, but it
> doesn't really seem to fit anywhere. Suggestions?
>
> What do you think of putting a more general binary form class in
> binary_qf.py and renaming the file to binary.py or binary_forms.py but
> leaving the directory structure untouched?

An alternative would be to have a .reduce() function on univariate
polynomials over ZZ or QQ.  The implementation will use the real and
complex roots anyway, and if the input is really homogeneous in 2
varaibles one will have to dehomogenise to get to the roots anyway.
This would also have the advantage of not having to worry about what
to call a global function whose purpose is to take a binary form and
reduce it.

John


>
>   Ben
>
>
> On Sunday, August 7, 2016 at 5:15:17 PM UTC-5, Justin C. Walker wrote:
>>
>> Hi, Rebecca,
>>
>> On Aug 7, 2016, at 14:02 , Rebecca Miller wrote:
>>
>> > I am implementing Cremona and Stoll's Binary Form Reduction Algorithm.
>> > I'm just not sure where it should live. I had some houghts but would like
>> > opinions. Currently there is just a Quadratic Forms folder.  I could create
>> > a folder containing just this algorithm, or I could rename the quadratic
>> > form folder and put it in there because binary quadratic forms should
>> > inherit form this algorithm. Any other ideas?
>>
>> Binary forms have two incarnations, both, I think, in the quadratic_forms
>> directory.  One is part of the general implementation, but John Hanke and
>> others, and one is specific to binary forms.  Check there to see where your
>> implementation would best fit.
>>
>> Renaming an existing directory is a fairly big step, given what's there.
>> If you have implemented a full class for this, you may have gone too far :-}
>>
>> But check what's there.  Write here if you have questions, suggestions,
>> complaints, brick-bats, ...
>>
>> HTH
>>
>> Justin
>>
>> --
>> Justin C. Walker, Curmudgeon at Large
>> Institute for the Absorption of Federal Funds
>> ---
>> If it weren't for carbon-14, I wouldn't date at all.
>> ---
>>
>>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: unable to change default milestone on trac

[leif]

leif wrote:
> Vincent Delecroix wrote:
>> Dear all,
>>
>> I wanted to change the default milestone to 7-4 on our trac server
> 
> Which is "ours"?
> 
> I already changed it on sage-trac a few days ago.

Oooops, indeed, now it's 7.3 again.  WTF?


>> (in
>> Admin->Milestones). However after clicking on the button "Apply changes"
>> on the bottom of the page the server does not respond. Anybody can help?
> 
> When I first tried, trac did hang indefinitely (leaving the connection
> open), no matter what browser, no change after reload.
> 
> Perhaps half a day later, I retried, and everything went smooth.

Now also hangs for me again as it did on first try ~last week.


-leif


-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: unable to change default milestone on trac

[leif]

Vincent Delecroix wrote:
> Dear all,
> 
> I wanted to change the default milestone to 7-4 on our trac server

Which is "ours"?

I already changed it on sage-trac a few days ago.

> (in
> Admin->Milestones). However after clicking on the button "Apply changes"
> on the bottom of the page the server does not respond. Anybody can help?

When I first tried, trac did hang indefinitely (leaving the connection
open), no matter what browser, no change after reload.

Perhaps half a day later, I retried, and everything went smooth.


-leif


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Where should binary form reduction live?

[Ben Hutz]

Yes we see that the quadratic form folder contains all the quadratic 
implementations. inside that there is some specific functionality for 
binary quadratic forms (binary_qf.py).  However, Lauren's function is for 
binary forms of *any* degree. As such, it doesn't really belong under the 
'quadratic_form' folder. However, there doesn't seem to be a more 
appropriate place for it.  She could add it to the binary_qf.py file and 
rename that binary.py, but it is still under the quadratic form code. As 
you say it seems overkill to restructure things for a single function, but 
it doesn't really seem to fit anywhere. Suggestions?

What do you think of putting a more general binary form class in 
binary_qf.py and renaming the file to binary.py or binary_forms.py but 
leaving the directory structure untouched?

  Ben

On Sunday, August 7, 2016 at 5:15:17 PM UTC-5, Justin C. Walker wrote:
>
> Hi, Rebecca, 
>
> On Aug 7, 2016, at 14:02 , Rebecca Miller wrote: 
>
> > I am implementing Cremona and Stoll's Binary Form Reduction Algorithm. 
> I'm just not sure where it should live. I had some houghts but would like 
> opinions. Currently there is just a Quadratic Forms folder.  I could create 
> a folder containing just this algorithm, or I could rename the quadratic 
> form folder and put it in there because binary quadratic forms should 
> inherit form this algorithm. Any other ideas? 
>
> Binary forms have two incarnations, both, I think, in the quadratic_forms 
> directory.  One is part of the general implementation, but John Hanke and 
> others, and one is specific to binary forms.  Check there to see where your 
> implementation would best fit.   
>
> Renaming an existing directory is a fairly big step, given what's there. 
>  If you have implemented a full class for this, you may have gone too far 
> :-} 
>
> But check what's there.  Write here if you have questions, suggestions, 
> complaints, brick-bats, ... 
>
> HTH 
>
> Justin 
>
> -- 
> Justin C. Walker, Curmudgeon at Large 
> Institute for the Absorption of Federal Funds 
> --- 
> If it weren't for carbon-14, I wouldn't date at all. 
> --- 
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] unable to change default milestone on trac

[Vincent Delecroix]

Dear all,

I wanted to change the default milestone to 7-4 on our trac server (in 
Admin->Milestones). However after clicking on the button "Apply changes" 
on the bottom of the page the server does not respond. Anybody can help?


Cheers,
Vincent

--
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: FriCAS installation fails

[Volker Braun]

Yes, you need to update sage

$ sage --package create -h
usage: sage --package create [-h] [--version VERSION] [--tarball TARBALL]
 [--type TYPE]
 [package_name]

positional arguments:
  package_name   Package name. Default: fix all packages.

optional arguments:
  -h, --help show this help message and exit
  --version VERSION  Package version
  --tarball TARBALL  Tarball filename pattern, e.g. Foo-VERSION.tar.bz2
  --type TYPEPackage type

Create new package, or overwrite existing package

EXAMPLE:

$ sage --package create foo --version=3.14 
--tarball=Foo-VERSION.tar.bz2 --type=standard
Creating new package "foo"




On Thursday, August 11, 2016 at 7:45:35 PM UTC+2, Martin R wrote:
>
> I get
>
> :~$ sage --package create fricas --version 1.2.7 --tarball 
> fricas-1.2.7.tar.bz2 --type experimental
> ERROR [cmdline|run:74]: unknown subcommand: create
>
> with
>
> ┌┐
> │ SageMath version 7.3.beta4, Release Date: 2016-06-12   │
> │ Type "notebook()" for the browser-based notebook interface.│
> │ Type "help()" for help.│
> └┘
> ┏┓
> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
> ┗┛
>
> Do I need to upgrade sage first?
>
> Martin
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: FriCAS installation fails

[leif]

'Martin R' via sage-devel wrote:
> I get
> 
> :~$ sage --package create fricas --version 1.2.7 --tarball
> fricas-1.2.7.tar.bz2 --type experimental
> ERROR [cmdline|run:74]: unknown subcommand: create
> 
> with
> 
> ┌┐
> │ SageMath version 7.3.beta4, Release Date: 2016-06-12   │
> │ Type "notebook()" for the browser-based notebook interface.│
> │ Type "help()" for help.│
> └┘
> ┏┓
> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
> ┗┛
> 
> Do I need to upgrade sage first?

Apparently.

TBH, I've never used any of the scripts creating new-style or old-style
packages; even the checksums file can of course easily be created
manually with sha1sum, md5sum and cksum.

But as the documentation I pointed to is for 7.3, and it anyway makes
sense to base your branch on the ticket on 7.3 or 7.4.beta0, you should
probably just pull the master or develop branch and run 'make' before
proceeding.


-leif


-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: FriCAS installation fails

['Martin R' via sage-devel]

I get

:~$ sage --package create fricas --version 1.2.7 --tarball 
fricas-1.2.7.tar.bz2 --type experimental
ERROR [cmdline|run:74]: unknown subcommand: create

with

┌┐
│ SageMath version 7.3.beta4, Release Date: 2016-06-12   │
│ Type "notebook()" for the browser-based notebook interface.│
│ Type "help()" for help.│
└┘
┏┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗┛

Do I need to upgrade sage first?

Martin

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: FriCAS installation fails

[leif]

leif wrote:
> 'Martin R' via sage-devel wrote:
>> Are http://www.sagemath.org/git-developer-guide/packaging.html the
>> instructions I should follow?
> 
> If in doubt, this is probably more recent:
> 
> http://doc.sagemath.org/html/en/developer/packaging.html#packaging-third-party-code
> 
> (It says version 7.3 rather than 1.0?!)

The latter is *definitely* more up-to-date (for example w.r.t. the
'type' file).


-leif


-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: FriCAS installation fails

[leif]

'Martin R' via sage-devel wrote:
> Are http://www.sagemath.org/git-developer-guide/packaging.html the
> instructions I should follow?

If in doubt, this is probably more recent:

http://doc.sagemath.org/html/en/developer/packaging.html#packaging-third-party-code

(It says version 7.3 rather than 1.0?!)


-leif


> Am Mittwoch, 10.. August 2016 18:55:55 UTC+2 schrieb Dima Pasechnik:
> 
> Also, we have an old version of FriCAS, current is 1.2.7.
> I just opened 
> 
> https://trac.sagemath.org/ticket/21209
>  (update the package)
> 
> 
> On Wednesday, August 10, 2016 at 5:46:55 PM UTC+1, Dima Pasechnik wrote:
> 
> 
> 
> On Wednesday, August 10, 2016 at 4:43:27 PM UTC+1, Daniel Krenn
> wrote:
> 
> On my SageMath 7.3 on Linux Mint 17.3 the command "sage -i
> fricas"
> fails. Part of the logfile is below. If someone wants more
> of the
> logfile, do not hesitate to ask.
> 
> Any ideas what goes wrong?
> 
> 
> ECL does not use uffi: prefix any more, it's ffi: instead,
> according to their docs.
> Replacing all the  uffi: with ffi: in src/lisp/fricas-lisp.lisp
> makes compiler happy.
> 
> Currently running the build, takes a while...
> 
> 
> 
> Best
> 
> Daniel
> 
> 
> [...]
> ECL (Embeddable Common-Lisp) 16.1.2 (git:UNKNOWN)
> Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
> Copyright (C) 1993 Giuseppe Attardi
> Copyright (C) 2000 Juan J. Garcia-Ripoll
> Copyright (C) 2015 Daniel Kochmanski
> ECL is free software, and you are welcome to redistribute it
> under certain conditions; see file 'Copyright' for details.
> Type :h for Help.
> Top level.
> >
> ;;; Loading
> 
> "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-package.lisp"
> 
> ;;; Loading #P"/local/dakrenn/sage/7.3/local/lib/ecl/cmp.fas"
> 
> #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-package.lisp"
> 
> >
> ;;; Loading
> 
> "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-config.lisp"
> 
> 
> #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-config.lisp"
> 
> >
> ;;; Loading
> 
> "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-ecl.lisp"
> 
> 
> #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-ecl.lisp"
> 
> >
> ;;; Loading
> 
> "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-lisp.lisp"
> 
> 
> Condition of type: SIMPLE-ERROR
> There is no package with the name UFFI.
> Available restarts:
> 
> 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL.
> 
> Broken at SI:BYTECODES. [Evaluation of: (LOAD
> "fricas-lisp.lisp")]
> >>
> echo timestamp > do_it.ecl
> make[4]: Leaving directory
> 
> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp'
> 
> make[4]: Entering directory
> 
> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot'
> 
> Building stage 0
> [ -d stage0 ] || ../../config/mkinstalldirs stage0
> mkdir -p -- stage0
> rm -rf prev-stage
> rm -f stage0/ptyout.o stage0/btincl2.o stage0/btscan2.o
> stage0/typrops.o
> stage0/btpile2.o stage0/typars.o stage0/tytree1.o
> rm -f stage0/ptyout.clisp stage0/btincl2.clisp
> stage0/btscan2.clisp
> stage0/typrops.clisp stage0/btpile2.clisp stage0/typars.clisp
> stage0/tytree1.clisp
> make OBJECTS="stage0/ptyout.o stage0/btincl2.o stage0/btscan2.o
> stage0/typrops.o stage0/btpile2.o stage0/typars.o
> stage0/tytree1.o"
> stage0/bootsys
> make[5]: Entering directory
> 
> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot'
> 
> 
> /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper
> 
> --compile_lisp --debug=no
> 
> --use=/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/build/x86_64-unknown-linux/bin/lisp
> 
> --output=stage0/ptyout.o compiled/ptyout.clisp
> 
> /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper:
> 
> 13:
> 
> 

[sage-devel] Re: FriCAS installation fails

['Martin R' via sage-devel]

Are http://www.sagemath.org/git-developer-guide/packaging.html the 
instructions I should follow?

Martin

Am Mittwoch, 10. August 2016 18:55:55 UTC+2 schrieb Dima Pasechnik:
>
> Also, we have an old version of FriCAS, current is 1.2.7.
> I just opened 
>
> https://trac.sagemath.org/ticket/21209 (update the package)
>
>
> On Wednesday, August 10, 2016 at 5:46:55 PM UTC+1, Dima Pasechnik wrote:
>>
>>
>>
>> On Wednesday, August 10, 2016 at 4:43:27 PM UTC+1, Daniel Krenn wrote:
>>>
>>> On my SageMath 7.3 on Linux Mint 17.3 the command "sage -i fricas" 
>>> fails. Part of the logfile is below. If someone wants more of the 
>>> logfile, do not hesitate to ask. 
>>>
>>> Any ideas what goes wrong? 
>>>
>>
>> ECL does not use uffi: prefix any more, it's ffi: instead, according to 
>> their docs.
>> Replacing all the  uffi: with ffi: in src/lisp/fricas-lisp.lisp makes 
>> compiler happy.
>>
>> Currently running the build, takes a while...
>>
>>
>>
>>> Best 
>>>
>>> Daniel 
>>>
>>>
>>> [...] 
>>> ECL (Embeddable Common-Lisp) 16.1.2 (git:UNKNOWN) 
>>> Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya 
>>> Copyright (C) 1993 Giuseppe Attardi 
>>> Copyright (C) 2000 Juan J. Garcia-Ripoll 
>>> Copyright (C) 2015 Daniel Kochmanski 
>>> ECL is free software, and you are welcome to redistribute it 
>>> under certain conditions; see file 'Copyright' for details. 
>>> Type :h for Help. 
>>> Top level. 
>>> > 
>>> ;;; Loading 
>>> "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-package.lisp"
>>>  
>>>
>>> ;;; Loading #P"/local/dakrenn/sage/7.3/local/lib/ecl/cmp.fas" 
>>> #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-package.lisp"
>>>  
>>>
>>> > 
>>> ;;; Loading 
>>> "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-config.lisp"
>>>  
>>>
>>> #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-config.lisp"
>>>  
>>>
>>> > 
>>> ;;; Loading 
>>> "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-ecl.lisp"
>>>  
>>>
>>> #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-ecl.lisp"
>>>  
>>>
>>> > 
>>> ;;; Loading 
>>> "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-lisp.lisp"
>>>  
>>>
>>>
>>> Condition of type: SIMPLE-ERROR 
>>> There is no package with the name UFFI. 
>>> Available restarts: 
>>>
>>> 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. 
>>>
>>> Broken at SI:BYTECODES. [Evaluation of: (LOAD "fricas-lisp.lisp")] 
>>> >> 
>>> echo timestamp > do_it.ecl 
>>> make[4]: Leaving directory 
>>> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp'
>>>  
>>>
>>> make[4]: Entering directory 
>>> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot'
>>>  
>>>
>>> Building stage 0 
>>> [ -d stage0 ] || ../../config/mkinstalldirs stage0 
>>> mkdir -p -- stage0 
>>> rm -rf prev-stage 
>>> rm -f stage0/ptyout.o stage0/btincl2.o stage0/btscan2.o stage0/typrops.o 
>>> stage0/btpile2.o stage0/typars.o stage0/tytree1.o 
>>> rm -f stage0/ptyout.clisp stage0/btincl2.clisp stage0/btscan2.clisp 
>>> stage0/typrops.clisp stage0/btpile2.clisp stage0/typars.clisp 
>>> stage0/tytree1.clisp 
>>> make OBJECTS="stage0/ptyout.o stage0/btincl2.o stage0/btscan2.o 
>>> stage0/typrops.o stage0/btpile2.o stage0/typars.o stage0/tytree1.o" 
>>> stage0/bootsys 
>>> make[5]: Entering directory 
>>> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot'
>>>  
>>>
>>> /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper
>>>  
>>>
>>> --compile_lisp --debug=no 
>>> --use=/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/build/x86_64-unknown-linux/bin/lisp
>>>  
>>>
>>> --output=stage0/ptyout.o compiled/ptyout.clisp 
>>> /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper:
>>>  
>>>
>>> 13: 
>>> /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper:
>>>  
>>>
>>> /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/build/x86_64-unknown-linux/bin/lisp:
>>>  
>>>
>>> not found 
>>> make[5]: *** [stage0/ptyout.o] Error 127 
>>> make[5]: Leaving directory 
>>> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot'
>>>  
>>>
>>> make[4]: *** [stage0/stamp_bootsys] Error 2 
>>> make[4]: Leaving directory 
>>> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot'
>>>  
>>>
>>> make[3]: *** [all-boot] Error 2 
>>> make[3]: Leaving directory 
>>> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src' 
>>> make[2]: *** [all-src] Error 2 
>>> make[2]: Leaving directory 
>>> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src' 
>>> Error building fricas. 
>>>
>>> real0m3.101s 
>>> user0m1.528s 
>>> sys0m0.528s 
>>> 

[sage-devel] Re: Dealing with libc math differences

[leif]

Erik Bray wrote:
> On Thu, Aug 11, 2016 at 2:17 PM, Dima Pasechnik  wrote:
>>> FWIW, on Cygwin we used to use the Cephes library for a while.  (No idea
>>> whether it now replaced libm or parts of it got merged into libm
>>> upstream, or none of that.)
>>>
>>> But the result you get presumably also depends on whether libm was
>>> compiled with -mfpmath=sse or -mfpmath=387 etc.
>>>
>> not sure about this; cygwin uses libm from something called newlib, which is
>> mostly developed by Sun some 20+ years ago.
>> So it's pretty much non-optimised for particular hardware.
>> Although they keep adding more stuff to it even now, cf. e.g.
>> https://sourceware.org/ml/newlib-cvs/2016-q1/msg00046.html
> 
> Yup, that's why I wrote "libc" at some point--just because newlib
> incorporates both libc and libm so it's easy to think of them as part
> of the same library.  I have no idea how it is configured.
> 
> One major disadvantage to it is it is still missing most double
> complex functions which creates a lot of hassle, though that's an
> orthogonal issue.

Lacking (at least some) C99 functions (especially long double versions
of the gamma functions) was the reason to include and use Cephes on
Cygwin, but that was years ago.  (It's no longer built on Cygwin since
about four years, cf. #9543.)


-leif


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Dealing with libc math differences

[Erik Bray]

On Thu, Aug 11, 2016 at 2:17 PM, Dima Pasechnik  wrote:
>> FWIW, on Cygwin we used to use the Cephes library for a while.  (No idea
>> whether it now replaced libm or parts of it got merged into libm
>> upstream, or none of that.)
>>
>> But the result you get presumably also depends on whether libm was
>> compiled with -mfpmath=sse or -mfpmath=387 etc.
>>
> not sure about this; cygwin uses libm from something called newlib, which is
> mostly developed by Sun some 20+ years ago.
> So it's pretty much non-optimised for particular hardware.
> Although they keep adding more stuff to it even now, cf. e.g.
> https://sourceware.org/ml/newlib-cvs/2016-q1/msg00046.html

Yup, that's why I wrote "libc" at some point--just because newlib
incorporates both libc and libm so it's easy to think of them as part
of the same library.  I have no idea how it is configured.

One major disadvantage to it is it is still missing most double
complex functions which creates a lot of hassle, though that's an
orthogonal issue.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Dealing with libc math differences

[Dima Pasechnik]

On Thursday, August 11, 2016 at 12:15:32 PM UTC+1, leif wrote:
>
> Erik Bray wrote: 
> > On Wed, Aug 10, 2016 at 2:45 PM, Thierry Dumont 
> >  wrote: 
> >> Le 10/08/2016 à 13:38, Erik Bray a écrit : 
> >>> Hi all, 
> >>> 
> >>> Sorry if this has been discussed ad-infinitum before--I looked around 
> >>> a bit but didn't find a definitive answer. 
> >>> 
> >>> I have one (well at least one) test that's failing on Cygwin due to 
> >>> tiny difference in the last digit of the result of log(3). 
> >>> 
> >>> This leads to to several questions: 
> >>> 
> >>> 1) Is it worth investigating the reason for the difference? 
> >>> 2) Is it worth trying to provide a workaround for the difference? 
> >>> 3) Or should the test just be updated to ignore the last couple digits 
> >>> of the result, and if so how (ellipses?) 
> >>> 
> >>> Thanks, 
> >>> Erik 
> >>> 
> >> Hello, 
> >> 
> >> What do you mean by log(3) ? 
> >> 
> >> Is it log(3.) or log(RDF(3)) ? 
> > 
> > Really what I meant was `float(log(3))` which I guess in Sage ends up 
> > being same as `log(RDF(3))` 
> > 
> >> With log(RDF(3)), this is classical; changing the library version, or 
> >> the compiler version often changes the way some expressions and 
> >> functions are computed. As floating point arithmetic is not 
> associative, 
> >> this is classical. With log(3.) (RealField()), I don't know. 
> >> When we wrote the book "Calcul Mathématique avec Sage", we had this 
> >> problem: after some release (some months) some  doctests of the chapter 
> >> on numerical algebra and floating point numbers failed. The only work 
> >> around we found was to truncate the last digit in the output, to try to 
> >> test what should remain constant. 
> > 
> > I have: 
> > 
> > sage: R = RealField(100) 
> > sage: log(R(3)) 
> > 1.0986122886681096913952452369 
> > 
> > Okay.  With Cygwin's libm: 
> > 
> > sage: float(log(3)) 
> > 1.0986122886681096 
> > 
> > While on Linux I get: 
> > 
> > sage: float(log(3)) 
> > 1.0986122886681098 
> > 
> > It looks like the latter result is properly rounded up (with an error 
> > of 1ulp) while my result on Cygwin is just truncated. 
>
>
> FWIW, on Cygwin we used to use the Cephes library for a while.  (No idea 
> whether it now replaced libm or parts of it got merged into libm 
> upstream, or none of that.) 
>
> But the result you get presumably also depends on whether libm was 
> compiled with -mfpmath=sse or -mfpmath=387 etc. 
>
> not sure about this; cygwin uses libm from something called newlib, which 
is mostly developed by Sun some 20+ years ago.
So it's pretty much non-optimised for particular hardware.
Although they keep adding more stuff to it even now, cf. e.g.
https://sourceware.org/ml/newlib-cvs/2016-q1/msg00046.html

Dima

>
> -leif 
>
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Dealing with libc math differences

[leif]

Erik Bray wrote:
> On Wed, Aug 10, 2016 at 2:45 PM, Thierry Dumont
>  wrote:
>> Le 10/08/2016 à 13:38, Erik Bray a écrit :
>>> Hi all,
>>>
>>> Sorry if this has been discussed ad-infinitum before--I looked around
>>> a bit but didn't find a definitive answer.
>>>
>>> I have one (well at least one) test that's failing on Cygwin due to
>>> tiny difference in the last digit of the result of log(3).
>>>
>>> This leads to to several questions:
>>>
>>> 1) Is it worth investigating the reason for the difference?
>>> 2) Is it worth trying to provide a workaround for the difference?
>>> 3) Or should the test just be updated to ignore the last couple digits
>>> of the result, and if so how (ellipses?)
>>>
>>> Thanks,
>>> Erik
>>>
>> Hello,
>>
>> What do you mean by log(3) ?
>>
>> Is it log(3.) or log(RDF(3)) ?
> 
> Really what I meant was `float(log(3))` which I guess in Sage ends up
> being same as `log(RDF(3))`
> 
>> With log(RDF(3)), this is classical; changing the library version, or
>> the compiler version often changes the way some expressions and
>> functions are computed. As floating point arithmetic is not associative,
>> this is classical. With log(3.) (RealField()), I don't know.
>> When we wrote the book "Calcul Mathématique avec Sage", we had this
>> problem: after some release (some months) some  doctests of the chapter
>> on numerical algebra and floating point numbers failed. The only work
>> around we found was to truncate the last digit in the output, to try to
>> test what should remain constant.
> 
> I have:
> 
> sage: R = RealField(100)
> sage: log(R(3))
> 1.0986122886681096913952452369
> 
> Okay.  With Cygwin's libm:
> 
> sage: float(log(3))
> 1.0986122886681096
> 
> While on Linux I get:
> 
> sage: float(log(3))
> 1.0986122886681098
> 
> It looks like the latter result is properly rounded up (with an error
> of 1ulp) while my result on Cygwin is just truncated.


FWIW, on Cygwin we used to use the Cephes library for a while.  (No idea
whether it now replaced libm or parts of it got merged into libm
upstream, or none of that.)

But the result you get presumably also depends on whether libm was
compiled with -mfpmath=sse or -mfpmath=387 etc.


-leif



-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] fplll 5.0 in sage

['Martin R. Albrecht' via sage-devel]

This is now

  https://trac.sagemath.org/ticket/21221

Cheers,
Martin

Jean-Pierre Flori writes:
> Yes!
>
> Did you open a ticket for this?


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Dealing with libc math differences

[Erik Bray]

On Wed, Aug 10, 2016 at 2:45 PM, Thierry Dumont
 wrote:
> Le 10/08/2016 à 13:38, Erik Bray a écrit :
>> Hi all,
>>
>> Sorry if this has been discussed ad-infinitum before--I looked around
>> a bit but didn't find a definitive answer.
>>
>> I have one (well at least one) test that's failing on Cygwin due to
>> tiny difference in the last digit of the result of log(3).
>>
>> This leads to to several questions:
>>
>> 1) Is it worth investigating the reason for the difference?
>> 2) Is it worth trying to provide a workaround for the difference?
>> 3) Or should the test just be updated to ignore the last couple digits
>> of the result, and if so how (ellipses?)
>>
>> Thanks,
>> Erik
>>
> Hello,
>
> What do you mean by log(3) ?
>
> Is it log(3.) or log(RDF(3)) ?

Really what I meant was `float(log(3))` which I guess in Sage ends up
being same as `log(RDF(3))`

> With log(RDF(3)), this is classical; changing the library version, or
> the compiler version often changes the way some expressions and
> functions are computed. As floating point arithmetic is not associative,
> this is classical. With log(3.) (RealField()), I don't know.
> When we wrote the book "Calcul Mathématique avec Sage", we had this
> problem: after some release (some months) some  doctests of the chapter
> on numerical algebra and floating point numbers failed. The only work
> around we found was to truncate the last digit in the output, to try to
> test what should remain constant.

I have:

sage: R = RealField(100)
sage: log(R(3))
1.0986122886681096913952452369

Okay.  With Cygwin's libm:

sage: float(log(3))
1.0986122886681096

While on Linux I get:

sage: float(log(3))
1.0986122886681098

It looks like the latter result is properly rounded up (with an error
of 1ulp) while my result on Cygwin is just truncated.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Dealing with libc math differences

[Erik Bray]

On Wed, Aug 10, 2016 at 3:08 PM, Jeroen Demeyer  wrote:
> On 2016-08-10 13:38, Erik Bray wrote:
>>
>> 1) Is it worth investigating the reason for the difference?
>
>
> No, but it is worth determining how bad the error is. In all cases, I would
> say that an error of less than 1 ulp is totally acceptable. If the error is
> 1 ulp or more for a basic function (like log) on a reasonable
> non-pathological input (like 3.0), I would consider that an upstream bug.
> Still, it would not necessarily be a problem for Sage if the error is a few
> ulp.

In this case the difference is just one ulp.

>> 3) Or should the test just be updated to ignore the last couple digits
>> of the result, and if so how (ellipses?)
>
>
> The best way is to use # (rel|abs) tol in the doctest.

Great, I found that shortly after posting.  I think in this case it
should probably be fine?

-- 
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.
For more options, visit https://groups.google.com/d/optout.