• 0

VB.NET Checking Division by Zero and Multiple Fields


Question

Me again :D

 

New problem -

 

(Flav1Cost.Value / Flav1Size.Value) + (Flav2Cost.Value / Flav2Size.Value) + (Flav3Cost.Value / Flav3Size.Value) + (Flav4Cost.Value / Flav4Size.Value) + (and so on up to 10)

 

Some of these pairs may both be zero (resulting in a DivideByZero exception), but they all need to be added together.

 

What's the solution? Im sure it's stupidly simple and I can't see it... :s

 

Thanks :)

24 answers to this question

Recommended Posts

  • 0

1) Switch to using an array.

2) Use a loop

3) In the loop only do the division and add the result to the sum total if the size value is not zero (possibly only if both the size and cost are not zero; avoiding the division by zero exception is the important thing, whether or not to check the other value  in the if statement is a micro optimisation that I doubt is worth worrying about here).

 

Pseudo code:

$sum_total = 0

# Array of ten flavs, each a pair of values, size then cost
$flavs = array( { 1, 2}, {8, 3} ... )

# loop, either a for loop looping specifically ten times, or a more dynamic statement that takes the number of items in the array and loops that many times (more flexible, less prone to bugs)
for each $flav in $flavs
{
    if ($flav[0] != 0 && $flav[1] != 0)
    {
        $sum_total += $flav[0] / $flav[1]
    }
}

print "Sum total: $sum_total"
  • 0

Me again :D

 

New problem -

 

(Flav1Cost.Value / Flav1Size.Value) + (Flav2Cost.Value / Flav2Size.Value) + (Flav3Cost.Value / Flav3Size.Value) + (Flav4Cost.Value / Flav4Size.Value) + (and so on up to 10)

 

Some of these pairs may both be zero (resulting in a DivideByZero exception), but they all need to be added together.

All you need to do is figure out the pattern and isolate it. Obviously the pattern here is:

Flav[x]Cost.Value / Flav[x]Size.Value

Since you have a collection of values of the same type you should be a using a collection to store them, not an arbitrary number of individual variables.

 

You could either use two collections of doubles (or whatever the type of "Value" is), but that's a bit error-prone because you need to ensure the two collections will have the same number of elements. Easier would be to create a data type that contains the two values and have a collection of this data type. Then just iterate the collection using a for-each loop or such.

 

At that point you just need to handle the cases where the "Size" component is 0, obviously throwing a DivideByZeroException is not a viable option. If-Else could help you.

  • 0

Thanks Andre and blazingangel.

 

blazingangel's reply gave me an idea and I was able to accomplish what I needed.

Andre, I haven't ventured into Collections yet but I'll look into them for the future. Thanks for the advice.

  • 0

Late but would be helpful to create a function to do the calculation and then just loop through the collection and pass the values to the function. Pretty much same as what others have said but a function allows you to keep code common and easily testable.

  • 0

I'd be curious to see an example where goto actually is the best solution. I've read and wrote a fair bit of code by now and never saw it used, much less had to use it myself. In fact I currently lean towards languages that incidentally don't have goto, like F# and Haskell.

  • 0

Not trying to be a d*ck here but why does people still code in VB? Use C# at least cmon! hehehe

If it's VB.NET then in the end it all compiles down to MSIL so there really is no difference... now if it's old VB then yes, why are you still using that...

  • 0

VB.NET is so much better than VB6, but even then it's still kinda meh, and there are some things C# can do that VB can't (Like unsafe sections)

It might be because I grew up writing BASIC, but now when I see it I just get the feeling it's so outdated (Compared of course, to a new language like C)

  • 0

Unsafe aside it's pretty much the same thing with a different syntax. For some reason lots of people associate this syntax - or perhaps just the name "Visual Basic" - with "easy" or "novice" which apparently makes VB still hugely popular. At this point VB really isn't any simpler than C#, so its sole reason for existence is this self-perpetuating aura of beginner-friendliness. There's nothing really wrong with the language IMO, but I'd say it's sort of redundant and pointless, given C#.

  • Like 1
  • 0

Not trying to be a d*ck here but why does people still code in VB? Use C# at least cmon! hehehe

Like others have said C# and VB.NET are almost identical. VB can do some things C# can't, and C# can do some things VB can't.

You can easily translate code between the two with several online tools - one click and you got VB->C# or vise versa.

 

It was a PITA coming from VB6 to .NET, having to re-learn alot of things, but in the end it's a much better language.

Now if they can just solve the problem with slow startups...

  • 0

Yeah but I mean the syntax. VB is more like a pseudolanguage syntax while C# kinds of prepares you to easly learn probably every other language you want.. thecnnically, vb.net and c# are the same, for the final program

  • 0

Like others have said C# and VB.NET are almost identical. VB can do some things C# can't, and C# can do some things VB can't.

You can easily translate code between the two with several online tools - one click and you got VB->C# or vise versa.

 

It was a PITA coming from VB6 to .NET, having to re-learn alot of things, but in the end it's a much better language.

Now if they can just solve the problem with slow startups...

slow startups? If anything it's the assembly not being precompiled that causes that, you can either have it precombiled for the architecture it's running on or have it happen at runtime... the compiler compiles it to MSIL, after that on the end system you get the local system compile it for the system it runs on at first run if it's not precompiled... I've never had a slow app start that was written in .NET when I precompiled it for the end arch

  • 0

slow startups? If anything it's the assembly not being precompiled that causes that, you can either have it precombiled for the architecture it's running on or have it happen at runtime... the compiler compiles it to MSIL, after that on the end system you get the local system compile it for the system it runs on at first run if it's not precompiled... I've never had a slow app start that was written in .NET when I precompiled it for the end arch

 

What I've done is run ngen on my assembly on the customer's machine on install. Fixed issue, but IIRC you can't precompile and distribute assemblys because they are processor specific.

  • 0

RyuJIT is addressing JIT compilation times, and .NET Native will essentially nullify all these costs by statically linking everything together and compiling to optimised native code. That said on projects I currently work on, including a very large application with dozens of assemblies and millions of LOCs, startup time isn't a huge issue, and it's something we can keep under control in various ways.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.