RE: Code for converting between Elisp and Calc floats

["Vincent Belaïche" <vincent.b.1@hotmail.fr>]

[-- Attachment #1: Type: text/plain, Size: 3218 bytes --]














Hello Stefan,


> [SNIP]

> 
> I understand the code is simpler on the Lisp side, but I'm more
> concerned about the C side.  Of course, if the Lisp side becomes
> unmanageable it's also relevant.
>

For the C code anyhow, even if the integer component word size was not passed along in the interface, you would have anyhow to manage strange word sizes. This is because the mantissa is 53 bits, and 53 is not a multiple of 16. Also the mantissa is not aligned on the double word boundary (the sign + exponent not being a muliple of 16 bits) and
you also have this phantom bit case to handle.

I agree however that the C could have been slightly simpler if the integer component word size was forced to be 16bits.

Maybe we could add one more layer in Lisp that would encapsulate the C function and add the word lengths to be 16 for those who would like to use the builtin function for other purpose, but with a simpler interface. This would basically achieve the interface that you envisionned as far as I can understand. Calc would however not use this additional layer of code.


> [SNIP] 
> > This is the switch between the two types of implementations: the one
> > using builtin support, and the one not needing builtin support.
> 
> So (fboundp 'construct-float) would work as well?
>

Yes, definitely. That could be done this way, the  reason why I used a specific variable is more historical than rational.


> [SNIP] 
> I think it fits better in C. Basically, it would be the equivalent to
> C's frexp.

C++' frexp and ldexp are not a direct alternative, because the significand is still a non integer number (between 0.5 and 1 for frexp). So anyhow you would have to build clean powers of two to convert from the frexp returned significand to Calc internal mantissa that is an integer. Also the dynamic of the mantissa is higher than that of a Lisp integer, so any how you have so stick/split bits together/apart. However by combining calls to frexp, ldexp and floor one could get around.


Frankly speaking, I must admit that I ignored the existance of frexp and ldexp standard functions. If I had known about them, maybe I would have tried to write the builtin functions with using only frexp ldexp and stuff like _isnan and suhclikes to handle special cases. That would have come at the cost of a slight additional processing cost, but this is completely neglectable in the case of Calc, due to the overhead of Lisp.

Another alternative would be that frexp and ldexp and suhlikes are made builtin functions, and that the construct-float, deconstruct-float functions are in Lisp using those builtins: that would indeed be my preference if everyone thinks that the submitted C code is too complex. 


I am not sure however that re-coding those functions with frexp, ldexp and floor, would be that significantly less complex to justify the effort, now that I have already done the job in a more primitive way.

     Vincent.



 		 	   		  
_________________________________________________________________
Nouveau ! Tout Windows débarque dans votre téléphone. Voir les Windows phone
http://clk.atdmt.com/FRM/go/175819071/direct/01/

[-- Attachment #2: Type: text/html, Size: 3742 bytes --]