Re: [sage-devel] On scientific computing, Python and Julia
Dear RJF, Dear list, This was an interesting read and I have learnt some things: * I wrongly assumed floating point in computer context to mean sign bit, fixed range for mantissa, fixed range for exponent, special cases for -inf, +inf, +0, -0, nan. * I think Sage's RealField(prec) is more accurately called fixed-precision floating-point than arbitrary-precision floating-point, since range of mantissa and exponent are fixed once prec is known. * Priest's Algorithms for Arbitrary Precision Floating Point Arithmetic is an interesting read, and made me realize the above. * I wrongly assumed the truncated power series to be QQ[[t]]/t^n for some fixed non-negative integer n. * I should not be participating in threads like these. They take too much time that should be spent on work. I also have a question: * Is there a definition of computational domain? If so, do you have some pointers? That'd be interesting. Regards, Erik Massop On Wed, 20 Aug 2014 16:47:03 -0700 (PDT) rjf fate...@gmail.com wrote: On Saturday, August 9, 2014 7:35:13 PM UTC-7, Erik Massop wrote: Similarly I would call RealField(prec) a field, because it represents the field of real numbers (e.g. Dedekind cuts). At the same time I am sure that some mathematical properties that I know from the mathematical field of real numbers will not hold in RealField(prec). So it seems to me that you should not call it a Field. Here's the inverse. Or maybe contrapositive. As a riddle: How many legs does a sheep have if you call its tail a leg? (Answer later...) Luckily Sage readily admits that RealField(prec) is not an exact representation of the mathematical field of real numbers: sage: F = RealField(100) sage: F.is_exact() False Hardly luck, but random insertion of a fact in a way similar to the riddle. (Answer later) I agree that it is imprecise that when using F.is_field(), we are asking whether the mathematical object of real numbers is a field, while when using F.is_exact() we are asking whether the representation is exact. By the way, there also is AA or AlgebraicRealField() in Sage, which is an exact representation of the real closed field of algebraic real numbers. ... The domain of arbitrary-precision integers is an excellent model of the ring of integers. It is true that one can specify a computation that would fill up the memory of all the computers in existence. or even all the atoms in the (known?) universe. Presumably a well-constructed support system will give an error message on much smaller examples. I assume that your Real Field operation of division would give an error if the result is inexact. RealField(prec) is an inexact approximation of a field (as witnessed by is_exact), so I never expect the division to be exact. Oh, so it just gives wrong answers without a clue. In fact I don't expect addition, negation, multiplication, or subtraction to be exact either. Indeed, they are not exact: sage: a = 1e-58 sage: a 1.00e-58 sage: (1+a)-1 0.000 That's because it is not a field, and you know it. So why call it a field? Does Sage have other um, approximations, in its nomenclature? Sure. RealField(123)[x]. Power series rings. P-adics. These approximations are approximations by their nature. If you are computing with a power series, the concept inherently includes an error term which you are aware of. Real Field is (so far as I know) a concept that should have the properties of a field. The version in Sage does not. It's like saying someone isn't pregnant. well only a little pregnant. They're no more approximate by nature than the real numbers. Huh? How so? I was not aware that real numbers (at least the ones that you can construct) are approximate by nature. But maybe you can direct me to some reference on this. What do you mean by can construct? The computable reals perhaps? Those would indeed form an actual field. I am very unsure about how practical they are though. How about the rational numbers? Those you can easily construct. The computable reals are not fun to compute with in most application circumstances. Might we then not also have a ring of computable power series? That is, those power series given by an algorithm that given n returns the n'th term in finite time? It is not usually phrased that way, but given a collection of base functions as explicit power series and operations like composition, there is a computational domain of truncated power series. It is usually set up to NOT be a ring because of truncation issues. ... Power series (to make things concrete, say the power series in one variable over the integers) form a ring.
[sage-devel] __repr__ for RDF
Currently in Sage, we have sage: RR(2/3) 0.667 sage: float(2/3) 0. sage: RDF(2/3) 0.6667 It's annoying that all these 3 are exactly the same thing (53-bit precision floats with the same bit pattern), but all 3 have a different __repr__. I noticed this in a doctest failure #16858 (a float was expected, but an RDF element was returned). The easy thing to do would be to just fix those doctests. However, I would actually like to make the __repr__ of RDF consistent with the __repr__ of Python floats (except maybe NaN and infinity values, which are currently special-cased anyway). The change itself is quite easy, but it obviously gives massive amounts of doctest failures. I personally don't mind fixing those, but I wanted to ask for opinions here, since that change will have a significant impact. Everything I said about RDF also applies to CDF, I would change that also. Opinions? Jeroen. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
On Wednesday, August 20, 2014 4:54:35 AM UTC+2, Bill Hart wrote: Oh what a shame I missed the party. And I don't have time to read all the wonderfully eloquent nonsense in this thread. So, since we both are the only remaining hangover crowd, I've one last question about Julia: But I think Julia is good for a few years yet. It's one of the few truly 21st century programming languages available. All your arguments center around technical arguments: speed, efficiently maintenance of exponentially growing complexities in codebases, etc. Those are without question desirable properties. What's missing for me is the other side for the actual humble user of this. Python's roots are in ABC (which does not stand for abstract base classes, but for the effort to produce a human friendly programming language as a basic successor). Does Julia have such goals? Second question is about multi-dispatch, and goes in the same direction: Given I have an object behind x, is there a x.[TAB] which lists me what I can do with it? Or does this playful way of discovering functionalities work differently? -- H -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Sage at EuroSciPy?
Hi all, Is anybody planning to be at EuroScipy 2014 next week in Cambridge? https://www.euroscipy.org/2014/ Any Sage or SageMathCloud projects that could benefit from an impromptu sprint? All the best, Joris -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] William Stein says Sage has overall failed
Surprisingly, sometimes Reddit contains actual discussions: http://www.reddit.com/r/math/comments/2e3qla/william_stein_says_sage_has_overall_failed/ -- H -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [sage-cloud-internal] William Stein says Sage has overall failed
On Thu, Aug 21, 2014 at 12:16 PM, Harald Schilly harald.schi...@gmail.com wrote: Surprisingly, sometimes Reddit contains actual discussions: http://www.reddit.com/r/math/comments/2e3qla/william_stein_says_sage_has_overall_failed/ I just read through it. It might be one reason that there were over 250 new SageMathCloud accounts in the last 24 hours, but that might also be partly due to the new semester/quarter. Thanks to all the knowledgable Sage contributors that answered questions in that thread. The title they gave it -- 'William Stein says Sage has overall failed' -- seems a bit sensational. I think that if people read the blog post they will see that I don't mean that the enormous effort that people like Volker, Jereon, etc., are doing, isn't a fantastic job. I'm measuring progress specifically in terms of the original mission statement. -- William -- H -- You received this message because you are subscribed to the Google Groups sage-cloud-internal group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-cloud-internal+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-cloud-internal. For more options, visit https://groups.google.com/d/optout. -- William Stein Professor of Mathematics University of Washington http://wstein.org wst...@uw.edu -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: __repr__ for RDF
On 2014-08-21, Jeroen Demeyer jdeme...@cage.ugent.be wrote: Currently in Sage, we have sage: RR(2/3) 0.667 sage: float(2/3) 0. sage: RDF(2/3) 0.6667 It's annoying that all these 3 are exactly the same thing (53-bit precision floats with the same bit pattern), but all 3 have a different __repr__. I noticed this in a doctest failure #16858 (a float was expected, but an RDF element was returned). The easy thing to do would be to just fix those doctests. However, I would actually like to make the __repr__ of RDF consistent with the __repr__ of Python floats (except maybe NaN and infinity values, which are currently special-cased anyway). The change itself is quite easy, but it obviously gives massive amounts of doctest failures. I personally don't mind fixing those, but I wanted to ask for opinions here, since that change will have a significant impact. Everything I said about RDF also applies to CDF, I would change that also. Opinions? I think it's a great idea, and will reduce the confusion level quite a bit; what precision will you choose as the right one? float() ? Jeroen. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: __repr__ for RDF
On 2014-08-21 15:05, Dima Pasechnik wrote: I think it's a great idea, and will reduce the confusion level quite a bit; what precision will you choose as the right one? I will simply use the repr() function for Python floats (except for NaN and infinities). -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
* I think Sage's RealField(prec) is more accurately called fixed-precision floating-point than arbitrary-precision floating-point, since range of mantissa and exponent are fixed once prec is known. Yes, and although I am not an expert in such things, I always point this out in tutorials. I don't know how often people make this mistake, though. * I should not be participating in threads like these. They take too much time that should be spent on work. Yup, correct again! But you had some valuable contributions and learned something, so it wasn't a total waste. - kcrisman -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [sage-cloud-internal] William Stein says Sage has overall failed
The title they gave it -- 'William Stein says Sage has overall failed' -- seems a bit sensational. I think that if people read the blog post they will see that I don't mean that the enormous effort that people like Volker, Jereon, etc., are doing, isn't a fantastic job. I'm measuring progress specifically in terms of the original mission statement. To be fair, you did kind of invite that interpretation with a somewhat dramatic line like that. Sage clearly IS a viable alternative, and basically is a replacement at the undergraduate level. It is not a replacement for everything - perhaps we need a jump like the combinat and matroid crowds did in arithmetic geometry? But neither are they replacements for Sage at this point, right, in many areas? Again, Sage is a viable alternative even for Matlab. It's not as good for this as Octave, apparently, and no third-party support etc. - but some people do use it, or they wouldn't be asking for help. So I think that it would have been better to say that the statement that has failed is a viable *replacement* for all four M's. Well, that would be a hard goal indeed! For precisely the reasons you give. I don't think that makes Sage a failure, it just makes it different. Presumably Maple and Mathematica are not replacements for each other either. - kcrisman -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: __repr__ for RDF
+1 There is another ticket that'll require some larger scale fixing of doctests at http://trac.sagemath.org/ticket/16746... On Thursday, August 21, 2014 8:07:22 AM UTC+1, Jeroen Demeyer wrote: Currently in Sage, we have sage: RR(2/3) 0.667 sage: float(2/3) 0. sage: RDF(2/3) 0.6667 It's annoying that all these 3 are exactly the same thing (53-bit precision floats with the same bit pattern), but all 3 have a different __repr__. I noticed this in a doctest failure #16858 (a float was expected, but an RDF element was returned). The easy thing to do would be to just fix those doctests. However, I would actually like to make the __repr__ of RDF consistent with the __repr__ of Python floats (except maybe NaN and infinity values, which are currently special-cased anyway). The change itself is quite easy, but it obviously gives massive amounts of doctest failures. I personally don't mind fixing those, but I wanted to ask for opinions here, since that change will have a significant impact. Everything I said about RDF also applies to CDF, I would change that also. Opinions? Jeroen. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
On Thursday, 21 August 2014 10:58:36 UTC+2, Harald Schilly wrote:
On Wednesday, August 20, 2014 4:54:35 AM UTC+2, Bill Hart wrote:
Oh what a shame I missed the party. And I don't have time to read all the
wonderfully eloquent nonsense in this thread.
So, since we both are the only remaining hangover crowd, I've one last
question about Julia:
But I think Julia is good for a few years yet. It's one of the few truly
21st century programming languages available.
All your arguments center around technical arguments: speed, efficiently
maintenance of exponentially growing complexities in codebases, etc.
Those are without question desirable properties. What's missing for me is
the other side for the actual humble user of this.
Python's roots are in ABC (which does not stand for abstract base classes,
but for the effort to produce a human friendly programming language as a
basic successor). Does Julia have such goals?
I think it manifestly does. Julia was inspired by Lisp, Python and a third
language that I forgot. The syntax is very pythonic, where the language
doesn't fundamentally deviate from the paradigm python belongs to. I would
say I'm far more productive in Julia than I could be in Python. It makes
easy things easy, intermediate things intermediate and difficult things
feasible. Python does not do this. Many difficult things are nearly
impossible in Python and many intermediate things are very hard.
Second question is about multi-dispatch, and goes in the same direction:
Given I have an object behind x, is there a x.[TAB] which lists me what I
can do with it?
Yes. Note the dot notation is not used in Julia. It uses a different
paradigm (multi-methods, not classes). The Julia approach is much easier
and far less restrictive than the usual OO paradigm.
Given a type A I can do methodswith(A) and it will list all methods that
use type A *anywhere* in their prototype.
But the focus in Julia is usually on functions, not objects. So it is more
usual in practice to be writing methods(A) where A is the name of a
*constructor* for a type (usually also called A). The constructor for A is
a generic function with numerous methods, and methods(A) will give you a
short list of methods that can be used to construct A (which usually won't
have A at all in their prototype -- unless you count the return value --
yes, it would appear explicitly in the prototype in Python and implicitly
in the prototype in C++, but not in Julia which doesn't overload on return
type).
Or does this playful way of discovering functionalities work differently?
It does. But it is extremely practical.
There's also an online help system baked right into Julia. So you can get
help on any function, method, type, etc. And this is generated
automatically, though you can add your own documentation to that system
easily.
It's also trivial to extend Julia's assistance to the user in whatever way
you like. One of my favourite things is the ability to be able to overload
the show method for any given type and any given value of any type. Doing
the former will change the way the type is displayed. E.g.
julia R, x = PolynomialRing(ZZ, x)
(Univariate polynomial ring in x over ZZ,x)
Note that the type R is really Poly{ZZ, :x} in Julia's notation. But we
overload the show method to display (Univariate polynomial ring in ,
string(:x), over , ZZ).
And the polynomial x would usually be displayed as Poly(2, 2,
0xa56c4856727f0a40). We overload the show method to display x.
I personally think Julia dominates most other languages entirely. I would
certainly include Python in that. I can't think of a single feature of
Python I would miss in Julia, including easy to use syntax.
Some languages I think that aren't completely dominated by Julia are Rust,
D and Nimrod, and to some degree C++, though it certainly completely
dominates more areas of C++ than those other languages.
When I say some languages I'm only referring to languages with imperative
syntax. There are functional languages that aren't strictly comparable.
Note, Julia is not some obscure unheard of language. It gets 150,000 visits
a month to its website. And it is gaining popularity rapidly. There are
already hundreds of user contributed packages for Julia (which by the way
you can download into any Julia session connected to the internet by typing
Pkg.add(name of package).
I doubt it would be this popular if it had awkward syntax.
Take a look at my Nemo documentation and see if you feel comfortable with
the syntax:
http://www.flintlib.org/nemo.pdf
Note that Nemo is Julia, in the same way as Sage is Python. There is no
preparser used in Nemo.
Julia is not the best possible language for computer algebra. I list some
of the issues I have with it in my nemo.pdf above. But the Julia developers
are actively thinking about some of those. It's even possible that Julia
will always suffice and I'll
Re: [sage-devel] On scientific computing, Python and Julia
Sorry, my answer to your question about tab completion was incomplete. I
posted it before rereading it.
You can define the A.b syntax in Julia if you should so desire. It's
essentially just another kind of method overload in Julia.
And then, it supports A.tab giving a list of all the things that could
follow the dot, just as Python would.
For example Pkg.tab yields:
Pkg.Cache Pkg.Resolve Pkg.edit Pkg.register
Pkg.DEFAULT_META Pkg.Types Pkg.eval Pkg.release
Pkg.Dir Pkg.Write Pkg.fix Pkg.resolve
Pkg.Entry Pkg.add Pkg.fixup Pkg.rm
Pkg.Generate Pkg.available Pkg.free Pkg.status
Pkg.META_BRANCH Pkg.build Pkg.generate Pkg.tag
Pkg.Pkg Pkg.cdPkg.installed Pkg.update
Pkg.Query Pkg.checkout Pkg.init
Pkg.Read Pkg.clone Pkg.pin
Pkg.Reqs Pkg.dir Pkg.publish
But you have to ask yourself how useful that actually is. If you want to
write Python in Julia, I suppose it is useful. But the Julia paradigm is
different to the Python paradigm. You might actually find that Julia is not
generically used that way very much.
On Thursday, 21 August 2014 17:26:50 UTC+2, Bill Hart wrote:
On Thursday, 21 August 2014 10:58:36 UTC+2, Harald Schilly wrote:
On Wednesday, August 20, 2014 4:54:35 AM UTC+2, Bill Hart wrote:
Oh what a shame I missed the party. And I don't have time to read all
the wonderfully eloquent nonsense in this thread.
So, since we both are the only remaining hangover crowd, I've one last
question about Julia:
But I think Julia is good for a few years yet. It's one of the few truly
21st century programming languages available.
All your arguments center around technical arguments: speed, efficiently
maintenance of exponentially growing complexities in codebases, etc.
Those are without question desirable properties. What's missing for me is
the other side for the actual humble user of this.
Python's roots are in ABC (which does not stand for abstract base
classes, but for the effort to produce a human friendly programming
language as a basic successor). Does Julia have such goals?
I think it manifestly does. Julia was inspired by Lisp, Python and a
third language that I forgot. The syntax is very pythonic, where the
language doesn't fundamentally deviate from the paradigm python belongs to.
I would say I'm far more productive in Julia than I could be in Python. It
makes easy things easy, intermediate things intermediate and difficult
things feasible. Python does not do this. Many difficult things are nearly
impossible in Python and many intermediate things are very hard.
Second question is about multi-dispatch, and goes in the same direction:
Given I have an object behind x, is there a x.[TAB] which lists me what I
can do with it?
Yes. Note the dot notation is not used in Julia. It uses a different
paradigm (multi-methods, not classes). The Julia approach is much easier
and far less restrictive than the usual OO paradigm.
Given a type A I can do methodswith(A) and it will list all methods that
use type A *anywhere* in their prototype.
But the focus in Julia is usually on functions, not objects. So it is more
usual in practice to be writing methods(A) where A is the name of a
*constructor* for a type (usually also called A). The constructor for A is
a generic function with numerous methods, and methods(A) will give you a
short list of methods that can be used to construct A (which usually won't
have A at all in their prototype -- unless you count the return value --
yes, it would appear explicitly in the prototype in Python and implicitly
in the prototype in C++, but not in Julia which doesn't overload on return
type).
Or does this playful way of discovering functionalities work differently?
It does. But it is extremely practical.
There's also an online help system baked right into Julia. So you can get
help on any function, method, type, etc. And this is generated
automatically, though you can add your own documentation to that system
easily.
It's also trivial to extend Julia's assistance to the user in whatever way
you like. One of my favourite things is the ability to be able to overload
the show method for any given type and any given value of any type. Doing
the former will change the way the type is displayed. E.g.
julia R, x = PolynomialRing(ZZ, x)
(Univariate polynomial ring in x over ZZ,x)
Note that the type R is really Poly{ZZ, :x} in Julia's notation. But we
overload the show method to display (Univariate polynomial ring in ,
string(:x), over , ZZ).
And the polynomial x would usually be displayed as Poly(2, 2,
0xa56c4856727f0a40). We overload the show method to display x.
I personally think Julia dominates most other languages entirely. I would
certainly include
Re: [sage-devel] On scientific computing, Python and Julia
I should probably add, since it might excite you Harald, that most syntax
in Julia does not actually exist in the language proper. Much of the syntax
is defined in library code, e.g. array access, the dot notation and all
sorts of other things.
But because of the way Julia operates, all of that does not come with a
runtime penalty. You can see from Stefan's examples above that many
abstractions in Julia come with zero runtime cost. So an array access, or
a range syntax, or a dot notation (well, in the next version anyway), etc,
can all be overloaded with user defined functions for any type, or
typeclass, or union of types or parameterised class of types, or whatever.
But those function calls don't result in a runtime penalty when used.
Thus the language is formally extensible at no cost and in an extremely
simple way that the user can easily do themselves. Again, total domination
of Python.
This is similar to the way Lisp was the first language to have OO, since
the language was formally extensible by the user, and so people just wrote
macros which did the OO stuff. The only difference is, that was hard to do
unless you understood a lot about metaprogramming in Lisp. In Julia, anyone
can do it.
julia getindex(a::Array{Int, 1}, b::Int) = print(test)
getindex (generic function with 140 methods)
julia a = [1, 2]
2-element Array{Int,1}:
1
2
julia a[2]
test
Bill.
On Thursday, 21 August 2014 17:36:20 UTC+2, Bill Hart wrote:
Sorry, my answer to your question about tab completion was incomplete. I
posted it before rereading it.
You can define the A.b syntax in Julia if you should so desire. It's
essentially just another kind of method overload in Julia.
And then, it supports A.tab giving a list of all the things that could
follow the dot, just as Python would.
For example Pkg.tab yields:
Pkg.Cache Pkg.Resolve Pkg.edit Pkg.register
Pkg.DEFAULT_META Pkg.Types Pkg.eval Pkg.release
Pkg.Dir Pkg.Write Pkg.fix Pkg.resolve
Pkg.Entry Pkg.add Pkg.fixup Pkg.rm
Pkg.Generate Pkg.available Pkg.free Pkg.status
Pkg.META_BRANCH Pkg.build Pkg.generate Pkg.tag
Pkg.Pkg Pkg.cdPkg.installed Pkg.update
Pkg.Query Pkg.checkout Pkg.init
Pkg.Read Pkg.clone Pkg.pin
Pkg.Reqs Pkg.dir Pkg.publish
But you have to ask yourself how useful that actually is. If you want to
write Python in Julia, I suppose it is useful. But the Julia paradigm is
different to the Python paradigm. You might actually find that Julia is not
generically used that way very much.
On Thursday, 21 August 2014 17:26:50 UTC+2, Bill Hart wrote:
On Thursday, 21 August 2014 10:58:36 UTC+2, Harald Schilly wrote:
On Wednesday, August 20, 2014 4:54:35 AM UTC+2, Bill Hart wrote:
Oh what a shame I missed the party. And I don't have time to read all
the wonderfully eloquent nonsense in this thread.
So, since we both are the only remaining hangover crowd, I've one last
question about Julia:
But I think Julia is good for a few years yet. It's one of the few
truly 21st century programming languages available.
All your arguments center around technical arguments: speed, efficiently
maintenance of exponentially growing complexities in codebases, etc.
Those are without question desirable properties. What's missing for me is
the other side for the actual humble user of this.
Python's roots are in ABC (which does not stand for abstract base
classes, but for the effort to produce a human friendly programming
language as a basic successor). Does Julia have such goals?
I think it manifestly does. Julia was inspired by Lisp, Python and a
third language that I forgot. The syntax is very pythonic, where the
language doesn't fundamentally deviate from the paradigm python belongs to.
I would say I'm far more productive in Julia than I could be in Python. It
makes easy things easy, intermediate things intermediate and difficult
things feasible. Python does not do this. Many difficult things are nearly
impossible in Python and many intermediate things are very hard.
Second question is about multi-dispatch, and goes in the same direction:
Given I have an object behind x, is there a x.[TAB] which lists me what I
can do with it?
Yes. Note the dot notation is not used in Julia. It uses a different
paradigm (multi-methods, not classes). The Julia approach is much easier
and far less restrictive than the usual OO paradigm.
Given a type A I can do methodswith(A) and it will list all methods that
use type A *anywhere* in their prototype.
But the focus in Julia is usually on functions, not objects. So it is
more usual in practice to be writing methods(A) where A is the name of a
*constructor* for a type (usually also called A). The constructor for A is
a generic
[sage-devel] About pi?
Hellooo everybody ! Earlier today Vincent and I needed to enumerate some twin primes (integers x such that x and x+2 are both primes). We were lucky, for Sage contains a twinprimes object. sage: twinprime twinprime sage: twinprime(4) /home/ncohen/.Sage/local/lib/python2.7/site-packages/IPython/core/interactiveshell.py:2883: DeprecationWarning: Substitution using function-call syntax and unnamed arguments is deprecated and will be removed from a future release of Sage; you can use named arguments instead, like EXPR(x=..., y=...) See http://trac.sagemath.org/5930 for details. ... ValueError: the number of arguments must be less than or equal to 0 sage: twinprime() twinprime sage: twinprime()()()()()()()()()()()()() twinprime sage: twinprime()==twinprime twinprime == twinprime As you can see, it is not immediately obvious what this object is. And Sage's doc for twinprime? is not exactly... Explicit. Explanation: it turns out that for Sage, twinprimes is a constant, like pi, e, gamma, ... And for all these objects the documentation is the same, and for all of them the doc is a bit unclear. SOooo if somebody understands how these symbolic objects work, would it be possible to indicate it in their documentation ? I'm sure we can find quite interesting things to say about pi or e in Sage. And it would help the next guy solve the twinprimes mystery ;-) Have fuun ! Nathann -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
Incidentally, the whole argument type-dependent function dispatch is at the
core of the GAP language (though you have to recompile the GAP kernel to
change it). And GAP predates KR C.
On Thursday, August 21, 2014 4:56:12 PM UTC+1, Bill Hart wrote:
Thus the language is formally extensible at no cost and in an extremely
simple way that the user can easily do themselves.
Depends on your point of view. If you want to tie together different
third-party libraries then it can quickly become a liability that you can
just redefine everything.
julia getindex(a::Array{Int, 1}, b::Int) = print(test)
getindex (generic function with 140 methods)
Type this into the REPL on your colleague's computer who just left to get a
coffee and see if he ever figures that one out. My bet would be that he's
not going to get any work done until the next restart ;-)
--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: About pi?
We were lucky, for Sage contains a twinprimes object. sage: twinprime twinprime sage: twinprime(4) /home/ncohen/.Sage/local/lib/python2.7/site-packages/IPython/core/interactiveshell.py:2883: DeprecationWarning: Substitution using function-call syntax and unnamed arguments is deprecated and will be removed from a future release of Sage; you can use named arguments instead, like EXPR(x=..., y=...) See http://trac.sagemath.org/5930 for details. ... ValueError: the number of arguments must be less than or equal to 0 sage: twinprime() twinprime sage: twinprime()()()()()()()()()()()()() twinprime sage: twinprime()==twinprime twinprime == twinprime As you can see, it is not immediately obvious what this object is. And Sage's doc for twinprime? is not exactly... Explicit. Explanation: it turns out that for Sage, twinprimes is a constant, like pi, e, gamma, ... Indeed. I'm not sure how to fix this, though. http://git.sagemath.org/sage.git/tree/src/sage/symbolic/constants.py#n1149 In this class, we don't quite instantiate the nice documentation we actually have for TwinPrime r The Twin Primes constant is defined as `\prod 1 - 1/(p-1)^2` for primes `p 2`. EXAMPLES:: sage: float(twinprime) 0.6601618158468696 sage: twinprime.n(digits=60) 0.660161815846869573927812110014555778432623360284733413319448 but instead do TwinPrime().expression() which gets rid of all that useful info. Same for most such constants, I believe, so that they are in the symbolic ring/Ginac. Does anyone have a quick way to fix this? (Maybe even by getting rid of .expression() ?) I have wondered about this too but I knew what the twin prime constant was so I didn't run into it... but of course Nathann is right that this is not that helpful currently. - kcrisman -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
On Thursday, 21 August 2014 18:23:48 UTC+2, Volker Braun wrote:
Incidentally, the whole argument type-dependent function dispatch is at
the core of the GAP language (though you have to recompile the GAP kernel
to change it). And GAP predates KR C.
There are other languages which have used it. That's not particularly novel.
It's just the other way of doing object orientation.
There is one significant issue with it. To do arithmetic efficiently on
composite types, you need to be able to replace c = a*b with mul(c, a, b).
Using the class based approach, this is possible using metaprogramming. We
do this in flint. Unfortunately, the flint C++ module takes minutes per
file to compile and blows up many version of gcc and all versions of MSVC
(internal errors).
So it's not such a huge loss that you can't use template class
metaprogramming in a language like Julia (template class metaprogramming
has other major issues which make it essentially unusable in practice
anyway, such as needing to recompile to change anything).
I don't know a solution to the c = a*b = mul(c, a, b) problem. Nimrod
claims to have found some sort of solution, called term rewriting macros.
But I really don't know enough about them to evaluate their effectiveness
as a solution to this problem.
Julia will have to solve the problem some day, though it will be hard.
In my language I (theoretically) get around it by defining two kinds of
type. One is an arithmetic type, which has the above semantics. The other
is a usual type which has the usual semantics. But I've not fully
implemented the solution, so I don't know to what extent it can really be a
solution to the problem. Either way, it will be really, really hard to
implement in the compiler.
Bill.
On Thursday, August 21, 2014 4:56:12 PM UTC+1, Bill Hart wrote:
Thus the language is formally extensible at no cost and in an extremely
simple way that the user can easily do themselves.
Depends on your point of view. If you want to tie together different
third-party libraries then it can quickly become a liability that you can
just redefine everything.
julia getindex(a::Array{Int, 1}, b::Int) = print(test)
getindex (generic function with 140 methods)
Type this into the REPL on your colleague's computer who just left to get
a coffee and see if he ever figures that one out. My bet would be that he's
not going to get any work done until the next restart ;-)
--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
Oh, I should mention, the c = a*b = mul(c, a, b) problem is probably
soluble in D with a much cleaner and easier to compile solution than C++
offers. D metaprogramming is strictly more powerful than that of C++.
On Thursday, 21 August 2014 18:59:39 UTC+2, Bill Hart wrote:
On Thursday, 21 August 2014 18:23:48 UTC+2, Volker Braun wrote:
Incidentally, the whole argument type-dependent function dispatch is at
the core of the GAP language (though you have to recompile the GAP kernel
to change it). And GAP predates KR C.
There are other languages which have used it. That's not particularly
novel.
It's just the other way of doing object orientation.
There is one significant issue with it. To do arithmetic efficiently on
composite types, you need to be able to replace c = a*b with mul(c, a, b).
Using the class based approach, this is possible using metaprogramming. We
do this in flint. Unfortunately, the flint C++ module takes minutes per
file to compile and blows up many version of gcc and all versions of MSVC
(internal errors).
So it's not such a huge loss that you can't use template class
metaprogramming in a language like Julia (template class metaprogramming
has other major issues which make it essentially unusable in practice
anyway, such as needing to recompile to change anything).
I don't know a solution to the c = a*b = mul(c, a, b) problem. Nimrod
claims to have found some sort of solution, called term rewriting macros.
But I really don't know enough about them to evaluate their effectiveness
as a solution to this problem.
Julia will have to solve the problem some day, though it will be hard.
In my language I (theoretically) get around it by defining two kinds of
type. One is an arithmetic type, which has the above semantics. The other
is a usual type which has the usual semantics. But I've not fully
implemented the solution, so I don't know to what extent it can really be a
solution to the problem. Either way, it will be really, really hard to
implement in the compiler.
Bill.
On Thursday, August 21, 2014 4:56:12 PM UTC+1, Bill Hart wrote:
Thus the language is formally extensible at no cost and in an extremely
simple way that the user can easily do themselves.
Depends on your point of view. If you want to tie together different
third-party libraries then it can quickly become a liability that you can
just redefine everything.
julia getindex(a::Array{Int, 1}, b::Int) = print(test)
getindex (generic function with 140 methods)
Type this into the REPL on your colleague's computer who just left to get
a coffee and see if he ever figures that one out. My bet would be that he's
not going to get any work done until the next restart ;-)
--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: new layout breaks sagenb development?
I have set up a pull request to move the flask_version directory to inside sagenb. The documentation can be fixed later, but this should enable anyone to start working on sagenb dev immediately. I also checked that the newly generated sagenb tarball installs and works correctly. I've merged this. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: what is the plot3D viewer used in sagemath cloud
three.js, which is also available in SageCell (you have to call it explicitly as (threejs(plot(sin))), but they function differently. There are some threads on the notebook list about three.js problems. On Wednesday, 20 August 2014 14:19:52 UTC-6, Frédéric Chapoton wrote: Hello, I am trying in #12212 to allow plotting colored 3D surfaces. http://trac.sagemath.org/ticket/12212 So far, progress has been done on jmol, tachyon and canvas3D viewers. Does anybody know what is the viewer used in sagemath cloud ? -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
Let me be even more specific. If you could come up with a workable solution
to the c = a*b = mul(c, a, b) problem, you could write a paper on it and
get a lot of kudos for doing so. Even after 50 years, it's still
essentially an open problem in modern compiler design.
Move semantics and rvalue assignment in C++ gets you partially the way
there. That's a significant advance, technologically, based around the
observation that previously, languages were conflating two concepts which
should be distinguished. There is probably another equally simple
observation that will lead to a solution to this problem. But currently, I
don't think it has been solved fully.
I could be wrong. I'm a mathematician after all, not a computer scientist.
Bill.
On Thursday, 21 August 2014 19:03:08 UTC+2, Bill Hart wrote:
Oh, I should mention, the c = a*b = mul(c, a, b) problem is probably
soluble in D with a much cleaner and easier to compile solution than C++
offers. D metaprogramming is strictly more powerful than that of C++.
On Thursday, 21 August 2014 18:59:39 UTC+2, Bill Hart wrote:
On Thursday, 21 August 2014 18:23:48 UTC+2, Volker Braun wrote:
Incidentally, the whole argument type-dependent function dispatch is at
the core of the GAP language (though you have to recompile the GAP kernel
to change it). And GAP predates KR C.
There are other languages which have used it. That's not particularly
novel.
It's just the other way of doing object orientation.
There is one significant issue with it. To do arithmetic efficiently on
composite types, you need to be able to replace c = a*b with mul(c, a, b).
Using the class based approach, this is possible using metaprogramming.
We do this in flint. Unfortunately, the flint C++ module takes minutes per
file to compile and blows up many version of gcc and all versions of MSVC
(internal errors).
So it's not such a huge loss that you can't use template class
metaprogramming in a language like Julia (template class metaprogramming
has other major issues which make it essentially unusable in practice
anyway, such as needing to recompile to change anything).
I don't know a solution to the c = a*b = mul(c, a, b) problem. Nimrod
claims to have found some sort of solution, called term rewriting macros.
But I really don't know enough about them to evaluate their effectiveness
as a solution to this problem.
Julia will have to solve the problem some day, though it will be hard.
In my language I (theoretically) get around it by defining two kinds of
type. One is an arithmetic type, which has the above semantics. The other
is a usual type which has the usual semantics. But I've not fully
implemented the solution, so I don't know to what extent it can really be a
solution to the problem. Either way, it will be really, really hard to
implement in the compiler.
Bill.
On Thursday, August 21, 2014 4:56:12 PM UTC+1, Bill Hart wrote:
Thus the language is formally extensible at no cost and in an extremely
simple way that the user can easily do themselves.
Depends on your point of view. If you want to tie together different
third-party libraries then it can quickly become a liability that you can
just redefine everything.
julia getindex(a::Array{Int, 1}, b::Int) = print(test)
getindex (generic function with 140 methods)
Type this into the REPL on your colleague's computer who just left to
get a coffee and see if he ever figures that one out. My bet would be that
he's not going to get any work done until the next restart ;-)
--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
So, would it be thinkable of to move sage from Python to Julia? Sounds like a titanic task, but sounds like if there are so many advantages in Julia with respect to Python, it could be worth it. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: what is the plot3D viewer used in sagemath cloud
Thanks ! Do you know which file format is used by sagemath cloud to communicate with threejs ? Is it .obj or .x3d or json ? Where can I find the code ? and some documentation ? Le jeudi 21 août 2014 19:17:51 UTC+2, Andrey Novoseltsev a écrit : three.js, which is also available in SageCell (you have to call it explicitly as (threejs(plot(sin))), but they function differently. There are some threads on the notebook list about three.js problems. On Wednesday, 20 August 2014 14:19:52 UTC-6, Frédéric Chapoton wrote: Hello, I am trying in #12212 to allow plotting colored 3D surfaces. http://trac.sagemath.org/ticket/12212 So far, progress has been done on jmol, tachyon and canvas3D viewers. Does anybody know what is the viewer used in sagemath cloud ? -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
Julia can already call Python functions (and I don't mean in some theoretical, technical sense, I mean very practically via an interface designed explicitly for such). So it's not necessary to move Sage from Python to Julia. Other Scientific Python projects haven't done this. There are other reasons why this is not necessary, because of other technical advances that will become available in the coming few years (they are working in labs right now). Instead, the Sage project should do two things in my opinion: 1) Make Julia part of the Sage ecosystem (it's already had a huge investment from the scientific and statistical communities, so this is a no-brainer if you want to embrace that community) 2) Invest in the technologies that are making Julia successful (jit, dependent typing, metaprogramming, type checking and inference, etc.) Whether 2 involves rewriting some functionality in Julia, or simply finding ways of adding such functionality to Python is really neither here nor there. What Sage can't do is just stagnate and ignore progress. If it does, it will be brushed aside as if it wasn't even there, as has happened over and over again in the history of computer algebra! And it's happening to Sage. A few years ago, people at conferences were excitedly demonstrating stuff in Sage. This year, they've moved back to Magma. As I have already mentioned, the technology behind Julia can in theory do generic programming even faster than C or C++. So it is a strictly superior technology to what has been available in the past. It's a genuine innovation, whether the Julia designers see it that way or not. The Julia developers are not like me. They like Python and embrace it (many of them are pythonistas). They would never go around claiming Julia is in any way superior to Python. But I am not one of them and can go around making such claims, because in the sense that I mean it, it is true. Bill. On Thursday, 21 August 2014 20:33:00 UTC+2, mmarco wrote: So, would it be thinkable of to move sage from Python to Julia? Sounds like a titanic task, but sounds like if there are so many advantages in Julia with respect to Python, it could be worth it. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: what is the plot3D viewer used in sagemath cloud
On Thursday, 21 August 2014 13:27:06 UTC-6, Frédéric Chapoton wrote: Thanks ! Do you know which file format is used by sagemath cloud to communicate with threejs ? Is it .obj or .x3d or json ? Where can I find the code ? and some documentation ? I think JSON, William is probably the right person to ask about code/documentation location. SMC replaces show command from Sage with its own version to handle it. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
Having been dabbling in Julia myself, I can agree it's definitely worth a look for people interested in numerical programming and lispy metaprogramming facilities. For people coming from other languages it can take a while to figure out where exactly you're supposed to *put* things, and the type system takes some getting used to, but there are some really neat features once you push through that. I don't know how typical my experience is, but their benchmark page put me off the language for quite a while. (Explaining exactly why would be even more off-topic than this thread already is, but this SO link http://stackoverflow.com/questions/9968578/speeding-up-julias-poorly-written-r-examples has arguments on both sides, including from Stefan). But one commercial with an annoyingly stupid jingle doesn't mean the product isn't worth buying, and I'm glad I finally decided to push mute. It's still a very small community -- I woke up one day and was in the top ten on StackOverflow in terms of answering Julia questions, and it's not because I've spent a lot of time doing it -- and the documentation ecology is as yet underdeveloped as a result. There are also a number of things they were surprisingly slow to embrace (modules, for one; the counterarguments were pretty silly), but they seem to come around eventually, so I'm optimistic about its future. Still not sure I'd recommend it as a language for beginners, or as an every-day multitool, but what it's good at it's very good at. Doug -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
On Thu, Aug 21, 2014 at 9:45 PM, Bill Hart goodwillh...@googlemail.com wrote: Julia can already call Python functions (and I don't mean in some theoretical, technical sense, I mean very practically via an interface designed explicitly for such). So it's not necessary to move Sage from Python to Julia. Other Scientific Python projects haven't done this. There are other reasons why this is not necessary, because of other technical advances that will become available in the coming few years (they are working in labs right now). Instead, the Sage project should do two things in my opinion: 1) Make Julia part of the Sage ecosystem (it's already had a huge investment from the scientific and statistical communities, so this is a no-brainer if you want to embrace that community) 2) Invest in the technologies that are making Julia successful (jit, dependent typing, metaprogramming, type checking and inference, etc.) Whether 2 involves rewriting some functionality in Julia, or simply finding ways of adding such functionality to Python is really neither here nor there. What Sage can't do is just stagnate and ignore progress. If it does, it will be brushed aside as if it wasn't even there, as has happened over and over again in the history of computer algebra! And it's happening to Sage. A few years ago, people at conferences were excitedly demonstrating stuff in Sage. This year, they've moved back to Magma. To fill out this point a little, in my experience (recently, and in the past), such people choose to use Magma instead of Sage because Magma is capable of doing X, where X is something important they need for their work. In some cases, Magma does X slowly, with frequent crashes, etc.. But it does X nonetheless; whereas, programming Sage to do X from scratch would take the right expert about 2 years. This illustrates how Sage is failing to be a viable alternative to Magma. If Magma does X, and Sage doesn't, and people care about X, then Sage is not a viable alternative. Unfortunately, I don't think see Sage switching to Julia, or Sage having better support for (jit, dependent typing, metaprogramming, type checking and inference, etc.) in itself would be enough of a reason for people to have the option to choose Sage over Magma. Such advantages don't address the **real difficulty** in implementing a first version of X that works, since implementing X fundamentally takes reading and understanding papers, working out the right algorithms, etc. -- it's almost entirely a human expert and design problem.At least that's my experience watching/making this happen many times over the last decade.Please keep in mind that much of your (Bill Hart's) implementation work has been looking at implementations of various algorithms and coming up with a new approach that is better in certain ways -- that's certainly very important and useful, but it is a different problem than doing the first general implementation of code for computing with some class of mathematical objects.It's like the difference between building the first ever car and inventing a better wheel. Here are two concrete examples of X's where I've seen this exact situation in the last few months, and for which there is no open source implementation in any language, despite a demand for one over the last 10 years: - (a) quaternion algebras over number fields (topic of Sage Days 61 next week -- https://sites.google.com/site/sagedays61/) - (b) functional fields, mainly Florian Hess's Riemann-Roch spaces algorithm; this supports basic algebraic geometry constructions, which Magma has and Sage doesn't. There are dozens of other similar examples. They are hard to get funded with grants, because in all cases the proposal basically says: replicate something that's already been done... years ago. Also, the type of funding one wants is for a person to work full time on the problem for 1-2 years.A grant proposal that says We plan to do Y, and [lots about Y], but we need X [a little about X], has a chance to get funded (depending on Y). However, there are many X's (like a and b above) where I certainly can't make a compelling case for any Y except make sage a viable alternative. If we actually had real money to support open source math software development, I'm certain there could be useful open source implementations of (a) and (b) above within 2 years. I can think of specific people who would love to carry out these core implementation problems, but instead will be teaching a lot of Calculus instead, and probably not enjoying it. Anyway, a lack of funding is a big obstruction to creating a viable open source free alternative to the Ma's for all. -- William -- 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
Re: [sage-devel] Re: About pi?
+1 to dynamically generating a suitable docstring if the expression consists only of a single constant. But IMHO it should still make clear that this is a symbolic expression, so every functionality for symbolics still applies. Its just a special symbolic expression that is just a constant. On Thursday, August 21, 2014 9:18:50 PM UTC+1, Erik Massop wrote: On Thu, 21 Aug 2014 09:38:54 -0700 (PDT) kcrisman kcri...@gmail.com javascript: wrote: In this class, we don't quite instantiate the nice documentation we actually have for TwinPrime ... but instead do TwinPrime().expression() which gets rid of all that useful info. Same for most such constants, I believe, so that they are in the symbolic ring/Ginac. Does anyone have a quick way to fix this? (Maybe even by getting rid of .expression() ?) I have wondered about this too but I knew what the twin prime constant was so I didn't run into it... but of course Nathann is right that this is not that helpful currently. The quickest fix is probably writing in the documentation of sage.symbolic.expression.Expression that the user should maybe try sage: tmp = expression.pyobject() sage: tmp? for some more useful information. Here's what the result would be for twinprime: sage: tmp = twinprime.pyobject() sage: tmp? Type: TwinPrime String form:twinprime File: /home/erik/sage/local/lib/python2.7/site-packages/sage/symbolic/constants.py Docstring: The Twin Primes constant is defined as prod 1 - 1/(p-1)^2 for primes p 2. EXAMPLES: sage: float(twinprime) 0.6601618158468696 sage: twinprime.n(digits=60) 0.660161815846869573927812110014555778432623360284733413319448 Init docstring: EXAMPLES: sage: loads(dumps(twinprime)) twinprime The docstring of sage.symbolic.expression.Expression-objects could also be dynamically generated. This is done as a proof of concept in the attached patch. Recursing in docstring generation is maybe not so nice though. Also you still get the nasty Init and Call documentation from Expression. The cleanest solution from a docstring-perspective is probably getting rid of expression(). Is there a ticket for this? Regards, Erik Massop -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: On scientific computing, Python and Julia
On 2014-08-21, Bill Hart goodwillh...@googlemail.com wrote: --=_Part_5_2037022158.1408650350021 Content-Type: text/plain; charset=UTF-8 Julia can already call Python functions (and I don't mean in some theoretical, technical sense, I mean very practically via an interface designed explicitly for such). So it's not necessary to move Sage from Python to Julia. Other Scientific Python projects haven't done this. There are other reasons why this is not necessary, because of other technical advances that will become available in the coming few years (they are working in labs right now). Instead, the Sage project should do two things in my opinion: 1) Make Julia part of the Sage ecosystem (it's already had a huge investment from the scientific and statistical communities, so this is a no-brainer if you want to embrace that community) 2) Invest in the technologies that are making Julia successful (jit, dependent typing, metaprogramming, type checking and inference, etc.) Whether 2 involves rewriting some functionality in Julia, or simply finding ways of adding such functionality to Python is really neither here nor there. What Sage can't do is just stagnate and ignore progress. If it does, it will be brushed aside as if it wasn't even there, as has happened over and over again in the history of computer algebra! And it's happening to Sage. A few years ago, people at conferences were excitedly demonstrating stuff in Sage. This year, they've moved back to Magma. Perhaps, it's merely thanks to Simons Foundation making Magma free for all universities in USA? Oh, perhaps you mean that Magma has switched over to Julia? :-) As I have already mentioned, the technology behind Julia can in theory do generic programming even faster than C or C++. So it is a strictly superior technology to what has been available in the past. It's a genuine innovation, whether the Julia designers see it that way or not. Wait, are you saying there is an optimising Julia compiler available? Without it, it sounds a bit like claims by Java poeple saying that their JIT compilers are so great that they beat C compiled with gcc... My cursory look into Julia only poped out JIT stuff, not a real complier... The Julia developers are not like me. They like Python and embrace it (many of them are pythonistas). They would never go around claiming Julia is in any way superior to Python. But I am not one of them and can go around making such claims, because in the sense that I mean it, it is true. What personally put me off Julia when it was announced was that We are power Matlab users in the top of the blog post announcing Julia project back in Feb 2012. I thought oh yes, swell, we do need a better Matlab nchoosek() and 'everything is a matrix' greatness :-)... Dima Bill. On Thursday, 21 August 2014 20:33:00 UTC+2, mmarco wrote: So, would it be thinkable of to move sage from Python to Julia? Sounds like a titanic task, but sounds like if there are so many advantages in Julia with respect to Python, it could be worth it. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
On Thursday, 21 August 2014 22:29:04 UTC+2, wstein wrote: On Thu, Aug 21, 2014 at 9:45 PM, Bill Hart goodwi...@googlemail.com javascript: wrote: Julia can already call Python functions (and I don't mean in some theoretical, technical sense, I mean very practically via an interface designed explicitly for such). So it's not necessary to move Sage from Python to Julia. Other Scientific Python projects haven't done this. There are other reasons why this is not necessary, because of other technical advances that will become available in the coming few years (they are working in labs right now). Instead, the Sage project should do two things in my opinion: 1) Make Julia part of the Sage ecosystem (it's already had a huge investment from the scientific and statistical communities, so this is a no-brainer if you want to embrace that community) 2) Invest in the technologies that are making Julia successful (jit, dependent typing, metaprogramming, type checking and inference, etc.) Whether 2 involves rewriting some functionality in Julia, or simply finding ways of adding such functionality to Python is really neither here nor there. What Sage can't do is just stagnate and ignore progress. If it does, it will be brushed aside as if it wasn't even there, as has happened over and over again in the history of computer algebra! And it's happening to Sage. A few years ago, people at conferences were excitedly demonstrating stuff in Sage. This year, they've moved back to Magma. To fill out this point a little, in my experience (recently, and in the past), such people choose to use Magma instead of Sage because Magma is capable of doing X, where X is something important they need for their work. In some cases, Magma does X slowly, with frequent crashes, etc.. Conversely, Magma often does things much faster than Sage and without the crashes. I don't think the two projects are strictly comparable on such a metric. It depends on the domain you are talking about. By and large, Magma is faster than Sage for the things I am interested in. But you know I'm no Magma fan. Its closed source model is indefensible, even if people believe it is responsible for its success (its not). But it does X nonetheless; whereas, programming Sage to do X from scratch would take the right expert about 2 years. This illustrates how Sage is failing to be a viable alternative to Magma. If Magma does X, and Sage doesn't, and people care about X, then Sage is not a viable alternative. You are absolutely right. And I fully support what you are trying to do to fix this problem (i.e. raise funds). But let me divert the discussion slightly. It isn't the only issue. Once those experts find a way to develop quaternion algebras or whatever else you want (there was some talk of doing this in Antic for a while, but it died down), the question is, which system will they choose to invest their time in developing such code. We already have the answer to that question, and unfortunately it is a closed source system. Sage needs to be attractive to experts as a platform for doing such work. And there are a number of key things they will care about. Ease of development is the main one. Performance is another. I think Julia has it over Sage in both cases. Whilst you do need to be sufficiently smart to understand what a type is. And some of the mathematicians I have met don't meet this standard. But those that do, recognise that the type checker can save an enormous amount of implementation work. Unfortunately, I don't think see Sage switching to Julia, or Sage having better support for (jit, dependent typing, metaprogramming, type checking and inference, etc.) in itself would be enough of a reason for people to have the option to choose Sage over Magma. No, it wouldn't. But those things would enable what is currently impossible in Sage. As I said, I don't think Sage switching to Julia is something people should be talking about. An independent project which uses Julia instead of Python is much more practical. I already made a choice along those lines. I could have chosen Sage as a higher level language for flint and spent a lot of time speeding up Cython code which does generic arithmetic in Sage. I didn't, because it would not meet any of the criteria I would set for such a project. Fundamentally, the Cython and Python people aren't willing to adopt technological advances fast enough. And that is not a new problem. Such advantages don't address the **real difficulty** in implementing a first version of X that works, Yes, they do. And that's the fundamental point you are missing. To the extent that it is easier to do job X in project Y than project Z, and to the extent that the result will be more impressive in project Y than project Z, people will choose project Y instead of
[sage-devel] Re: On scientific computing, Python and Julia
On Thursday, 21 August 2014 23:08:18 UTC+2, Dima Pasechnik wrote: On 2014-08-21, Bill Hart goodwi...@googlemail.com javascript: wrote: --=_Part_5_2037022158.1408650350021 Content-Type: text/plain; charset=UTF-8 Julia can already call Python functions (and I don't mean in some theoretical, technical sense, I mean very practically via an interface designed explicitly for such). So it's not necessary to move Sage from Python to Julia. Other Scientific Python projects haven't done this. There are other reasons why this is not necessary, because of other technical advances that will become available in the coming few years (they are working in labs right now). Instead, the Sage project should do two things in my opinion: 1) Make Julia part of the Sage ecosystem (it's already had a huge investment from the scientific and statistical communities, so this is a no-brainer if you want to embrace that community) 2) Invest in the technologies that are making Julia successful (jit, dependent typing, metaprogramming, type checking and inference, etc.) Whether 2 involves rewriting some functionality in Julia, or simply finding ways of adding such functionality to Python is really neither here nor there. What Sage can't do is just stagnate and ignore progress. If it does, it will be brushed aside as if it wasn't even there, as has happened over and over again in the history of computer algebra! And it's happening to Sage. A few years ago, people at conferences were excitedly demonstrating stuff in Sage. This year, they've moved back to Magma. Perhaps, it's merely thanks to Simons Foundation making Magma free for all universities in USA? Definitely a factor. But a minor one. William is pretty much right about why people are going back to Magma. But a lot of people are missing the other reasons Oh, perhaps you mean that Magma has switched over to Julia? :-) N. Julia is not the issue here. I honestly couldn't give a toss about Julia. I've been very open about the fact that I think there are things wrong with Julia and that I will likely move my work from Julia to some other language in the future (when such a language becomes available). But it is definitely the best language around for this sort of thing. The issue here is the technology Julia is based on. Without it, you are going to very rapidly fall behind. And I said so very publicly, years before Julia was even announced (I'd have to check, but possibly even before private development of Julia began). At the time my criticism was posted to sage-flame and ridiculed. Anyway, to address your point. Magma is technologically superior to Sage in many ways (and in other ways is completely backward). Magma has been actively investing in parallel and GPU technology. And I happen to know they employed at least one person working on LLVM and web-based technologies. Magma has its own language, and doesn't need Julia. They can (just as Sage can), embrace the new technological innovations, without throwing away everything they have. Magma isn't a static target for which development stopped when Sage began. It is a moving target, that in some areas will always outstrip Sage. The only way to beat it, is to make sure Sage can move even faster than they can in embracing new technology. It needs to be possible to get a Magma beating solution off the ground in half the time Magma can do it. And that is nowhere near the case. As I have already mentioned, the technology behind Julia can in theory do generic programming even faster than C or C++. So it is a strictly superior technology to what has been available in the past. It's a genuine innovation, whether the Julia designers see it that way or not. Wait, are you saying there is an optimising Julia compiler available? You don't need an optimising compiler for Julia. Precisely the same backend that is used for the Clang C/C++ compiler underlies Julia. It's over 1 million lines of code. The difference is, it is jit compiled. Without it, it sounds a bit like claims by Java poeple saying that their JIT compilers are so great that they beat C compiled with gcc... No, I said generic programming can be faster in Julia than in C. Not that generic programming can be faster than some particular C compiler. The technology is fundamentally superior to C. That's a concept people are going to take a long time to understand and accept, but it's true. In theory, I can do generic programming in Julia that is faster (at runtime) than you can do in *any* C compiler. And I don't just mean a little bit. I mean a lot. I don't even think the Julia people fully realise this yet (I might be wrong about that, I don't know). And it's not been realised in practice for many cases. But it is true. On the other hand, because the Julia Jit is based on the technology
[sage-devel] Re: On scientific computing, Python and Julia
On Friday, 22 August 2014 00:08:20 UTC+2, Bill Hart wrote: My cursory look into Julia only poped out JIT stuff, not a real complier... Static compilation is coming to Julia. But not because it will speed things up. It already has all the speed of an optimising compiler at the console, as you type! I should qualify that. Technically, jit compilation and type inference begin at the function boundary in Julia. So stuff you type at the top level is not optimised. I think that is a mistake, as it's unnecessary. In the language I was working on (using LLVM) type inference and optimisation begin at the top level (which for me is a function). There is a small runtime hit with global variables, but that is all. In particular, in the language I was working on, loops at the top level are jit compiled. In Julia they are not. But it's almost irrelevant, except when doing timing experiments to see how fast Julia really goes. You might easily think to type a loop into the top level and time it and wonder what all the fuss is about. Put that loop inside a function and you'll soon see. julia function sumit(n::Int) s = 0 for i = 1:n s += i end return s end sumit (generic function with 1 method) julia @time sumit(10) elapsed time: 0.913325036 seconds (78060 bytes allocated) 55 Bill. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: On scientific computing, Python and Julia
Another thing that I think is terribly important is that the entire technology stack, LLVM, all its libraries and packages, its console, the IJulia web interface and Julia itself, all work out of the box on Windows 64, natively, not as a Cygwin app (they use MinGW64/MSYS2 to build Julia). And I've personally verified this. After some initial troubles due to the fact that flint.dll is not built correctly on Windows 64, Nemo works perfectly on Windows and from the IJulia interface running on my local Windows 64 machine. This doesn't solve any problems for Sage, as many mathematical libraries still don't natively support Windows 64 despite it being a decade old. But it is a significant feature of Julia (and of the Nemo project I am writing with Julia). Bill. On Friday, 22 August 2014 00:26:23 UTC+2, Bill Hart wrote: On Friday, 22 August 2014 00:08:20 UTC+2, Bill Hart wrote: My cursory look into Julia only poped out JIT stuff, not a real complier... Static compilation is coming to Julia. But not because it will speed things up. It already has all the speed of an optimising compiler at the console, as you type! I should qualify that. Technically, jit compilation and type inference begin at the function boundary in Julia. So stuff you type at the top level is not optimised. I think that is a mistake, as it's unnecessary. In the language I was working on (using LLVM) type inference and optimisation begin at the top level (which for me is a function). There is a small runtime hit with global variables, but that is all. In particular, in the language I was working on, loops at the top level are jit compiled. In Julia they are not. But it's almost irrelevant, except when doing timing experiments to see how fast Julia really goes. You might easily think to type a loop into the top level and time it and wonder what all the fuss is about. Put that loop inside a function and you'll soon see. julia function sumit(n::Int) s = 0 for i = 1:n s += i end return s end sumit (generic function with 1 method) julia @time sumit(10) elapsed time: 0.913325036 seconds (78060 bytes allocated) 55 Bill. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: On scientific computing, Python and Julia
I just found time to actually read the links posted by the OP on Graydon Hoare's history of programming language development, culminating in Julia. Oh I wish I could write like that! The guy is clearly a genius of immense proportions. I truly, truly wish that the computer algebra and number theoretic communities were engaging people like this and leveraging their insight and vision to the fullest. Bill. On Friday, 22 August 2014 01:19:22 UTC+2, Bill Hart wrote: Another thing that I think is terribly important is that the entire technology stack, LLVM, all its libraries and packages, its console, the IJulia web interface and Julia itself, all work out of the box on Windows 64, natively, not as a Cygwin app (they use MinGW64/MSYS2 to build Julia). And I've personally verified this. After some initial troubles due to the fact that flint.dll is not built correctly on Windows 64, Nemo works perfectly on Windows and from the IJulia interface running on my local Windows 64 machine. This doesn't solve any problems for Sage, as many mathematical libraries still don't natively support Windows 64 despite it being a decade old. But it is a significant feature of Julia (and of the Nemo project I am writing with Julia). Bill. On Friday, 22 August 2014 00:26:23 UTC+2, Bill Hart wrote: On Friday, 22 August 2014 00:08:20 UTC+2, Bill Hart wrote: My cursory look into Julia only poped out JIT stuff, not a real complier... Static compilation is coming to Julia. But not because it will speed things up. It already has all the speed of an optimising compiler at the console, as you type! I should qualify that. Technically, jit compilation and type inference begin at the function boundary in Julia. So stuff you type at the top level is not optimised. I think that is a mistake, as it's unnecessary. In the language I was working on (using LLVM) type inference and optimisation begin at the top level (which for me is a function). There is a small runtime hit with global variables, but that is all. In particular, in the language I was working on, loops at the top level are jit compiled. In Julia they are not. But it's almost irrelevant, except when doing timing experiments to see how fast Julia really goes. You might easily think to type a loop into the top level and time it and wonder what all the fuss is about. Put that loop inside a function and you'll soon see. julia function sumit(n::Int) s = 0 for i = 1:n s += i end return s end sumit (generic function with 1 method) julia @time sumit(10) elapsed time: 0.913325036 seconds (78060 bytes allocated) 55 Bill. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [sage-cloud-internal] William Stein says Sage has overall failed
2014-2015 will be a big year for Sage i think, with SMC leading the charge, now that SMC in particular has matured alot. From personal everyday experience i know that the idea of being able to make a free account and have access to a more mathematically substantial/capable version of Wolfram Alpha ,where you can log in and save things, would be popular once school starts. Its annoying for students (including myself) trying to do something on wolfram alpha, but you cant because your only allowed to use the non-paid gimped version, unless you subscribe to become a pro member ($$$). A lot more that could be said, but just some quick thoughts. On Thursday, August 21, 2014 6:32:03 AM UTC-7, kcrisman wrote: The title they gave it -- 'William Stein says Sage has overall failed' -- seems a bit sensational. I think that if people read the blog post they will see that I don't mean that the enormous effort that people like Volker, Jereon, etc., are doing, isn't a fantastic job. I'm measuring progress specifically in terms of the original mission statement. To be fair, you did kind of invite that interpretation with a somewhat dramatic line like that. Sage clearly IS a viable alternative, and basically is a replacement at the undergraduate level. It is not a replacement for everything - perhaps we need a jump like the combinat and matroid crowds did in arithmetic geometry? But neither are they replacements for Sage at this point, right, in many areas? Again, Sage is a viable alternative even for Matlab. It's not as good for this as Octave, apparently, and no third-party support etc. - but some people do use it, or they wouldn't be asking for help. So I think that it would have been better to say that the statement that has failed is a viable *replacement* for all four M's. Well, that would be a hard goal indeed! For precisely the reasons you give. I don't think that makes Sage a failure, it just makes it different. Presumably Maple and Mathematica are not replacements for each other either. - kcrisman -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: SageMathCloud / closed source / GPL / Spirit of Sage??
Seems like some people forget that, you have to play the game in order to be successful. The game could broadly be described as: navigating the framework of society. That framework whether you like it or not, is and likely will continue to be composed largely of money. The game consists for everyone, as we all play it, and of anything really, buying milk at the grocery store, making a product successful/popular/accessible etc, there are boundaries and limits that as mentioned, are usually monetary in nature. Hopefully this makes sense so far lol. One of the limits that Sage has encountered against so far, as William explicitly points out, is money. Sage MathCloud (SMC) among other things, makes Sage more accessible to people as no local installation is needed, among other benefits. The barrier to entry to having access to a world class piece of mathematics software, is incredibly low with SMC. Back to the game side of things, all the benefits of SMC came and and continue to come at a cost, the servers and infrastructure cost money. That's easy to forget if you use SMC just as a black box sort of thing. But how else would you do this without cost? Make some sort of distributed Computer Algebra System or something? There is no way else, there will always be a cost, money, in trying to acheive Sage's Mission: *Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab.* William even explicitly mentions having to play the game in his blog post. If you don’t play the game, you lose. Just as an example, since it Magma gets brought up alot, as per Magma's Website: Availability of a student version A student version of Magma is available. The only difference between it and the full version is that the memory usage is restricted to 150MB. The student version is now *only available* through *educational institutions*. See (ii) — (iv) below. We regret to announce that the supply of a restricted version of Magma for a small price to students enrolled at a college or university has been *discontinued* for the time being. The costs associated with distributing and supporting the student versions have become far greater than the income received from student licences and we are not in a position to cross-subsidise these costs. ... Developing countries Users from newly industrialised and developing countries may apply for Magma licences at a reduced rate, by special agreement. I have no idea what Magma's Mission is, and it doesnt matter, as im not comparing/contrasting them here, i just post that from their website to show people, detractors/haters of SMC that theres others in the game as well, trying to achieve whatever their goal is, but bound by same limits as sage, money. Sage's Mission, its goal, is lofty, so if your a person that loves sage but hates all or just some of SMC, then your free to never use SMC and can just view it as *playing the game*. On Tuesday, August 19, 2014 2:35:13 AM UTC-7, Nathann Cohen wrote: About William's blog post (*): even though I don't like you do much (but I don't like what a lot of persons do, so apparently there is nothing wrong in that), I was wondering about your plans. If you ever end up earning money with this for-profit company you have in mind, who would you hire to write Sage code ? What I mean is that I feel safe when I write graph code, but that I am afraid of touching group stuff, or categories. I would not dare writing any statistics-related stuff (it was too long ago), nor differential equations, nor symbolics... Well, not anything else, actually. And so I felt that one perso can write code for his specific domain, and not for a lot of other things. Sooo I wondered. Where do you think you could find guys able to work on Sage who you could hire for a long time, i.e. with in mind that they have several years of work ahead of them, probably on different mathematical topics. Even though I guess you also want to expand non-mathematical parts of Sage, i.e. some infrastructure, or support on new platforms, things like that. Just wondering. Nathann (*) It made me laugh at first. Recently our former president Nicolas Sarkozy was arrested because of one of the + procedures against him (like hundreds of others are, daily). The following day, he was at prime time on the TV explaining why he did not deserve any different justice than the one given to any normal citizen, and why everything against him was a conspiracy. Most other persons can't do that. It made me laugh because you answered a sage-devel thread on a blog. -- 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
[sage-devel] Re: NameError: global name 'sage' is not defined
I was able to get things working okay in my development version of sage,
the sage git repo at ~/sage , but when i try to do this:
sage: t = Tachyon()
sage: t.show()
in my system non development sage installation, i get the same error as
before? Im using sage 6.3. Im assuming my installations didnt cross paths
or anything funky, but, it just donned on me that i had the same issue in
my non development install, and to see if others where having the issue?
On Tuesday, August 19, 2014 10:10:14 PM UTC-7, Travis Scrimshaw wrote:
No that's correct. The difference is that my way imports the *function* as
oppose to the *module* given by John. This is a python thing, see
https://docs.python.org/3/reference/import.html
https://www.google.com/url?q=https%3A%2F%2Fdocs.python.org%2F3%2Freference%2Fimport.htmlsa=Dsntz=1usg=AFQjCNHFrh-OlETJ3pXspWW4COICVwUI3w
for more details.
Best,
Travis
On Tuesday, August 19, 2014 9:24:16 PM UTC-7, Paul Graham wrote:
Ok i did:
from sage.misc.viewer import png_viewer
at the top of the file tachyon.py, and then in my code as you suggest, in
Tachyon.show, i changed it from:
os.system('%s %s 2/dev/null 1/dev/null '%(sage.misc.viewer.png_viewer
(), filename))
to:
os.system('%s %s 2/dev/null 1/dev/null '%(png_viewer(), filename))
and it works just fine. I never made any modifications to that line
originally, so not sure why its stopped working... Works now though, thanks.
Or referring to changing it somewhere else?
On Tuesday, August 19, 2014 8:40:52 PM UTC-7, Travis Scrimshaw wrote:
Interestingly, i tried doing:
from sage.misc.viewer import png_viewer
first, but got the same error.
In your code, you just want `png_viewer`, not
`sage.misc.viewer.png_viewer` (which is what I suspect you had).
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Finding SAGE_ROOT?
In trying to setup development for the Sage Notebook, by following the guide at: http://www.sagemath.org/doc/developer/sagenb/index.html , you first need to locate the root directory of the Sage installation, SAGE_ROOT . Thats the part where im stuck as i dont know where SAGE_ROOT is... Many other places make reference to this place, not just the notebook. So kind of a general dev issue. Im on ubuntu and have a development directory, just containing the sage repository at : ~/sage , and have what is supposed to be a non-development working stable installation of sage that was installed using the UBUNTU PPA instructions at http://www.sagemath.org/download-linux.html, just: sudo apt-add-repository -y ppa:aims/sagemath sudo apt-get update sudo apt-get install sagemath-upstream-binary Im not sure where this installs to, what the default installation directory is on ubuntu, or if sage installs somewhere different? If i do: user1@computer0:~$ ./sage bash: ./sage: Is a directory but but if i do: user1@computer0:~$ sage ┌┐ │ Sage Version 6.3, Release Date: 2014-08-10 │ │ Type notebook() for the browser-based notebook interface.│ │ Type help() for help.│ └┘ /usr/lib/sagemath/local/lib/python2.7/site-packages/IPython/utils/path.py: 310: UserWarning: IPython dir '/home/user1/.sage/ipython-2.1.0' is not a writable location, using a temp directory. using a temp directory.%ipdir) sage: I dont know what the difference between sage and ./sage is, but maybe above info will help someone pinpoint where my SAGE_ROOT is? I tried alot of searching but no luck so far. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Finding SAGE_ROOT?
On Fri, Aug 22, 2014 at 5:46 AM, Paul Graham paulgrah...@outlook.com wrote: In trying to setup development for the Sage Notebook, by following the guide at: http://www.sagemath.org/doc/developer/sagenb/index.html , you first need to locate the root directory of the Sage installation, SAGE_ROOT . Thats the part where im stuck as i dont know where SAGE_ROOT is... Many other places make reference to this place, not just the notebook. So kind of a general dev issue. Im on ubuntu and have a development directory, just containing the sage repository at : ~/sage , and have what is supposed to be a non-development working stable installation of sage that was installed using the UBUNTU PPA instructions at http://www.sagemath.org/download-linux.html, just: sudo apt-add-repository -y ppa:aims/sagemath sudo apt-get update sudo apt-get install sagemath-upstream-binary Im not sure where this installs to, what the default installation directory is on ubuntu, or if sage installs somewhere different? If i do: user1@computer0:~$ ./sage bash: ./sage: Is a directory but but if i do: user1@computer0:~$ sage ┌┐ │ Sage Version 6.3, Release Date: 2014-08-10 │ │ Type notebook() for the browser-based notebook interface.│ │ Type help() for help.│ └┘ /usr/lib/sagemath/local/lib/python2.7/site-packages/IPython/utils/path.py:310: UserWarning: IPython dir '/home/user1/.sage/ipython-2.1.0' is not a writable location, using a temp directory. using a temp directory.%ipdir) sage: I dont know what the difference between sage and ./sage is, but maybe above info will help someone pinpoint where my SAGE_ROOT is? I tried alot of searching but no luck so far. Try typing SAGE_ROOT at the sage prompt, e.g., sage: SAGE_ROOT '/usr/local/sage/sage-6.2.rc2' William Stein Professor of Mathematics University of Washington http://wstein.org wst...@uw.edu -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: what is the plot3D viewer used in sagemath cloud
On 8/21/14, 15:27, Frédéric Chapoton wrote: Thanks ! Do you know which file format is used by sagemath cloud to communicate with threejs ? Is it .obj or .x3d or json ? Where can I find the code ? and some documentation ? The relevant files for smc are the 3d.* files here: https://github.com/sagemath/cloud (at least, those were the files a while ago, and I doubt much has changed with the 3d rendering since then.) My students and I rewrote that 3d renderer for the sage cell server, and then we again rewrote a system to use the IPython widget infrastructure (so it works in the sage cell server and the IPython notebook). If you're interested in either of those, let me know. Thanks, Jason -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: interact.sagemath.org
On 8/18/14, 17:33, kcrisman wrote: On Monday, August 18, 2014 3:22:00 PM UTC-4, wstein wrote: Hi, Andrey Novoseltsev kindly pointed out that interact.sagemath.org http://interact.sagemath.org is deluged with spam, e.g., http://interact.sagemath.org/node/1194 http://interact.sagemath.org/node/1194 Can somebody volunteer to deal with this ASAP? Either clean up the spam, or move hosting somewhere else (i'll point DNS their way). I'm afraid UW is likely to disconnect sagemath.org http://sagemath.org from the internet if we don't. I don't know who is currently administering this or has such privileges... One easy fix is to disable comments, perhaps. Wow, I had no idea. Just following up---that's exactly what I did, and made the site essentially read-only except for trusted author accounts. If you'd like one of those, email me. If someone wants to take over the site, let me know. Thanks, Jason -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [sage-cloud-internal] William Stein says Sage has overall failed
Hi William, From my point of view Sage definitely has *not* failed! I would not be able to do the computations I need for my research on any other platform at this point (of course this could be possibly done, but with an enormous effort). More and more people are interested in switching to Sage at least people with a focus in combinatorics, representation theory, root systems, and are offering to organize Sage Days to learn and start using and contributing to Sage. In fact, we just concluded Sage Days in India and there were people interested in a variety of topics. From this point of view, Sage has gone far beyond any other mathematical software system I know! Best, Anne -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Crazy/dumb idea about Sage on Windows...
Hi folks, off the cuff, probably totally dumb. Reading some of the threads about Sage, Julia, Windows, etc, got me thinking... If/when there's a Sage kernel for the IPython/Jupyter notebook, I wonder if that could give you guys a way to move forward on Windows, where I know you've fought pretty hard and bitter battles... My idea (assuming the aforementioned kernel): package *just* the Sage kernel inside a VM, and run it purely as a service, but connect to it from an IPython terminal, Qt console or Notebook running from a native Anaconda installation. Because our execution model decouples the kernel from the filesystem, the user gets their 'normal' environment, files, etc, and they don't really need to know anything about the VM to get to their work, their directories, etc. I know IPython provides a very different execution model to the Sage NB (no hidden directories, it lives on the normal filesystem, etc), so 'native' Sage notebooks won't work. But ipynbs will work fine, and this may at least give you guys a better way to reach a Windows audience... And since this VM would be running only the bare kernels, it can be a very small and lightweight one, and it should be a lot easier to deal with ports and firewall issues. There will be zeromq traffic on some sockets, but that's it. Just an idea... Cheers, f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
