@MSGID:
<ce6b1092-5bf5-4bf3-9e8a-b5e6e753a8f0n@googlegroups.com> 8a2b205a
@REPLY: 1@dont-email.me> 0157cb83
@REPLYADDR gah4 <gah4@u.washington.edu>
@REPLYTO 2:5075/128 gah4
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:
<873f9cc4-6139-4bd3-9ed8-de7e37a76730n@googlegroups.com> <d24b9f27-36da-4011-963d-eba713b1f16an@googlegroups.com>
<3cb57395-be28-4451-9e98-c20ed41386fbn@googlegroups.com> 1@dont-email.me>
@RFC-Message-ID:
<ce6b1092-5bf5-4bf3-9e8a-b5e6e753a8f0n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
On Sunday, August 27, 2023 at 5:51:39 PM UTC-7, Gary Scott wrote:
> On 8/27/2023 7:45 PM, Kim Hanjoon wrote: 
 > > Thank you! I have never expected fortran`s default precision is
float not double.

> I was surprised some other languages don`t do the same. In the past, 
> many systems only supported double precision with software which was 
> painfully slow. I find single precision perfectly fine for the majority 
> of common programming uses. But then I`ve always been aware of the 
> availability of double precision and on some system beyond double precision.

For the majority of common use, single precision results are fine, but often
that requires double precision intermediates.  Many matrix operations easily
lose precision, when subtracting numbers that are close in value.

But yes, double precision hardware was slow in coming.  First in the larger
mainframes, and then later also in the minicomputers that allowed for more
personal computing.  

--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441