Using AppleTalk framework in MacOS X?

[Lava Man]

Can anyone give me any pointers on how to access the AppleTalk
framework which is provided with MacOS X? I am porting a legacy
application which requires AppleTalk support (PAP workstation and
server). I see the AppleTalk framework in my
System/Libraries/Frameworks folder, but Apple's standard distribution
doesn't seem to include the header file to access it. Are these
header files available publicly or to developers, or is there some
other way to access the routines in this framework?

I would appreciate any information you could provide...

Steve Phillips
Software Development Consultant
Southborough, MA USA
mailto: [email]steve.phillips@alum.mit.edu[/email]

[Chris Espinosa]

"Lava Man" <avpd16@hotmail.com> wrote in message
news:81ae97a5.0307240840.7e3dbcaa@posting.google.c om...

> Can anyone give me any pointers on how to access the AppleTalk
> framework which is provided with MacOS X? I am porting a legacy
> application which requires AppleTalk support (PAP workstation and
> server). I see the AppleTalk framework in my
> System/Libraries/Frameworks folder, but Apple's standard distribution
> doesn't seem to include the header file to access it. Are these
> header files available publicly or to developers, or is there some
> other way to access the routines in this framework?
>
> I would appreciate any information you could provide...

Header files are distributed with development environments, not in end-user
installs. At minimum you need to install the Developer Tools CD that came
with your operating system disc set. Updates to these tools (the latest is
December 2002) are posted on the Apple Developer Connection site at
[url]http://www.apple.com/developer[/url] (registration is free).

If you're porting a legacy application, you're probably using the
CodeWarrior development. Be sure to upgrade to the latest CodeWarrior (CW
for Mac 8.3). If you're building a product that uses the CFM binary format
(runs on 9 and X) when you link with CarbonLib that will automatically link
you to the AppleTalk framework; if you're building for the Mach-O runtime
format, you should add the AppleTalk.framework in your project and #include
<AppleTalk/AppleTalk.h> in your source files.

Chris Espinosa
Apple

[Ando Sonenblick]

Gang,

Is it Codewarrior? Is it the PPC? Or is it just the accepted nature of
floating point math that it is inaccurate?

By inaccurate I mean this:

float x;

x = 3.5 + 4.7;

Examine the value of x (say in the debugger) and it is 8.20000000476837

Now I can understand if you perform division or other complex math that
you'll have such small "left over" digits, but can't the internal definition
of a floating pt variable be able to accurately have 3.5 + 4.7 be exactly
8.2?!?!?!

Where is the reason for this inaccuracy? Is it codewarrior?

Thx
Ando

[David Phillip Oster]

In article <BB4C644A.D8E3%ando@spritec.com>,
Ando Sonenblick <ando@spritec.com> wrote:

> By inaccurate I mean this:
>
> float x;
>
> x = 3.5 + 4.7;
>
> Where is the reason for this inaccuracy? Is it codewarrior?

The reason is the IEEE standard for floating point numbers implemented
by modern processors, and used on the Mac and in MS-Windows.
<http://www.psc.edu/general/software/packages/ieee/ieee.html>


You figure it out: floating point numbers are essentially a binary
fraction and a 2-to-then-n scale factor.

You understand Arabic numerals; numbers to the left of the decimal point
are successively higher powers of 10, numbers to the left of the decimal
point are successively lower powers of 10.

so, 3.5 is 3 + 5/10
this can be represented exactly in binary as:

11.1


i.e.:

1 0 -1
2 + 2 + 2

Now try the same trick with 4.7
You'll find that 7/10 can't be represented precisely in a finite
number of negative powers of 2.

[Joe Gwinn]

In article <BB4C644A.D8E3%ando@spritec.com>,
Ando Sonenblick <ando@spritec.com> wrote:

> Gang,
>
> Is it Codewarrior? Is it the PPC? Or is it just the accepted nature of
> floating point math that it is inaccurate?

No. No. Yes. A better term is "approximate", as the inaccuracy is no
greater than a known fraction of the value.

More simply, floating point arithmetic is inherently slightly fuzzy.

> By inaccurate I mean this:
>
> float x;
>
> x = 3.5 + 4.7;
>
> Examine the value of x (say in the debugger) and it is 8.20000000476837

This is error=(8.20000000476837-8.2)=4.76837*10^-9, or
(4.76837*10^-9)/8.2= 5.82*10^-10

This is pretty good for a 32-bit float. Is this actually a 64-bit
double float? Or, are we just lucky this time?

> Now I can understand if you perform division or other complex math that
> you'll have such small "left over" digits, but can't the internal definition
> of a floating pt variable be able to accurately have 3.5 + 4.7 be exactly
> 8.2?!?!?!
>
> Where is the reason for this inaccuracy? Is it codewarrior?

Floating-point arithmetic is approximate, and numbers like 4.7 cannot be
expressed exactly in binary, and so get rounded to the closest binary
value, causing a small error. (Numbers like 3.5 are exact.)

IEEE 754 floats, used by PPCs and just about everybody else, carry a
23-bit mantissa, so the resolution is 2^-23= 1.192*10^-7, while 64-bit
double floats have 52-bit mantissas, so the resolution is 2^-52=
2.220*10^-16. In other words, floats have about six significant digits,
while doubles have about sixteen digits. A significat digit is one that
conveys information, so leading zeros (to the left) and noise digits (to
the right) don't count. Nor does the decimal point. Only the digits in
the middle count.

Look in <float.h> for the characteristics of floating point arithmetic.

A consequence of the fuzzy nature of floating point is that tests of
equality cannot be done directly:

If one has two floats (or doubles) A and B, the comparison test "if A==B
then whatever" will almost always fail due to tiny errors in the
computations of A and B, so whatever will never be executed.

The correct way to do this is "if abs(A-B)<tol then whatever", where tol
is a value that's large compared to the likely fuzz in A and B but small
compared to A and B.

Even better is to recast the problem so that tests of equality are not
needed, so we get only something like "if A<B then whatever", which
works despite the fuzz.

Also beware of computing the same value A in two places, which we will
call A1 and A2, and (implicitly) expecting that A1==A1. It never is,
because optimizing compilers will never do exactly the same thing in the
two places, even if the source code is letter-for-letter identical. If
this matters, compute A once and save it for later use; do not recompute
it.

Joe Gwinn

[Mike Hall]

Ando Sonenblick wrote:

>Is it Codewarrior? Is it the PPC? Or is it just the accepted nature of
>floating point math that it is inaccurate?

I can think of no better reference than this:

"What Every Computer Scientist Should Know About Floating-Point Arithmetic"

It's from Sun Microsystems.

[url]http://docs.sun.com/source/806-3568/ncg_goldberg.html[/url]
[url]http://docs-pdf.sun.com/800-7895/800-7895.pdf[/url]
[url]http://docs.sun.com/db/doc/800-7895/6hos0aou4?q=Computer+Scientist+Should+Know+About+F loating-Point+&a=view[/url]

Enjoy! :-)