----- Original Message -----
From: "Steve Sabram" <[EMAIL PROTECTED]>
To: "Palm Developer Forum" <[EMAIL PROTECTED]>
Sent: Sunday, March 12, 2000 6:20 PM
Subject: Re: Getting "60.05" not to print "6.005000e01"!!!!
>
>
> Alexey Zaparovanny wrote:
>
> > > > I'd like my users to see "60.05", it's not asking that much is it?
> > >
> > > That is not much for your users but way too much for Palm. Floating
point
> > management routines can eat up CPU and memory like you
> > > wouldn't believe.
> >
> > I disagree, they ended up with that every serious program now is having
> > extra fat for floating point operations.
> > I got 6 different programs on my palm 2 of them share MathLib (good
thing)
> > and 4 using their own floating point routines.
> > Where is gain in space or usability ???
>
> It is the way that floating point is handled and managed. Get a hold of
any of the general purpose floating point management
> routines and you can see a LOT of code to service every valid permutation.
A single app will use maybe 5% of a general purpose
> floating point support lib. This is the same reason why printf() is no
fully supported.
I do not believe that printf for floating point is needed only in 5%
applications.
EVERY application I wrote (even for MCU) needed printf for floating point.
Many serious/usable applications for Plilot needed printf for %f or %g.
And I was not saying that they need to include all possible FP operations
into OS.
But they still do not have usable minimum at the acceptable level.
I would say that they should support at least basic trigonometry/logs/exp
and may be couple more.
That would add at most 20-30K to the OS.
>
> >
> > That was not wise from Palm not to include good math built-in in OS. (I
> > understand they wanted to be first on the market, but
> > Palm is now at least 2 y/o)
>
> And I believe it is still not time. Floating point like MathLib still
belongs in the realm of third party support and not OS.
>
> >
> > > This is why all of the early PC's had separate math coprocessors with
each
> > development environment shipping
> > > separate libraries for different floating point types.
> >
> > That was bad thing. I remember how I struggled too.
>
> Struggling is not the point. The fact is that floating point is used by a
small minority of applications that don't warrant
> attention by the OS.
>
> > >
> > > And another quote, "It's only a 16 MHz, 68K machine!"
> > >
> >
> > Wait couple more years. (Who needs 640K ?:))
>
> Remember, Moore's Law is no longer valid. Moore assumed unlimited power
and if you take battery consumption into mind, memory
Yeah.. they beat it recently :)
> growth and CPU speed will not be as fast. It is now MIPS per Watt now and
not MIPS per second. When the transoptical storage
> becomes viable and the CPU processer technology is measured in photo
gates, I'll be more than happy to consider this.
>
> You must remember that "piling the features on" has killed many a PDA in
the past. All of them had floating point support build in
> (WinCE, Newton, et. al.) If you are really this hard up, write a floating
point library -- maybe even full printf() support for
That is not FP that killed Newton or almost killed CE.
> floating point, %g is my favorite -- and I'll be one of the first ones to
use it. But please, don't feature creep the OS. This
> adds unnessary cost to the baseline in engineer costs and memory usage
that will not be leveraged by the majority of the
> applications out there.
It would be interesting to see what % off applications uses fp as of
today...
Regards,
Alex.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
