Re: [sage-support] Re: SAGE and .NET interoperability.
On Fri, 2010-01-08 at 07:10 -0800, Dima Pasechnik wrote: > > On Jan 8, 11:02 pm, Dag Sverre Seljebotn > wrote: > > On Fri, 2010-01-08 at 06:51 -0800, dimpase wrote: > > > > > On Jan 8, 9:59 pm, kcrisman wrote: > > > > > no, it doesn't give you *any* reasonable figures, at all! > > > > > In fact, I am sure lots of people (a vast majority) are running Cygwin > > > > > (or Mingw - a clone of Cygwin) apps on their Windows boxes without > > > > > even realising this. Cygwin works quietly behind the scenes here. > > > > > > That is very interesting. When you say "a vast majority", can you > > > > give an example of a specific application people are using? That > > > > could be good to know about. > > > > > a good and relevant to Sage example is GAP (which is also available > > > from within Sage) > > > A binary distribution of GAP for Windows consists (apart from the > > > common to all platforms code in GAP language etc) of an executable > > > built in Cygwin environment and linked against the Cygwin DLL, and the > > > latter DLL itself (and a DOS batch file to start the thing up). > > > That's all you need to run GAP on Windows, no fullblown Cygwin > > > environment is needed. > > > (you can try it yourself:www.gap-system.org) > > > > > > Also, from earlier in the discussion it sounded like it was possible > > > > to make Sage-Cygwin be a one-step download, e.g. > > > > > > 1. Download sage-cygwin.msi > > > > 2. Double click and click through an install process > > > > 3. Click the icon for sage-cygwin and begin using Sage > > > > > > If that is possible, that would be fantastic. Up to now my > > > > understanding was that one first had to download Cygwin and install/ > > > > configure it, then download the Sage install and hope that it > > > > cooperated with Cygwin on one's computer. > > > no, I don't see any reason for this being impossible (see above). GAP > > > is basically like this, although it's packaged using zip... > > > > Well Sage is a bit different than this because you'd want the full set > > of tools for easy porting of SPKGs -- bash, tar, make, gcc, ... > > well, that's if you want to do Sage development, isn't it? > (I'd be surprised if Sage needs a gcc compiler for a binary install) Well, the installation of optional SPKGs currently relies on the availability of a compiler. If you are happy with loosing optional SPKGs then you are right. In theory one could introduce the concept of "binary SPKGs" (though I'd take a hard look at alternative, pre-written distribution mechanisms first). Dag Sverre -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] Re: SAGE and .NET interoperability.
On Fri, 2010-01-08 at 06:51 -0800, dimpase wrote: > > On Jan 8, 9:59 pm, kcrisman wrote: > > > no, it doesn't give you *any* reasonable figures, at all! > > > In fact, I am sure lots of people (a vast majority) are running Cygwin > > > (or Mingw - a clone of Cygwin) apps on their Windows boxes without > > > even realising this. Cygwin works quietly behind the scenes here. > > > > That is very interesting. When you say "a vast majority", can you > > give an example of a specific application people are using? That > > could be good to know about. > > a good and relevant to Sage example is GAP (which is also available > from within Sage) > A binary distribution of GAP for Windows consists (apart from the > common to all platforms code in GAP language etc) of an executable > built in Cygwin environment and linked against the Cygwin DLL, and the > latter DLL itself (and a DOS batch file to start the thing up). > That's all you need to run GAP on Windows, no fullblown Cygwin > environment is needed. > (you can try it yourself: www.gap-system.org) > > > > Also, from earlier in the discussion it sounded like it was possible > > to make Sage-Cygwin be a one-step download, e.g. > > > > 1. Download sage-cygwin.msi > > 2. Double click and click through an install process > > 3. Click the icon for sage-cygwin and begin using Sage > > > > If that is possible, that would be fantastic. Up to now my > > understanding was that one first had to download Cygwin and install/ > > configure it, then download the Sage install and hope that it > > cooperated with Cygwin on one's computer. > no, I don't see any reason for this being impossible (see above). GAP > is basically like this, although it's packaged using zip... Well Sage is a bit different than this because you'd want the full set of tools for easy porting of SPKGs -- bash, tar, make, gcc, ... But they are just a few extra .exe files, really. There's likely no reason they couldn't be bundled with a Sage one-click installer and installed inside the sage /local/bin directory. There's no reason the user would need to ever see those tools unless one were debugging SPKG build failures etc. -- "!cmd" could always be manually redirected to Windows cmd.exe. For the more ambitious one could move away from SPKGs and find a fancier package solution with Windows compatability, leaving the DLL as the only trace of Cygwin (I don't really see the point though -- Cygwin is pretty small compared to a lot of the other stuff bundled with Sage!) Dag Sverre -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] SAGE and .NET interoperability.
Jaap Spies wrote: > Dr. David Kirkby wrote: >> William Stein wrote: >> But that is very different from a native Windows port, which was I thought we were talking about. >>> We are talking about porting Sage to windows. I will leave it to the >>> lawyers to define "native Windows port". >> Fair enough. >> >>> I strongly disagree with your assertion that Cygwin would be vastly >>> inferior to VirtualBox for Windows users.How much have you used >>> VirtualBox or Cygwin? I've used both for hundreds of hours, and I've >>> also listened to and watched tons of Windows users.Sage built >>> using Cygwin would be vastly better for most Windows users than >>> VirtualBox. >>> >>> -- William >> I've not used either very much, but of the two, I much prefer VirtualBox. >> Personally I was never over impressed with Cygwin, but I find Virtualbox very >> impressive. >> > > I've used both. If I remember correctly cygwin-0.18-alpha in the years about > 1995. > I loved to have a unix like environment in the Windows world. > > I remember compiling Sage in cygwin took centuries, as opening a file took > ages :( > > Maybe times have changed. Looking forward to a cygwin build of Sage. > > VirtualBox has its own virtues. Let alone we could install Windows-whatever > in VirtualBox, install cygwin and try to install Sage with it :) Has anybody tried Microsoft's SUA (Unix compatability layer on Windows)? It uses gcc as the default compiler, seems to support 64-bit... It comes preinstalled (though must be turned on) on Windows Ultimate and Enterprise versions. So I guess it's harder to create a one-click installer that will "just work with Windows", but SUA support would e.g. allow a lot of universities to install Sage on their Windows boxes. I know nothing more and don't have access to a Windows box; recent thread on cython-dev and www.interix.com has some more details. -- Dag Sverre -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] Re: An abbreviation for lambda?
Robert Bradshaw wrote: > On Dec 14, 2009, at 11:43 AM, Carlos Córdoba wrote: > >> I have to agree with Marshall, because it could be confusing for new >> sage users that come from python to see such a different syntax >> meaning. >> >> But what about the Mathematica syntax? Could it be adopted by sage? > > The Mathematica syntax is (in my opinion) much less Pythonic than > using "->" in this context, even if the latter will have another > meaning in Python 3. Does the CAS syntax really mean Python "lambda" though? I would think that using -> in Maple would define something symbolic which one could manipulate...more like an anonymous f(x) = x**2 than "lambda x: x**2". For the latter one cannot find symbolic derivatives and so on. -- Dag Sverre -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] Re: An abbreviation for lambda?
Jason Grout wrote: > kcrisman wrote: > >> On Dec 14, 9:19 am, Carlos Córdoba wrote: >> >>> I don't think it would be so hard to do but this could break >>> interoperability with Python, the language on which Sage is based. Besides >>> it could make Sage like a dialect of python, something that sage devs don't >>> want to do. >>> >>> Unfortunately python is not a very friendly functional programming >>> language, although it has some constructs that can help you if you like to >>> do things in the functional style. >>> >>> Hope this helps, >>> Carlos >>> >>> 2009/12/13 Alasdair >>> >>> >>> >>> In some CAS's (Sage, Maxima), the "lambda" construct is used for an anonymous function: p=prime_range(30) map(lambda x:x^2+1,p) whereas in others, an arrow notation is used: map(x->x^2+1,p) (Maple, MuPAD) map(x+->x^2+1,p) (Axiom) I'm very fond of the convenience of arrow notation. Would it be very hard to incorporate such a notation into the Sage parser? >> If this would cause a Python syntax error, then presumably foo -> bar >> could be turned into lambda foo: bar, which would be completely >> native. Perhaps someone who is quite familiar with the preparser will >> comment. But this seems like a reasonable thing to add, particularly >> for those coming from Maple. What does Mathematica do for such >> anonymous functions (if anything)? >> > > > It looks like -> might cause a syntax error, at least in a trivial case: > > sage: x -> x^2 > > File "", line 1 > x -> x**Integer(2) > ^ > SyntaxError: invalid syntax > > > We currently print out things in sort of functional notation: > > sage: f(x)=x^2 > sage: f > x |--> x^2 > > I don't know if it's a good idea to make this valid Sage syntax, though. > I'm on the fence, but leaning towards not favoring it just because > of the added complexity and the departure from true Python, and the > python version isn't all that bad. > Note that -> gets a meaning in Python 3, to annotate the result of a function: def foo(a: int) -> float: ... I don't think this is a technical problem as one can rely on the statement to start with "def", but at least -> already means something. Dag Sverre -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: random number generation from cython
Flavio Coelho wrote: > Thanks for the pointer, > > but randstate.pyx, which allows one to choose between differents RNGs, > offers the built-in python RNG as a python object. > > on line 561 it does a > import random > rand = random.Random() > return rand > > What I am looking for is a way to call the C function behind > random.random directly from Cython, thus saving the overhead of a > python call. check the performance difference of the two calls from > the cython snippets below: > > %cython > %timeit > from random import random > cdef int i > for i in xrange(1): > random() > > CPU time: 11.78 s, Wall time: 13.13 s > > %cython > %timeit > cdef extern from "stdlib.h": > long c_libc_random "random"() > void c_libc_srandom "srandom"(unsigned int seed) > cdef int i > for i in xrange(1): > c_libc_random() > > CPU time: 1.85 s, Wall time: 3.11 s > > Now, the above code would suffice me if the documentation of > randstate.pyx didn't mention explicitly that the RNG from libc is of > poor quality and to be avoided. Moreover, by using the RNG built into > Python, I guarantee reproducibility across platforms (I think) and > avoid external dependencies... If you look at the sources for the random module in Python you'll see that this essentially can't be done -- it's all declared static in the C file creating the "_random" module. Of course, if it is for some reason *very* important to have the Python RNG, you could copy&paste the source code from Python. Then you have full control. (But I think you could probably just as well use another of Sage's PRNG). Then there's NumPy's PRNG (yet another one) where you can draw as many numbers at the time as you wish in an array, then access them afterwards using Cython's fast array access. Then the Python call is only done once regardless of N (but you need enough memory...) randnums = numpy.random.uniform(size=1) -- Dag Sverre --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Python lists and removals
Robert Bradshaw wrote: > On Oct 27, 2009, at 3:15 AM, Francois Maltey wrote: > > >> Hello, >> >> I'm an old lisp-list user and python is my first use of dynamic >> array-list. >> >> Complexity for lisp-list is constant and fast o(1) when we add a new >> element at the head of the list. >> (cons e L) in Lisp or e::L in caml. >> >> Complexity is also o(1) when we take the end of the list, or read the >> first term. >> (cdr L) and (car L) in Lisp, or hd L and tl L in caml. >> >> In theses cases the list L remains the same. >> >> Can I see in python that L[-1], L.push() and L.pop() are always fast >> in >> constant time ? >> > > If you really want to see, you could look at the source or benchmark it. > > >> The only difference is about the global change of L in sage and >> python. >> >> Python lists have also constant time for reading an element L[k] and >> get >> the length L.len. >> For lisp-list theses two times are not constant and may be long for >> long >> lists. >> >> And the python code must either never use the previous value of L, or >> copy the list, but it may be long... >> And it must be always exclude to change the list L in a loop over L. >> >> Do you know standard algorithms which are better with python and >> impossible with lists ? >> I think it's mainly that "the average Python programmer" tends to use random indexing a lot more than remove(), and so list is optimized for that common use pattern. Those who actually think about algorithms, complexity etc. can be assumed to be able to switch another better suited type if needed. (Also, everything else being equal, a dynamic array uses 1/2 the memory as there's no need for pointers between elements). Dag Sverre --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Python lists and removals
kcrisman wrote:
> Dear support,
>
> I'm trying to resolve #7315 and have discovered something that
> disturbs me, but probably is reasonable to someone who really
> understands Python lists. Namely:
>
> {{{
L=[1,2,3,4]
for x in L:
> ... L.remove(x)
> ... x
> ... L
> ...
> 1
> [2, 3, 4]
> 3
> [2, 4]
L
> [2, 4]
> }}}
>
> Somehow it is going by the index of the list, not the actual
> elements. Assuming this is intended behavior, what is the right
> workaround? Any link to the official Python documentation would be
> wonderful as well.
As you say, the iterator goes by index. This isn't really "solvable" the
way you seem to expect because of how lists fundamentally work. Workarounds:
a) for x in L[:]: ... # makes a copy
b) remove from the end of the list...
If your list is big: Note that removing from the middle of a list is
going to be expensive since the remainder of the list is copied for each
iteration. You should consider alternative ways of expressing your
algorithm (or, if you have to do this, look around for a linked list
implementation for Python).
Removing from the end is cheap, so is removing from either end using
collections.deque.
--
Dag Sverre
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: graphic with R statistic program
Vincent Delecroix wrote:
> Hi,
>
> I'm working on simple statistic example for which I use the SAGE
> interface of the R program. I'm not able to plot a graphic.
>
> In R we use :
> {{{
> R: x <- (1, 1, 1, 2, 3, 3, 4, 5, 5, 6)
> R: hist(x)
> }}}
>
> I try the following in SAGE (version 4.1) :
> {{{
> sage: x = r("c(1, 1, 1, 2, 3, 3, 4, 5, 5, 6)")
> sage: r.hist(x)
> ...
> }}
>
> The last command returns a strange objects, which does not plot
> anything ! In the documentation string of the r.hist object, it is
> asked to set a plot parameter to TRUE (in upper case, which is the R
> syntax). I tried the following without success :
> {{{
> sage: r.hist(x, plot=True)
> ...
> }}}
>
> Does anybody know how to use graphic functions from R ?
>
You probably need to set up a graphics device. Try e.g
r.png('testfile.png')
# then plot
# then:
r.dev_off()
Dag Sverre
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: changeing sage -b (cython)
Robert Bradshaw wrote: > On Jul 29, 2009, at 1:14 PM, dagss wrote: > >> On Jul 29, 7:22 pm, Robert Bradshaw >> wrote: >>> On Jul 29, 2009, at 9:46 AM, Dag Sverre Seljebotn wrote: >>> >>> >>> >>>> Robert Bradshaw wrote: >>>>> I'm not sure if or when either of these will be available, but >>>>> neither are trivial. Both questions are probably better asked on >>>>> the >>>>> cython lists. >>>>> - Robert >>>>> On Jul 22, 2009, at 12:17 PM, Ethan Van Andel wrote: >>>>>> Robert, >>>>>> Is there any prediction for when numpy complex types will work? >>>>>> (outside of the notebook, when compiling via sage -b) >>>> I assume this will happen when Cython is upgraded in Sage, i.e. >>>> #6438 / >>>> 4.1.1. If it doesn't, please send cython-dev (or me if you can't be >>>> bothered) a mail. >>> No, that doesn't work with plain Cython either. Perhaps we need to >>> require casting with extern typedefs? >> Ahh, of course; "Cython complex" (either C99 or custom structs) are >> not >> compatible with NumPy structs. >> >> I've selected this strategy: >> >> http://trac.cython.org/cython_trac/ticket/347 >> >> Fix is up in cython repo. > > Ah, that's a lot simpler than I was thinking of. So npy_complex128 > still doesn't work, but it's never used. Well, npy_complex128 should probably be used if one is e.g. using PyArray_GETITEM1. So the two fills different purposes. -- Dag Sverre --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
