Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: "hotness" (Read 201811 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

"hotness"

Reply #175 –
Quote
this is true that taylor series would produce that result. i believe that most calculation programs actually use a taylor algorythm to calculate #e but the problem with usign this is still the need for the usage of a power of x during the series. thinking of all possible solutions that i know of i think that the only way to do this would be some sort of code added to foobar itself to be able to handle exponentials and powers. in fact, looking through that entire page i see that every solution to finding #e contains at least one power that cant be hard coded as just a coefficient (at least in any ways that this novice can think of). and i would have loved to have seen this in hotness also but i dont think it is possible with foobar's current capabilities
[a href="index.php?act=findpost&pid=315639"][{POST_SNAPBACK}][/a]

Maybe using the exponential Taylor serie expressed as:

Code: [Select]
1+x*(1+x/2*(1+x/3*(1+x/4(1+x/5(...)))))



may reduce the calculation time depending on the priority of operations in the foobar algorythm as it may reduce it by a bunch of multiplications (and i think that "factoriel": "!" (I'm french)  isn't an already existing operation in foobar)

And as a limited development at the sixth or seventh degree might be already sufficient for something as simple as calculating hotness which is still experimental and doesn't need precision but something with the global behavior of the exponential function, if that was what you were talking about

edit: anyway it's true that an already existing exponential function would be nice 

"hotness"

Reply #176 –
umm... well... lol.. I just thought of something. If accuracy isn't that big of an issue then we don't need to use something like Taylor series to calculate #e. After all, #e is an irrational constant that is calculated by such methods. But the fact is that #e IS A CONSTANT that is approximately 2.71828182846. If we need more accuracy than that then it is a little ridiculous for something like 'hotness'. The only real problem would be coding some sort of method to bring this number to a power of '-at', where '-a' is the coefficient of decay, and 't' is the interval of time. Therein lay the problem that one would need to solve for this to be able to be implemented.

I can’t believe that I didn’t think about #e as a constant before. I am a ‘recovering’ math major after all.
Anyone who takes himself too seriously always runs the risk of looking ridiculous; anyone who can consistently laugh at himself does not. -- Havel

"hotness"

Reply #177 –
um, i'm having trouble implementing this could some help me. There are 3 versions on the front page so i chose the "play date" version. I copied that into globals > variables and ticked the 2 boxes. Then created a column with the %_hotness% and i get this :S

screenshot

those numbers are wrong

[span style='font-size:8pt;line-height:100%']moderation: please refrain from inlining images larger than roughly 800x600 and 80KB. please use thumbnails and/or links for large pictures instead. try PNG for reduced filesize.[/span]

"hotness"

Reply #178 –
Do we really need to use exponential function for this?  I think you can approximate the behavior of a decay curve like e^(-x) using a rational function like 1/(x*(x+1)+1).

"hotness"

Reply #179 –
Quote
Do we really need to use exponential function for this?  I think you can approximate the behavior of a decay curve like e^(-x) using a rational function like 1/(x*(x+1)+1).
[a href="index.php?act=findpost&pid=319628"][{POST_SNAPBACK}][/a]


some form of that could work. So far i have com up with 100(count*rating)/((age)x*(x+1)+1).
where
count == playcount
rating == song rating
age == age of song in some incrimental value based on the added (or some other standardised) variable.

The problem is that this allows for values over 100 and we are no longer working with percents. we would need to figure out some sort of way to limit it to only being at 100. maybe an $if statement that would just hold the value at 100 until the decay brings the hotness below 100. Another problem would be to choose the units of x (time after song was last played) and age so that they wouldn't cause the song to delay too slow or too fast (there might need to be some conversion involved with this).
Another problem would be if someone doesn't use added or any other variable to base the age of the song on then the function will not work. there would need to be some check for that with an alternate function. Maybe the origional linear script could be used then. I don't know. I am not a coder so I am not sure how much of this is viable for use.
Anyone who takes himself too seriously always runs the risk of looking ridiculous; anyone who can consistently laugh at himself does not. -- Havel

"hotness"

Reply #180 –
Quote
um, i'm having trouble implementing this could some help me. There are 3 versions on the front page so i chose the "play date" version. I copied that into globals > variables and ticked the 2 boxes. Then created a column with the %_hotness% and i get this :S

screenshot

those numbers are wrong

[span style='font-size:8pt;line-height:100%']moderation: please refrain from inlining images larger than roughly 800x600 and 80KB. please use thumbnails and/or links for large pictures instead. try PNG for reduced filesize.[/span]
[a href="index.php?act=findpost&pid=319536"][{POST_SNAPBACK}][/a]


i get the same thing. it looks like the hotness variable isn't done being calculated before being the value is shown.

"hotness"

Reply #181 –
@matth6546 and @12zmcnvow1277

I also had the same thing happen for a while there. Check the format of your variables for last_played and also make sure you have make date info available checked under globals tab.
last_played needs to be in the %Y-%m-%d %H:%M:%S format for this to work correctly. Also, if you use the Added tag then it needs to be in the %Y%m%d format.
Anyone who takes himself too seriously always runs the risk of looking ridiculous; anyone who can consistently laugh at himself does not. -- Havel

"hotness"

Reply #182 –
i'm using the play_date version, not last_played. and i dont have the added tag.

"hotness"

Reply #183 –
Quote
i'm using the play_date version, not last_played. and i dont have the added tag.
[a href="index.php?act=findpost&pid=319889"][{POST_SNAPBACK}][/a]

if you're using the most recent version of foo_playcount, you need to use the last_played version (or the hourly decay version).  play_date is an obsolete tag used by old versions of foo_playcount.


also, i've been putting off a huge revamp of this code for some time now.  but eventually the nature of hotness will be very different, and will take all play_stamps into account if you have them enabled, allowing for much more nuanced decay curves.  so, turn on play_stamp tagging now to collect data if this is something you'd like to see.

"hotness"

Reply #184 –
I really like this idea, it's very cool to have all these data that I'd never otherwise look at, and which on their own don't really say anything terribly useful, reduced to a single useful and interesting dimension. Now if I only had some playcounter data that wasn't from the last few days.... Anyway, awesome stuff! 

Just thought I'd suggest an alternate code for the actual display column - to blend between a few different colours on its trip from 100 to 0 hotness, and give a little more potential for differentiation. In my code it goes 100->0 red->orange->yellow->green->blue->blue/black, but it's easy enough to muck around with the colour values. And if the song's never been played, the dot doesn't show up at all. All this just goes straight in the column's display field (the colour field gets left totally alone). All fairly pointless, but there you go.

Code: [Select]
//colours used, hotness=100:0
$puts(colour100,0000FF)
$puts(colour99,0000FF)
$puts(colour75,00FFFF)
$puts(colour50,00FF00)
$puts(colour25,FF8800)
$puts(colour0,880000)

//dotshading
$if(%last_played%,
$select(
$add($put(hotdiv,$div(%_hotness%,25)),1)
$puts(shade,$sub(%_hotness%,$mul($get(hotdiv),25))),
$blend($get(colour0),$get(colour25),$get(shade),25),
$blend($get(colour25),$get(colour50),$get(shade),25),
$blend($get(colour50),$get(colour75),$get(shade),25),
$blend($get(colour75),$get(colour99),$get(shade),25),
$get(colour100)
)• 
,)


Also spiffy alternate colour sets to paste over the other colour bit:

white->yellow->orange->red->black
Code: [Select]
$puts(colour100,FFFFFF)
$puts(colour99,FFFFFF)
$puts(colour75,00DDDD)
$puts(colour50,0088FF)
$puts(colour25,0000AA)
$puts(colour0,000000)


white->blue->black
Code: [Select]
$puts(colour100,FFFFFF)
$puts(colour99,FFFFFF)
$puts(colour75,DDAA22)
$puts(colour50,CC0000)
$puts(colour25,880000)
$puts(colour0,000000)

"hotness"

Reply #185 –
Quote
@matth6546 and @12zmcnvow1277


last_played needs to be in the %Y-%m-%d %H:%M:%S format for this to work correctly. Also, if you use the Added tag then it needs to be in the %Y%m%d format.
[a href="index.php?act=findpost&pid=319806"][{POST_SNAPBACK}][/a]



Is last play part of playcount? because in playcount I only have play date and play time available, do i replace play time with last played? and in playdate, have:

%Y-%m-%d %H:%M:%S ?

Also my tags are tagged %D/%M/%y would i have to play each track once to make them tag at the new standard? or is there someway i can convert all tags to the new way? thanks for your help.

"hotness"

Reply #186 –
Quote
Quote
i'm using the play_date version, not last_played. and i dont have the added tag.
[a href="index.php?act=findpost&pid=319889"][{POST_SNAPBACK}][/a]

if you're using the most recent version of foo_playcount, you need to use the last_played version (or the hourly decay version).  play_date is an obsolete tag used by old versions of foo_playcount.


also, i've been putting off a huge revamp of this code for some time now.  but eventually the nature of hotness will be very different, and will take all play_stamps into account if you have them enabled, allowing for much more nuanced decay curves.  so, turn on play_stamp tagging now to collect data if this is something you'd like to see.
[a href="index.php?act=findpost&pid=319911"][{POST_SNAPBACK}][/a]

thanks man. i just installed the latest play_counter plug-in, pasted in the hourly decay and everything works as it should.
 

"hotness"

Reply #189 –
Quote
Quote
is this the latest playcount version?
http://65.17.81.165/foobar/foo_playcount.dll
it's 40kb, if it's old can someone give me the link to the newest version, i cant seem to find it
[{POST_SNAPBACK}][/a]

[a href="http://pelit.koillismaa.fi/plugins/tagging.php#125]http://pelit.koillismaa.fi/plugins/tagging.php#125[/url]
[a href="index.php?act=findpost&pid=320355"][{POST_SNAPBACK}][/a]



Thanks for the Link! it would be nice if the link in the playcoun thread was updated too, i thought that was the latest build

"hotness"

Reply #190 –
hotness 2.0

A completely revamped version of the hotness algorithm, employing %play_stamp% tags supplied by foo_playcount 1.7.6 to create dynamic hotness decay tailored to each song's unique play history.

In order to use this script, you MUST have foo_playcount 1.7.6, with the PLAY_COUNTER, LAST_PLAYED, FIRST_PLAYED, and PLAY_STAMP boxes checked in preferences.  Although I am not releasing the script yet, if it's something you plan to use, I highly recommend turning these options on now to begin collecting data for the script to use as soon as it's installed.


In previous versions of the hotness algorithm, a song's hotness began at 100 and decayed in a linear fashion to 0, over a period of time that was defined by the song's rating and play frequency.

This meant, in short, that periods of heavy or light play were not weighted properly.  Even if you were to play a song many times in the past few days, a low overall play frequency would cause the hotness to decline very quickly.

The new algorithm uses a song's entire play history rather elegantly to construct a unique decay curve for that song.  Here are some graphs to illustrate.



This is the play history of a song.  The black dot (node) at the bottom is the first play.  As time passes upward on the graph, each node represents another play.  Notice that it has been played relatively steadily.

Now we are going to take these nodes and spread them out horizontally, an arbitrary three units per node:



This is the basic outline for the hotness decay curve.  The horizontal axis will become time, and the vertical axis will become hotness.

However, we don't want the hotness to begin exactly at 100.  So, in order that the most recent play is taken into account, but not so heavily, we will "deaden" the hotness a little by placing secondary hotness nodes in between each primary playstamp node:



The red line you see is exactly the path hotness will follow throughout its decay.  The timespan that the horizontal axis represents will be determined by rating: a higher rating will "stretch" the decay period horizontally, while maintaining the shape of the curve.  Overall play frequency is no longer considered in this algorithm.*

Now see the dramatic effect this new approach has on an irregularly-played track:



Notice that, because the song has been played a lot recently, its hotness will remain quite high for the majority of the decay.

Likewise, a song that was played a lot in the past, then played recently after a very long break, will start with a relatively low hotness, drop off rather quickly, then plateau at a low hotness for the remainder of its decay.


I'm waiting to release the script until I make sure all the bugs are out of it, and to get some feedback.  *For instance, the length of the decay period is now determined only by rating, not by overall play frequency.  Is this a good idea / bad idea?  That's one issue that comes to mind.  Because of the quirks of this algorithm, I may also have to begin using minutes, not hours, as the unit of measure, but I'm doing my best to avoid that.

Any other feedback would be greatly appreciated.

"hotness"

Reply #191 –
I don't think play_stamp is available in the official 1.7.6 of play_count.  I will try and get a new version out in the next week or so with the feature you suggested as well as finalised play_stamp support (don't worry, the format won't change).

"hotness"

Reply #192 –
Quote
I don't think play_stamp is available in the official 1.7.6 of play_count.  I will try and get a new version out in the next week or so with the feature you suggested as well as finalised play_stamp support (don't worry, the format won't change).
[a href="index.php?act=findpost&pid=323888"][{POST_SNAPBACK}][/a]


I can't find Play Stamp either, how long until you release the code? Will it be beta or are you jumping straight into version 2? can't wait 

"hotness"

Reply #193 –
Quote
Quote
I don't think play_stamp is available in the official 1.7.6 of play_count.  I will try and get a new version out in the next week or so with the feature you suggested as well as finalised play_stamp support (don't worry, the format won't change).
[a href="index.php?act=findpost&pid=323888"][{POST_SNAPBACK}][/a]


I can't find Play Stamp either, how long until you release the code? Will it be beta or are you jumping straight into version 2? can't wait 
[a href="index.php?act=findpost&pid=323970"][{POST_SNAPBACK}][/a]

i'm not sure when i'll release it, i'm waiting for all the changes to foo_playcount to be finalized.  or at least until i find out from kl33per how it will behave when it's done.

i can't wait either, i really like the way this operates. 

"hotness"

Reply #194 –
Wow... this is taking some interesting turns. I may just switch from the SQL version of playcount to use this. I really would like to keep the playcount data in my SQL database though. oh well.  at least I will be able to use my quicktagger SQL data. lol.

@12zmcnvow1277

And what I did to get %last_played% was just edit one of the variables that my version of playcount used. sorry it took so long to get back on this. have not been able to get to my computer (I am on someone elses at the moment) and wont get back to it till after september 16th.
Anyone who takes himself too seriously always runs the risk of looking ridiculous; anyone who can consistently laugh at himself does not. -- Havel

"hotness"

Reply #195 –
i have a question.
i have about 5000 songs . some of them from 6 years ago.
none of the songs has FIRST PLAYED tag. only LAST PLAYED. is there a way to add first played automaticlly to all of them by the "date created" in the explorer?

thanx.

"hotness"

Reply #196 –
To eliazu

You must use foo_quicktag plugin.

"hotness"

Reply #197 –
pIv,
great but what is the command for putting the date created file in FIRST PLAYED ?
i saw that there is import button in the quicktag plugin properties - can someone upload a file that do so?

"hotness"

Reply #198 –
To eliazu

You also need plugin foo_filedate: create tag Created or Added or Modified or Accessed.

Then in quicktags you create new field First_played

with value %created%' 00:00:00'

"hotness"

Reply #199 –
Quote
pIv,
great but what is the command for putting the date created file in FIRST PLAYED ?
i saw that there is import button in the quicktag plugin properties - can someone upload a file that do so?
[a href="index.php?act=findpost&pid=324193"][{POST_SNAPBACK}][/a]

for the purposes of hotness, i would recommend that you just let the playcount plugin create the first_played tag.  otherwise the algorithm will reflect what appears to be a large gap between the first play (the creation date) and the first play_stamp (which won't appear until you turn on foo_playcount).  in other words it will think you haven't played it at all between the time it was created and the first time you played it with foo_playcount running.