Using AppleTalk framework in MacOS X?

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.phillipsalum.mit.edu[/email]

Re: Using AppleTalk framework in MacOS X?

"Lava Man" <avpd16hotmail.com> wrote in message

news:81ae97a5.0307240840.7e3dbcaaposting.google.c om... Quote:

> 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

Wherefore the floating point inaccuracy?

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

Re: Wherefore the floating point inaccuracy?

In article <BB4C644A.D8E3%andospritec.com>,

Ando Sonenblick <andospritec.com> wrote:

Quote:

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

Re: Wherefore the floating point inaccuracy?

In article <BB4C644A.D8E3%andospritec.com>,

Ando Sonenblick <andospritec.com> wrote:

Quote:

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

Quote:

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

Quote:

> 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

Re: Wherefore the floating point inaccuracy?

Ando Sonenblick wrote:

Quote:

>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! :-)