I was trying to counter the notion that you can't get a high performance application with C#; part of that argument is that you can't consider just C# by itself, you have to look at all of .NET.  But it sounds like you have some evidence that even C# by itself isn't as bad as one might think.

   Dan

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b7817f$296o$1@digitaldaemon.com...
> > Also, I don't think that Microsoft necessarily designed C# to be a super high-performance language.  If you need absolute performance, use C++ to create a .NET component that is used from C#; in C++ you have much more control over the managed/unmanged interface.
>
> I can't say I agree with this. The marketing hype squeaks performance, and high-scalable servers, and all that.
>
> Also, I've been working on a series of C# performance articles -
contrasting
> with C, C++, D and Java - for WDM (the first instalment goes in in June's issue), and there are a number of areas in which it comes across very
well.
> (And you can take it from me, a committed C++ fan, that I'd not be suggesting this if honesty didn't force me to.) There are also, of course, areas in which it performs very badly. I'm halfway through the series, so it's too early to tell a definitive picture, of course, but it's clear Microsoft have spent a lot of effort in providing competitive efficiency.
>
> As regards Managed C++, I think that it's largely a marketing sell to C++ programmers, and to score a psychological blow to "Unmanaged" C++ programmers. I get the argument that it lets one deal with the CLR from
C++,
> rather than C#, but I'm yet to come across something I cannot do in C#, or in C# calling into COM components or C API functions.
>
>
>
>

It's very patchy. Some things it's good at, some not.


"J. Daniel Smith" <J_Daniel_Smith@HoTMaiL.com> wrote in message news:b7efic$gi4$1@digitaldaemon.com...
> I was trying to counter the notion that you can't get a high performance application with C#; part of that argument is that you can't consider just C# by itself, you have to look at all of .NET.  But it sounds like you
have
> some evidence that even C# by itself isn't as bad as one might think.
>
>    Dan
>
> "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b7817f$296o$1@digitaldaemon.com...
> > > Also, I don't think that Microsoft necessarily designed C# to be a
super
> > > high-performance language.  If you need absolute performance, use C++
to
> > > create a .NET component that is used from C#; in C++ you have much
more
> > > control over the managed/unmanged interface.
> >
> > I can't say I agree with this. The marketing hype squeaks performance,
and
> > high-scalable servers, and all that.
> >
> > Also, I've been working on a series of C# performance articles -
> contrasting
> > with C, C++, D and Java - for WDM (the first instalment goes in in
June's
> > issue), and there are a number of areas in which it comes across very
> well.
> > (And you can take it from me, a committed C++ fan, that I'd not be suggesting this if honesty didn't force me to.) There are also, of
course,
> > areas in which it performs very badly. I'm halfway through the series,
so
> > it's too early to tell a definitive picture, of course, but it's clear Microsoft have spent a lot of effort in providing competitive
efficiency.
> >
> > As regards Managed C++, I think that it's largely a marketing sell to
C++
> > programmers, and to score a psychological blow to "Unmanaged" C++ programmers. I get the argument that it lets one deal with the CLR from
> C++,
> > rather than C#, but I'm yet to come across something I cannot do in C#,
or
> > in C# calling into COM components or C API functions.
> >
> >
> >
> >
>
>

Helmut Leitner wrote:
> In a way I fail to understand what the imaginary types
>   - ifloat
>   - idouble
>   - ireal
> are for.
> 
> I have sometimes used complex numbers - though rarely - in my life, but I never came upon applications or mathematical functions that used "pure" imaginary parts of numbers.
> 
> Could someone explain?
> 

Separate use of imaginary numbers is often used in complex arithmatic.

A simple example in electronics:

Inductive reactance X(L) of 5 ohms is described as 5i (or j5 in engineering notation).

Capacitive reactance X(C) of -5 ohms is described as -5i (or -j5 in egineering notation)

In both above examples XC and XL could be stored in an ifloat, idouble or ireal.

Calculating these imaginary values separately in a circuit is always useful. A case in which a capacitor and inductor are in series would produce a net +,-, or 0 Reactance in the circuit when added together (depending on signal frequency).  The complete complex number is made when a resistance is combined with the reactance to produce an impedance Z:

2 ohm resistance + 5 ohm (inductive) reactance:  2 + 5i (complex number) ohm.  But manipulating in equations may involve calculating imaginary values separately.

This is just basic electronic math (well actually electrical). I imagine other fields will come across similar situations, since reality has so many similar applications for mathematical tools.

Looking at Walters answer later, I don't really understand the branch cut thing.  I'll have to read the link he gave.  While complex reactances above could be stored as 0 + 5i or 0 - 5i to form a full complex number, I don't think that is "proper" syntax in electronics. Mind you, I haven't had any success in recombining these ifloat or idouble values into a whole complex number in D which is eventually necessary. I may be wrong in my understanding of this.

Hope that helps a little,

Later,

John

I don't (yet) buy Kahan's argument that a new type is needed, though. The library should be able to handle any "smarts" that the type would have. Basically, the information you get by declaring a variable to be type "imaginary" is the same as declaring it to be "complex" and testing that it has zero real part.

Said differently, you can take any algorithm that works just the way you want on pure imaginary number y*i, call it f(y), and use it in an algorithm, call it g(x,y), that does the same thing on complex numbers of the form 0+y*i by adding the following test:

if (x == 0) {
  f(y)
} else {
  ...
}

The only difference is that the imaginary class is known at compile time and the zero test is only known at run time. However if you are computing logs and sqrts, which is where branch cuts come up, the test is not going to be significant.

-Ben

"Walter" <walter@digitalmars.com> wrote in message news:b75u4a$rab$1@digitaldaemon.com...
>
> "Helmut Leitner" <leitner@hls.via.at> wrote in message news:3E967152.A99DD24E@hls.via.at...
> > Walter wrote:
> > > Having a separate imaginary type is necessary for some calculations
that
> > > need to preserve the sign of branch cuts. Multiplying by an imaginary
> number
> > > doesn't have quite the same semantics as multiplying by  0+yi.
> > I can't understand "sign of branch cuts".
> > Is this an application programming or an implementation issue?
>
> Hopefully, this will explain it better than I can:
>
> http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
>
> A branch cut (simplisticly) is attempting to draw a distinction between +0 and -0. It comes up a lot in complex arithmetic calculations. Prof. Kahan did another paper on that, but unfortunately it isn't online.
>
>