Hello Stefan,
Thanks for your valuable feedback.
I attached the Lisp part of the contribution. The entry point is just the two functions math-numfloat and math-floatnum. The former converts from Lisp to Calc, and the latter the other way round.
>
> If you take (calc-in "3.5") as input rather than 3.5, then there is no
> such issue, right?
>
I just tried it (with setting math-lisp-float-binary-ieee754-conformance to nil so that no builtin support is used)
(math-numfloat 3.5)
evals correctly to
(float 35 -1)
but
(math-floatnum '(float 35 -1))
evals to:
3.4999999999968168
Note that by default Calc has a 12 digit accuracy (that is less than a double that has almost 16 digit accuracy). So, to that extent, this latter conversion does not betray the accuracy of Calc (the 1st false digit is after 12 good digits).
If I had used the version with builtin support, there would not be this issue (to be 100% frank I did not checked it just now, but I am quite confident that (math-floatnum '(float 35 -1)) would have evaluated to 3.5).
[SNIP]
> Also, the mantissa should probably be represented as either a single
> integer or a list of integers where each integer provides 16bits of data
> (that's a format already used elsewhere in Emacs to represent "large
> integers" such as for time).
>
I did it this way because it allowed a simpler algorithm: in the conversion algorithm the integer size step is based on the number of decimal digits that Calc uses in representing big integers. The Calc big integers are not composed of 16bits integers (and actually there is not an integral number of bits, because these components are in radix 10). From that perspective it was easier if the number of bits of each component integer is passed along with the component integer in the interface.
> You could rename them to something like construct-float and deconstruct-float.
>
No problem to rename them, I fully agree that what name you propose is better.
> I'd also rename the mantissa and exponent size info, or maybe even
> consider providing it differently (in case its use is always linked to
> calls to one of the previous 2 functions, maybe those functions could
> return the relevant info. E.g. make-float could return the part of the
> mantissa it ignored). Since you're using those constants, you clearly
> know better how they're used, so I'll let you figure out whether there's
> a better way to ptovide the same info.
>
OK, this can be improved. Actually, my intention was not that these builtin functions were kind-of part of Calc
library API, these are really internal things that the user developing above Calc should not need.
> Also, how is math-lisp-float-binary-ieee754-conformance used?
>
This is the switch between the two types of implementations: the one using builtin support, and the one not needing builtin support.
Note that I can imagine that it is possible to implement the construct/deconstruct builtin functions just using lisp, this is after all just a matter of generating clean powers of 2. But, since this code would be so machine/system dependant, and since Lisp would be so more uselessly complex than C code,I thought that it was a better choice to make it in C.
> > Note that it took to me some time to make this work, the first attempt
> > was a very simple Calc format to a string, followed by string to
> > number, or vice versa.
>
> What was the problem with this simple solution?
>
String formatting/reading may depend on many parameters, including locale settings. It seemed to me unwise to go this way. You could of course use some default locale, and make all the settings in accordance with the objective of making this conversion, but conceptually I did not like the idea that you relie on functions whose objective is human/machine *interfacing* in order to make *computation*. Interfacing and Inner guts should be cleanly separate in any good software. These kind of function may depend on 3rd parties libraries from the compiling chain, there would certainly be porting issues, ...
Vincent.
> Stefan
Nouveau Windows 7 : Trouvez le PC qui vous convient. En savoir plus.