I'm writing a little javascript app that will have a pokerstove like ui. I have a deck object with each 2 card combo as a key, and a subobject with each 2suit combo as a key and a boolean value,

I've worked out a way to parse the deck object into a range string like "AA-88, AQs+, KdQd, KcQc" although I haven't written it yet. But I'm wondering at what point does this parsing (or any callback function more generally) have too many operations that it becomes a performance issue? The deck object would be parsed into a string on each change event to either the range string or the deck object via the button controls.

A worst case parse would be if every card is selected except 1 combo like heart and club 'hc'. Roughly it would be like 18 * 17 compares with pushing each combo onto a temporary array before turning that into a string among other variable updates and compares to see when something like AJ+ could be substituted for [AK, AQ, AJ] etc

Now I'm sure theres a smarter way to do this, like watching what individual card object has changed instead of reparsing the whole deck on each change and comparing that to some datastructure representing the current range string, but my question is if it's necessary. How many javascript operations can be performed on an event callback for something like a button click or input text change before it gets sluggish and its time to throttle/debounce the callback.

Well, it's not a Deck object, it's a Range object.

I would not worry about the performance of something like this until you do it and it's a problem (which I doubt it will be).

I do think the modelling problem here is more complicated than it appears, though. You have a Range, made up of PreflopHand objects, which are in turn made up of sets of 4 to 16 Card objects, depending. Then you have the interaction with flops, which removes possibilities from those sets of cards. So the meaning of a "having" the PreflopHand 98s changes depending on whether you are PF or flop, and what the particular flop is. PF there are 4 combos, but there will be fewer on some flops, etc.

A Range is made up of PreflopHand objects, and the strings you are referring to are "views" of that Range, ie, just a string representation of the object (the model). You then you need to have the concept of two PreflopHands being continguous, since that is required for doing stuff like JJ+ or 22-55, etc. The string representation itself probably should use Rule objects encapsulating how different sets of cards may be combined into discrete subsets which make up the shortcuts like 22-55, etc. It's actually a fairly difficult problem to model cleanly.

Yes, I should have called it that. I haven't written any code specifically for this, just have a file on my desktop with brainstorming notes I started a few days ago (although this has been a project idea of mine for a long time).

This is made much more managable with angular's 2 way bindings. I can make a flop directive which will directly manipulate the top level range object, so card removal effects will be accounted for before being parsed into a range string.

What do you mean by rule objects? I've figured out a goofy/bad way to parse the full range object into a pokerstove type range string, but I can tell that there is probably some elegant solution out there. Basically it's just iterating through the range object in a predefined order (AA-A2, KK-K2, etc) checking if all combos are set, in which case it gets pushed to a staging array. When it hits a card that isn't all set, it parses the first and last elements of the staging array and makes a string. ie [KT, K9, K8, K7] then if K6 isn't set or only has some combos, the string KT-7 is added to the main range string. When the 'all' condition fails it also checks for all suited combos and will push the suited card tag to a second staging array which works similar. Pairs are the easiest to fold up.

Pokerstove expired apparently (wtf) So I can't check, but I'm pretty sure this would produce the same type of range string. There are weaknesses to it like if you select all the same cards in a row they don't fold up. ie A2, K2, Q2, J2, T2. I saw syntax on I think pro poker tools for something like {x}2 but I'll put off that because it adds more complexity for little gain in terms of the big picture imo.

Angular has the idea of formatters and parsers, so this functionality would actually be a formatter for the range model even though I've been calling it a parser. The parser would be easier imo although I haven't worked on it. With 2way bindings also you could type in AK-2 and the column of buttons should compress automatically. We'll see how it goes though I haven't written a line of code other than playing around to see if I could get the bindings coordinated between components.

The long term goal is to send the range string to a server to play with

I just write a comment if I see a potential performance problem and then 95%, never come back to the code for performance.

Not entirely sure I follow your plan, but using Angular (or any other library) can't solve a modeling problem -- only an implementation one.



So right now you have a monolithic algorithm which is enacting, in an ad hoc fashion, a set of discrete rules about how to combine hands into range strings.

Rule objects would encapsulate that algorithm, and allow it to be easily broken down and changed. Practically speaking, think of the different string syntaxes for ranges out there in the real world: PokerStove, Slice, Propokertools, etc. As an example of a small change, you might want the range of all pairs to be represented as 22+ or as 22-AA. Similarly all combos of AK could be "AK" or "AKs, AKo". You might want the ability to combine along the diagonal (eg, 98s, 87s, 76s = 98s-76s), and you might want diagonal grouping to have precedence over horizontal grouping, or maybe the other way around, etc. You might even want completely different, and more powerful, syntax like propoker tools has. And you want this all to be swappable (eg, it could be a user-configurable option). In addition, you need to be able to transform the other direction: given a range string, convert to a Range object. And ideally you don't want to duplicate your rule logic when doing this inverse transformation. These are not trivial problems. The correct design is not even clear to me.

Thinking a bit more deeply about this, I understand what you mean. The problem comes in when trying to map the actual card combinations to the contextual meaning of a range.

Think of what would happen if I exclude the 8 of diamonds from the main range object because it appears in the flop. What then happens when I add 87s to the card range string input? The only decent resolution in my mind would be to have the 87s update the range model but not override the excusion of the 8 of diamonds. On the second digest loop, angular would reformat the updated model and output 8c7d, 8h7h, 8s7s in the place of the 87s we had just put in. I remember pokerstove didn't do this, but I think that was a flaw on their part. For simplicitys sake if nothing else, the range in this app will be explicit and not contextual. 87s means they could have every suited combination and not sometimes only 8c7c 8h7h.


I would like to see something like this even if I couldn't understand it.

Going from string to range object is easy so long as you make it so the presence of a card in a string whitelists the inclusion of the card. So having A8-A2 in addition to A4 wouldn't include duplicates or whatever.

Well, this part is up for debate and depends on how we want the software to work, but what I was trying to say before, and what I believe is the preferred behavior, is that *meaning* of 87s changes once an 8d is dealt on the flop. At that point 87s now means {87ss, 87cc, 87hh} rather than the full set of 4, because the phrase "your opponent has 87s in his range," eg, means that he could have any of those 3 hands. So a PreflopHand object is not a static thing referring to a static set of cards, but should probably depend on a DeadCardSet, or something like that. The "all" property in your original post (which should really be a method) would then return true if all *possible* combinations, given the dead cards, were true.



I will try, but work is still pretty busy these days. I do think this is an interesting problem.

If you think it's easy, you are probably thinking about it from the POV of one particular static way of representing cards, the stove way, and not about the larger problem I was alluding to which would solve the problem in a general way allowing for the easy swapping of representation rules and syntaxes. Because the larger problem isn't easy. Which isn't necessarily bad, if you only care about making a tool which supports stove syntax and don't anticipate it changing.

Well I realize now that I'm thinking of how to make a single street range calculator in angularjs and you're thinking much larger

overengineering ftw!

e i pi,

here's a sketch of the design i was alluding to. if how to apply it isn't clear just ask away.

Thanks for upgrading flawlessly jQuery, my plugin works great with the new version said no developer ever.

I'm starting to play around with iOS programming. I haven't done very much work with visual / event based programming before. It's wonky.

Thanks for this, I'll play around with it later.

What book are you using?

The Interwebz, by Al Gore.

I'm mostly just playing at this point and googling for stuff as I need it. I think the main thing I need is a good explanation of how the views/controllers hook together. I've been able to cobble some stuff together but it definitely doesn't seem good.

So far my impression of Xcode is pretty meh. It's missing a bunch of the eclipse/java features I like and doesn't seem as easy to use as I found Visual Studio in my brief VB.net foray.

jj,

i'm actually just about to do the same. rubymotion looks very nice. may want to check that out.

so yeah what do I do with this? somehow only broken on chrome and FF, not IE.

May I ask what you are trying to do?

In FF and Chrome, I get some strange effect that looks like a typewriter creating the text. I also think you are trying to over-ride the font-face (probably only on CSS?), but I'm not entirely sure since I don't allow site-generated fonts on FF.

On IE, it just pops up the text with no effects on it, but it does come up as (I think) Ariel. On Chrome, I am getting Arial (?) as well, but the same typewriter effect.

not sure if this helps, but here's a slightly simpler rewrite that works in both versions:

http://jsfiddle.net/Yt26F/

e i pi: I played with this when I was reading through the ANTLR book. Built a toy grammer to parse pokerhand notations.

Won't have access to the code until next month but I'll post if I don't forget. I'll have to implement this cleanly eventually, I'll let you know when I did/how I plan on doing it.

yeah that seems like a good approach for going from string --> model

I need someone to write a script for me that will do a search and replace in real-time in some text hand history files. I'm playing on some NJ sites and in the hand histories there just needs to be a slight formatting change for it to be recognized by HEM. I've tried some search and replace programs but you have to manually press it every time to execute the s+r. I need something that constantly updates. Seems like it should be pretty basic for anyone good at programming. Please PM if you are willing to help or can lead me to someone who can. Willing to ship a little bit of $$ as well. Thanks.

How have I not heard about this? Awesome.

The biggest annoyance I've had with jQuery is .prop vs .attr

Oh, very nice. I think I'll give this a shot. I wasn't particularly loving all the pointless 'C stuff' I was having to do.