Visual Basics Calculater hexadecimal and binary numbers - vb.net

as an exercise for university we need to create a calculator with visual basic.
It has to be able to work with hexadecimal numbers and binary numbers.
My plan is to translate those to normal numbers, calculate and than translate them back, so i can use the simple +, -, *, / .
Unfortunately i wasn't able to find any translation between the number systems.
Is there anybody, who could send one in? It'd help me quite a lot.
Greetings Phil

The Convert class:
Dim fromHex As Long = Convert.ToInt64("beef", 16)
Dim fromBin As Long = Convert.ToInt64("1011110", 2)

Related

Kotlin: Convert Hex String to signed integer via signed 2's complement?

Long story short, I am trying to convert strings of hex values to signed 2's complement integers. I was able to do this in a single line of code in Swift, but for some reason I can't find anything analogous in Kotlin. String.ToInt or String.ToUInt just give the straight base 16 to base 10 conversion. That works for some positive values, but not for any negative numbers.
How do I know I want the signed 2's complement? I've used this online converter and according to its output, what I want is the decimal from signed 2's complement, not the straight base 16 to base 10 conversion that's easy to do by hand.
So, "FFD6" should go to -42 (correct, confirmed in Swift and C#), and "002A" should convert to 42.
I would appreciate any help or even any leads on where to look. Because yes I've searched, I've googled the problem a bunch and, no I haven't found a good answer.
I actually tried writing my own code to do the signed 2's complement but so far it's not giving me the right answers and I'm pretty at a loss. I'd really hope for a built in command that does it instead; I feel like if other languages have that capability Kotlin should too.
For 2's complement, you need to know how big the type is.
Your examples of "FFD6" and "002A" both have 4 hex digits (i.e. 2 bytes).  That's the same size as a Kotlin Short.  So a simple solution in this case is to parse the hex to an Int and then convert that to a Short.  (You can't convert it directly to a Short, as that would give an out-of-range error for the negative numbers.)
"FFD6".toInt(16).toShort() // gives -42
"002A".toInt(16).toShort() // gives 42
(You can then convert back to an Int if needed.)
You could similarly handle 8-digit (4-byte) values as Ints, and 2-digit (1-byte) values as Bytes.
For other sizes, you'd need to do some bit operations.  Based on this answer for Java, if you have e.g. a 3-digit hex number, you can do:
("FD6".toInt(16) xor 0x800) - 0x800 // gives -42
(Here 0x800 is the three-digit number with the top bit (i.e. sign bit) set.  You'd use 0x80000 for a five-digit number, and so on.  Also, for 9–16 digits, you'd need to start with a Long instead of an Int.  And if you need >16 digits, it won't fit into a Long either, so you'd need an arbitrary-precision library that handled hex…)

What is the difference between String.Substring and Mid?

I am really confused between Mid and Substring in VB.NET. Can anyone help me understand the difference with the help of a program? It will be really appreciated.
You can read the documentation for Mid and for Substring
The biggest difference arises from Mid being a legacy adapter function intended either to help VB6 code work if pasted into a vb.net project, or to provide VB6 programmers with some familiar functionality while they switch to using the modern .NET equivalent (Substring)
As a legacy function, Mid adopts the VB6 notions of strings being one-based indexing, rather than zero based (used by nearly everything else .NET) so anything you Mid should have a start parameter that is 1 greater than anything you Substring
Mid("Hellow World",1,5) 'returns Hello
Substring("Hellow World",0,5) 'returns Hello
Substring has a corollary, Remove, which removes chars after a certain point like Left used to. Ditching Left/Mid/Right in favour of Substring/Remove makes it easier to understand what to use/what will happen if the string passed in is in a right-to-left language

How do I return several consecutive from a string? vb

Trying to create a small Visual Basic console application in visual studio here. I need to obtain a couple of consecutive characters from a string entered by the user. I know how to return one character from a string using the getchar( 'string name', 'where is char you want located') but am not aware on how to obtain several consecutive chars. If there's way to do something like: getchar(string, count, count + 1, count + 2) that'd be great to know. And i'm not very experienced with visual basic or any type of code at all so keeping it simple and understandable would really be appreciated.
Thanks.

VB 2010, Complex numbers

Hi does anybody know if is possible to utilise formulas containing complex numbers within basic programming. Part of the formula im trying to implement is i(e^2-e^2-2), e represents exponential and i the imaginary number. Any help appreciated.
Add a reference to the System.Numerics library to your project (Go to MyProject->References->Add->Assemblies->Search the list for System.Numerics). You can also import the namespace in your source by using Imports System.Numerics.
In this library you can find functions to compute complex numbers.
You define a complex number for example with the line
Dim MyComplex as New Complex(Realpart, ImaginaryPart)
To compute the exponential you would use
Dim Exped as Complex = Complex.Exp(MyComplex)
and so on. There are functions for most operations and the complex numbers support general operators like +, -, *, / as well.
For your specific problem you would just use
Dim result as New Complex(0, Math.Exp(2)-Math.Exp(2)-2)
This works because i*x is a complex number with a real part of zero and an imaginary part of x. I'm not judging how much sense your definition makes :-)

What is the rationale behind "0xHHHHHHHH" formatted Microsoft error codes?

Why does Microsoft tend to report "error codes" as hexadecimal values?
Error codes are 32-bit double word values (4 byte values.) This is likely the raw integer return code of whatever C-style function has reported an error.
However, why report the error to a user in hexadecimal? The "0x" prefix is worthless, and the savings in character length is minimal. These errors end up displayed to end users in Microsoft software and even on Microsoft websites.
For example:
0x80302010 is 10 characters long, and very cryptic.
2150637584 is the decimal equivalent, and much more user friendly.
Is there any description of the "standard" use of a 32-bit field as an error code mechanism (possibly dividing the field into multiple fields for developer interpretation) or of the logic behind presenting a hexadecimal code to end users?
We can only guess about the reason, so this question cannot be answered for sure. But let's guess:
One reason might be that with hex numbers, you know the number will have 8 digits. If it has more or less digits the number is "corrupt" (for example, the customer mistyped). With decimal numbers the number of digits for the same value varies.
Also, to a developer, hex numbers are more convenient and natural than decimal numbers. For example, if some info is coded as bit flags you can decipher them manually easily in hex numbers but not in decimal numbers.
It is a little bit subjective as to whether hexadecimal or decimal error codes are more user friendly. Here is a scenario where the hexadecimal error codes are significantly more convenient, which could be part of the reason that hexadecimal error codes are used in the first place.
Consider the documentation for Win32 Error Codes for Active Directory Service Interfaces, ADSI uses error codes with the format 0x8007XXXX, where the XXXX corresponds to a DWORD value that maps to a Win32 error code.
This makes it extremely easy to get the corresponding Win32 error code, because you can just strip off the last 4 digits. This would not be possible with a decimal error code representation.
The middle ground answer to this would be that formatting the number like an IPv4 address would be more luser-friendly while preserving some sort of formatting that helps the dev guys.
Although TBH I think hex is fine, the hypothetical non-technical user has no more idea what 0x1234ABCD means than 1234101112 or "Cracked gangle pin on fwip valve".