PS:
On 29 Okt., 00:52, Maarten Derickx
wrote:
> Make the functions super_categories and all_super_categories say in the
> documentation that developers shouldn't use these but that they should use
> the lazy attributes.
With a deprecation warning, too? Or better no deprecation, since your
soluti
Hi Maarten,
On 29 Okt., 00:52, Maarten Derickx
wrote:
> What I think would be the best solution in this case would be is:
>
> make lazy attributes
>
> _super_categories and
> _all_super_categories
>
> Make the functions super_categories and all_super_categories say in the
> documentation that dev
On Oct 28, 7:48 pm, Eviatar wrote:
> Thank you for the information.
>
> However, I do think Sage acts inconsistently with logarithms.
>
> Why should this work:
>
> sage: log(0)
> -Infinity
>
> but not this:
>
> sage: log(2, 0)
> ValueError: m must be positive
The base is the *second* argument.
On 10/28/11 5:52 PM, Maarten Derickx wrote:
My comment was purely a reaction to jasons claim that it is hard to
document attributes in python and not a solution to your problem.
That's really cool. I didn't realize that ipython would pick up the
documentation to properties. I assume it appea
Thank you for the information.
However, I do think Sage acts inconsistently with logarithms.
Why should this work:
sage: log(0)
-Infinity
but not this:
sage: log(2, 0)
ValueError: m must be positive
Both of these are undefined, but only one returns an error.
--
To post to this group, send a
Sorry for the confusion Simon. My comment was purely a reaction to jasons
claim that it is hard to document attributes in python and not a solution
to your problem.
What I think would be the best solution in this case would be is:
make lazy attributes
_super_categories and
_all_super_categori
My Opensolaris box hawk is back up. Those who have accounts, and the buildbot,
can use it again.
Dave
--
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
We are the e^(4.59511985013459)% !
-Marshall
On Oct 28, 3:52 pm, John H Palmieri wrote:
> On Friday, October 28, 2011 1:42:25 PM UTC-7, kcrisman wrote:
>
> > On Oct 28, 3:40 pm, Jason Grout wrote:
> > > For the last few years, we've had a Sage Days following the AMS/MAA
> > > Joint Meetings. A
On Friday, October 28, 2011 1:42:25 PM UTC-7, kcrisman wrote:
>
>
>
> On Oct 28, 3:40 pm, Jason Grout wrote:
> > For the last few years, we've had a Sage Days following the AMS/MAA
> > Joint Meetings. Are we planning on that again this January? The Joint
> > Meetings are Jan 4-7.
>
> That
On Oct 28, 3:40 pm, Jason Grout wrote:
> For the last few years, we've had a Sage Days following the AMS/MAA
> Joint Meetings. Are we planning on that again this January? The Joint
> Meetings are Jan 4-7.
That would be a nice idea. Maybe if we demonstrate that there is a
lot of interest tho
For the last few years, we've had a Sage Days following the AMS/MAA
Joint Meetings. Are we planning on that again this January? The Joint
Meetings are Jan 4-7.
Thanks,
Jason
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email
Hi!
Just to show you what speed differences we are talking about, consider
a situation were we see the overhead in its purest form:
sage: class Bar(object):
: def pure_method(self):
: return 1
: @property
: def test_property(self):
: return 2
:
Hi Jason,
On 28 Okt., 19:27, Jason Grout wrote:
> > * A property would be called over and over again and would do the
> > same computation over and over again.
> > * A cached method would be called over and over again, but would do
> > the computation only once.
> > * A lazy attribute would
On Oct 27, 3:27 am, Burcin Erocal wrote:
> I don't think we can use omalloc in Sage since it is not thread safe.
> Using GMP with two different memory allocators is not an option either.
> So I am not sure if this problem can be solved easily.
A similar issue arises in ECL. By default, it plugs
On 10/28/11 9:28 AM, Simon King wrote:
Hi Maarten,
On 28 Okt., 15:32, Maarten Derickx
wrote:
Well, it is supported if you make the attribute a property. Since most of
those things are already functions it would be very easy
...
http://docs.python.org/library/functions.html#property
Thank yo
Hi Maarten,
On 28 Okt., 15:32, Maarten Derickx
wrote:
> Well, it is supported if you make the attribute a property. Since most of
> those things are already functions it would be very easy
>
> ...
>
> http://docs.python.org/library/functions.html#property
Thank you, I didn't know "properties" be
I think attributes are considered more pythonic for many things than
> methods. We insist on methods for many things in Sage because you can
> document methods (but it's hard and not intrinsically supported by
> python to document and introspect attribute documentation).
>
Well, it is suppor
On Wed, Oct 26, 2011 at 11:18:21PM -0700, Simon King wrote:
> Hi Florent,
>
> On 26 Okt., 17:58, Florent Hivert wrote:
> > If you want some example of what has been painful in the past, here they
> > are. Note: I don't intend any offense against the responsible of those
> > changes, I'm just aski
I think a Sage Days on algebraic topology would be great. The first
things you need to figure out are:
* Where and when is it happening? You should think about other
conferences in algebraic topology (mostly to avoid conflicts for your
audience, but possibly so that people can stay for a Sage Day
There may be usefull info to be found
on http://wiki.sagemath.org/HowToHostASageDays . I don't have experience in
organizing either, but I've been to multiple sage days and they where all
very different. So I guess that as soon as you manage to get enough good
speakers to come an enough people
On Friday 28 October 2011, William Stein wrote:
> On Thu, Oct 27, 2011 at 12:57 PM, Volker Braun
wrote:
> > On Thursday, October 27, 2011 1:38:34 PM UTC-4, Martin Albrecht wrote:
> >> Sure, but it's still worrisome that a computation is slower in
> >> libSingular than in Singular.
> >
> > Just t
21 matches
Mail list logo