[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: floating point and other comments

This page is part of the web mail archives of SRFI 48 from before July 7th, 2015. The new archives for SRFI 48 contain all messages, not just those from before July 7th, 2015.



On Mon, Dec 22, 2003 at 09:09:03AM +0100, Ken Dickey wrote:

> A good start.

Ugh, no it wasn't, it was a very sloppy rip-off of my previous code
which introduced several bugs.  The ~A fix was also broken.  I
apologize for the poor code and attach a new version.

> Unfortunately,  the code did not do the whole job.

I don't think anybody has suggested doing the whole job.  This is,
after all, "Intermediate Format."  The problem is choosing the right
balance of features to include in SRFI-48.  I really think ~w,dF
should be included and it does not complicate the code greatly.

> E.g.:

[snip]

All examples work now as you expected, and the code is no larger.  I
specifically don't handle non-numbers for ~F, I'm not sure if we want
to support that.  It also handles complex numbers but we may want to
remove that.

> I am willing to do the work, but I suspect that handling such cases
> would make the code larger--and cons more.

The code only cons' more if you use ~F or parameters.  So if you don't
use the new features it behaves just as it did before.  There are
still no set!s.  ~F is kind of a clumsy (I was too lazy to lookup a
real floating point formatter algorithm :) but I suspect it is more
compact as it is now.  Generally your goals of code space efficiency
and runtime heap efficiency are at odds with one another - better
algorithms tend to be longer.  Specifically you claim
display:number->string can be more efficient than (display
(number->string ...)) but the reference implementation doesn't take
advantage of that.  Which is more important, and does either really
matter for a SRFI?

-- 
Alex