[sage-devel] Re: devising a speed comparison test between different types

On Sunday, December 4, 2016 at 12:00:58 AM UTC+1, Pierre wrote: > > I tried naive things like setting x and y to be integers of a certain > type, and then > > sage: %timeit x^y > > for example, but I always get "" The slowest run took 59.81 times longer > than the fastest. This could mean that

[sage-devel] devising a speed comparison test between different types

Hi, I hope that this is appropriate for sage-devel, as it is technical. As some colleagues who are new to Sagemath were asking me what I knew, I realized that I was unable to comment very sensibly on the various types of integers and of real numbers treated by Sage (no doubt because in my own

Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

On Saturday, December 3, 2016 at 2:30:36 PM UTC-8, William wrote: > > On Sat, Dec 3, 2016 at 2:28 PM, Paul Masson > wrote: > > There's apparently no good way in general to test whether the scene is > > unchanged. This is a known issue: > > > >

Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

On Sat, Dec 3, 2016 at 2:28 PM, Paul Masson wrote: > There's apparently no good way in general to test whether the scene is > unchanged. This is a known issue: > > https://github.com/mrdoob/three.js/issues/7670 > > One of the comments on this thread offers another option:

Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

There's apparently no good way in general to test whether the scene is unchanged. This is a known issue: https://github.com/mrdoob/three.js/issues/7670 One of the comments on this thread offers another option: only render the scene upon user interaction. I'm so accustomed to writing Three.js

Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

On Sat, Dec 3, 2016 at 1:11 PM, Volker Braun wrote: > Well if the scene is static, the controls didn't change, and the canvas size > didnt't change then your callback in requestAnimationFram should just do > nothing instead of repainting the unchanged scene, right? +1 --

Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

Well if the scene is static, the controls didn't change, and the canvas size didnt't change then your callback in requestAnimationFram should just do nothing instead of repainting the unchanged scene, right? On Saturday, December 3, 2016 at 9:46:50 PM UTC+1, Paul Masson wrote: > > > > On

Re: [sage-devel] Re: three.js on 7.5 beta 5: cpu...

On Friday, December 2, 2016 at 11:47:40 PM UTC-8, tdumont wrote: > > > But why is three.js consuming cpu when the browser shouls have nothing > to do ? (no interaction). > There is a rendering loop that runs continuously to call requestAnimationFram(). This is a standard technique for

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

On Sat, Dec 03, 2016 at 05:55:19PM +0100, Emmanuel Charpentier wrote: > The key words are "within the Sage source"... ;-) > > More on this later (i'a bit overwhelmed right now). Note that the following is already possible, though it seems irrelevant for macs, which are the real problem (since

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

The key words are "within the Sage source"... ;-) More on this later (i'a bit overwhelmed right now). -- Emmanuel Charpentier Le 3 déc. 2016 17:51, "Thierry" a écrit : On Sat, Dec 03, 2016 at 02:50:19PM +0100, Emmanuel Charpentier wrote: [...] > Ok. So we

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

On Sat, Dec 03, 2016 at 02:50:19PM +0100, Emmanuel Charpentier wrote: [...] > Ok. So we might try the following sequence : > > 1) in a pristine, openssl-virgin VM, compile Sage, and test pip's > ability to work (test 0, negative, as you proved). > > 2) install Sage's openssl, test pip's ability

Re: [sage-devel] Re: make giac/giacpy a standard package

Le samedi 3 décembre 2016 13:55:30 UTC+1, Jeroen Demeyer a écrit : > > On 2016-07-03 21:08, Han Frederic wrote: > > Yes these binaries were left in upstream 1.2.2-37 source tarball, but it > > is a mistake. > > How do you create those binaries? It should be done by a script ("make > dist" if

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

Le samedi 03 décembre 2016 à 13:02 +0100, Thierry a écrit : > Hi, > > On Sat, Dec 03, 2016 at 10:48:18AM +0100, Emmanuel Charpentier wrote: > [...]  > > If you still have this VM, could you try to add the current > > "openssl" > > Sage package and tell us if , after this addition, "sage -pip

Re: [sage-devel] Re: make giac/giacpy a standard package

On 2016-07-03 21:08, Han Frederic wrote: Yes these binaries were left in upstream 1.2.2-37 source tarball, but it is a mistake. How do you create those binaries? It should be done by a script ("make dist" if you use autotools), not by hand. -- You received this message because you are

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

+1 for the manual (bring your own .pc file) approach to blas configuration. Otherwise you'd need configure switches for all combinations of (blas+cblas+lapack) * (cflags+ldflags+libs) which would make it even more difficult to use. -- You received this message because you are subscribed to

Re: [sage-devel] Re: make giac/giacpy a standard package

Hi, On Fri, Dec 02, 2016 at 10:59:48PM -0800, Ralf Stephan wrote: > Apologies. I had the impression that repackaging is frowned upon for > security reasons. However, just removing files can be automated, either by > the original author or the Sage release manager, so there is room for >

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

Hi, On Sat, Dec 03, 2016 at 10:48:18AM +0100, Emmanuel Charpentier wrote: [...] > If you still have this VM, could you try to add the current "openssl" > Sage package and tell us if , after this addition, "sage -pip list" > works ? I droped it, but i can create a new one. Do you mean just add

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

Hi, On Sat, Dec 03, 2016 at 10:00:51AM +0100, Jeroen Demeyer wrote: > On 2016-12-02 09:21, Thierry wrote: > >Would it be > >preferable to have this possibility dealt at configure time > > Absolutely. Whatever you do, do *NOT* introduce a new environment variable. Why ? We do this for various

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

On Sat, Dec 03, 2016 at 10:43:07AM +0100, Emmanuel Charpentier wrote: [...] > It remains to be seen if our "openssl" package allows a Sage system, > initially compiled with, say, GnuTLS, to use, say PIP. That could be an > hypocritical but efficient workaround. No, you will have to recompile (at

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

Le vendredi 02 décembre 2016 à 13:23 -0800, Volker Braun a écrit : > On Friday, December 2, 2016 at 9:39:13 AM UTC+1, Dima Pasechnik > wrote: > > Do you understand the story about root certs here? Is it a missing > > python code (in some package, existing or not?) that would be able > > to access

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

Dear Thierry, Le jeudi 01 décembre 2016 à 22:56 +0100, Thierry a écrit : > Hi, > > On Sun, Nov 27, 2016 at 03:52:59AM -0800, Emmanuel Charpentier wrote: > > OK. Let's try again : > > I have two questions : > > > >    1. What are the parts (standard, optional or experimental, > > except, of  > >

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

Le samedi 03 décembre 2016 à 10:07 +0100, Jeroen Demeyer a écrit : > On 2016-12-02 12:50, Emmanuel Charpentier wrote: > > Le jeudi 1 décembre 2016 23:47:40 UTC+1, Volker Braun a écrit : > > > > On Linux, you can build Sage with and without openssl. If you > > ever > > hit the network > >

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

Hi, On Fri, Dec 02, 2016 at 03:50:07AM -0800, Emmanuel Charpentier wrote: [...] > As far as I can tell, everybody else will have someday to hit the network > (at least for PIP packages...). It is not always possible. At least many users of Sage Debian Live from places where there is not (much)

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

> On 3/12/2016, at 22:00, Jeroen Demeyer wrote: > > On 2016-12-02 09:21, Thierry wrote: >> Would it be >> preferable to have this possibility dealt at configure time > > Absolutely. Whatever you do, do *NOT* introduce a new environment variable. > Use a configure

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

On 2016-12-02 12:50, Emmanuel Charpentier wrote: Le jeudi 1 décembre 2016 23:47:40 UTC+1, Volker Braun a écrit : On Linux, you can build Sage with and without openssl. If you ever hit the network Who doesn't ? The 95% of Sage users who just uses Sage for computations and doesn't

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

On 2016-12-02 09:21, Thierry wrote: Would it be preferable to have this possibility dealt at configure time Absolutely. Whatever you do, do *NOT* introduce a new environment variable. Use a configure option instead. -- You received this message because you are subscribed to the Google