This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
Dave Mason <dmason@xxxxxxxxxxxxxxx> writes: > Sorry I haven't been following the (rather long, detailed) discussion > here, but I would love to see this proposal in effect. It's important > that people be able to express the inexactness of their calculations - > regardless of the type of the result. Brilliant. When you apply make-string to an inexact integer, we get a string with an inexact length. When we use it as a file name, the file is created inexactly. Then checking whether the file exists returns an inexact boolean - the file might not really have existed after all. Trying to open it enters an inexact continuation, which lies between the success contiunuation and the continuation taken in case of an I/O error. Displaying contents of the file, even if it's English prose, taints the terminal with inexactness, such that anybody copying the text into a Scheme program gets back inexact strings. Huh? Tracking exactness of anything which doesn't model a continuous domain is nonsense. Consider this statement: (if (< (sin x) 0.0) (newline)) If it doesn't display an inexact newline, you can't say that inexactness is truly contagious. > If I have a test suite that claims that a test passes but in reality > it is dependent on the actual values of operands of inexact > operations, I would really want to know that. In this case just don't use operations which might give inexact results given exact arguments (R5RS: exp log sin cos tan asin acos atan sqrt expt make-polar magnitude angle exact->inexact) and don't feed the program with inexact data nor textual representation of inexact data. -- __("< Marcin Kowalczyk \__/ qrczak@xxxxxxxxxx ^^ http://qrnik.knm.org.pl/~qrczak/