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?

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

IIRC imaginary types are fakes. That is, it's only a type for constants, which generates complex.

Pure imaginary has also sense, as someone said, because it distinguishes between a positve and a negative zero.

-i.

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?
> 

Helmut Leitner wrote:
> 
> In a way I fail to understand what the imaginary types
>   - ifloat
>   - idouble
>   - ireal
> are for.
me too, only Walter can tell.

-- 
+----------------------------------------------------------------------+ I Dr. Olaf Rogalsky                         Institut f. Theo. Physik I I I Tel.: 09131 8528440                       Univ. Erlangen-Nuernberg   I I Fax.: 09131 8528444                       Staudtstrasse 7 B3         I I rogalsky@theorie1.physik.uni-erlangen.de  D-91058 Erlangen           I +----------------------------------------------------------------------+

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.

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3E953FB0.3761738@hls.via.at...
> 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?
>
> --
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com

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?

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.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.

Walter wrote:
> 
> "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.

Does this a commitment that D will comply with IEEE 754 (or whatever
the latest of floating point processing standards is), better than
C, C++ and Java? (Don't know about the state of C#)

If yes, it would be an important addition to
   <http://www.digitalmars.com/d/comparison.html>
for those folks dealing with that black art.

BTW I think that there should be another two entries to the comparison:

   - one is something like "native interface" or "native call interface"
     which means that you can call a OS function directly without a
     special interface or thunk converting parameters.

     Neither Java nor C# do. Java defines "jni" (java native interface),
     a real PITA where you have to create a DLL function for any call
     you want to make into the native OS libraries. They are a lot of
     work and they slow down the calls considerably, e. g. from 7 to 40
     us for a call to QueryPerformanceCounter (750 Mhz Athlon).
     C# automates building these interfaces but it doesn't change its
     nature - they are just as slow as Javas (40 us in the example).

     This also means that a Java/C# programmer can never resort to
     small native low level functions when he wants to write software
     having competitive performance. He must hope that the functions
     are duplicated in the runtime. Often they aren't.

   - a point that should IMHO not be hidden is "runtime reflection"
     which both C# and Java have.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

C# allows the use of "unsafe" code which pretty much lets you do anything you can do in C++ (i.e., pointers are allowed).

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.

   Dan

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3E96CAD6.6E24AEB4@hls.via.at...
>
>
> Walter wrote:
> >
> > "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.
>
> Does this a commitment that D will comply with IEEE 754 (or whatever
> the latest of floating point processing standards is), better than
> C, C++ and Java? (Don't know about the state of C#)
>
> If yes, it would be an important addition to
>    <http://www.digitalmars.com/d/comparison.html>
> for those folks dealing with that black art.
>
> BTW I think that there should be another two entries to the comparison:
>
>    - one is something like "native interface" or "native call interface"
>      which means that you can call a OS function directly without a
>      special interface or thunk converting parameters.
>
>      Neither Java nor C# do. Java defines "jni" (java native interface),
>      a real PITA where you have to create a DLL function for any call
>      you want to make into the native OS libraries. They are a lot of
>      work and they slow down the calls considerably, e. g. from 7 to 40
>      us for a call to QueryPerformanceCounter (750 Mhz Athlon).
>      C# automates building these interfaces but it doesn't change its
>      nature - they are just as slow as Javas (40 us in the example).
>
>      This also means that a Java/C# programmer can never resort to
>      small native low level functions when he wants to write software
>      having competitive performance. He must hope that the functions
>      are duplicated in the runtime. Often they aren't.
>
>    - a point that should IMHO not be hidden is "runtime reflection"
>      which both C# and Java have.
>
> --
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3E96CAD6.6E24AEB4@hls.via.at...
> Does this a commitment that D will comply with IEEE 754 (or whatever
> the latest of floating point processing standards is), better than
> C, C++ and Java? (Don't know about the state of C#)

Yes, although C99 has come a long way forward in supporting it.

> If yes, it would be an important addition to
>    <http://www.digitalmars.com/d/comparison.html>
> for those folks dealing with that black art.
>
> BTW I think that there should be another two entries to the comparison:
>
>    - one is something like "native interface" or "native call interface"
>      which means that you can call a OS function directly without a
>      special interface or thunk converting parameters.
>
>      Neither Java nor C# do. Java defines "jni" (java native interface),
>      a real PITA where you have to create a DLL function for any call
>      you want to make into the native OS libraries. They are a lot of
>      work and they slow down the calls considerably, e. g. from 7 to 40
>      us for a call to QueryPerformanceCounter (750 Mhz Athlon).
>      C# automates building these interfaces but it doesn't change its
>      nature - they are just as slow as Javas (40 us in the example).
>
>      This also means that a Java/C# programmer can never resort to
>      small native low level functions when he wants to write software
>      having competitive performance. He must hope that the functions
>      are duplicated in the runtime. Often they aren't.
>
>    - a point that should IMHO not be hidden is "runtime reflection"
>      which both C# and Java have.

Good ideas.

> 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.