Re: t_QUAD printed representation

[Sam Steingold <sds@gnu.org>]

> * Karim Belabas <Xnevz.Orynonf@zngu.h-obeqrnhk.se> [2017-12-24 15:57:34 +0100]:
> * Sam Steingold [2017-12-22 19:59]:
>
> It's impossible in full generality: floating point numbers are stored
> in binary (64-bit words, say) and output in base 10. Lossless
> conversion between floating point base-10 and base-2^64 is impossible,
> every such involves a rounding error.

This is false mathematically: if you print enough decimal digits,
the number will eventually represent a unique binary float.

Moreover, this is false practically: ANSI CL standard requires that
numbers are printed (machine) readably, and they are, indeed, printed
(machine) readably: 

(= x (read-from-string (prin1-to-string x)))

evaluates to T for any floating number x.

> Those real numbers are "close" but certainly not functionally equivalent.

Yes, but they are _read_ as a functionally equivalent number.

i.e., "0.333333333333333333333333333333" is, of course, a different
number than "1.0/3.0" but _reading_ the string
"0.333333333333333333333333333333" and executing the division "1.0/3.0"
will produce identical numbers.

> No, sorry. The main showstopper is inexact floating point data.

Easily solved, see
http://clhs.lisp.se/Body/02_cbb.htm
http://clhs.lisp.se/Body/22_acac.htm

> Besides that it would be possible BUT detrimental to readability.

Ah, here you have the perennial conflict between human readability and
machine readability.
CL solves it using the variable *PRINT-READABLY*
(http://clhs.lisp.se/Body/v_pr_rda.htm).

> Here are some further examples

Looks like a good case for *PRINT-READABLY*.
Note that I am _not_ suggesting that you change the current default
behavior, just add a user option to print machine readably.

>>>> gequal(gp_read_str(GENtostr_raw(x)),x) = 1
>>>> strcmp(s,GENtostr_raw(gp_read_str(x))) = 0
>>>
>> However, do you agree that, in general, it _should_ hold?
>> ("normatively", not "positively").
>
> Normatively, yes.

Great!

> But it must not make the output harder to read or understand (for the
> majority of users...).

Sure, this just means that "unreadable" output should be marked as such
(cf. http://clhs.lisp.se/Body/02_dht.htm) and the user should be able to
specify whether they want human-readable or machine-readable output.

> So I ask what you actually want to achieve, besides general design
> principles I can agree with :-).

I want to be able to preserve the print/read consistency in CLISP for
PARI objects. They are printed in CLISP as #Z"<return value of
GENtostr_raw>" and read back using gp_read_str().

> For instance we can make 'raw output format' (\o0 or default(output,0)
> NOT the default) output t_QUAD using quadgen() and t_FFELT using
> ffgen().  Would that be useful ? sufficient ? annoying ?

Adding GENtostr_readably that would return a string representation of
GEN that is guaranteed to read using gp_read_str as gidentical to itself
or NULL if such representation is not possible would be perfect.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://mideasttruth.com
http://www.dhimmitude.org http://jij.org http://no2bds.org http://iris.org.il
Yeah, yeah, I love cats too... wanna trade recipes?