[sage-devel] Re: Some polynomial timings

[parisse]

And why not giac? flint is a little faster for basic multivariate 
polynomial arithmetic on 1 thread, but giac is multithread and has more 
advanced fast functionnalities like gcd, factorization, Groebner basis or 
rational univariate representation.

-- 
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] Trouble while compiling sage---- compiling ends during plot3d

[manrique . miguelangel]

Thank you. I got the same error even with 'make build' with the j1 flag.  I 
will compile from a local virtual machine and try going the route you 
suggest.

Miguel-Angel Manrique

On Monday, September 4, 2017 at 2:07:25 PM UTC-7, Samuel Lelievre wrote:
>
> If you have access to another machine with more RAM
> and the same OS, you could produce binaries on that
> machine and then install on the machine with less RAM
> from the binaries you created. To create binaries, use:
>
> https://github.com/sagemath/binary-pkg
> ​
>

-- 
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] Does anyone use SAGE64?

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 4 September 2017 at 18:34, Erik Bray  wrote:

> On Mon, Sep 4, 2017 at 6:08 PM, Jean-Pierre Flori 
> wrote:
> +1 I think if this functionality is needed for Solaris (or any other
> platform) it should be moved into configure.ac, and the explicit
> environment variables done away with.
>
>
But the variable does more than add -m64.
I fail to see what harm it is doing leaving it there, but removing it would
make a 64-bit Solaris port  more work. A lot of time was put into adding
the code in various files to accept that variable.

What is it going to gain by removing it? Make the download a few hundred
bytes smaller?

Dave

-- 
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] Trouble while compiling sage---- compiling ends during plot3d

[Samuel Lelièvre]

If you have access to another machine with more RAM
and the same OS, you could produce binaries on that
machine and then install on the machine with less RAM
from the binaries you created. To create binaries, use:

https://github.com/sagemath/binary-pkg
​

-- 
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] Trouble while compiling sage---- compiling ends during plot3d

[manrique . miguelangel]

Unfortunately I cannot add more RAM to the server. One day I hope to have 
the server be in-house and to swim in many GB of RAM.

>
I will try these suggestions. Thanks 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.

Re: [sage-devel] Trouble while compiling sage---- compiling ends during plot3d

[manrique . miguelangel]

I am trying to keep costs down. I would like to have more RAM, but it is 
not in the budget.

-- 
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] Trouble while compiling sage---- compiling ends during plot3d

[Dima Pasechnik]

you can try

MAKE="make -j1" make

to build the docs.
This should make sure you do not build it in parallel.

-- 
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] Trouble while compiling sage---- compiling ends during plot3d

[Samuel Lelievre]

Sun 2017-09-03 20:27:44 UTC-5, Miguel-Angel Manrique:

> 2048MB RAM total, 4 core 64bit processor;  the server was running
> webwork in the background, but no students have access yet.
>
> Building in parallel: no idea but I presume so. I didn't specify the
> number of threads to use during install. I suppose I will try one more
> time, specifying option j1 this time. I use the ww_install script blindly.

Can you add RAM to your computer? A total of 2 GB is very little today.
Building Sage's documentation is especially memory-consuming,
as Jeroen pointed out.

Regarding whether you are building in parallel, you could check
the result of typing

echo $MAKE

in a terminal.

-- 
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: doctests: non-sorted output

[David Roe]

Given the transition to Python 3, I don't think we should directly compare
the elements in a set (though perhaps an exception should be made if they
all have the same parent).  Comparing their string representations seems
better.

If we do sort the string representation of sets, we can reduce surprise for
users by using something like natural sort (see
https://github.com/SethMMorton/natsort for a library, or various code
snippets available online).

As for whether to do this only for doctests or for the user interface as
well, I think it's nicer for the two to be the same.  So I would prefer 2.2
over 2.1.
David

On Tue, Aug 29, 2017 at 9:25 AM, Maarten Derickx <
m.derickx.stud...@gmail.com> wrote:

> Option 2.3 might be to make solution 2.1 optional and dependent on the
> presence of something like  # unorderedset in the doctest. I actually like
> this the best since it allows us to use it only in the cases where it is
> really needed. So we can have the advantages of 2.1 and 2.2 depending on
> the situation!
>
>
> On Tuesday, 29 August 2017 17:44:10 UTC+2, Maarten Derickx wrote:
>>
>> The output of both dict and set are ordered by a display hook from
>> IPython, the problem is that this sorting is done on the basis of __cmp__
>> and the default way of sorting using __cmp__ is using the id of an object
>> which is not deterministic, so even though the output is sorted it is done
>> on a nondeterministic basis for objects which have this nondeterministic
>> __cmp__.
>>
>> I see basically 2 options going forward:
>>
>> 1. Just fix the doctests of pynormaliz themselves by making them
>> deterministic.
>>
>> 2. Make the doctesting of sets more robust by ordering the output basted
>> on the string representation instead of __cmp__ . This has two ways of
>> doing it.
>> 2.1 Only change the order of the output in the doctesting framework
>> 2.2 Change it both in the doctesting framework and the user interface
>>
>> At https://trac.sagemath.org/ticket/23586 there is a partial solution
>> using 2, I stopped working on this because I want feedback on wether we
>> should do 2.1 or 2.2. But the progress on this ticket is slow.
>>
>> So I propose doing the quick fix 1 independently of 2, because this will
>> remove a lot of false negatives of the patchbot on other tickets helping
>> greatly in the sage development.
>>
>> Do people have feedback on 2.1 vs 2.2?
>> Main advantage of 2.1, the user will get more meaningful output in the
>> case where __cmp__ is deterministic. For example with 2.2 the user will get
>> the following awkward output:
>>
>> sage: set(GF(11))
>> {0, 1, 10, 2, 3, 4, 5, 6, 7, 8, 9}
>>
>> The main advantage of 2.2 is that the doctest and the actual output of
>> sage are guaranteed to agree and that the code paths for doctesting and
>> actual output are more similar.
>>
>> My personal preference is for 2.1 since sets are inherently unordered,
>> but I am open for feedback.
>>
>> On Friday, 18 August 2017 09:14:55 UTC+2, Daniel Krenn wrote:
>>>
>>> A patchbot reported two failing doctests because the result is a set and
>>> the elements were in a different order, see
>>>   https://trac.sagemath.org/ticket/23637
>>> 
>>> I somehow remember that such an issue was discussed here and I thought
>>> it was about the output of dict and set being sorted by a display hook.
>>> Am I wrong and this is not done or even not possible?
>>>
>>> Best
>>>
>>> Daniel
>>>
>> --
> 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] Does anyone use SAGE64?

[Erik Bray]

On Mon, Sep 4, 2017 at 6:08 PM, Jean-Pierre Flori  wrote:
>
>
> On Monday, September 4, 2017 at 6:06:35 PM UTC+2, Jean-Pierre Flori wrote:
>>
>> I would also say that passing -m64 is needed on Solaris even when the
>> kernel is 64bits, and I think the situation is the same on linux running on
>> sparc.
>> On these platforms default versions of gcc produces 32 bits stuff by
>> default, unless you begin compiling your own gcc and convince it to do
>> something else.
>
> I'm not sure that this is a sufficient reason to keep the SAGE64 semi broken
> mess in the install scripts though.
> I would even consider it a good idea to remove it now and reintroduce it
> later if someone really needs such support.
> In btw playing with C*FLAGS should do the trick.

+1 I think if this functionality is needed for Solaris (or any other
platform) it should be moved into configure.ac, and the explicit
environment variables done away with.

-- 
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] Does anyone use SAGE64?

[Jean-Pierre Flori]

On Monday, September 4, 2017 at 6:06:35 PM UTC+2, Jean-Pierre Flori wrote:
>
> I would also say that passing -m64 is needed on Solaris even when the 
> kernel is 64bits, and I think the situation is the same on linux running on 
> sparc.
> On these platforms default versions of gcc produces 32 bits stuff by 
> default, unless you begin compiling your own gcc and convince it to do 
> something else.
>
I'm not sure that this is a sufficient reason to keep the SAGE64 semi 
broken mess in the install scripts though.
I would even consider it a good idea to remove it now and reintroduce it 
later if someone really needs such support.
In btw playing with C*FLAGS should do the trick. 

-- 
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] Does anyone use SAGE64?

[Jean-Pierre Flori]

I would also say that passing -m64 is needed on Solaris even when the 
kernel is 64bits, and I think the situation is the same on linux running on 
sparc.
On these platforms default versions of gcc produces 32 bits stuff by 
default, unless you begin compiling your own gcc and convince it to do 
something else.

-- 
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: Some polynomial timings

[Jean-Pierre Flori]

Anyway we should definitely get some multivariate polynomial arithmetic 
over Z based on flint and keep singular for groebner bases or things it is 
meant for.

On Monday, September 4, 2017 at 7:13:59 AM UTC+2, parisse wrote:
>
>
>
> Le dimanche 3 septembre 2017 16:06:46 UTC+2, rjf a écrit :
>>
>> I was doing timing on the same task and found that one system
>> (used for celestial mechanics) was spectacularly fast on a test just like 
>> this one.
>> One reason was that it first changed f*(f+1)   to
>>
>> f^2 +f
>> and was clever in computing f^2.  You should be clever
>> at this too.
>>
>> Anyway, be careful when you are testing.
>>
>>
> giac does not cheat, it does the product f*(f+1) not f^2+f. For more 
> details, you can have a look at Bill Hart blog:
>
> http://wbhart.blogspot.fr/2017/07/update-on-fast-multivariate-polynomial.html
>

-- 
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: Trouble while compiling sage---- compiling ends during plot3d

[Travis Scrimshaw]

> it doesn't solve anything, but... do you need to make the doc? it's 
> online: http://doc.sagemath.org/
> the command `make start` can be helpful.
>
> Also "make build".

Best,
Travis

-- 
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] Unable to compile 8.0.rc2 on mac

['Bill Hart' via sage-devel]

Reimer Behrends has helped me track down the explicit issue. We don't have 
a patch yet, but the bug (and solution) is described here [1].

Basically the M4 macro JMPENT in mpn/x86_64/x86_64-defs.mac needs to do 
more than just subtract the two addresses on Mac. However, I'm confused why 
this isn't affecting every 64 bit Skylake Mac out there. But his has only 
been reported twice! Are Skylake Macs really rare or something?

Bill.

[1] https://gmplib.org/list-archives/gmp-bugs/2012-December/002836.html

On Wednesday, 19 July 2017 11:15:09 UTC+2, Bill Hart wrote:
>
> It's certainly not a generic problem affecting Mac [0]. It's Skylake 
> specific and something their linker doesn't like that works on that 
> architecture on Linux.
>
> Bill.
>
> [0] 
> https://travis-ci.org/wbhart/mpir/builds/252901954?utm_source=github_status_medium=notification
>
> On Wednesday, 19 July 2017 11:12:37 UTC+2, Bill Hart wrote:
>>
>> Alex Best pointed out this morning that something similar came up for the 
>> GMP guys a while back. Apparently something to do with jump tables. That is 
>> probably affecting our code here [1].
>>
>> We'll look into it. Unfortunately, in the mean time, the best one can 
>> really do is delete the affected file.
>>
>> Bill.
>>
>> [1] 
>> https://github.com/wbhart/mpir/blob/master/mpn/x86_64/skylake/avx/addmul_1.asm#L100
>>
>> On Wednesday, 19 July 2017 01:46:48 UTC+2, Andrew wrote:
>>>
>>>
>>>
>>> On Wednesday, 19 July 2017 00:59:27 UTC+10, Dima Pasechnik wrote:

 Surely MPIR guys would appreciate feedback.
 This might be their assembler bug.

 Will let them know.
>>> A. 
>>>
>>

-- 
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] Trouble while compiling sage---- compiling ends during plot3d

[Jeroen Demeyer]

There is the message "Killed" which can normally only happen if 
something external kills Sage. A common case is the Linux OOM 
(out-of-memory) killer which kills processes when the system runs out of 
memory. Second, the docbuilder is known to use huge amounts of memory.


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