On Mar 20, 10:01 am, leif wrote:
> Abstraction. Although it's (currently) not foo._f nor foo.__f, I
> wouldn't say f is part of a cached function's public interface, but
> rather an implementation detail.
Fair enough. So why not make "foo.f" part of the public interface?
Python properties (and t
Nils Bruin wrote:
On Mar 20, 7:18 am, leif wrote:
And calling foo.f() will break if someone decides to no longer cache the
function or method, or to rename the attribute.
[...]
my_foo=get_uncached_function(foo)
I've seen that last argument before and I don't quite understand why
intro
On Mar 20, 7:18 am, leif wrote:
> And calling foo.f() will break if someone decides to no longer cache the
> function or method, or to rename the attribute.
[...]
> my_foo=get_uncached_function(foo)
I've seen that last argument before and I don't quite understand why
introducing a function m
Nathann Cohen wrote:
Helloo !!!
> I think it should be fairly rare that you want to explicitly opt out of
> caching (so I don't see the problem with calling
Thing.my_function.f()). I
> echo Robert's -1.
It's not hard when you know it. And it's not the most user-friendly
thing ever eithe
On Wednesday, March 20, 2013 5:09:40 AM UTC, Nils Bruin wrote:
> On Mar 19, 9:10 pm, Robert Bradshaw
> wrote:
> > Sounds good. What if we called this foo.uncached(args) instead (which
> > is more verbose but much clearer, and tab completion shouldn't make
> > that too bad...) I could make cac
Hell !
> > Sounds good. What if we called this foo.uncached(args) instead (which
> > is more verbose but much clearer, and tab completion shouldn't make
> > that too bad...) I could make cached methods work as well.
>
> Do we actually have a use-case?
I don't. I'm wary cached functions be
On Mar 19, 9:10 pm, Robert Bradshaw
wrote:
> Sounds good. What if we called this foo.uncached(args) instead (which
> is more verbose but much clearer, and tab completion shouldn't make
> that too bad...) I could make cached methods work as well.
Do we actually have a use-case?
--
You received t
On Tue, Mar 19, 2013 at 3:32 PM, John H Palmieri wrote:
>
> On Tuesday, March 19, 2013 10:47:10 AM UTC-7, Robert Bradshaw wrote:
>>
>> You can always call the uncached version explicitly,
>>
>> sage: @cached_function
>> : def test(x):
>> : print "doing something with", x
>> : r
On Tuesday, March 19, 2013 10:47:10 AM UTC-7, Robert Bradshaw wrote:
>
> You can always call the uncached version explicitly,
>
> sage: @cached_function
> : def test(x):
> : print "doing something with", x
> : return x
> :
> sage: test.f("a")
> doing something with
Helloo !!!
> I think it should be fairly rare that you want to explicitly opt out of
> caching (so I don't see the problem with calling Thing.my_function.f()).
I
> echo Robert's -1.
It's not hard when you know it. And it's not the most user-friendly thing
ever either :-P
Nathann
--
You re
I think it should be fairly rare that you want to explicitly opt out of
caching (so I don't see the problem with calling Thing.my_function.f()). I
echo Robert's -1.
David
On Tue, Mar 19, 2013 at 3:29 PM, Nathann Cohen wrote:
> Helloo !!
>
>
> > -1, that completely defeats the purpos
Helloo !!
> -1, that completely defeats the purpose of having caching being
> transparent, as well as being backwards incompatible. It's an
> implementation detail chosen by the implementor. Having to inspect the
> keyword argument each time would slow things down as well. Opt out,
> p
On Tue, Mar 19, 2013 at 2:18 PM, Nathann Cohen wrote:
> Helloo !!!
>
>
>> UniqueRepresentation uses a weak cache. Therefore, unused stuff should
>> vanish from memory in the next garbage collection.
>>
>> Hence, if things are *not* forgotten, then you (accidentally?) kept a
>> refe
Helloo !!!
> UniqueRepresentation uses a weak cache. Therefore, unused stuff should
> vanish from memory in the next garbage collection.
>
> Hence, if things are *not* forgotten, then you (accidentally?) kept a
> reference to it. But then the stuff would accumulate in memory even i
Hi Nathann,
On 2013-03-19, Nathann Cohen wrote:
> I personally totally hate cached functions. I hate them because I'm big
> enough to know what I should store and what I should not. And I hate cached
> functions and UniqueRepresentation (for instance in Posets) because it
> means that some algori
Hellooo
> I would definitely encourage a healthy dislike for cached functions.
> However I suspect you might be misdiagnosing the cause of the overhead
> you're seeing in UniqueRepresentation. If you're seeing a lot of
> memory use where there shouldn't be, that's an indic
On Mar 19, 9:51 am, Nathann Cohen wrote:
> And I hate cached
> functions and UniqueRepresentation (for instance in Posets) because it
> means that some algorithms that do not require any big memory
> (1) create one poset
> (2) test something
> (3) forget about it
> (repeat many many times)) can ta
> You can always call the uncached version explicitly,
O_O
NIIIic !!!
THaanks ! :-)
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
You can always call the uncached version explicitly,
sage: @cached_function
: def test(x):
: print "doing something with", x
: return x
:
sage: test.f("a")
doing something with a
'a'
sage: test.f([1,2,3])
doing something with [1, 2, 3]
[1, 2, 3]
sage: test.f([1,2,3])
doing
Really, the problem is that caching and iterables don't make much sense
together. You either want to iterate over a large set with a function that
returns quickly or you want to do one expensive computation whose result
should be cached.
One could alleviate this by making @cached_method conver
Hello !
> Without the cached_function decorator the error would be a ValueError
> in both cases. It seems difficult to remedy, though. If you want
> custom argument checking you shouldn't use `cached_function`.
I personally totally hate cached functions. I hate them because I'm big
enough
On Mar 17, 10:29 am, Volker Braun wrote:
> On the contrary, the error message that you get right now is 100% spot on.
It does show that cached_function changes the interface behaviour,
though, which is a little less than desirable:
sage: @cached_function
: def t(a):
: if not isin
On Sunday, March 17, 2013 9:07:41 AM UTC-4, Nathann Cohen wrote:
> But I have no way to give a meaningful error message if the user feeds it
> with any other non-hashable iterable :-/
>
On the contrary, the error message that you get right now is 100% spot on.
--
You received this message bec
Well, the function only takes tuples as input right now.
But I have no way to give a meaningful error message if the user feeds it
with any other non-hashable iterable :-/
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe fr
HellO !!!
> The error message tells it: Lists (as opposed to tuples) can not be used
> as keys of a dictionary (are unhashable), because they are mutable.
>
> The values computed by a cached_function are stored in a dictionary
> (unless it is a cached method that takes no arguments apa
Hi Nathann,
On 2013-03-17, Nathann Cohen wrote:
> TypeError: unhashable type: 'list'
>
> ...
>
> Would anybody here know what's happening ?
The error message tells it: Lists (as opposed to tuples) can not be used
as keys of a dictionary (are unhashable), because they are mutable.
The values com
26 matches
Mail list logo
