(format t "~0f" 3.0)
should print "3.0", not "3.", since the former is valid float. Latter should be printed, if zero fdigits explicitly declared:
(format t "~0,0" 3.0)
Is this really a bug? http://www.lispworks.com/documentation/lw51/CLHS/Body/22_cca.htm states that the full format string is "~w,d,k,overflow char,padcharF" and that "exactly d characters will follow the decimal point". In your case, (format t "~0f" 3.0) doesn't set the number of digits to print after the decimal, it only sets the width of the output (the total number of digits to print.) According to the standard, if the width is impossible, then the scaled value is printed, using however much space is needed. If you try (format t "~0f" 3.5) you'll see that 4 is printed, confirming that clisp is behaving appropriately. Also, SBCL behaves this way, so I'm inclined to say this is a feature.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to CLHS argument is printed "as a float" what is imo conclusive. 3.' is an integer, so minimal number of characters needed to print argument as a float is 3 in this example, therefore result should be3.0'.
If we specify number of digits after the decimal point, then we can safely assume, that user knows what he's doing when he says - print with "0 digits after decimal point" - conversion is explicit.
Fortunately we have spec, not reference implementation (like python for instance), therefore saying that CCL and LW treat it differently means nothing in this regard. More of it, (format t "~0f" 3.5)' in SBCL prints3.5' in fact, not `4'.
I've found somehow hard sixth paragraph ("if the parameter d is omitted") wrt processing non-zero integers, but taken into account previous paragraphs it seems bogus and inconsistent.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to CLHS argument is printed "as a float" what is imo conclusive. '3.' is an integer, so minimal number of characters needed to print argument as a float is 3 in this example, therefore result should be '3.0'.
If we specify number of digits after the decimal point, then we can safely assume, that user knows what he's doing when he says - print with "0 digits after decimal point" - conversion is explicit.
Fortunately we have spec, not reference implementation (like python for instance), therefore saying that CCL and LW treat it differently means nothing in this regard. More of it, '(format t "~0f" 3.5)' in SBCL prints '3.5' in fact, not '4'.
I've found somehow hard sixth paragraph ("if the parameter d is omitted") wrt processing non-zero integers, but taken into account previous paragraphs it seems bogus and inconsistent.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What's really the problem here is that CLISP isn't reading 3. as a float. If you run the following code: (format t "~,2f~%" (eval (format nil "~0f" 3.0)))
You'll see that 3. is still outputted. I think that outputting zero digits after the decimal point is appropriate behavior, but it should definitely still be read as a floating point number.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is this really a bug? http://www.lispworks.com/documentation/lw51/CLHS/Body/22_cca.htm states that the full format string is "~w,d,k,overflow char,padcharF" and that "exactly d characters will follow the decimal point". In your case,
(format t "~0f" 3.0)doesn't set the number of digits to print after the decimal, it only sets the width of the output (the total number of digits to print.) According to the standard, if the width is impossible, then the scaled value is printed, using however much space is needed. If you try(format t "~0f" 3.5)you'll see that4is printed, confirming that clisp is behaving appropriately. Also, SBCL behaves this way, so I'm inclined to say this is a feature.According to CLHS argument is printed "as a float" what is imo conclusive.
3.' is an integer, so minimal number of characters needed to print argument as a float is 3 in this example, therefore result should be3.0'.If we specify number of digits after the decimal point, then we can safely assume, that user knows what he's doing when he says - print with "0 digits after decimal point" - conversion is explicit.
Fortunately we have spec, not reference implementation (like python for instance), therefore saying that CCL and LW treat it differently means nothing in this regard. More of it,
(format t "~0f" 3.5)' in SBCL prints3.5' in fact, not `4'.I've found somehow hard sixth paragraph ("if the parameter d is omitted") wrt processing non-zero integers, but taken into account previous paragraphs it seems bogus and inconsistent.
According to CLHS argument is printed "as a float" what is imo conclusive. '3.' is an integer, so minimal number of characters needed to print argument as a float is 3 in this example, therefore result should be '3.0'.
If we specify number of digits after the decimal point, then we can safely assume, that user knows what he's doing when he says - print with "0 digits after decimal point" - conversion is explicit.
Fortunately we have spec, not reference implementation (like python for instance), therefore saying that CCL and LW treat it differently means nothing in this regard. More of it, '(format t "~0f" 3.5)' in SBCL prints '3.5' in fact, not '4'.
I've found somehow hard sixth paragraph ("if the parameter d is omitted") wrt processing non-zero integers, but taken into account previous paragraphs it seems bogus and inconsistent.
What's really the problem here is that CLISP isn't reading
3.as a float. If you run the following code:(format t "~,2f~%" (eval (format nil "~0f" 3.0)))You'll see that
3.is still outputted. I think that outputting zero digits after the decimal point is appropriate behavior, but it should definitely still be read as a floating point number.no, trailing "." after number is printed after integer to indicate, that it's base is 10 - depending on value of print-radix (consult http://www.lispworks.com/documentation/lw51/CLHS/Body/v_pr_bas.htm#STprint-radixST and http://www.lispworks.com/documentation/lw51/CLHS/Body/02_cbb.htm)