memoized vs once
Locked
123
123
 
|
On 26 January 2017 at 02:10, [hidden email] <[hidden email]> wrote:
you mean like those that seaside using? it lives as long as session lives, and tied to session you are working in.. in early versions of seaside they were using exceptions to access session storage.. quite ineffective.. but it works. for that purpose it is much better to use process-specific variables, that live and die together with process that hosts them.. but has significantly better access timings. and since seaside allocates a separate process per session, that's perfect fit. in any case, the concern about getting rid of volatile data is covered.. while with memoization, i don't see it. and that seems like a HUGE argument against using it, because it is more trouble in a long run than time saver when you just start using it everywhere.
Best regards,
Igor Stasenko. |
|
|
There is the memoized with the internally declared Dictionary new as the cache and memoized using: cache There cache is known and the result is a block that does the caching thing. ([ :cacheKey| self getIssueCreateMetaWithExpandKeys: true ] memoizedUsing: self cache) value: #issueCreateMeta BlockClosure>>#memoizedUsing: cache "Provide a memoization block using the given cache. So one can tune by passing a LRUCache for instance" ^[ :x | cache at: x ifAbsentPut: [ self value: x ] ] Basically a shorthand for your recommendation. But I would have put a cull: instead of value: because sometimes, like in my case, there is no parameter, the only useful thing is the cacheKey. And it would be nice to have the :v1 :v2 :vn version with the cache key being made out of the combination + cull:cull:cull: Really, this is just a shorthand. This is nicer IMHO than having cache at:ifAbsentPut: all over. | cache factorial result | cache := LRUCache new maximumWeight: 3. factorial := 0. "avoid not-initialised warning when saving method source" factorial := [ :n | n = 1 ifTrue: [1] ifFalse: [(factorial value: n - 1) * n] ] memoizedUsing: cache. result := (1 to: 5) collect: factorial. Phil On Thu, Jan 26, 2017 at 1:36 AM, Igor Stasenko <[hidden email]> wrote:
|
|
|
In reply to this post by Eliot Miranda-2
Oops, forgive me Ben. I'm wrong. once is only equivalent to memoized for nullary blocks. It is not the same as memoized:[value:] for N-ary blocks. Forgive the noise. _,,,^..^,,,_ (phone)
|
|
|
In reply to this post by philippeback
I had a prototype called “vigorous caching”. It worked for methods without parameters though (http://blog.yuriy.tymch.uk/2016/02/vigorous-caching-in-pharo-or-how-i-used.html)
|
|
|
In reply to this post by Denis Kudriashov
Denis can we rename this selector? asMethodConst should be at least be renamed to asConstantMethod
-- Using Opera's mail client: http://www.opera.com/mail/ |
|
|
stepharong wrote:
>can we rename this selector? >asMethodConst should be at least be renamed to asConstantMethod When you use "as {something}" then "something" depicts the result of the conversion message sent to an object. Like in #asNumber or #asString which shows to what the receiver will be converted. My understanding is that in the case discussed the receiver object is NOT converted to a constant unchangeable method, so #asConstantMethod would not fit as a selector. Instead it is sent to an object that afterwards is a constant within a method (so it will not be evaluated later at runtime again) so IMHO #asMethodConstant instead of #asMethodConst would be better. Finding good names is really hardest part in programming... Thanks T. |
|
|
In reply to this post by Torsten Bergmann
Hi Torsten,
On Wed, Jan 25, 2017 at 2:45 PM, Torsten Bergmann <[hidden email]> wrote: Hi, Let's separate the implementation from the semantics. Memorizing a function implies cacheing its results for some set of arguments and answering the results, avoiding evaluating the function again. This is the effectively same semantics as [expr] once, which says that expire will be evaluated exactly once. So they're both forms of memorization. I recognized this but was too stupid/tired to realize they weren't the same, since once applies to nullify blocks and memorize applies to Nary blocks. That started this whole discussion, apologies. Now, descending to the implementations, I understand that Ben's memorize answers a block that wraps a dictionary which caches the arguments -> results mappings. #once is implemented to use become to convert the block (which in VW must be a clean block) into a cacheingBlockClosure which has an extra inst var to hold its values. We can make this work in Squeak and Pharo because we now have a prototype for clean blocks. So, quite different implementations, but very similar semantics That brings me to mention that in VW there's another, rather elegant, use for the once style block tricks, and that is to speed up step into in the debugger. Currently the implementation of step into is to simulate election (that's Smalltalk executing the InstructionStream byte code execution code, byte code by byte code) until control either returns or enters a block in the current method. That's slooooooow. The alternative is for the debugger to find all the blocks in the method and change their classes to a subclass of BlockClosure that raises an exception on value, and then use the step over code to get the VM to execute the code (via perform:) until either control returns or the exception is raised. The debugger then changes all the classes back and sets the focus to the current method. This is fast. Of course things get hairy when one considers debugging the debugger, but its all about the particular debugger only halting execution if it sees the exception is raised by the current set of blocks it has changed the classes of, and uses #pass to ignore any others created by other debuggers.
_,,,^..^,,,_ best, Eliot |
|
|
In reply to this post by Torsten Bergmann
On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <[hidden email]>
wrote: > stepharong wrote: >> can we rename this selector? >> asMethodConst should be at least be renamed to asConstantMethod > > When you use "as {something}" then "something" depicts the result of the > conversion message sent to an object. > > Like in #asNumber or #asString which shows to what the receiver will be > converted. Yes I thought that it was doing that. > > > My understanding is that in the case discussed the receiver object is > NOT converted to a constant unchangeable method, so #asConstantMethod > would > not fit as a selector. > > Instead it is sent to an object that afterwards is a constant within a > method > (so it will not be evaluated later at runtime again) so IMHO > #asMethodConstant > instead of #asMethodConst would be better. I do not understand any of them. > > Finding good names is really hardest part in programming... > > Thanks > T. > -- Using Opera's mail client: http://www.opera.com/mail/ |
|
|
On Thu, Jan 26, 2017 at 2:02 PM, stepharong <[hidden email]> wrote: On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <[hidden email]> wrote: In other words, this is creating a constant inside the method (#asMethodConstant) instead of making the method return a constant (which would be your #asConstantMethod). If I have that right. In any case, not having the contracted 'Const' would be nice. -cbc |
|
|
On 27 January 2017 at 00:28, Chris Cunningham <[hidden email]> wrote:
ah.. that sounds similar to what i proposed for computed literals, that has been computed at compilation time and placed in method's literal frame, a simple catch by reserving special selector for it, i.e..: mymethod ^ (something that should be computed , and takes a loong time) asMethodLiteral but that, of course, won't work if you would want to cache results based on method's input parameters.
Best regards,
Igor Stasenko. |
|
|
In reply to this post by stepharong
On Fri, Jan 27, 2017 at 6:02 AM, stepharong <[hidden email]> wrote:
> On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <[hidden email]> wrote: > >> stepharong wrote: >>> >>> can we rename this selector? >>> asMethodConst should be at least be renamed to asConstantMethod >> >> >> When you use "as {something}" then "something" depicts the result of the >> conversion message sent to an object. >> >> Like in #asNumber or #asString which shows to what the receiver will be >> converted. > > > Yes I thought that it was doing that. >> >> >> >> My understanding is that in the case discussed the receiver object is >> NOT converted to a constant unchangeable method, so #asConstantMethod >> would >> not fit as a selector. >> >> Instead it is sent to an object that afterwards is a constant within a >> method >> (so it will not be evaluated later at runtime again) so IMHO >> #asMethodConstant >> instead of #asMethodConst would be better. > > > I do not understand any of them. method constant = constant of a method constant method = method that does not change HTH, cheers -ben |
|
|
On 27 January 2017 at 01:30, Ben Coman <[hidden email]> wrote: On Fri, Jan 27, 2017 at 6:02 AM, stepharong <[hidden email]> wrote: are you sure? maybe it is constant method = method that returns constant? apparently, that's why 'constant' term doesn't fits there, because there's so many confusion about it. what are the constant in dynamic system, after all? HTH, cheers -ben Best regards,
Igor Stasenko. |
|
|
On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko <[hidden email]> wrote:
> > > On 27 January 2017 at 01:30, Ben Coman <[hidden email]> wrote: >> >> On Fri, Jan 27, 2017 at 6:02 AM, stepharong <[hidden email]> wrote: >> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <[hidden email]> >> > wrote: >> > >> >> stepharong wrote: >> >>> >> >>> can we rename this selector? >> >>> asMethodConst should be at least be renamed to asConstantMethod >> >> >> >> >> >> When you use "as {something}" then "something" depicts the result of >> >> the >> >> conversion message sent to an object. >> >> >> >> Like in #asNumber or #asString which shows to what the receiver will be >> >> converted. >> > >> > >> > Yes I thought that it was doing that. >> >> >> >> >> >> >> >> My understanding is that in the case discussed the receiver object is >> >> NOT converted to a constant unchangeable method, so #asConstantMethod >> >> would >> >> not fit as a selector. >> >> >> >> Instead it is sent to an object that afterwards is a constant within a >> >> method >> >> (so it will not be evaluated later at runtime again) so IMHO >> >> #asMethodConstant >> >> instead of #asMethodConst would be better. >> > >> > >> > I do not understand any of them. >> >> method constant = constant of a method >> constant method = method that does not change >> > are you sure? pretty sure. 'method' is the subject. 'constant' is the adjective that modifies the subject. Its a bit hard to explain that intrinsic feeling of what is right, but maybe.... If the adjective follows the subject its usually separated by little joining words. http://www.grammar-monster.com/glossary/adjective_definition.htm > maybe it is > constant method = method that returns constant? For me this does not compute. But I understand rules differ in other languages and its hard to avoid subtle influences from your primary language. And still, it could just be my personal bias. So if you & Stef find it ambiguous, it may be for others and we should aim to avoid that. cheers -ben > > apparently, that's why 'constant' term doesn't fits there, because there's > so many confusion about it. what are the constant in dynamic system, after > all? |
|
|
On 27 January 2017 at 02:28, Ben Coman <[hidden email]> wrote:
heh.. you see my pain! right now i have to deal with C++ and seeing all these const Type & foo const.. and cannot parse it.. :) And still, it could just be my personal bias. Well, we have more general term for objects that do not change over their lifetime - immutable. And it is moare precise, if we're talking in smalltalk context. So, why borrowing rather alien term into our ecosystem, because i barely heard that anyone were using it, and saying something like 'constant object' or something like this, when talking smalltalk context. Because when you open this 'can' of constant method, what does it means being a constant? Is is that method's properties won't change, or all object(s) it is pointing to never change as well? cheers -ben Best regards,
Igor Stasenko. |
|
|
On 27 January 2017 at 03:45, Igor Stasenko <[hidden email]> wrote:
(or if not general, but well settled)
Best regards,
Igor Stasenko. |
|
|
In reply to this post by Eliot Miranda-2
On Fri, Jan 27, 2017 at 4:32 AM, Eliot Miranda <[hidden email]> wrote:
btw, I feel a bit of an impostor having it called "my" memorize. It was Torsten's initiative based on gist by John Cromartie. cheers -ben |
Re: memoized vs once
|
|
Le 27 janv. 2017 05:55, "Ben Coman" <[hidden email]> a écrit :
Thx for the link. So, multi arg blocks someone? Phil
|
|
|
In reply to this post by Igor Stasenko
We use the term immutable for an object that _can not_ be changed and not for objects that _do not_ change. Norbert
|
|
|
In reply to this post by cbc
2017-01-26 23:28 GMT+01:00 Chris Cunningham <[hidden email]>: On Thu, Jan 26, 2017 at 2:02 PM, stepharong <[hidden email]> wrote:On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <[hidden email]> wrote: Ok, this is done 19611. Interesting to mention that while #asMethodConstant is defined on Object it also works well when sent to block. In that case BlockNode is replaced by result as literal |
|
|
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |