Most of the cards pick on one 'Thing or Item' to learn and memorise at a time:  
in decks.

A piano piece is a whole 'System: lasting two minutes to an hour.

There must be something that can be researched in this area:  Eg. how long it 
takes, after how much practice;  for the system to begin to fall apart.  Then 
reorganise the values of 'Forgetting Index'  for systems together with a 
'System complexity' fudge factor.  This may lead to very useful training 
programs with real value.  One thing that would be essential is to begin to use 
system logic to crack the nut.

Some concert musicians lock themselves in their practice rooms for 8 to 14 
hours at a time:  until their current pieces "Are scheduleat the very least 
'Perfect'".  If possible they will go on to be 'Transcendent' or whatever will 
confound the critics.  As soon as a version of Mnemosyne can be developed to 
help this overly heroic practice schedule we have to think of some clever words 
to prevent the critics using it to perfect their articles.

The same idea should help train pilots fly to the Moon, or to Brazil, on their 
simulators.  Dazed Confusion does lead somewhere...

George


On 6 Jan 2011, at 21:04, dazedconfused wrote:

> I'm wondering whether the same algorithm would be appropriate for
> procedural memory. I'm not intimately acquainted with Ebbinghaus'
> work, but I think it was based on declarative memory. These types of
> memory are executed by different parts of the brain (declarative in
> hippocampus, procedural is less understood), so there may indeed be
> differences. Any thoughts? Research?
> 
> I play piano, and if I don't practice a song from time to time, I
> forget how to play it completely. It's not that I can't remember the
> names of the chords, but my hands just don't know where to go. A
> mnemosyne card that reminds me to play a given song would be great,
> but I'm not sure that the algorithm would be appropriate for that sort
> of memory.
> 
> On Jan 6, 3:26 pm, Gwern Branwen <[email protected]> wrote:
>> On Thu, Jan 6, 2011 at 3:00 PM, Oisín <[email protected]> wrote:
>>> Very nice article. What do you mean by a system-wide executable here,
>>> though? Could we just check for an attribute "lang" or something, and take
>>> that to be the interpreter that will execute the (escaped) code in the src
>>> parameter?
>>> e.g.
>>> <eval src="a = rand(99)+1; b = rand(99)+1; puts \"#{a} * #{b} = #{a*b}\""
>>> lang="ruby"/>
>>> Mnemosyne could just dump the src value to a temporary file and call the
>>> specified interpreter (in this case "ruby tmp"), capturing the standard as
>>> the result of the <eval>?
>> 
>> Well, you could do this. For *some* languages. For some uses. And it
>> would quickly fall apart when one goes beyond a toy math example - how
>> does one link in all the libraries one might want to employ or specify
>> versions?  This approach is not too terrible for one language used in
>> stereotypical ways, like the current Latex functionality. Whereas if
>> you simply shelled out to a specified executable, the executable could
>> be a script for whatever language or a compiled binary or whatever.
>> It's more flexible.
>> 
>>> While I love the idea, I'm finding it hard to come up with simple-to-write
>>> dynamic cards that would really be useful, outside of perhaps some
>>> mathematical things like this or long division.
>> 
>> Nobody has thought much about this sort of thing in an SRS context
>> before. Basically, one can take any computer-graded set of questions -
>> increasingly common in education - and turn it into SRS flashcards.
>> Programming exercises fromhttp://turingscraft.com/? English vocab
>> from AWAD or Wiktionary? Sure. I gave some examples like Go problems,
>> but maybe those aren't convincing to non-Go players; dynamic cards may
>> be like Blub* - you have a hard time understanding their value until
>> you develop them on their own or use them for a problem.
>> 
>> * seehttp://www.paulgraham.com/avg.html&http://c2.com/cgi/wiki?BlubParadox
>> 
>> --
>> gwernhttp://www.gwern.net
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "mnemosyne-proj-users" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/mnemosyne-proj-users?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"mnemosyne-proj-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/mnemosyne-proj-users?hl=en.

Reply via email to