Float based math class. Is it exist?

[kiplring]

float sum = (float)Math.Sqrt( floatA*floatA + floatB*floatB);

I'm using DirectX with c#. But the Math class in .net framework has a
problem. It is "double" base!

So I'm doing type casting every line with Math class.

Is there any Math library float based?

[Oliver Sturm]

ki******@hanmail.net wrote:

float sum = (float)Math.Sqrt( floatA*floatA + floatB*floatB);

I'm using DirectX with c#. But the Math class in .net framework has a
problem. It is "double" base!

So I'm doing type casting every line with Math class.

Is there any Math library float based?

I don't think there's something like an alternate Math class that uses
float instead of double, no.

I assume there may be use cases where one really, explicitely doesn't
want the added precision of the double type over the float type. But in
most situations, I'd say why don't you just make your calculations with
double types, using the additional precision to your advantage, and then
cast the values just once when you pass them into the interface that
needs a float type? Is that not a usable approach for some reason I'm
not seeing?

Oliver Sturm
--
omnibus ex nihilo ducendis sufficit unum
Spaces inserted to prevent google email destruction:
MSN oliver @ sturmnet.org Jabber sturm @ amessage.de
ICQ 27142619 http://www.sturmnet.org/blog

[Atmapuri]

Hi!

needs a float type? Is that not a usable approach for some reason I'm
not seeing?

Float precision math is approx 2x faster than double.
Regards!
Atmapuri

[Jon Skeet [C# MVP]]

Atmapuri <ja************@usa.net> wrote:

needs a float type? Is that not a usable approach for some reason I'm
not seeing?

Float precision math is approx 2x faster than double.

Possibly on your computer - certainly not on all computers, and
probably not even on all operations on your computer. I've seen
examples where using float was actually slower than double, because the
processor was doing a double calculation internally, and making it
float just incurred the overhead of conversion both ways.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Atmapuri]

Hi!

needs a float type? Is that not a usable approach for some reason I'm
not seeing?

Float precision math is approx 2x faster than double.
Regards!
Atmapuri

[Jon Skeet [C# MVP]]

Atmapuri <ja************@usa.net> wrote:

needs a float type? Is that not a usable approach for some reason I'm
not seeing?

Float precision math is approx 2x faster than double.

Possibly on your computer - certainly not on all computers, and
probably not even on all operations on your computer. I've seen
examples where using float was actually slower than double, because the
processor was doing a double calculation internally, and making it
float just incurred the overhead of conversion both ways.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[kiplring]

1.

because the processor was doing a double calculation internally

Mr.Jon Skeet , Do you mean 64bit processor?
I can't image a situation that double is calculated faters than float.
Even in 64bit processor. Especially dealling directx functions. ( All
directx functions are float based)

2. There are two reasons why I want float based math
First, float precision math is 2x faster than double. It is said by
Atmapuri.
Second, type casting is severe work if it deals thousands of points.
All of the point in vertexbuffer should be calculated by math class.
and should be saved to float data every render frame.

[kiplring]

1.

because the processor was doing a double calculation internally

Mr.Jon Skeet , Do you mean 64bit processor?
I can't image a situation that double is calculated faters than float.
Even in 64bit processor. Especially dealling directx functions. ( All
directx functions are float based)

2. There are two reasons why I want float based math
First, float precision math is 2x faster than double. It is said by
Atmapuri.
Second, type casting is severe work if it deals thousands of points.
All of the point in vertexbuffer should be calculated by math class.
and should be saved to float data every render frame.

[Jon Skeet [C# MVP]]

<ki******@hanmail.net> wrote:

1.

> because the processor was doing a double calculation internally

Mr.Jon Skeet , Do you mean 64bit processor?
No.
I can't image a situation that double is calculated faters than float.
Even in 64bit processor. Especially dealling directx functions. ( All
directx functions are float based)
In some 32-bit processors, I believe there is no microcode support for
performing some floating point operations in less than 80 bits. In
other words, everything's already being converted.
2. There are two reasons why I want float based math
First, float precision math is 2x faster than double. It is said by
Atmapuri.
I'm afraid I don't know who Atmapuri is, but things may have changed
since he said that anyway.
Second, type casting is severe work if it deals thousands of points.
All of the point in vertexbuffer should be calculated by math class.
and should be saved to float data every render frame.

Certainly if you need to do a lot of converting, that could be a
performance problem - but as I said, it's possible that the processor
is having to do that conversion anyway for each floating point op.

You seem utterly convinced that you need to do everything with 32-bit
operations though, so I'll just leave it at "No, I don't know of any
maths libraries that provide the functionality you want."

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

<ki******@hanmail.net> wrote:

1.

> because the processor was doing a double calculation internally

Mr.Jon Skeet , Do you mean 64bit processor?
No.
I can't image a situation that double is calculated faters than float.
Even in 64bit processor. Especially dealling directx functions. ( All
directx functions are float based)
In some 32-bit processors, I believe there is no microcode support for
performing some floating point operations in less than 80 bits. In
other words, everything's already being converted.
2. There are two reasons why I want float based math
First, float precision math is 2x faster than double. It is said by
Atmapuri.
I'm afraid I don't know who Atmapuri is, but things may have changed
since he said that anyway.
Second, type casting is severe work if it deals thousands of points.
All of the point in vertexbuffer should be calculated by math class.
and should be saved to float data every render frame.

Certainly if you need to do a lot of converting, that could be a
performance problem - but as I said, it's possible that the processor
is having to do that conversion anyway for each floating point op.

You seem utterly convinced that you need to do everything with 32-bit
operations though, so I'll just leave it at "No, I don't know of any
maths libraries that provide the functionality you want."

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[kiplring]

Thanks for your kindness and patience. ^_^

[kiplring]

Thanks for your kindness and patience. ^_^

[Christoph Nahr]

On Mon, 22 Aug 2005 17:12:23 +0200, "Atmapuri"
<ja************@usa.net> wrote:

Float precision math is approx 2x faster than double.

Not on the Intel x86 architecture...
--
http://www.kynosarges.de

[Christoph Nahr]

On Mon, 22 Aug 2005 17:12:23 +0200, "Atmapuri"
<ja************@usa.net> wrote:

Float precision math is approx 2x faster than double.

Not on the Intel x86 architecture...
--
http://www.kynosarges.de

[Christoph Nahr]

On Tue, 23 Aug 2005 06:22:46 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:

In some 32-bit processors, I believe there is no microcode support for
performing some floating point operations in less than 80 bits. In
other words, everything's already being converted.

The FPU of the x86 line always performs calculations at 80 bit
precision, that's why you don't get any speedup for using float
instead of double (other than some memory transfer savings).

NB: In an earlier discussion I was notified that you can explicitly
put the FPU into 32-bit IEEE mode, but (a) I don't think it's actually
faster -- Intel just provides this feature to accomodate existing
programs; and (b) the .NET libraries don't use this mode anyway.

<ki******@hanmail.net> wrote:

2. There are two reasons why I want float based math
First, float precision math is 2x faster than double. It is said by
Atmapuri.

Tip: Don't believe everything you read on the Internet...

By the way, I think professional game developers use the FPU's SIMD
unit (MMX/SSE/3DNow) extensively for their math. These units do
support single-precision math natively, and you may in fact get a
factor 2 speedup if you use them (since they split their 64-bit
registers into two 32-bit registers for that job). However, .NET does
not support these units at all, so that won't help you either.
--
http://www.kynosarges.de

[Christoph Nahr]

On Tue, 23 Aug 2005 06:22:46 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:

In some 32-bit processors, I believe there is no microcode support for
performing some floating point operations in less than 80 bits. In
other words, everything's already being converted.

The FPU of the x86 line always performs calculations at 80 bit
precision, that's why you don't get any speedup for using float
instead of double (other than some memory transfer savings).

NB: In an earlier discussion I was notified that you can explicitly
put the FPU into 32-bit IEEE mode, but (a) I don't think it's actually
faster -- Intel just provides this feature to accomodate existing
programs; and (b) the .NET libraries don't use this mode anyway.

<ki******@hanmail.net> wrote:

2. There are two reasons why I want float based math
First, float precision math is 2x faster than double. It is said by
Atmapuri.

Tip: Don't believe everything you read on the Internet...

By the way, I think professional game developers use the FPU's SIMD
unit (MMX/SSE/3DNow) extensively for their math. These units do
support single-precision math natively, and you may in fact get a
factor 2 speedup if you use them (since they split their 64-bit
registers into two 32-bit registers for that job). However, .NET does
not support these units at all, so that won't help you either.
--
http://www.kynosarges.de

[kiplring]

You are perfect man!

I don't think there can be better answer than yours.

Sincerely.

[kiplring]

You are perfect man!

I don't think there can be better answer than yours.

Sincerely.