Visual Basic 2012 Random number generator

Archive
1

Hi

Again another noob question but I want to make a random number generator for 0-10 that then just simply displays on the OLED screen. I am using VB2012 not C# and have been digging around the forums and pieced this together, it just shows 0 on the OLED constantly. This is the code I am using:

Private dave As Random
Private davew As Integer
Public Sub dave2()
davew = dave.Next(10)
End Sub

    Private Sub timer_Tick(timer As Gadgeteer.Timer) Handles timer.Tick
        oledDisplay.SimpleGraphics.Clear()
        oledDisplay.SimpleGraphics.DisplayText(davew, font, GT.Color.Red, 50, 50)

Sorry if this is really bad as I am so new to it!

Thanks

2

Your question is missing one or more of these details:[ul]
The name of the product.
The code you’re trying to run. (smallest complete program showing the problem)
Details on your setup.[/ul]
(Generated by QuickReply)

3

It is a fez hydra main board, seeed oled display, VB2012.

4

@ Linkin1977 - Still need a complete program that will compile. It should be as small as possible and it should have the problem you are asking about.

5 

'global: 
Dim dave As Random = New Random()

Private Function davew() As integer
   davew = dave.Next(10)
End Function

this should work

6

Thanks Daniel

I will try it in the morning.

7

Don’t you need to call Flush() on the Glide stuff?

I’ve never used it…

Also, is anything calling dave2() to actually update your random number?

8

Thank you Daniel that is perfect. Thanks again

9

My pleasure!

Hope there are more codeshare projects with the “VB-Project”-Tag soon

10

You have a gadgeteer…

Take ANY analog reading pick one digit after comma and MOD it with 5 and add 1. Purest and best random number you will get :slight_smile:

Mod returns 0 - 5 if you mod 5, that is why you add 1 to get a random 1 - 6

1 Like
11

@ VB-Daniel - Hi

Thanks again for answering my post about the random number generator, it worked perfectly. I saw your comment about hoping there are more VB projects, do most people use C# for Gadgeteer? I quite enjoy VB but I am finding it a steep learning curve!

12

@ Linkin1977 - If I may offer my humble opinion on the topic…

If you are not familiar with either C# or VB.NET I would suggest you go the C# route.

Why? Well as you will probably realize, most examples etc. for .NET and even more so for .NETMF are in C# and if you are just learning then having to do double work of learning a language and at the same time translate samples from another language that you do not know on a platform that is also new to you, well that just seems like the least productive route to me.

If you are familiar with VB.NET and the only thing that is new to you is the platform then stick with what you know, there is nothing wrong with VB.NET. And in fact Microsoft has stated that they intend to achieve and maintain feature parity between VB.NET and C# so ultimately the only difference will be syntax.

Of course syntax is important, for example working with XML and LINQ to XML (on the desktop) is unsurpassed in VB.NET, but on the other hand lambas are much less succinct in VB.NET and C# wins that one.

This is just an opinion based on my observation so your view and others may very well differ…

13

@ taylorza - Hi, thanks for the advise. The reason I am going to stick with VB is that I am a secondary School teacher and we are introducing Computer Science for the first time (I am an Engineering teacher!) and I have been asked to set it up. We are using the exam board AQA and one of their supported languages is VB and they are doing the support material for VB as well.

I am really enjoying the gadgeteer though and starting to get to grips with it, that then raises more questions, I have just posted tonight about reading from an SD card! I suppose it shows I am keen!

It also seems a really good community on here too which is great.

14

@ Linkin1977 - That is a more than reasonable reason to stick with VB.NET and Gadgeteer/NETMF is a fun way to learn the language.

Since you will be guiding young minds, I feel compelled to tell you that some of the ‘best practices’ you might learn on NETMF do not translate to ‘best practices’ on the full desktop .NET Framework. In fact certain things you might do for performance in .NETMF will negatively impact performance on the desktop and would be considers bad practice.

15

My initial thought was most things you have to do for NETMF would be good practice for the full framework, since they involve writing efficient code. We often do things “quick and dirty” on the full framework because of the faster processor speed and larger memory.

I am sure there are a few things that would have a negative effect on the full framework, but I would have to think a while to itemize them.

16

@ Mike - Here is a quick example, and I can give more…

For performance reasons in .NETMF you would loop through an array like this


int count = arrayOfData.Length;
for (int i = 0; i < count; i++)
{
  arrayOfData[i] = someValue;
}

This performs better in .NETMF because the limit variable is not evaluated every time as it would be if it is left in the for statement.

Now because of the JIT the .NET Framework on the desktop does two things with the following version.


for (int i = 0; i < arrayOfData.Length; i++)
{
  arrayOfData[i] = someValue;
}
  1. It will automatically hoist the variable, effectively doing what we did above automatically.
  2. It will eliminate the bounds checks on the array access in the loop

The second here is the most significant, because the JIT recognizes that you are iterating through the array using the limits of the array and these are immutable it can eliminate the costly bounds check on every access. In fact if you do manually hoist the variable like the first example the JIT will no longer perform the second optimization which will ultimately hurt performance on the full Framework.

Another example is using ‘foreach’ horribly slow in .NETMF, but can in fact be faster on the desktop version for reasons not un-similar to the first example above.

Of course you only run into these things when performance is an issue. But I would say that on the desktop always use ‘foreach’ while in .NETMF I seldom use it out of habit now so someone looking at my .NETMF code might cringe, but I have profiled almost everything that I use that is contrary to the ‘best practice’ on the desktop and in a tight loop where performance is critical these things make a huge difference.

1 Like
17

@ taylorza - Good points…

My code is so efficient, I seldom have to resort to analysis to improve it. :slight_smile:

The magic word for today is “Hubris”.

18

@ taylorza - I seriously wish you would write a book about writing high performance NETMF code. You have in your brain a rare collection of information that the community (myself included) could seriously benefit from and would eagerly pay to read.

2 Likes