I think thats all premature optimization. First we need a bulletproof way
of running Sage in the VM. At the end we can still worry about ways to
shave off another megabyte or two. Most VM questions I got were about how
to add more stuff to the VM within its space constraints. Nobody had an
On 02/ 4/12 11:59 PM, Nathann Cohen wrote:
And it's not only your time, it's other's time that is being used (if not,
hmm, wasted) to look for bugs that are so commonplace
in C code.
Please Dima, do not look at my patches if you can not stand their
clumsiness. I do not pay anybody to review
On 02/ 4/12 08:30 PM, R. Andrew Ohana wrote:
Out of curiosity, is anyone actively working on a suncc port. (I ask
since libcsage's SConstruct needs changing, and there is some stuff in
there pertaining to such a port.)
I would not say I'm actively working on it, but I have looked at it in the
A more technical detail - I am curious:
How to you allow persistant changes to the sage directory in the
compressed filesystem? Do you plan to use an overlayed filesystem with
a persistant savefile? Or do you have the sage directories just as
read only?
cheers
I use unionfs to mix the
On 5 feb, 09:30, Volker Braun vbraun.n...@gmail.com wrote:
I think thats all premature optimization. First we need a bulletproof way
of running Sage in the VM. At the end we can still worry about ways to
shave off another megabyte or two. Most VM questions I got were about how
to add more
Le 05/02/2012 09:51, Dr. David Kirkby a écrit :
I know both Dima and myself have been critical of some of your code
methology before, but I believe in this instance Dima is not singling
you out at all, but making a general observation of C code.
I also think Dima was making a general
On 02/ 4/12 10:11 PM, Robert Bradshaw wrote:
Note that what is broken[1] here is ARM's libc, if one types
gamma(6.0) one gets 120. on all systems. It's a
question about gamma(float(6.0)) which is explicitly requesting the
(presumably faster but potentially less accurate) system
On Feb 5, 8:30 am, Volker Braun vbraun.n...@gmail.com wrote:
I think thats all premature optimization. First we need a bulletproof way
of running Sage in the VM.
I agree - premature optimization, the root of all evil. In fact the
VM itself is just one module of the interface and it is
Le 04/02/2012 23:11, Robert Bradshaw a écrit :
On Sat, Feb 4, 2012 at 8:17 AM, rjffate...@gmail.com wrote:
On Feb 2, 1:16 pm, Julien Puydtjulien.pu...@laposte.net wrote:
Le 02/02/2012 23:22, Jonathan Bober a crit :
Can you think of a reason that the answer should change? Does maxima use
well, what about this one:
http://trac.sagemath.org/sage_trac/ticket/12091
Open for 2 months, priority set to critical...
Perhaps Nathann takes it personal from me (at least his appeal above
certainly sounds like this),
and refuses to even look at anything I report about his code.
I do not
On Sunday, 5 February 2012 18:08:46 UTC+8, mmarco wrote:
On 5 feb, 09:30, Volker Braun vbraun.n...@gmail.com wrote:
I think thats all premature optimization. First we need a bulletproof
way
of running Sage in the VM. At the end we can still worry about ways to
shave off another
On Feb 5, 12:23 pm, Dima Pasechnik dimp...@gmail.com wrote:
On Sunday, 5 February 2012 18:08:46 UTC+8, mmarco wrote:
On 5 feb, 09:30, Volker Braun vbraun.n...@gmail.com wrote:
I think thats all premature optimization. First we need a bulletproof
way
of running Sage in the VM. At the
Hi,
this thread is getting... long. Let me try to refocus it on more
constructive grounds.
Let's list the problematic expressions:
1. gamma(float(6))
2. SR(10.0r).gamma()
3. float(maxima(1.7e17))
4. binomial(0.5r,5)
The following is known :
(a) 1,3 and 4 give test-passing results with #tol
On Sunday, 5 February 2012 21:03:46 UTC+8, Snark wrote:
Hi,
this thread is getting... long. Let me try to refocus it on more
constructive grounds.
Let's list the problematic expressions:
1. gamma(float(6))
2. SR(10.0r).gamma()
3. float(maxima(1.7e17))
4. binomial(0.5r,5)
The
Le 05/02/2012 14:43, Dima Pasechnik a écrit :
On Sunday, 5 February 2012 21:03:46 UTC+8, Snark wrote:
(b) 1, 2 and 4 are all the same bug in various disguise : the libc
lgammal function isn't good enough ;
more precisely, the (e)glibc gamma function is not good. (lgammal isn't
too good
FWIW you should be able to work around the problem by opening Terminal.app
before starting sage. At least if it's the manifestation of the problem that I
think it is.
-Ivan
On Feb 4, 2012, at 7:52 PM, Mike OS wrote:
Just corroborating.
I encountered the same problem this week installing
Hi Jim and Dima,
the error also occurs with the latest development version (2.1.1,
available via the project page). I guess the new Cython version is
stricter than the old.
So, I need to fix it, and also comment on the trac ticket.
Cheers,
Simon
--
To post to this group, send an email to
On Feb 4, 2012, at 22:33 , Dima Pasechnik wrote:
Hi Simon,
it also fails with Sage 5.0.beta2 on Debian x86_64, with the same symptoms.
So it's not Suse-specific, it seems.
$ uname -a
Linux arando 3.1.0-1-amd64 #1 SMP Tue Jan 10 05:01:58 UTC 2012 x86_64
GNU/Linux
gcc version 4.6.2
Hi all,
On 5 Feb., 19:19, Justin C. Walker jus...@mac.com wrote:
FWIW, I got the same error on Mac OS X, 10.6.8: gcc version 4.2.1 (Apple Inc.
build 5666) (dot 3).
No surprise - the bug is in my code. While with the old Cython
version, it would occur at running time (in a way that apparently
On Sunday, February 5, 2012 2:59:40 AM UTC-8, Emil Widmann wrote:
About those other parts: Really, the Interface from the windows side
has a lot of potential. All this stuff typical windows users expect
when installing new software like desktop icons, menu entries,
installer, on screen
On Sun, Feb 5, 2012 at 11:34 AM, Volker Braun vbraun.n...@gmail.com wrote:
On Sunday, February 5, 2012 2:59:40 AM UTC-8, Emil Widmann wrote:
About those other parts: Really, the Interface from the windows side
has a lot of potential. All this stuff typical windows users expect
when installing
Various aspects of building Sage might be cleaner if we used autoconf:
./configure OPTIONS
make
OPTIONS could include a location to install Sage, various flags for
building ATLAS, and other options which we currently control by setting
environment variables. For typical users, we should
William and I are planning three workshops in the next four months and we
have funding available to support attendees. If you're seriously
interested in attending one (or more) of these please e-mail me
immediately. A priori we have no restrictions on where you're flying from
and we don't need a
Are these workshops all going to be in Seattle?
--
John
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at
On Sun, Feb 5, 2012 at 1:29 PM, John H Palmieri jhpalmier...@gmail.com wrote:
Are these workshops all going to be in Seattle?
Yes.
--
John
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
On Sun, Feb 5, 2012 at 1:23 PM, John H Palmieri jhpalmier...@gmail.com wrote:
Various aspects of building Sage might be cleaner if we used autoconf:
./configure OPTIONS
make
OPTIONS could include a location to install Sage, various flags for building
ATLAS, and other options which we
Note that we almost have something like this already, the prereq tarball
(in spkg/base) uses the autotools to check that various prerequisities for
building Sage are satisifed.
PS: its configure.ac now, configure.in is deprecated ;-)
--
To post to this group, send an email to
Le dimanche 5/02/2012, John H Palmieri jhpalmier...@gmail.com a
écrit :
[ ] Switch to autoconf
Yes!
Snark on #sagemath
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more
See http://trac.sagemath.org/sage_trac/ticket/12449
I'm in the middle of [hopefully] fixing this by calling the gsl gamma
function. While I'm at it, I'll also make the evaluation on basic types
much faster, as it shouldn't go though Ginac. (Actually, I've already
mostly written a fix. I opened
I've submitted sage-notebook for archival. Gmane does not
automatically know how to search the currently existing Google
archives of this group, though, so only new posts will be archived,
unless someone can provide an .mbox file containing old messages. Does
anyone have or can anyone prepare such
On Sun, Feb 5, 2012 at 6:59 PM, Keshav Kini keshav.k...@gmail.com wrote:
On Mon, Feb 6, 2012 at 03:03, Jason jason.harri...@gmail.com wrote:
I have no problem with moving away from Google groups.
Definitely not suggesting that, though I wouldn't have a problem with
that either, if the
I think we may be overlooking a very reasonable option. Python already has
a gamma function in the math module! It is a separate implementation that
does not depend on libc, and it gives reasonable results (though perhaps
not as good as eglibc tgammal() on x86):
sage: max(( abs(
I'm trying to make a wiki page for Days 37, which will be in Seoul --
but I can't, because it's refusing to make a page with Seo in it. Can
someone fiddle with the spam filter so that I can refer to Korea's
largest city (and the first Sage Days in east Asia)?
Thanks!
Dan
--
--- Dan Drake
-
Le Sun, 5 Feb 2012 14:16:39 -0800,
Jonathan Bober jwbo...@gmail.com a écrit :
Never mind all that: the gsl implementation is not very good at all,
whereas the libc implementation on my machine seems quite good.
Bad :-/
Old (libc):
sage: gamma(1.23).str(base=2)
On 02/ 5/12 09:23 PM, John H Palmieri wrote:
Various aspects of building Sage might be cleaner if we used autoconf:
./configure OPTIONS
make
I feel that would be a step forward. It would take a bit of work, but I've
already done part of it with the prereq script, which uses autoconf.
35 matches
Mail list logo
