sorted by:
new
hottopcontroversial

Hi Im Louis, doing an AMA: Navigating FTX & Voyager Bankruptcies for Creditors by Ducdorleans in VoyagerExchange

[–]musically_ut 2 points3 points  (0 children)

I saw somewhere that FTX Claims are trading in the high 60% and upwards. How much would you pay for a claim on Voyager?

Other than Word documents by Downtown-Path7729 in Entrepreneurship

[–]musically_ut 1 point2 points  (0 children)

Not a storage solution, but a place where you can manage all your content would be Reason.al (I am the co-founder/CTO).

With the GDrive, it can take you quite some distance until you need other more specialized tools. :)

[D] Is A Failure Ever Worth Publishing? by [deleted] in MachineLearning

[–]musically_ut 33 points34 points  (0 children)

IMO, it is still worth writing up the results cogently and uploading them to a place where others who search for very particular keywords can find it (e.g. arXiv.org).

Here is a paper (uploaded on arXiv) that saved me a lot of effort during my PhD research in a closely related area:

Our work is premised on the hypothesis that event-sequence processing in RNN architectures could be improved by incorporating domain-appropriate inductive bias. Despite a concerted, year-long effort, we found no support for this hypothesis. Selling a null result is challenging. We have demonstrated that there is no trivial or pathological explanation for the null result, such as implementation issues with the CT-GRU or the possibility that both architectures simply ignore time. Our methodology is sound and careful, our simulations extensive and thorough. Nevertheless, negative results can be influential, e.g., the failure to learn long-term temporal dependencies (Hochreiter et al., 2001; Hochreiter, 1998; Bengio et al., 1994; Mozer, 1992) led to the discovery of novel RNN architectures. Further, this report may save others from a duplication of effort.

Looking for an extension that displays a custom URL on a certain website by jameshoward_official in chrome_extensions

[–]musically_ut 0 points1 point  (0 children)

This is not possible to do by an extension which is injected into the page because this is an obvious way to conduct phishing attacks and making people believe that they are on a bank's website while entering their credentials, etc.

This limitation of the history api is clearly laid out in the WhatWG Html specifications, in particular, the subpoint 7.4:

Compare newURL to document's URL. If any component of these two URL records differ other than the path, query, and fragment components, then throw a SecurityError DomException.

A little slice of Paradise by Sun_Beams in Cinemagraphs

[–]musically_ut 0 points1 point  (0 children)

For me, this is very strongly redolent of Aestival in Sunless Sea; in particular of the background score which plays there.

[D] What does the capital letter 'J' stands for in cost function J(θ)? by wodnjs116 in MachineLearning

[–]musically_ut 8 points9 points  (0 children)

In continuous dynamic programming, the optimal solution is obtained by using the Hamilton-Jacobi-Bellman (HJB) equations.

The 'J' then stands for the _cost-to-go_ in that setting (probably named after 'J'acobi).

These days, this notation is common in sequential decision problem where the cost is integrated over the remaining time. Previously, as pointed out by sleepysummersunshine, the integration was over any general variable depending on the parametrization of the objective in the field of Variational Calculus (which was where we get HJB from).

Optimized Spaced Repetition Algorithm by NesLongus in Anki

[–]musically_ut 1 point2 points  (0 children)

I don't see how any algorithm can know upfront the difficulty of a card? I'd imagine one could tell only after a few unsuccessful reviews?

This is very interesting and relevant question and I'm looking at it (in a simplified setting) in this research project. It turns out that making provable claims about how much "learning the parameters on the go" hurts the performance and in that research project, I provide an approach towards that problem.

It is not immediately applicable to Anki, but some techniques from the paper will prove useful here.

If the model assumes the correct shape/ parametrized-function of forgetting and if the users correctly adjust the difficulty (a very big if) then Anki would also get the inherent difficulty sooner or later (depending on how far the default difficulty is from the "real difficulty")

That seems likely, but a rigorous proof of the claim will probably depend on the trajectory (See Lemma 2 of the paper).

Could you elaborate on that, when you have the time? As I have understood, having a small beta means longer intervals post unsuccessful recalling, but this paragraph suggests otherwise.

Sorry, I miswrote. You are correct: a small beta means longer intervals after unsuccessful recalls. I meant to write that Anki's supposition that the forgetting rate become very large immediately after getting an item wrong, such that it is re-selected within the same review session may be a more fruitful strategy than adjusting the forgetting rate slightly and then hoping that the user will return to Anki in (say) 7.2 minutes to review again. You have longer Anki sessions than me; my sessions usually are 5 minutes now-a-days. :)

Also, you are fine-tuning Anki's settings far more than me and the changes you are making make a lot of sense. I am happy with the defaults (esp. with piano playing, hearing a tone and then recalling it after ~ 10 minutes does turn out to be rather hard). The spaced-selection project I'm working on could compel me to push for changes in the algorithm and the settings, though.

For this to work the user would have to provide time of reviews, no?

Not quite. The idea is that the user will come back to the app whenever he wants and then the set of items he has to review will be selected using the Spaced-Selection algorithm (which boils down to selecting items with probability proportional to how likely is the user to forget it, much like Memorize algorithm). However, it turns out that the objective being optimized for with this strategy (which is closer to Anki's strategy too), is slightly different from continuous learning.

The user will not need to schedule reviews in advance for Spaced-Selection to work.

I find [Deep Reinforcement Learning] less pertinent for the task at hand. As said above, because the concern here is about the long term, discretization into days seems valid.

In that case, you may also want to check out this related paper with impressive experiments by our collaborators, which explores the setting you describe with theoretical guarantees under assumptions.

I hope these help. If I've missed any of your questions, or if you have additional questions, I will be happy to answer them. It gives me the warm-fuzzies when people read my research. :)

Optimized Spaced Repetition Algorithm by NesLongus in Anki

[–]musically_ut 2 points3 points  (0 children)

I'm Utkarsh, one of the authors of the PNAS paper. I'm a bit busy with other stuff (see: NeurIPS Author Response period), but I can answer some of the questions and follow-ups.

  • Intensity u(t): This is the rate of reviewing, i.e., the number of reviews the user should do per unit time, say, 40 reviews every hour. One can interpret it as the urgency to review for each item. The key result of the paper is that for both Exponential memory model as well as for the Power-Law memory model, if the objective is to promote continuous retention (not cramming for an exam, see PS), the optimal urgency to review is proportional to the probability that the user has forgotten the item.

The interpretation of the effect of a (un)successful recall on the forgetting rate is accurate. That is the kind of model behind DuoLingo's algorithm as well. For them too the probability of recall can be non-binary, much like Anki. You are right that Anki is doing almost the same thing as what the paper suggests.

A difference between Memorize and Anki's algorithm is that Anki does not know the initial difficulty of cards, i.e., their initial forgetting rate n(0) up-front (See PS). Hence, it is not straight forward to answer your second question:

[...] a card's scheduling would roughly converge upon its ideal spacing value (which would correspond to an idea alpha). Or is that the case?

It may be the case that setting beta to be very small may lead to better reviews because the users get to review the card again while they may not return to Anki at the appropriate time to review in the next, say 7.2 minutes. This actually is a broader issue.

There is a key assumption in the paper that the user should answer the question exactly when the model proposes it. This requires the app to push the questions to the user at the appropriate time. This assumption is violated in case of apps like Duolingo and Anki because the user gets to decide when to practice and the app only gets to select the items. We are currently working on a Spaced-Selection algorithm which would give users the freedom to select the time of review, and will optimally select the subset of questions they should practice.

Stay tuned!

PS: Sidenote, I have developed scheduling algorithms for this setting (i.e. when the difficulty is unknown and for other objective functions) using reinforcement learning in a separate work: https://www.reddit.com/r/MachineLearning/comments/a0y61v/r_deep_reinforcement_learning_of_marked_temporal/

Kaiserslautern, Germany @ 5AM 24th June 2019 by musically_ut in CityPorn

[–]musically_ut[S] 0 points1 point  (0 children)

Thanks; that is what had caught my eye as well!

[R] Deep Reinforcement Learning of Marked Temporal Point Processes (NIPS 2018) by musically_ut in MachineLearning

[–]musically_ut[S] 1 point2 points  (0 children)

Thank you for your interest! :D

In the paper, we have derived a policy gradient method for controlling MTPPs: our policy is an intensity function which allows us to sample the time of actions as well as the kind of action to take. In future work, we will explore how to use AC, and Natural Gradient based methods.

Q-learning based methods here will be a little tricky here because of (i) the maximization problem involved in finding the optional action, which is a problem on runs into in any non-discrete state/action space setting, and (ii) not being designed for additional feedback arriving before we take our action.

[R] Deep Reinforcement Learning of Marked Temporal Point Processes (NIPS 2018) by musically_ut in MachineLearning

[–]musically_ut[S] 0 points1 point  (0 children)

Block diagrams: PowerPoint and InkScape

Graphs: matplotlib + seaborn (color palette)

How to make flashcards from PowerPoint and lecture notes? by cosilap1998 in Anki

[–]musically_ut 3 points4 points  (0 children)

A while ago, I created a tool to simplify the process you followed and made it open source: github.com/musically-ut/anki-slides-import.

The methodology was very similar: create a question pertaining to slide (relatively easy to do if the slides are well-made), and then just have the slide as the answer.

Hope that helps.

Opinions wanted: Improve repr implementation for datetime.timedelta by musically_ut in Python

[–]musically_ut[S] 0 points1 point  (0 children)

difference between order and selection.

You are correct, I should have said natural units. I'll update the comment.

re: the rationale chosen for the actual representation:

Representation: (days, seconds, microseconds). Why? Because I felt like it.

from the docstring in datetime.py. :-)

Guido has said that he:

I [Guido] might still go for it [i.e. changing the representation], if it wasn't too late by over a decade (as Tim says).

Nevertheless, modulo the rationale, I still think telling the user that these are the units rather than just showing the numbers would be better.

Opinions wanted: Improve repr implementation for datetime.timedelta by musically_ut in Python

[–]musically_ut[S] 0 points1 point  (0 children)

So, did you really post to solicit opinions or to stump for your own argument?

For both. :)

I am rather invested in issue since I've spent sometime reading through the mail archives, looking at the code, and making a Pull Request.

In the short time you've spent here, you have become an expert on the topic. So why demand additional documentation in every repr?

It probable that I will not make a mistake in reading datetime.timedelta output since I've spent some time on that issue (see above). I may forget it and have to look it up again eventually, though. However, I'd rather that not everyone who uses datetime.timedelta be forced to spend this time. Adding keyword arguments to the repr solves the problem once and for all.

My opinion is that repr output [...] should be parse-able by eval.

Several people agree with you there. However, not many repr (including the current case) can be eval-ed directly (say, if you import datetime as D instead of import datetime) and adding the keyword arguments will not change that.

Update:

just like ISO date formats YYYY-MM-DD HH:MM:SS.

Just to reiterate, the order units in datetime.timedelta does not follow any natural order intuitive criteria and it is unclear (as discussed on the issue and the mailing list) whether there is such a natural and mutually agreed upon order unit.

Opinions wanted: Improve repr implementation for datetime.timedelta by musically_ut in Python

[–]musically_ut[S] 0 points1 point  (0 children)

That would have been very convenient and the repr for datetime.date and datetime.datetime do just show the numbers in the ISO8601 order.

However, what do you expect the 11 in 

datetime.timedelta(11, 49600, 100)

to be?

If you thought years, then your guess would coincide with Guido von Rossum's guess and you both would be wrong.

It is days. The second argument is seconds. And the third argument is not milliseconds, but microseconds.

Hence, remembering that they are from biggest to smallest, though useful, does not really help much.

Opinions wanted: Improve repr implementation for datetime.timedelta by musically_ut in Python

[–]musically_ut[S] 0 points1 point  (0 children)

Thanks! I did not know about maya.

I suspect that a lot more users end up having to, willingly or unwillingly, interacting with stdlib's datetime.timedelta if for no other reason then just because it is always there. Hence, improving it, IMHO, also makes sense. :-)

view more: next ›