Re: [Chicken-users] thoughts on alternate "posits" / "unums" instead of traditional floats?
On Tue, Jul 9, 2019 at 2:07 PM Peter Bex wrote: They could be, but Scheme does not really allow for multiple types > of inexact numbers. Actually it has no problem with them. There are literals for up to four separate inexact types, using S, F, D, and L as exponent markers, and arithmetic just requires that when two float types meet the shorter is widened and that in systems without rationals, the widest available float is returned from division. The flags and the widening coercion are inherited from Common Lisp. Currently Kawa (which inherits its two floating types from Java) supports 32-bit floats with the S or F flag, as well as standard 64-bit floats with the E, D, or L flag. So does Racket/C, but Racket/Chez does not, and it probably never will (since Chez does not) except perhaps as a separate type that doesn't participate in the numeric tower. It would also slow everything down even further > due to even more dispatching. That's for sure. It's one of the reasons why ad hoc polymorphism is not really Scheme's thing, with the big exceptions of numbers and ports; the more types you support ad hoc, the worse your performance is. > So it sounds like a modified C compiler and/or FPU would be the way to go > for this. Hardware support for posits will come shortly after the Devil dies of exposure. John Cowan http://vrici.lojban.org/~cowanco...@ccil.org What asininity could I have uttered that they applaud me thus? --Phocion, Greek orator ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] thoughts on alternate "posits" / "unums" instead of traditional floats?
On Tue, Jul 09, 2019 at 12:25:12PM -0500, Daniel Ortmann wrote: > I am probably the last to run across this alternate floating point > format ... but now I am curious. > > If these posits were implemented in Chicken, what sort of work would be > required? > Would they replace the traditional floats? It sounds like they would replace traditional floats, yes. > Or would they be an optional part of the numeric stack? They could be, but Scheme does not really allow for multiple types of inexact numbers. It would also slow everything down even further due to even more dispatching. Right now, if we know something's a float/inexact, we can simply inline calls. We rely quite a lot on the C compiler to do flonum code. > https://www.nextplatform.com/2019/07/08/new-approach-could-sink-floating-point-computation/ From this article: Better yet, he claims the new format is a “drop-in replacement” for standard floats, with no changes needed to an application’s source code. So it sounds like a modified C compiler and/or FPU would be the way to go for this. CHICKEN can then transparently make use of that via the C type "double". Cheers, Peter signature.asc Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] thoughts on alternate "posits" / "unums" instead of traditional floats?
I am probably the last to run across this alternate floating point format ... but now I am curious. If these posits were implemented in Chicken, what sort of work would be required? Would they replace the traditional floats? Or would they be an optional part of the numeric stack? https://www.nextplatform.com/2019/07/08/new-approach-could-sink-floating-point-computation/ https://en.wikipedia.org/wiki/Unum_(number_format)#Posit Just curious. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
