Where do I start

[MuppetMan]

Hi guys,
I test by hand am too slow.
What is best way to start coding so can test my methods systems and stop loss etc quicker.
Cheers

[Ralph]

Do you know any programming language, if so I think the best is to use that.

If it is not to complicated things use  a spreedsheet, if you do not have it get  Open Office its free.
If you need tutorials, there are plenty free on line.

I use  HTML/javaScript or VBScript, the reason is i happen to know it before.

[Still]

I recommend Excel.  It comes with a powerful Basic (Visual Basic for Applications = VBA).  You can test anything and see a visual (chart) of the results if you output data to cells.  You can read from a spreadsheet and write to it.  You don't need to use any formulas if you don't want.  VBA macro's are much more powerful, although i've seen minds in here do some pretty fancy stuff with formulas.  With VBA, you don't have to worry about making a GUI.  The spreadsheet can function like a stored array or an easy convenient place to store data before it is loaded into an array for processing.  Don't have to deal with file input/output at all if you don't want. 

Oh, and the editor supplied to work with VBA is excellent.  I don't know how it could get any easier.  The 'immediate window' comes in handy a lot too.  You can watch variables.  People take powerful tools for granted these days. 

[Stepkevh]

I recommend Excel.  It comes with a powerful Basic (Visual Basic for Applications = VBA).  You can test anything and see a visual (chart) of the results if you output data to cells.  You can read from a spreadsheet and write to it.  You don't need to use any formulas if you don't want.  VBA macro's are much more powerful, although i've seen minds in here do some pretty fancy stuff with formulas.  With VBA, you don't have to worry about making a GUI.  The spreadsheet can function like a stored array or an easy convenient place to store data before it is loaded into an array for processing.  Don't have to deal with file input/output at all if you don't want. 

Oh, and the editor supplied to work with VBA is excellent.  I don't know how it could get any easier.  The 'immediate window' comes in handy a lot too.  You can watch variables.  People take powerful tools for granted these days.

The excel sheets with formulas already helped me alot because i lack of knowledge in programming.
I know you can do alot with built-in vba macro's in excel but i really have no clue how to star and work with macros 
So i stick to my formulas 

Stephan

[Still]

The excel sheets with formulas already helped me a lot because i lack of knowledge in programming.
I know you can do a lot with built-in vba macro's in excel but i really have no clue how to star and work with macros 
So i stick to my formulas 

Stephan

that's exactly how i started, so i'm still pretty good with formulas.  But once i made the leap to learn something about programming, i was amazed by the magic.   I started in Windows 98 with memory restrictions.  My bigger spreadsheets would start to have problems.  I could see how much faster tests went using VBA.  I was clueless when i first got into programming...would look at examples for hours/days without getting it.  But its worth it, in my opinion, so you can use arrays. 

VBA has an excellent help library all its own.  Its important to know how to get data from cells and write results back into cells, so just now i looked at help>concepts>cells and ranges>how to refer to cells by using index numbers.  This is how i do it (rather than using ranges):

Sub EnterValue()
    Worksheets("Sheet1").Cells(6, 1).Value = 10
End Sub

The Cells property works well for looping through a range of cells, because you can substitute variables for the index numbers, as shown in the following example.

Sub CycleThrough()
    Dim Counter As Integer
    For Counter = 1 To 20
        Worksheets("Sheet1").Cells(Counter, 3).Value = Counter
    Next Counter
End Sub

Heres a more useful example of reading and writing: 

[reveal]
Global SizeArray As Integer
Global MyArray() As Integer
Global MyOtherArray() As Integer

Sub Main()
   SizeArray = 10          'how much data do you want to process?
   ReDim MyArray(SizeArray)
   ReDim MyOtherArray(SizeArray)
   
   Dim StartOnRow As Integer
   Dim SheetNumber As Integer
   StartOnRow = 1         'start reading data on any row you want!   
   SheetNumber = 1      'read from any sheet as long as the sheet is named "sheet1", "sheet2", ect
               'look at the subroutine parameter descriptions to find out what it handles.
               'v
   Reading 1, StartOnRow, SizeArray, SheetNumber, MyArray()
   Writing 2, StartOnRow, SizeArray, SheetNumber, MyArray()
   DoTheMath MyArray(), MyOtherArray()
   Writing 3, StartOnRow, SizeArray, SheetNumber, MyOtherArray()
End Sub

Sub DoTheMath(InputArray As Variant, OutPutArray As Variant)
    Dim I As Integer
    MyOtherArray(0) = 0 + InputArray(0)
    For I = 1 To UBound(MyArray)
        OutPutArray(I) = OutPutArray(I - 1) + InputArray(I)
    Next I   
End Sub

Sub Reading(Column As Integer, StartRow As Integer, ByVal NumRows As Integer, SheetNum As Integer, WhichArray As Variant)
   'Reading data into an array from cells.
    Dim I As Integer, Counter As Integer
    Counter = 0
    With Worksheets("Sheet" & SheetNum)
    For I = StartRow To StartRow + NumRows
          WhichArray(Counter) = .Cells(I, Column).Value
          Counter = Counter + 1
    Next I
    End With
End Sub

Sub Writing(Column As Integer, StartRow As Integer, ByVal NumRows As Integer, SheetNum As Integer, WhichArray As Variant)
   'Writing data from an array to cells.
    Dim I As Integer, Counter As Integer
    Counter = 0
    With Worksheets("Sheet" & SheetNum)
    For I = StartRow To StartRow + NumRows
          .Cells(I, Column).Value = WhichArray(Counter)
          Debug.Print WhichArray(Counter)
          Counter = Counter + 1
    Next I
    End With
End Sub
[/reveal]

You can get going with this as a starter template.  Almost anything you write will need to read some data into an array, process the array, and write the array back out to a sheet.  This starter template lets you easily control the source of the data, how much data, where to start reading the data (what row) and the location of the output.  The controls for all this are in Sub Main().  There isn't anything in the subroutines that is hard-coded.  It's all flexible through the use of parameters.   

You can cut and paste the above code into a 'module' (not a form, nor a class module), click the run button (or hit F5) and watch it go.  But first put some data on the sheet, and in the column from which you want to read.   I've used a lot of Integers so it will run fast.  If you will be reading or writing anything other than an integer, just change certain variables to the right data type, or none at all (will default to Variant).

Notice it also writes to the 'immediate window' which is especially useful for testing bits of code in a hurry. 

You can also use the macro recorder to learn some things about manipulating cells. 

There's several good practices going on in the example i concocted.  It may not be perfect. The work is done in the subroutines, and parameters allow a lot of flexibility.  The main subroutine sets the parameters and calls the subroutines to do the work. 

[VLS]

What is best way to start coding so can test my methods systems and stop-loss etc quicker.

My humble advice:


Start at the beginning, learning from scratch.


Familiarize yourself with programming foundations, then build upon them.


I would NOT advice to start with Excel programming, but rather with a text-mode/console language where you can get efficient with things like if/else for/do/while statements, variables, opening and closing files and just get a general sense of programming.


Then you can transfer your acquired basic knowledge to Excel's VBA or any other language you might end up favoring.


So, in short: You start at the "Hello World".


Plenty of wishes for your success MuppetMan!


A version of BASIC will provide you with a good initial experience. It is important for a newcomer to achieve gradually, and not become trapped and frustrated by syntax.


Vic

[VLS]

Sorry if I politely disagree dear Still! I'm very glad you are fostering interest towards Excel, yet MuppetMan is a newcomer, so -in my humble opinion- he would be better to start from the very beginning: BASIC and Text mode.

Do believe I've seen the dropout rate for other more complicated approaches!

If the newcomer sees himself achieving little by little it builds confidence... Aiming to a full-blown method tester as a first project might be daunting for a start; so he might better build foundations and get his skills up to par, then make an attempt at building the tester... of course, unless MuppetMan likes a challenge!

[Ralph]

Microsoft Visual Basic Express is free.  I use 6.0 which is older version, and have not update to the new, its more like Java nodays, which also you can get free.

[VLS]

Some BASIC dialects recommended to newcomers:

Basic256:

link:://:.basic256.org/

It is a very light-hearted BASIC aimed at kids, you don't have to worry about declaring the correct variable type.

Ideal for learning programming foundations.

JustBASIC:

link:://justbasic.com/

Can create windows applications.

Fellow member Esoito swears to it! He codes on it.

FreeBASIC:

link:://freebasic.net

Creates native applications for Linux and Windows. It's BASIC with the power of C!

There is a bundled Editor + Compiler package named FBIde: link:://fbide.freebasic.net/

The whole package is only 3 MB.

[VLS]

By the way, just wanted to say thanks to Still, Stepkevh and Ralph for lending a hand to MuppetMan.

It is always great to see the community helping a fellow member

Kudos MuppetMan for wanting to learn coding.

Remember: Where there's a will, there's a way! ...with a little help from your friends

Cheers!

[Still]

Sorry if I politely disagree dear Still! I'm very glad you are fostering interest towards Excel, yet MuppetMan is a newcomer, so -in my humble opinion- he would be better to start from the very beginning! BASIC and Text mode. Do believe I've seen the dropout rate of more complicated approaches! If the newcomer sees himself achieving little by little it builds confidence... Aiming to a full-blown method tester as first project might be daunting for a start; so he might better build and get his skills up to par, then attempt building the tester... of course, unless MuppetMan likes a challenge!

Hi VLS, yes i suppose my post was more for Stepkevh whom we know to be a very advanced formula user.  I collect Basics, even the most basic Basic, because they are fun.  A couple years ago i was intrigued by GW-Basic, you know, the line numbers and the fast immediate feedback.  I actually took the time to get good at it...maybe too much time.  But i would have to agree that no programming experience is wasted because the principles are the same over and over. 

If MuppetMan wants to have the same kind of fun i did he can check out GW-Basic.  If he runs XP he can check it out by clicking on the old executable and it will come up in a cmd window and be blazing fast.  If he has Win 7 he can run it in DosBox or try this very good online version that somebody wrote:

link:://:.addressof.com/basic/#/Home

And here's a very good online manual:

link:://:.antonis.de/qbebooks/gwbasman/index.html


On the other hand, both GW-Basic and Excel share in common a concept called 'immediate mode'.  According to another GW-Basic programmer linked next, Visual Basic (Basic not connected with Excel) never had an immediate mode. 

link:://:.galacticelectronics.com/NewBasic.HTML

But Excel does, and it's an interesting way to get 'immediate feedback' for beginning, or for debugging.  Excel provided an 'immediate window' where you could do something like this:

A = 10
B = 20
PRINT A + B
30 

...where 30 is the immediate feedback you get after entering the previous three lines.  A or B could be a reference to the value in a cell.  The immediate window is also a good way to test and debug individual subroutines before they get plugged into the main program.  Let's say MuppetMan wanted to start with a simple subroutine that tests the use of parameters and printing.  In a module he could write:

[reveal]
Sub Test(MyVar, MyOtherVar, MyImmediateReward)
      Fail = "It just doesn't add up!"
      Sum = MyVar + MyOtherVar
      TestNumber = 5
      If Sum = TestNumber Then Debug.Print "The sum is "; Sum
      If Sum = TestNumber Then Debug.Print MyImmediateReward
      If Sum <> TestNumber Then Debug.Print "Who cares if the sum is "; Sum; "?"
      If Sum <> TestNumber Then Debug.Print Fail
End Sub

[/reveal]

Then, he could go down to the immediate window and call this subroutine with parameters like so:

test 2,3,"Very Good!"
The sum is  5
Very Good!


Then, MuppetMan can change one parameter (or both, or all), position the cursor after the call, and hit enter again for more immediate results:

test 3,3,"Very Good!"
Who cares if the sum is  6 ?
It just doesn't add up!

This is as "Basic" as it gets.  Except with Excel, the beginner has the aid of the very excellent editor.  It offers color coding, and automatic capitalization of key/reserved words.  It checks syntax and offers intelligent error messages. Not least, it offers pop up suggestions what you can type next, and/or what it expects you to type next.  Example, if he goes to the immediate window and types test <space bar>, a little pop up will tell him all the parameters in his subroutine, and make bold the parameter it is expecting next.   The beginner can't go wrong.  To avoid misspelling variables (a bothersome bug) i introduce all my variables with CamelCase.  Then, when i'm typing code, i type the variable with all smalls.  If i spelled the variable right, the Excel editor will capitalize the letters that correspond to the CamelCase.  If i've misspelled, all the letters will stay small. It's a great way to avoid bugs. 

Since VBA doesn't even need to deal with spreadsheets cells if the programmer is not ready, it's a very 'Basic' way to begin.  I found the rewards sufficient to keep me going, even when programming seemed difficult.  The help library always offers an example or two to get the ball rolling when it's stalled. 

Be well,
~Still

[Ralph]

If your computer is Window, you allready can start using the script engine.
How to write scripts, just google "Window Script" .

Ex. of a first small program: Open Notpad and save the file as "test.vbs"
Doubleclick the icon, and the script will run.

Code is the line below

Wscript.echo "Hello World."

Simple but we all start here,

[Ralph]

Paste this in notepad, save as rand.vbs

Do not forget to set Notepad while saving "All files" otherwise it may be rand.vbs.txt as file name.

This gives you 37 random numbers between 0 and 36

Code:



intHighNumber = 36
intLowNumber = 0
For i = 1 to 37
   Randomize
   intNumber = Int((intHighNumber - intLowNumber + 1) * Rnd + intLowNumber)
   nostr = nostr & Cstr(intNumber) & ","
Next

Wscript.Echo nostr

[Still]

Another way to begin could be with an old text book...i mean really old, like from 1975, 1979 or 1985.  I have three from those eras, all teaching Basic to college students, where presumably they had access to either an IBM PC (perhaps in a lab) or a mainframe somewhere accessed through a Teletype Model 33 like Paul and Bill started on as shown in this picture:

[reveal][attachimg=1]  [/reveal]

You can tell a book is really old when you can tell the the code listings were typed on just such a Teletype Model 33 (or a dot matrix printer).  One book (from 1975) even says that the Teletype 'terminal' is likely to be the only part of the computer the student is likely to see.  The mainframe could be buildings, or miles away.  The 'terminal' printout was the sole output for such computers.  If you didn't see it on paper, you didn't see it.   Hence, the term PRINT, even though it now 'prints' to the non-paper 'display'. 

As late as 1985, line numbers were accepted as the way you deal with 'real' let's-get-down-to-business computers.  I was intrigued by this method and wanted to know why, and to experience whether or not it was harder or easier to program that way.  After much study in history, experience and thought, i've concluded that a line number for every line of code was because they were trying to combine a 'line editor' facility with the need to have 'labels' in code for jumps and loops...and because all this was being done sequentially on typed-out paper under usually very limited and/or expensive memory.   

So much code was written under these circumstances, that it almost (probably did) became an unnecessary tradition, held in place for compatibility with so much legacy code, legacy text books, and the idea that line numbers are associated with the world's most powerful business machines (so it could be a little marketing involved).  Thus, the IBM PC came configured with a line-numbered form of Basic (known as GW-Basic under  Microsoft's own brand) as late as 1985.  Everybody just took it for granted, didn't question, and dealt with it. 

My experience shows that even without code, the earliest text editors used line numbers.  You could not jump around the screen changing things because they didn't have screens!  Just sequential printers.   Generally speaking, your average code only needs about 20% of it's lines to be labeled for jumps and loops.  It's better if they don't need to be actually numbers!  History shows people made due with what they had in ingenious ways. 

Learning Basic from an old text book is potentially an interesting way to learn two things at the same time, programming, and also it's history.  Believe me, nowadays we've got it good.  Excel VBA is sweet compared to what they dealt with in those days without much complaint. 

One thing i notice about all these old college Basic texts is they always have lessons on how to calculate matrices.  As if you'd ever actually use one.  I think this was more about showing off the calculating power of the computer, when there wasn't much else to show off!  You never see an example anymore showing how to calculate a matrix! At least not since the movie came out! 

One thing they were always good at was the 'PRINT USING' facilities/statement. It was an ingenious way of formatting words and numbers for presentation on the printed report page. 

I wanted to know why they coded with all capital letters.  From a programmers point of view, you lose a lot of information.  But from a memory point of view, you save a lot of memory, and let it be used instead for functional power.  Once memory became cheap, and non-paper 'display' screens became the norm, you no longer saw line numbers.   

Quick Basic or QBasic is the first of Microsoft's flagship language products that finally dispensed with line numbers, and all cap letters.  With some ingenuity, smart programmers had already implemented such a scheme on the old 8-bit, memory starved CP/M (before DOS) machines.  So why didn't Microsoft do this before i can only speculate for reasons mentioned above; legacy code and marketing relative to legacy ideas about big mainframe computers.  Every college student was programmed to accept line numbers as the means of communication with a big mainframe computer somewhere. 

Even if you know how to program, stepping through an old text book doing the lessons can be a lot of fun...like time traveling. 

Be Well,
~Still

[Still]

If your computer is Window, you allready can start using the script engine.
How to write scripts, just google "Window Script" .

You're absolutely right.  VBScript is the new Basic that came packaged with every PC. It's right there, ready to go, with an editor as simple as Notepad, once the extension is changed to the very powerful .vbs   .

  And before that it was these things called BATCH (.bat) files, that still actually work on Windows 7, even though PowerShell has taken over that function.  PowerShell came installed with Windows 7 and something like it came with Vista and XP.  But as you'll notice, the syntax isn't nearly as 'Basic' looking as VBScript or what is known as WScript (Windows Script).  However, if you want to go beyond an input box and a message box, you have to go with a third party .com or .dll program. 

I'm happy to introduce a very useful, simple, helpful and powerful Basic-like language;

AutoIt.

I wouldn't doubt it could even allow a programmer to put together a robot that automatically plays roulette in a live account.   It has as much control over Windows as anything I've ever seen, comes with hundreds of sample programs, an excellent editor, and superb help files.  It simple, but it's not a toy!  This is a very useful tool.  Completely modern, supported, and on the cutting edge. And yet, it's still free.  Unbelievable!

~Still