Why do I use "parse" - vb.net

What is the reasoning for parsing an integer? For instance, Integer.Parse('variable'.text)
I see this a lot and while manipulating data for a calculator I am building I found that Val('variable'.text) was all I need to use "numeric" values.
So, my question is how does Integer.Parse() help me with regards to calculators?
Thanks!

I found that "Val('variable'.text)" was all I need
If that's the case then go ahead and use Val(). But be aware that it behaves differently than .Parse() (or, often preferably, .TryParse()) methods.
For example, what do you want to do if the user inputs "123 isn't 456"? Val() will (I think) return:
123 As Double
Or how about the input "123 456"? That would be:
123456 As Double
Do you want it to be a Double? Do you want it to throw an error because it's not purely numeric? Something else? The behavior you want should be reflected in the code you write. Use Val() for one set of behaviors, .Parse() for another.

Related

Is it acceptable to use `to` to create a `Pair`?

to is an infix function within the standard library. It can be used to create Pairs concisely:
0 to "hero"
in comparison with:
Pair(0, "hero")
Typically, it is used to initialize Maps concisely:
mapOf(0 to "hero", 1 to "one", 2 to "two")
However, there are other situations in which one needs to create a Pair. For instance:
"to be or not" to "be"
(0..10).map { it to it * it }
Is it acceptable, stylistically, to (ab)use to in this manner?
Just because some language features are provided does not mean they are better over certain things. A Pair can be used instead of to and vice versa. What becomes a real issue is that, does your code still remain simple, would it require some reader to read the previous story to understand the current one? In your last map example, it does not give a hint of what it's doing. Imagine someone reading { it to it * it}, they would be most likely confused. I would say this is an abuse.
to infix offer a nice syntactical sugar, IMHO it should be used in conjunction with a nicely named variable that tells the reader what this something to something is. For example:
val heroPair = Ironman to Spiderman //including a 'pair' in the variable name tells the story what 'to' is doing.
Or you could use scoping functions
(Ironman to Spiderman).let { heroPair -> }
I don't think there's an authoritative answer to this.  The only examples in the Kotlin docs are for creating simple constant maps with mapOf(), but there's no hint that to shouldn't be used elsewhere.
So it'll come down to a matter of personal taste…
For me, I'd be happy to use it anywhere it represents a mapping of some kind, so in a map{…} expression would seem clear to me, just as much as in a mapOf(…) list.  Though (as mentioned elsewhere) it's not often used in complex expressions, so I might use parentheses to keep the precedence clear, and/or simplify the expression so they're not needed.
Where it doesn't indicate a mapping, I'd be much more hesitant to use it.  For example, if you have a method that returns two values, it'd probably be clearer to use an explicit Pair.  (Though in that case, it'd be clearer still to define a simple data class for the return value.)
You asked for personal perspective so here is mine.
I found this syntax is a huge win for simple code, especial in reading code. Reading code with parenthesis, a lot of them, caused mental stress, imagine you have to review/read thousand lines of code a day ;(

Is there a null(empty) value in Numeric in labview?

I would like to enter empty in place of Zero in numeric. i dont want use strings.
In Numeric field we can enter only NAN or INF but i want enter Empty.
There is no such thing as an Empty value for floating-point numerics in LabVIEW, just as there is no such thing in C#, C++, Java, or C. They all use the same IEEE standard to define floating-point values.
I opened an idea for this on the Idea Exchange: Create an "Optional" input type wrapper in the style of C++17's std::optional.
It was largely rejected because it's not a suitably useful thing for general use, but some ideas as to how you might implement it yourself were discussed there (don't miss the second page).

Converting std::int to System::Single

Apologies if there's an answer out there already; but all I seem to be getting is a bunch of "I want to turn my 1 into a 1.0" chaff from my Google searches.
First things first. No, I'm not talking about a simple Convert::ToSingle() call. Rather, I need to convert the representation of the data to a System::Single.
So in other words, I'd like to take int myInt = 1065353216;, and the result should be something like 1.000. I know the pure c++ method would be something like float myFloat=*(float *)&myInt;;but I need the managed version.
Thanks in advance for your help.
If you're in C++/CLI, you can do it the same way as you do in C++: float myFloat=*(float*)&myInt;
In pure managed-land, there are built-in methods to do this for double & Int64 (DoubleToInt64Bits and Int64BitsToDouble, but not for single & Int32. However, if you look at the implementation of those methods (MS Reference Source), you'll see that they're doing the exact same thing as you have listed, so that's also the managed way to do it. The only difference is if you do it in C#, you have to tag the method as unsafe.

Which variable name is proper?

I want to make a variable that is condiments that the customer wants.
I thought 'condimentCustomerWants' is okay
But I would never see variable name that contains relative pronouns in other's codes.
So I asked to my friends, and he recommended 'customerWantsCondiment', which is sentence.
Hmm.. which name is proper, good, and readable?
I'll throw desiredCondiments into the mix.
Depends on everyone's coding style really. i would do
requestedCondiment
desiredCondiment
preferredCondiment
condimentForCustomer
preferredCondimentForCustomer
wantedCondiment
and so on...
HOW you name your variables is entirely up to you, however they should always reflect what the variable is actually supposed to do.
If it is: 'Does the customer want a condiment', you'd want:
CustomerWantsCondiment (true/false value, probably a boolean)
If it is: 'Which condiment does the customer want?', you'd want:
CondimentCustomerWants (for example an int value)
They sound similar, but both have different meanings.
Whatever works best for you, really.
You may also want to adhere to a variable name convention, starting your variable name with a letter, that indicates the type of the variable. That way, you will know the type of a variable at a glance, without having to look for the actual definition.
Please note, that the introducing letter(s) are always lower case.
For example:
bool bCustomerWantsCondiment;
int iCustomerWantsCondiment;
char *sCustomerWantsCondiment;
etc.
For more information regarding the hungarian notation, please look here for example:
http://en.wikipedia.org/wiki/Hungarian_notation
Also, for readability, you should use the 'CamelCase' convention. That means, each time you begin a new word in the variable name, start it with a capital letter.

can a variable have multiple values

In algebra if I make the statement x + y = 3, the variables I used will hold the values either 2 and 1 or 1 and 2. I know that assignment in programming is not the same thing, but I got to wondering. If I wanted to represent the value of, say, a quantumly weird particle, I would want my variable to have two values at the same time and to have it resolve into one or the other later. Or maybe I'm just dreaming?
Is it possible to say something like i = 3 or 2;?
This is one of the features planned for Perl 6 (junctions), with syntax that should look like my $a = 1|2|3;
If ever implemented, it would work intuitively, like $a==1 being true at the same time as $a==2. Also, for example, $a+1 would give you a value of 2|3|4.
This feature is actually available in Perl5 as well through Perl6::Junction and Quantum::Superpositions modules, but without the syntax sugar (through 'functions' all and any).
At least for comparison (b < any(1,2,3)) it was also available in Microsoft Cω experimental language, however it was not documented anywhere (I just tried it when I was looking at Cω and it just worked).
You can't do this with native types, but there's nothing stopping you from creating a variable object (presuming you are using an OO language) which has a range of values or even a probability density function rather than an actual value.
You will also need to define all the mathematical operators between your variables and your variables and native scalars. Same goes for the equality and assignment operators.
numpy arrays do something similar for vectors and matrices.
That's also the kind of thing you can do in Prolog. You define rules that constraint your variables and then let Prolog resolve them ...
It takes some time to get used to it, but it is wonderful for certain problems once you know how to use it ...
Damien Conways Quantum::Superpositions might do what you want,
https://metacpan.org/pod/Quantum::Superpositions
You might need your crack-pipe however.
What you're asking seems to be how to implement a Fuzzy Logic system. These have been around for some time and you can undoubtedly pick up a library for the common programming languages quite easily.
You could use a struct and handle the operations manualy. Otherwise, no a variable only has 1 value at a time.
A variable is nothing more than an address into memory. That means a variable describes exactly one place in memory (length depending on the type). So as long as we have no "quantum memory" (and we dont have it, and it doesnt look like we will have it in near future), the answer is a NO.
If you want to program and to modell this behaviour, your way would be to use a an array (with length equal to the number of max. multiple values). With this comes the increased runtime, hence the computations must be done on each of the values (e.g. x+y, must compute with 2 different values x1+y1, x2+y2, x1+y2 and x2+y1).
In Perl , you can .
If you use Scalar::Util , you can have a var take 2 values . One if it's used in string context , and another if it's used in a numerical context .