VB.net

M

Mark

Hello:

I work in Finance and have heard that VB.net is a very useful tool for
building financial models. Would anyone have an opinion? I am looking for
information related to the value of VB.net in Finance.

Thanks
 
P

Patrice

I work in Finance and have heard that VB.net is a very useful tool for
building financial models. Would anyone have an opinion? I am looking for
information related to the value of VB.net in Finance.

Do you mean http://en.wikipedia.org/wiki/Computational_finance ? As a
programming language allows to automate those computation then programming
could be interesting but you'll have to know first what to program...
 
F

Family Tree Mike

Hello:

I work in Finance and have heard that VB.net is a very useful tool for
building financial models. Would anyone have an opinion? I am looking for
information related to the value of VB.net in Finance.

Thanks

A long time ago my brother, an accountant, was required to take COBOL.
That was the language all finance was done in...

These days, I think there are many languages that _could_ be used, such
as Java or C#. The choice is mostly developer preference (or some would
say bias).
 
M

Michel Posseth [MCP]

Hello Mark ,

VB is an excellent tool for building financial applications as it has a
native financial module

why would it be bether as other languages you would ask ,why would you
favor VB ?

Well this has everything to do with the microsoft.visualbasic.dll as this is
the thing that makes
VB imho a more powerfull or call it easier to use tool as all other .Net
languages .

example :


This example uses the Pmt function to return the monthly payment for a loan
during a fixed period. Given are the interest percentage rate per period
(APR / 12), the total number of payments (TotPmts), the present value or
principal of the loan (PVal), the future value of the loan (FVal), and a
number that indicates whether the payment is due at the beginning or end of
the payment period (PayType).

Sub TestPMT()
Dim PVal, APR, Payment, TotPmts As Double
Dim PayType As DueDate
Dim Response As MsgBoxResult

' Define money format.
Dim Fmt As String = "###,###,##0.00"
' Usually 0 for a loan.
Dim FVal As Double = 0
PVal = CDbl(InputBox("How much do you want to borrow?"))
APR = CDbl(InputBox("What is the annual percentage rate of your loan?"))
If APR > 1 Then APR = APR / 100 ' Ensure proper form.
TotPmts = CDbl(InputBox("How many monthly payments will you make?"))
Response = MsgBox("Do you make payments at the end of month?",
MsgBoxStyle.YesNo)
If Response = MsgBoxResult.No Then
PayType = DueDate.BegOfPeriod
Else
PayType = DueDate.EndOfPeriod
End If
Payment = Pmt(APR / 12, TotPmts, -PVal, FVal, PayType)

MsgBox("Your payment will be " & Format(Payment, Fmt) & " per month.")
End Sub

This is just one of the manny manny examples of the
Microsoft.VisualBasic.Financial namespace
out of this box we have

Name Description
DDB Returns a Double specifying the depreciation of an asset for a specific
time period using the double-declining balance method or some other method
you specify.
Equals Overloaded. Determines whether two Object instances are equal.
(Inherited from Object.)
FV Returns a Double specifying the future value of an annuity based on
periodic, fixed payments and a fixed interest rate.
GetHashCode Serves as a hash function for a particular type. GetHashCode
is suitable for use in hashing algorithms and data structures like a hash
table. (Inherited from Object.)
GetType Gets the Type of the current instance. (Inherited from Object.)
IPmt Returns a Double specifying the interest payment for a given period of
an annuity based on periodic, fixed payments and a fixed interest rate.
IRR Returns a Double specifying the internal rate of return for a series of
periodic cash flows (payments and receipts).
MIRR Returns a Double specifying the modified internal rate of return for a
series of periodic cash flows (payments and receipts).
NPer Returns a Double specifying the number of periods for an annuity based
on periodic fixed payments and a fixed interest rate.
NPV Returns a Double specifying the net present value of an investment
based on a series of periodic cash flows (payments and receipts) and a
discount rate.
Pmt Returns a Double specifying the payment for an annuity based on
periodic, fixed payments and a fixed interest rate.
PPmt Returns a Double specifying the principal payment for a given period
of an annuity based on periodic fixed payments and a fixed interest rate.
PV Returns a Double specifying the present value of an annuity based on
periodic, fixed payments to be paid in the future and a fixed interest rate.
Rate Returns a Double specifying the interest rate per period for an
annuity.
ReferenceEquals Determines whether the specified Object instances are the
same instance. (Inherited from Object.)
SLN Returns a Double specifying the straight-line depreciation of an asset
for a single period.
SYD Returns a Double specifying the sum-of-years digits depreciation of an
asset for a specified period.
ToString Returns a String that represents the current Object. (Inherited
from Object.)

regards

Michel Posseth
 
M

Michel Posseth [MCP]

Mike ,,

AFAIK

The main tool for brokers , accountants etc etc etc is a spreadsheet a.k
Excel that is why VBA is extended with lots of handy calculation methods
as VBA is the litle brother of VB,,,, VB6 also had these methods builtin as
VB.Net is the brother ( some may argue that ) of VB6 these same methods have
there place in the VB namespace
( and no not for compatibility purposes , just the simple fact that these
methods are part of the language VB wether .Net or not )

I wonder why you answer to a post in a VB.Net newsgroup and mention Java ,
C# explicitly and not VB

By the way i work at a "financial" related company and we have rewritten the
COBOL system to VB.Net , and found that the VB.Net version of the billing
system
was more acurate as the COBOL system in several occasions.

regards

Michel
 
C

Cor Ligthert[MVP]

Michel,

I agree with every word you wrote in the messages currently in the thread,
including about Cobol which had in fact no financial methods build in like
Visual Basic has in all its dialects.

Cobol was not a financial based program language, it was oriented on Common
Business language (and then English) and therefore very much equal to Visual
Basic, while the then opponent Fortran was based on algebraic notations
(like now C#).

Fortran was used very much less in large (especial banking) solutions then
Cobol, which has been the main language from 1965 until somewhere around the
millennium. Most financial persons are not really algebraic, they are
natural language bound. (I am not aware which percentage of running large
bank solutions are still Cobol).

But tools are as good as the one(s) who uses those.

Cor
 
M

Michel Posseth [MCP]

Cor ,

I was once told that ING / Postbank still had a Cobol system and if you
google a bit you can find out that for instance Deutsche Bank AG stil,
uses Cobol
i know from one of my co workers that the interpay system had until 4
years ago ( then my colegue left there to work for us ) a Cobol system .

So i guess there is still a lot of Cobol out there what you see more and
more is that companies want to "connect" the Cobol with a nextgen layer to
the outside world
for instance look at this story
http://www.omg.org/mda/mda_files/SuccessStory_DBB_4pages.pdf

Rewriting is for those large mainframe systems probably not an option , i
only wonder who is going to maintain those systems in a few years from now
one of the reassons that ista hired me in the past was that i was capable of
reading there Cobol sources as legacy basic syntax ( pre Visual basic ) is
indeed in some way
easy for us Basic coders to understand .

Keeping this in mind i guess we as Visual Basic coders have a bright future
ahead of us :)

Michel
 
M

Michel Posseth [MCP]

Cor,

By the way you with your Cobol and VB.Net knowledge could probably sell
yourself for a fortune in such projects
it might be a good idea for you to create a Linkedin profile :) .

regards

Michel
 
F

Family Tree Mike

Mike ,,

I wonder why you answer to a post in a VB.Net newsgroup and mention Java
, C# explicitly and not VB

Sorry, I thought I had implied that VB.Net was a valid, and only pointed
out a couple of other languages that are just as valid.
 
F

Family Tree Mike

Hello Mark ,

VB is an excellent tool for building financial applications as it has a
native financial module

why would it be bether as other languages you would ask ,why would you
favor VB ?

Well this has everything to do with the microsoft.visualbasic.dll as
this is the thing that makes
VB imho a more powerfull or call it easier to use tool as all other .Net
languages .

Your point is well taken, as I didn't realize the Excel like functions
existed in that dll. My code background is in atmospheric modeling, not
financial applications. The original question had to do with the value
of VB.net in finance. I use VB.Net quite a bit, so don't think that I'm
only promoting C#.

It needs to be pointed out that your routine can be used in languages
other than VB.Net. Your code translates quite well to C#, and you can
reference the Microsoft.VisualBasic.dll from a C# project.
 
M

Michel Posseth [MCP]

Family Tree Mike said:
Sorry, I thought I had implied that VB.Net was a valid, and only pointed
out a couple of other languages that are just as valid.

Mike ,

To me that wasn`t clear , that is exactly the reasson why i mentioned it as
it looked like you diskwalified VB in favor of the other two
but i am happy that this is cleared up now , sometimes i get the feeling as
if C# evangelism is spreading through this newsgroup not that i have
anything against C#
i only have something against C# users who think that there language is
superior , cause that is just a mather of taste as i experience that in
some circumstances VB is the bether tool
as in this particular situation it definetly is . ( <sarcastic>unless the C#
coder lowers himself by setting a reference to the VB namespace
</sarcastic>)

regards

Michel
 
M

Michel Posseth [MCP]

Family Tree Mike said:
Your point is well taken, as I didn't realize the Excel like functions
existed in that dll. My code background is in atmospheric modeling, not
financial applications. The original question had to do with the value of
VB.net in finance. I use VB.Net quite a bit, so don't think that I'm only
promoting C#.

It needs to be pointed out that your routine can be used in languages
other than VB.Net. Your code translates quite well to C#, and you can
reference the Microsoft.VisualBasic.dll from a C# project.

Mike

Our replies have both crossed , but if you look up in the three in my
reponse to you ( 14:09 )
i point to the fact that a C# ( or anny other .Net language ) can use the
handy functions in the vb namespace by setting a reference

O.T.
But for some ( strange ) reasson if i mention this in a non language related
group i am beeing atacked with all sorts of non arguments to do so
personally i have the idea that it is foolish to rewrite a function for wich
the framework already provides a built in one and as the VB namespace is
part of the framework
i can not figure out anny valid argument why a C# coder would write his own
( a lot of work , error prone , a lot slower in performance if it excatly
does the same )

regads

Michel
 
T

Tom Shelton

Michel,

I agree with every word you wrote in the messages currently in the thread,
including about Cobol which had in fact no financial methods build in like
Visual Basic has in all its dialects.

Cobol was not a financial based program language, it was oriented on Common
Business language (and then English) and therefore very much equal to Visual
Basic, while the then opponent Fortran was based on algebraic notations
(like now C#).

Fortran was used very much less in large (especial banking) solutions then
Cobol, which has been the main language from 1965 until somewhere around the
millennium. Most financial persons are not really algebraic, they are
natural language bound. (I am not aware which percentage of running large
bank solutions are still Cobol).

But tools are as good as the one(s) who uses those.

Cor

It is my understanding that today, functional languages - such as OCamal - are
becomming the favored choice in the financial sector... Which is one of the
reasons we now have F# - basically OCamal.NET.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top