Re: [q-lang-users] Q 7.2 RC2

[Rob H. <hub...@gm...>]

Dear All,

On 26/06/06, Albert Graef <Dr....@t-...> wrote:
> John Cowan wrote:

> > 4) You had said earlier that you would provide unparsing rules for dict
> > and the other container types.
>
> I'm still undecided on this, because everything I do in the library sets
> a precedent that needs to be followed later. Numbers are a rather
> specific case, and it certainly makes sense to include default unparsing
> rules for complex and rational numbers in the library. But I'm not so
> sure whether this is the right thing for the container data structures
> yet, so I just postponed that decision. For the time being, you can
> easily add your own unparsing definitions for those data structures if
> you want/need them; they're all one-liners. :)

>From my experience with C++, containers are a real pain when
debugging. I don't care how a set is implemented - for me it's a black
box - just tell me what's in it.

Thus, I believe unparsing containers is the right thing to do.

> > 6) When % is called on floats, the result is a float.  Ideally, 2.5%1
> > should return 5%2, though I don't insist that the best possible fraction
> > should be returned, just some reasonable fraction.  This may be best
> > done in C, where you can call useful functions like frexp().
>
> No, I have to disagree. That would promote the result to a more specific
> type than the operands and we all agreed that this should never be done.
> Therefore, if (%) is to work on all numbers (which is a good thing,
> IMHO) then the right way to do this is to fall back to inexact division
> on inexact operands.
>
> Besides, there's also the issue that there's no single "canonical" way
> to do the rational approximation.

2.5%1 should be Float. (%) should be exact *if possible*. But 2.5 is
not exact (it is "2.5+epsilon". To make the result Rational would be
to hide inexactness.

Rob.