Hello,

Is there a way to determine the functions that get called when adding to
floating point numbers within Excel?

For example, let's say I put 2.43 in A1 and 5.43423 in B1. Then in C1, I do
a SUM(A1:B1). I would like to know the APIs that get called to make that SUM
happen and the DLLs that are the host of those APIs.

Thanks.

Why?

Maybe someone has a better answer for you if you say what you want to do.
If your thinking of distributing a dll and having all the functionality of
Excel without actually having Excel, besides the fact you don't have the
license to distribute the dll and would violate you EULA, I doubt it is
possible anyway.

--
Regards,
Tom Ogilvy

"Joel" wrote in message
...
Hello,

Is there a way to determine the functions that get called when adding to
floating point numbers within Excel?

For example, let's say I put 2.43 in A1 and 5.43423 in B1. Then in C1, I
do
a SUM(A1:B1). I would like to know the APIs that get called to make that
SUM
happen and the DLLs that are the host of those APIs.

Thanks.

Wow! I am somewhat offended at the insinuation that I would do something like
that. That is absolutely the last thing I would ever do. And, besides, my
question is *way* to specific to even garner wanting to distribute Excel DLLs
around. I.e. There is much more to Excel than just floating point operations.

If you want to know why, I can give you some idea. I didn't originally
because I didn't want to get to wordy in my original post.

Basically, if you have heard of Rotor (the shared source implementation of
the CLI), you know you can view the source code of the underlying virtual
machine and see how pretty much everything is working under the covers. For
some work I am doing, I needed to look at how floating point and decimal work
from the System.Decimal/System.Single/System.Double libary types down to what
is called in the implementations of those types. I wanted to see if Excel, a
program that makes use of FP somewhat heavily, follows the same path as the
..NET implementations. By path, I wanted to see if there was a convergence
point where both are calling into the same APIs or if they are totally
separated. There is obviously more "why" detail, but I can'r really get into
it because I am not sure it is appropriate for me to do so.

Does that make sense?

"Tom Ogilvy" wrote:

Why?

Maybe someone has a better answer for you if you say what you want to do.
If your thinking of distributing a dll and having all the functionality of
Excel without actually having Excel, besides the fact you don't have the
license to distribute the dll and would violate you EULA, I doubt it is
possible anyway.

--
Regards,
Tom Ogilvy

"Joel" wrote in message
...
Hello,

Is there a way to determine the functions that get called when adding to
floating point numbers within Excel?

For example, let's say I put 2.43 in A1 and 5.43423 in B1. Then in C1, I
do
a SUM(A1:B1). I would like to know the APIs that get called to make that
SUM
happen and the DLLs that are the host of those APIs.

Thanks.

"Joel" wrote in message
...
Wow! I am somewhat offended at the insinuation that I would do something
like
that. That is absolutely the last thing I would ever do. And, besides, my
question is *way* to specific to even garner wanting to distribute Excel
DLLs
around. I.e. There is much more to Excel than just floating point
operations.

If you want to know why, I can give you some idea. I didn't originally
because I didn't want to get to wordy in my original post.

Basically, if you have heard of Rotor (the shared source implementation of
the CLI), you know you can view the source code of the underlying virtual
machine and see how pretty much everything is working under the covers.
For
some work I am doing, I needed to look at how floating point and decimal
work
from the System.Decimal/System.Single/System.Double libary types down to
what
is called in the implementations of those types. I wanted to see if Excel,
a
program that makes use of FP somewhat heavily, follows the same path as
the
.NET implementations. By path, I wanted to see if there was a convergence
point where both are calling into the same APIs or if they are totally
separated. There is obviously more "why" detail, but I can'r really get
into
it because I am not sure it is appropriate for me to do so.

Does that make sense?


Exce is not based on .NET so I assume there are some differences,. AFAIK
excel uses 8 byte doubles for floating point arithmetic. I seem to remember
that Excel does compress doubles into a 4 byte structure when you save a
file. It's not a float.

I don't think there's much of a common API . My guess is that a
System.Double is pretty much the same as a double in C.
/Fredrik

"Joel" wrote in message
...
Hello,

Is there a way to determine the functions that get called when adding to
floating point numbers within Excel?

For example, let's say I put 2.43 in A1 and 5.43423 in B1. Then in C1, I
do
a SUM(A1:B1). I would like to know the APIs that get called to make that
SUM
happen and the DLLs that are the host of those APIs.

Thanks.

Here's something that you may find useful, An add-in written in C#. If you
want this function to work like Excel's sum, you need to sete a refernce to
Excel and modify the parameters.

http://www.thecodeproject.com/dotnet/excelnetauto.asp

/Fredrik

Since Excel isn't written in a net language, I think you can be sure that it
doesn't (at least in versions before xl2003/2 for sure). You might want to
pursue if C++ uses the same FP libraries since to the best of my knowledge,
Excel is written in C++ and assembler. In Visual Studion 3, Visual C++ net
appears to have the option of linking to the CLR, but I would bet that
Excel isn't compiled that way.

--
Regards,
Tom Ogilvy

"Joel" wrote in message
...
Wow! I am somewhat offended at the insinuation that I would do something
like
that. That is absolutely the last thing I would ever do. And, besides, my
question is *way* to specific to even garner wanting to distribute Excel
DLLs
around. I.e. There is much more to Excel than just floating point
operations.

If you want to know why, I can give you some idea. I didn't originally
because I didn't want to get to wordy in my original post.

Basically, if you have heard of Rotor (the shared source implementation of
the CLI), you know you can view the source code of the underlying virtual
machine and see how pretty much everything is working under the covers.
For
some work I am doing, I needed to look at how floating point and decimal
work
from the System.Decimal/System.Single/System.Double libary types down to
what
is called in the implementations of those types. I wanted to see if Excel,
a
program that makes use of FP somewhat heavily, follows the same path as
the
.NET implementations. By path, I wanted to see if there was a convergence
point where both are calling into the same APIs or if they are totally
separated. There is obviously more "why" detail, but I can'r really get
into
it because I am not sure it is appropriate for me to do so.

Does that make sense?

"Tom Ogilvy" wrote:

Why?

Maybe someone has a better answer for you if you say what you want to
do.
If your thinking of distributing a dll and having all the functionality
of
Excel without actually having Excel, besides the fact you don't have the
license to distribute the dll and would violate you EULA, I doubt it is
possible anyway.

--
Regards,
Tom Ogilvy

"Joel" wrote in message
...
Hello,

Is there a way to determine the functions that get called when adding
to
floating point numbers within Excel?

For example, let's say I put 2.43 in A1 and 5.43423 in B1. Then in C1,
I
do
a SUM(A1:B1). I would like to know the APIs that get called to make
that
SUM
happen and the DLLs that are the host of those APIs.

Thanks.

Thank you Fredrik and Tom your replies.

Yeah, I know that Excel is not written in a managed language (maybe in the
future). But many times .NET library API implementations call into unmanaged
code. So when this happens, it is quite possible that an Excel function and a
..NET library function converge at a lower layer in the call stack (a
contrived example could be: .NET C# library - PInvoke into msvcrt.ilb -
call pow - get result WHILE Excel directly calls into msvcrt.lib - call pow
- get result ... and the convergence point in this case would be the pow
function).

I guess the gist of my query tries to see if there are multiple fp
implementations floating (no pun intended :-) ) around for similar formats or
is there one central one (like in the PlatformSDK or something). It is quite
possible that there are multiple.

"Fredrik Wahlgren" wrote:


"Joel" wrote in message
...
Wow! I am somewhat offended at the insinuation that I would do something
like
that. That is absolutely the last thing I would ever do. And, besides, my
question is *way* to specific to even garner wanting to distribute Excel
DLLs
around. I.e. There is much more to Excel than just floating point
operations.

If you want to know why, I can give you some idea. I didn't originally
because I didn't want to get to wordy in my original post.

Basically, if you have heard of Rotor (the shared source implementation of
the CLI), you know you can view the source code of the underlying virtual
machine and see how pretty much everything is working under the covers.
For
some work I am doing, I needed to look at how floating point and decimal
work
from the System.Decimal/System.Single/System.Double libary types down to
what
is called in the implementations of those types. I wanted to see if Excel,
a
program that makes use of FP somewhat heavily, follows the same path as
the
.NET implementations. By path, I wanted to see if there was a convergence
point where both are calling into the same APIs or if they are totally
separated. There is obviously more "why" detail, but I can'r really get
into
it because I am not sure it is appropriate for me to do so.

Does that make sense?


Exce is not based on .NET so I assume there are some differences,. AFAIK
excel uses 8 byte doubles for floating point arithmetic. I seem to remember
that Excel does compress doubles into a 4 byte structure when you save a
file. It's not a float.

I don't think there's much of a common API . My guess is that a
System.Double is pretty much the same as a double in C.
/Fredrik