A free BJ simulator

New from ET Fan. There is a free open source BJ simulator on Arnold's site. Check it out! Shark

A) This is a new program. It's a major upgrade from the simulator that appeared on BJMath 5 years ago. It handles any balanced counting system, indices, custom user strategies, all the main rules including surrender, and generates win rate, average bet, percentage win, variance, score (DI squared) and ROR for any bet ramp and bankroll with the ScoCalc Score Calculator.

B) You do not need to be a programmer to begin using and enjoying SimSimp.

C) It's free and it's open source.

D) It's written in the XBasic programming language, which is also free and available over the net.

E) Since XBasic is a 32 bit compiler, it runs many times faster than the BJMath version. In fact, it does a million hands in under two seconds (counting the dealer's hand) on a typical 1 Ghz computer.

Enjoy,
ETF

You do not need to be a programmer to begin using and enjoying SimSimp.

Part of the reason you may not have got this (brilliant) idea to really take off in the past is probably down to misconceptions about this.
It would likely greatly increase the success of the project if you can give me people some examples of very simple things to do-with each step explained word for word in terms of every keyboard input.

One of the most important things to understand about programming in general is that stealing someone else's program and just changing numbers at random gives you some interesting results. Eventually, though trial-and-error you will begin to work out how to control the program.

that is probably asking for / expecting too much. I've been programming since 1968. Basic is hardly my first choice for _any_ programming project, but that is just a matter of tast (I prefer C personally, but that's yet another topic). But ETF is going to have a tough time explaining how to modify the code, while at the same time teaching both xbasic syntax and also simple programming concepts. That's what computer science departments do in universities. :)

BTW I'm staying out of the "war" but things like "gosub" are _not_ bad programming practices. C/C++ is chock full of procedure calls, which is the same sort of programming construct. Object oriented programming is certainly worthwhile, primarily from a code-reuse point of view, but it is hardly a necessity. I've written million-line applications in C, and even in assembly language, so while OOP is useful, it is not always essential, and in some key places is not used (an operating system kernel for example).

good work, ETF. I'm an open-source person (I can tell you more offline if you are interested) and think the idea can't be anything but good for everyone interested...

BTW I'm staying out of the "war" but things like "gosub" are _not_ bad programming practices. C/C++ is chock full of procedure calls, which is the same sort of programming construct.

Gosub is not the same as a procedure call. BASIC has both. There is nothing wrong with procedure calls. On the other hand, SimSimp contains 79 GOTOs.

Object oriented programming is certainly worthwhile, primarily from a code-reuse point of view, but it is hardly a necessity. I've written million-line applications in C, and even in assembly language, so while OOP is useful, it is not always essential, and in some key places is not used (an operating system kernel for example).

I absolutely agree and personally dislike OOP. But, you are talking about one person. If numerous people build an application these days, many principles of object oriented programming are common.

"Gosub is not the same as a procedure call. BASIC has both. There is nothing wrong with procedure calls. On the other hand, SimSimp contains 79 GOTOs. "

Two points:

1. What id difference between gosub and proc call? Both jump to some arbitrary point, and you can get back with a return.

2. who cares about goto's? Care to guess how many branches are inside the machine code of CVCX. :)

goto's work just fine, used correctly. Many use "pseudo-gotos" everywhere:

do {

if (c) break;

} while(0);

is a "classic" example of "goto-less" programming that really does (remember I am a compiler/operating-systems type person) have a goto, disguised as a "break". The problem I have with the "concept" is that I have seen far neater/easy-to-read code with gotos buried at key points, than with poorly written goto-less programming...

From a software engineering point of view, I would agree that the above "break" is easier to maintain as you know the break is a goto in the forward direction, and if the code is properly indented finding the target is easy enough. But I can show you some FORTRAN IV code that has gotos everywhere, yet is perfectly readable since even then indenting was perfectly legal...

And yes, ideas like data coupling, cohesiveness, etc, are important, and can be accomplished easier thru OOP models, but good programmers can do the same in assembly. After all, operating systems are huge projects, and until Unix, they were almost 100% written in pure assembler for the architecture at hand...

1. What id difference between gosub and proc call? Both jump to some arbitrary point, and you can get back with a return.

In Basic, one shares ALL variables and the other doesn't. Gosub is a violation of structure. The VB implementation is famously slow because the designers didn't feel anyone used it anymore.

2. who cares about goto's? Care to guess how many branches are inside the machine code of CVCX. :)

A very unusual statement from a CS:) Most Prof's tell first-year CS students "never use goto's." In any case, you know that branches in compiled code isn't the problem. The problem is program structure. Incidentally, branches in machine code are a separate problem as they slow execution. CVCX was coded to reduce branches and the sim engine contains no subroutines or functions at all.

goto's work just fine, used correctly. Many use "pseudo-gotos" everywhere:

do {

if (c) break;

} while(0);

is a "classic" example of "goto-less" programming that really does (remember I am a compiler/operating-systems type person) have a goto, disguised as a "break". The problem I have with the "concept" is that I have seen far neater/easy-to-read code with gotos buried at key points, than with poorly written goto-less programming...

But that is not a goto. As you go on to say:

From a software engineering point of view, I would agree that the above "break" is easier to maintain as you know the break is a goto in the forward direction, and if the code is properly indented finding the target is easy enough.

That's the point. This does not violate program structure. And code that is to be shared should be structured. (And as well as not containing a single ELSE, SimSimp is not properly indented.)

But I can show you some FORTRAN IV code that has gotos everywhere, yet is perfectly readable since even then indenting was perfectly legal...

Well FORTRAN was originally unstructured - until FORTRAN IV. Took awhile before FORTAN programmers used any structure or indentation.

And yes, ideas like data coupling, cohesiveness, etc, are important, and can be accomplished easier thru OOP models, but good programmers can do the same in assembly. After all, operating systems are huge projects, and until Unix, they were almost 100% written in pure assembler for the architecture at hand...

And they suffered from all the problems inherent in unstructured code:) Burroughs OS was written in ALGOL in the 60s. But more commonly, IBMs 370 OSs were developed in PLS starting in 1972. And the result was far superior to preceding IBM OSs. UNIX goes back that far but had nowhere near the use of IBMs mainframes.

Structured programming goes back to the early 60s. There really is no excuse in writting an unstructured program 40 years later. Particularly if it is open source.

You wrote:

"A very unusual statement from a CS:) Most Prof's tell first-year CS students "never use goto's." In any case, you know that branches in compiled code isn't the problem. The problem is program structure. Incidentally, branches in machine code are a separate problem as they slow execution. CVCX was coded to reduce branches and the sim engine contains no subroutines or functions at all. "

That isn't so unusual from an _experienced_ CS prof. I'm often reminded of the old "to the man who holds a hammer, everything looks like a nail" mantra. That leads me to write programs that are efficient and readable, without being stuck in a mold that says "goto's are bad, find an alternative." I can show you examples where a signficant piece of code has a single go-to, and where removing that goto would make the program 2x bigger, and 100x slower because it would make its cache footprint larger than physical cache.

BTW branches are no longer a problem from a speed perspective, it turns out they are very predictable, and with modern processors using hybrid branch predictors (i.e. the tournament branch predictor from the DEC Alpha as a good example) predicting branches is notoriously accurate when you use local branch history, global branch history (correlated branch prediction) and the like. The point is that nowadays, we can write clear/concise code without having to worry whether branches will hurt. Shoot, most don't even know that the ! operator in C produces branches every time it is used...

I suppose the point of this is to "think versatile". That is, there are, in addition to nails, a collection of screws, bolts, e-clips, c-clips, snap-rings, pins, and even good old duct-tape. :) For me, I'm just as happy writing assembly language as I am C, C++ or Snobol. It all depends on the project and goals...

And I have written _major_ projects in basic as well, when the target machine was one of the old Radio Shack machines (not the trash-80) that only had basic... They functioned perfectly well...

I never said that I agree with the common wisdom that GOTOs should never be used. There exist cases. (At least in my oldtimer's mind.) But you keep talking about programs that you have written. I am talking about open source projects and there is a big difference. When you look at someone else's work, and it has statement labels every few lines, you simply have no idea where control comes from at a particular spot in the program. Modifying the progam can be hazardous. Proper coding doesn't require statement labels. You can look backward as well as forward from any point without scanning the entire source looking for spots from which control could have passed. You think you're making a safe mod to a piece of code not realizing that you might affect some distant piece of seeemingly unrelated code. I'm not even talking about OOP. I'm talking about structured programming around for 40+ years. Most large pre-structured projects have long ago been redeveloped from scratch because the old methodology simply could not be maintained.

CVData has 253 times as much code as SimSimp. I would have no chance of adding new functionality if it weren't structured and I'm the only developer. (In fact the CVSim engine, the predecessor, was in assembly language, therefore unstructured and near impossible to modify.) Multiple developers attempting to modify one piece of unsegmented, unstructured could will see quick growing pains. And the type of project doesn't help. If you are one of many changing FireFox (an OSI project) and you make a mistake - it will be obvious. It won't work right. But if you are changing a simulator and hope to come up with a new answer; how do you know the answer is correct? There is no back of the book to look up the answer.

I guess this is the public scrutiny that ETF had to know was coming, and should be coming, regarding the SimSimp experiment.

Snyder (not ETF) like it or not has billed this experiment as the second coming of blackjack research.

In your opinion .. yes or no .. two paragraphs or less, please ..

It is an open source program (with that statement, my sum total of computer speak has just been exhausted) designed to allow anyone to open it up and code it to fit any change or nuance in the games they encounter. A reasonabale assumption for the blackjack playing public?

Add'ly, Snyder seems to feel that because it is open source many will come to the party and grow this basic structure into something really wonderful. Is SimSimp written in a form or fashion to allow it to grow and expand with the help of all the cooks in the kitchen or is it's core, it's backbone so dated or weak as to make Snyder's hope for it futile?

I would HOPE for the later but I truly have no idea.

If I understand Norm, and I don't intend to speak for him, he seems to think the hype far outstrips the real utility.

I'd be interested in your take .. believe it or not. :)

Remember, short answers are good for the programming challenged.

I have made a good living programming in a 4GL on mainframes. I have not used a PC-based language in 20 years. Last time I tried, I bought some C package which was a piece of junk. I know Basic or can at least figure it out, and I prefer not to relearn C. My question is this: What is a good, cheap, and simple PC-based programming package, where I can:
read and write to indexed files or tables
gather file/folder information
compute probabilities

your primary question. Reason is, I haven't looked at the thing. I already have CVCX and it has provided every answer I have needed in playing BJ.

In general, open source is a good thing. I have an open-source project, and the plus is that I do get feedback and changes that are worthwhile improvements to the project. The down-side is that I do get feedback and changes that are not worth anything. The good out-weighs the bad however...

The language is not what I would choose, for many reasons. I'm a long-time C/C++ programmer, and greatly prefer C to any dialect of basic ever written. Visual basic has an advantage in that there are good GUI libraries available to simplify doing lots of the things that are done in CVCX (I assume you use/have it). Simple ways to modify table rules, modify strategy indices, etc. So basic _could_ be workable, as several major companies (South Central Bell to name one big one) use visual basic for prototyping (quick and dirty way to develop an application to see if users will like the application...

Yes, there was hype about the simulator. But I've become immune to that since Microsoft has been hyping software for 20+ years. :) How good is it? No idea. ETF certainly is no dummy, whether it be in playing blackjack, explaining statistics, or probably in writing code. So chances are the reality is somewhere between the two extreme viewpoints we've seen.

Sorry, longer than two paragraphs. But hope it at least sheds some insight...

As you have said one of the points of open source is to receive comments and suggestions. I made mine. With a fair amount of detail. I have a long history of helping people that wish to write BJ software. As a result ETF impugned my motives and one of his co-moderators posted that I had a history of taking LSD and was about to be arrested. But, we�re getting used to this. It seems par for the course on these forums. I�m finished with my advice on this subject. It can be taken or not. Makes absolutely no difference to me. In fact the entire project has no effect on me other than a possible minor sales increase. But, what do I know about BJ software anyhow?

Blackjack Scams

I'm a happy owner/user of CVBJ and CVCX. And plan on continuing to be a happy user for quite a while.

Wish there was less "factioning" in the world of advantage play blackjack, but alas...

"It is an open source program (with that statement, my sum total of computer speak has just been exhausted) designed to allow anyone to open it up and code it to fit any change or nuance in the games they encounter. A reasonabale assumption for the blackjack playing public?"

That sounds accurate. Although open-source programs aren't generally designed to allow "anyone" to open it and code it, I think ETFan has said that he's designed his program to be easily tweaked by blackjack players having minimal or no programming experience. I'm not familiar with the language he used to write his sim so I have no idea how accurate that statement is.

I have to mention, though, that familiarity with a particular skill (in this case, programming) tends to cause practitioners of it to forget that their audience doesn't have the same knowledge base and experience with which to work. I'm a bit leery when someone suggests that "anyone" can alter the code.

Having said that, the simulator itself could be the best program ever written. I haven't seen the code so I have no idea. I applaud ETFan for taking the initiative to create something he hopes can be used by anyone who enjoys blackjack as much as he does. He didn't have to do it. He invested hundreds of hours in it, I'm sure, without an eye on the "profit motive". For that, he should be commended and thanked by all of us.

You do not need to be a programmer to begin using and enjoying SimSimp.

Part of the reason you may not have got this (brilliant) idea to really take off in the past is probably down to misconceptions about this.

Well, in the past, with the QBasic version, you really did need to do some programming to get something "interesting." You could get basic strategy expectations -- that's about it.

This is a whole new ball of wax.

It would likely greatly increase the success of the project if you can give me people some examples of very simple things to do-with each step explained word for word in terms of every keyboard input.

I'll follow through on your suggestion "Real Soon Now" in the weeks ahead. I'll also respond to some of the points in this thread about "structured programming" over on Arnold's board.

ETF

I don't even know what the word "co-moderator" means. What do you think? That we OK one another's posts to stay within the party line??

And I impugned your motives. So "profit motive" is a pejorative nowadays over on advantageplayer? You are a fun person.

Keep Laughin'! ;) ;)
ETF

Look, your RNG is no good. I spent a couple hours writing a new one for you and posted it. Your code is 1950s style. I explained what should be done. If you don't want to take my advice, what do I care? Don't take it. But in the last couple of weeks, for the sins of giving advice and making CVCX Online free, people from your group have demanded that my post on CVCX be deleted, I have been accused of taking LSD and of being a racist, it has been stated that I'm about to go to prison, my sex life has been discussed, you've likened me to the church in the Middle Ages and impugned my motives.

My motives are always the same. If I see a book that claims you can get a 50% advantage with no risk; I'm going to comment. I expect other authors to comment and not be attacked for doing so. If I see software that cannot calculate SCORE correctly, cannot calculate TC the way a player counts, has inadequate randomness and has almost no functionality and someone claims that non-programmers can use it to solve problems never before solved; I'm also going to comment. There is good and there is bad. This has nothing to do with 'competition.' You will never see me put down BJRM even though it is real competition. SimSimp does not compete with any CV product, so there simply is no 'profit motive.'

If you really believe you have created something on the level of a new discovery in quantum mechanics, go with God.

Besides, what do I know about BJ software.

Yes, I would agree that MVS/370 was much better than OS/360. PLAS is
an internal language that we first used on later models (small proj's)
of System 360. I'm not sure I can remember "structured programming"
in the 60's. SPS and Autocoder are distant memories. Maybe on the
larger models of the 1400 or 7000 series.

I'm puzzled by the comment that assembler language slows things. Are
you kidding or am I not understanding the context. Try channel programming and tell me that. Code that must be lean and mean as well
absolutely clean begs to differ.

UNIX is small potatoes...............