Welcome to RetroBBS

mail files register newsreader groups login

Message-ID:

Marriage is the sole cause of divorce.

Re: Subnormal anomaly

Subject	Author
Subnormal anomaly	Thomas Schnurrenberger
Re: Subnormal anomaly	gah4
Re: Subnormal anomaly	Peter Klausler US
Re: Subnormal anomaly	gah4
Re: Subnormal anomaly	Peter Klausler US
Re: Subnormal anomaly	jfh
Re: Subnormal anomaly	Thomas Schnurrenberger
Re: Subnormal anomaly	Steven G. Kargl
Re: Subnormal anomaly	Thomas Schnurrenberger
Re: Subnormal anomaly	Steven G. Kargl
Re: Subnormal anomaly	Thomas Schnurrenberger
Re: Subnormal anomaly	Steven G. Kargl
Re: Subnormal anomaly	Peter Klausler US
Re: Subnormal anomaly	Thomas Schnurrenberger
Re: Subnormal anomaly	Peter Klausler US
Re: Subnormal anomaly	gah4
Re: Subnormal anomaly	gah4
Re: Subnormal anomaly	Thomas Schnurrenberger

Subnormal anomaly

<ti913t$1pt36$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2946&group=comp.lang.fortran#2946

copy link Newsgroups: comp.lang.fortran

Path: i2pn2.org!i2pn.org!paganini.bofh.team!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: tsbg@gmx.net (Thomas Schnurrenberger)
Newsgroups: comp.lang.fortran
Subject: Subnormal anomaly
Date: Thu, 13 Oct 2022 14:42:37 +0200
Organization: A noiseless patient Spider
Lines: 77
Message-ID: <ti913t$1pt36$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 13 Oct 2022 12:42:37 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="f958cb410e1ad4f64846c24446515cbd";
logging-data="1897574"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Wkt8my8bOKd68JLJMC7zT"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.2
Cancel-Lock: sha1:YW57AhW5HJrmwQmKbpYyobac1mE=
Content-Language: de-CH, en-US

by: Thomas Schnurrenberg - Thu, 13 Oct 2022 12:42 UTC

The following program gives an unexpected result when compiled and
executed with gfortran on Windows:

program test
!
use :: iso_fortran_env
!
implicit none
!
real(real64), parameter :: SUB1 = real(z'1', real64)
real(real64), parameter :: SUB2 = real(z'2', real64)
!
character(len=1000) :: buff
real(real64) :: got
!
! Inexact representation of the smallest subnormal number:
buff = '5e-324'
read (buff, *) got
print *, 'Expected:', SUB1, ', got:', got, ',', SUB1 == got
!
! Inexact representation of the second smallest subnormal number.
buff = '9e-324'
read (buff, *) got
print *, 'Expected:', SUB2, ', got:', got, ',', SUB2 == got
!
! Exact representation of the number which is exactly halfway
! between the smallest and the second smallest subnormal number
! 2**(-1074) + 2**(-1075). This number should be rounded to the
! second smallest subnormal number according to the default IEEE
! 754 rounding rules:
buff = '7.41098468761869816264853189302332058547589703921&
&4871466383785237510132609053131277979497545424539&
&8856969484704316857659638998506553390969459816219&
&4016172817189451069785467106791768725751773473155&
&5330779540854980960845750095811137303474765809687&
&1009590975442271004757307809711118935784838675653&
&9987835030152280559340465937397917907387238682993&
&9581848166016912201945649993128979841136206248449&
&8678713572180352209017023903285791732520220528974&
&0208029068540216066123755499834026713000358124864&
&7904138574340187552090159017259254714629617513415&
&9774938718574737870961645638908718119841271673056&
&0170454930047052695901657637768849082679869725733&
&6652176556794107250876433756084600398490497214911&
&7463085539556354188641513168478436313080237596295&
&773983001708984375e-324'
read (buff, *) got
print *, 'Expected:', SUB2, ', got:', got, ',', SUB2 == got
!
end program test

I tried the program on Windows 7 with gfortran 11.2.0 and on
Windows 10 with gfortran 12.2.0. Both are from MSYS2/MinGW64
and the results are identical:

Expected: 4.9406564584124654E-324 , got: 4.9406564584124654E-324, T
Expected: 9.8813129168249309E-324 , got: 9.8813129168249309E-324, T
Expected: 9.8813129168249309E-324 , got: 2.2250738585072014E-308, F

The third print should give the same result as the second one.
The result looks like the smallest normal double precision number
which is not quiet correct.

On Windows 10 with the Intel ifort 64-Bit compiler version 2021.5.0
Build 20211109_000000:

Expected: 4.940656458412465E-324 , got: 4.940656458412465E-324, T
Expected: 9.881312916824931E-324 , got: 9.881312916824931E-324, T
Expected: 9.881312916824931E-324 , got: 9.881312916824931E-324, T

Can someone please test the program on Linux to verify that this
is not a Windows specific problem. Is this a known issue?

Regards

--
Thomas

Re: Subnormal anomaly

<aa9de517-532e-4db8-8608-0c09e5a36580n@googlegroups.com>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2948&group=comp.lang.fortran#2948

copy link Newsgroups: comp.lang.fortran

X-Received: by 2002:a05:6214:f24:b0:4b3:efeb:d800 with SMTP id iw4-20020a0562140f2400b004b3efebd800mr929527qvb.15.1665682828474;
Thu, 13 Oct 2022 10:40:28 -0700 (PDT)
X-Received: by 2002:a05:620a:1335:b0:6ee:883a:dcba with SMTP id
p21-20020a05620a133500b006ee883adcbamr792453qkj.449.1665682828319; Thu, 13
Oct 2022 10:40:28 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.fortran
Date: Thu, 13 Oct 2022 10:40:28 -0700 (PDT)
In-Reply-To: <ti913t$1pt36$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2601:602:9700:4689:21d5:8b8e:cc4c:677c;
posting-account=gLDX1AkAAAA26M5HM-O3sVMAXdxK9FPA
NNTP-Posting-Host: 2601:602:9700:4689:21d5:8b8e:cc4c:677c
References: <ti913t$1pt36$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <aa9de517-532e-4db8-8608-0c09e5a36580n@googlegroups.com>
Subject: Re: Subnormal anomaly
From: gah4@u.washington.edu (gah4)
Injection-Date: Thu, 13 Oct 2022 17:40:28 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2290

by: gah4 - Thu, 13 Oct 2022 17:40 UTC

On Thursday, October 13, 2022 at 5:42:40 AM UTC-7, Thomas Schnurrenberger wrote:
> The following program gives an unexpected result when compiled and
> executed with gfortran on Windows:

(snip)

> Expected: 4.9406564584124654E-324 , got: 4.9406564584124654E-324, T
> Expected: 9.8813129168249309E-324 , got: 9.8813129168249309E-324, T
> Expected: 9.8813129168249309E-324 , got: 2.2250738585072014E-308, F

> Can someone please test the program on Linux to verify that this
> is not a Windows specific problem. Is this a known issue?

Personally, I believe that subnormals were a bad idea.
They give a slightly greater exponent range, at a complication in hardware.
(Or, even worse, in some cases software.)

IEEE provides some bit representations for floating point values, and also some
suggestions on how to use them.

As well as I know, it is possible to use the IEEE formats without necessarily
following all the IEEE rules on using them.

Conversion between textual decimal representation and internal binary
representation is not easy. I would especially be surprised if any conversion
could use 722 digits in the conversion process.

Re: Subnormal anomaly

<8aad1cc0-4f05-4656-864c-7639cb342cb9n@googlegroups.com>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2949&group=comp.lang.fortran#2949

copy link Newsgroups: comp.lang.fortran

X-Received: by 2002:ac8:5716:0:b0:39c:c97e:ccea with SMTP id 22-20020ac85716000000b0039cc97ecceamr929435qtw.192.1665684175663;
Thu, 13 Oct 2022 11:02:55 -0700 (PDT)
X-Received: by 2002:a05:6214:5185:b0:472:f9b0:cbc6 with SMTP id
kl5-20020a056214518500b00472f9b0cbc6mr776508qvb.92.1665684174994; Thu, 13 Oct
2022 11:02:54 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.fortran
Date: Thu, 13 Oct 2022 11:02:54 -0700 (PDT)
In-Reply-To: <aa9de517-532e-4db8-8608-0c09e5a36580n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=12.154.207.45; posting-account=ZT-cAwoAAACx2tBPXm-WZoHIT8sjnGGy
NNTP-Posting-Host: 12.154.207.45
References: <ti913t$1pt36$1@dont-email.me> <aa9de517-532e-4db8-8608-0c09e5a36580n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8aad1cc0-4f05-4656-864c-7639cb342cb9n@googlegroups.com>
Subject: Re: Subnormal anomaly
From: pklausler@nvidia.com (Peter Klausler US)
Injection-Date: Thu, 13 Oct 2022 18:02:55 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 13957

by: Peter Klausler US - Thu, 13 Oct 2022 18:02 UTC

On Thursday, October 13, 2022 at 10:40:30 AM UTC-7, gah4 wrote:
> Conversion between textual decimal representation and internal binary
> representation is not easy. I would especially be surprised if any conversion
> could use 722 digits in the conversion process.

128-bit IEEE is even more fun, but I don't know of a Fortran compiler that has a limit on digits that would preclude exact conversions.

$ cat t.f90
print '(E11550.11540E4)', real(z'1', kind=16)
end
$ flang t.f90
$ ./a.out
0.64751751194380251109244389582276465524995693380346810096898843891970395401241193710176714912766499402558781414768481196765872198863825420466851100719726179830427927107513349344167346256384717402394485265055539903914555562521711480680708220346882569824762728287891030283573375613480310623865645926398262269919079078676632620657112115830646571960683083328452344530697605264894476609645793137514034026318043500399488700752556487133680661178794031557667133034674349370624094116852151376073331394228438350516689835671671968026429523535040797143471038605377828937002155211686677110429506100218815136279864294617004333392019353974988251843353855148928443399308529678384486821255023041141221530459464654630847641101744787370443353123896614836392105539434114765447862613978750641914512267676146258927903699614150696069800070805027886489199759168018782220022523817230472309718765709954288212192815965476330235387831371836463969528315305510686834195967353740867462905258679962169053233653198851726099568276255110363324783532289476318800506845591506083189865215401360612737714933904127847565521038975185277641587787593338807148822796333238263973123754069270394465253064478385143715036549878551723063075841554598267070959096177525268004013269908287216337267704409154390926779066467985735241991166482642069204511601336350713617738121217165281781482407207832267365496237361352749903091381431832483719598759788050275009286938080733369557527590884428656000751998889983238806435496700555054213624351085727320873229820271877724592312289894723729518643210992618787810843302529883339213629989633037224310597419687634524069538350151205337733852899047108436284027002747028704740738252488288899849942846076048472117942212107299131598290142171680044610495326626965429131836281571995616419499239366293689928566213830845453276369722655423553417498556630200048873168352161567672230537998110672589138084699942326078588545240644321457759221445357012364689857052129770454794895156900093889236255806857887076058773438576691708946567974233684903294072511603933560488206070850890690254135842698167397472112395135504143831175088267631435128620064970580411452960978929179999355770532342526986919337927247536821845376828355628299386300048383843639442431376228649182574742562801272911169650506001781204777207847421842053761959758316777217647400445366246457644713815714523818301253987651520832874831102793946978559157139819399706845991995948630072306240767861396175546314507349951900819321876168142346327387782244332564637383464352749057109255811060612738409755929317612667992655877654689467643370851923693583162984574500088094285869215047437308738957104746144800037271461623498583332915165521625453703122003908415883094809732746316462735973902494777466571318911964823986701187979100989188996894821969566606382257319606935427639643023089996929570910613001836483297851827933014072672000463830430052367599773876014077691103832957299186545209377855863906331570203476328121087286385898132825695295767693671733247640852857053083129549574015582471687399314465694228187234824710973743621052792785585707462781683315969037995279590016748561555646198214070447997200206206422332460578482364760475407628497883254356305924201944904435394289908994886558901838867886505185955421802579392005396450418083877602381895624283517746324406226180569131374998200219247331736680368064857334435670396138660371761559552538275484733604405170494226960755011832925730632506130211675038585610822383744391934132314726080728887333265128532878067733890732992973727602443973557915020046544581187280375103290341206430301823467160119749967195989342776352977629588372473893669097633674936822994303626689961939354052262211802804626913539122824557017598100371164399688836395961089264135288262005025115510716615410712418923190708129942695180863852959923810259571729923993121414142102355477070085555900495092940483311782588856452542957378349275903327731058438267977565400398102950216990377882282050721467380943202619808232520968528756705913661945565955494703620903172333491281604756262932465384300392264638772535178550629818900587124158665787276943628778050785941159390499226972156891390428844758297982013992218433398431443343297509762650543758986370876194067763578623415995395857721733625699297232173138562186107390799116939283955733541076952079243894430477359860970571171027616473985837467040662221924896284915792418615122284579427276776562170680603040634318594449990928730955468080358940711938726769242078935950513340678708669785852410632983994488016649795035762587308531377626567159326745848784087650743487153508082111604880375673700824495969140443786313843515745145744072662686015184181211406390177729507554398223521426054656397563309371854348127764374551700527042548736895259894456527815594746442275376849643216259462006473477261004688754457975922911923637246411006025717239601043897275614876162138938801586992615653538603942684125194782507558821215023508557775489873549571876113646443477834606239185697903577120787080300717298621472041190620031457830576579643356204906866547777758577724172306540056693801372721886501045028595632825356427345334305672873194983045289158766383702966072096547272468101207491470115798460076868768723489787676101970181674441015326565006995864076744043252493801870669562288776212062811301410353399292598950872168099763560393041763246150512238636421329874939892820961320237196286751796597930994411242341813545830826363061154303352482566365955427530635779461773992943363184596117548311896570650796799349281291132951894116607493062267470617533167604802907608464213475575536071852544625149916347891632155925545652886250214290645942174440344350946354898012946360442171418941286085602008379429011040147137830390465872288338880327095137327001016670028338850101424076202334381068610870620559068748728934911336784842597208208863977244389399443264499425166966286835100304262372577654262695325952481832896116023739523050738270294258384810074433614811720336641998936149326235543781013133539256991627675818094441749572935326410341123671639404724964548266454966082684914359753307547920224734132546416353091313653600139149095199632360469528970893470161367389841331337908741011431686910221419189677978774764501005850673487661832249908142536107635929747317842638328536750453432465332549661313115314110684787104297867918114046586808055881057685182920981292591641511531266153414983793243539534507238740924011520157876288793906037850575223750883227793640070184335825436730909908333522963022903901653366473552423659829036706485637272392835472412020290219019934934532314075439425333743031288555447188546811338187037173096159995636170260693602081563932149243338560377267712598579312984879090067829871959268359105372792135829056673849357458714838807249596853772844554513250093893591153563418597475483020757156144398767123041139956792509074548838953023966323816532305320326954817512319400628560244566563812207134134313254444837575342624493396751472142430791445986588082025489263121205966978633565547223481141949694091740724553722213548261898820239225248760549359059294542589255053878980395283290766895511089323428562436979996379382280686655953458559782154202745585623685902364677118847705126663283067562865593485746362729164143323499922252773790719520952344430418200548549703239314040776103237309889148891883561275339140748561070864798315847397556221068349713689973342464322640127572616289542136261777971272898183575589265919111753761345547373676729412244169665991445206880330323884944645974816006842331799696887133771539691070148205865001878900284197599666291258969038597244820185515673684593394372820274731637136305543701465182810680497018495750897434323493088492814561827450270118456536262907807382991813057724820012509917610475433447904546259431560850446611035765125233661613510996407511353851483059139878890086980092343709418913460983064379376612271723865069806369037435412852356057801672160089208286108420665220965895004209406064056926641099050632348661170775163086941757091232194762832302902074975551594671499793470202096735004966510235544750050539912953744307285247712124351073826643188427031978119010750270367030414193152291562632797088650640044733924017108175330402101527579666914164718363614985462491808660490397382942658638649254061357524285371598801320610428280907727331035614370210709388355204849875647849023578266450061853848472997115130425589131165506798429817857377137257900451280944116762648585732015290736780733963875192683737985825482638685921196660973811892552471906413521954430814329459819012237167457125437448471465030124600852161483358076196245283960690103708719816427127559329694845011551844874545978463757825988097080968936454398564786345081468590659781793510075807449289741145297882152264846018249741401073527587763789938000084794636404597737881060392216475279156196383758972796539468670573663378347212655000810356953729581870773676338484263513459595376441312553938869498280409661127680137456714766222219731722990213227238306843450548181574845017601137342996622982420394596944840746718088801262619639993014008335753665872202391804438859486349114326724549095784795869760645981266331778350118248120404400905297369154365643303177843432609414191990079945655563361956549947677683916418431672912425878824000912081243486699963430700610267325545874287799764395122591617370363358476823467285395497784933888705281029698229239764540224773220752049054203778238008765407245607822425400433584943057586483900713885561429549914408950260343422977546243874727326974232602110147317291961391725140539525914282478873832433447553891044960379753606772247655912119703822122259427975920052726807873862393039466894232937091489659994007959050737566970259675643966610274896063378721528541518875744009791508702959780667730599131031413380942061404461535957846596961169994512656270491627452814928318460338657079083049449757325746370901021307528602414961598977205665237114776739104923762572450196572717344514175659320348463410700930182627775077900261223027756801790257236852308834599246314626021755359780018362732357411642830346618712385372858319671074551751753535839070739214284733756952051790778559251708819222624804375884738892604238619410922374901606937212732406203867643351949310883489767987593674328357822783151502927183300462531882485372216004105175520380011017474788028906062599491204428761237835908855606562524601863579050091407619143991859866774393729755965509497071402000661849634862596730547395123886875782636441382145663125435453597270764337830374274650419536692568366947425227378669092588107437395795053686796107362749016500024070423872851964779086582045166346561971622339566877672226418816295873094916146723251141143910465492206472033714246298615982883833464876645673193387374322536302367207068826060198721670883870486731458615363090131349551311164222870171367924075637591840675748580255062139022593061492616809927526045793365723366505991850081080076078345252003916680026723603176735311981150759594908474221403177433019529518487314155168026579189575826869625019580587272880939451128445893971171233416351919888199706464118260700198467216414695910921640244013953434891479650705838116011056742366554042500373832895491218324603334786154100353121313597345196743578362465084391591890717383427522967952200117414999858207114551391874591355785209598616706102249254557412070590946252434411199061493512410984346297239238119679218216929431383849185152962764253480336296906549929910148259535067627152699210596536358136488677162709710373032645406398557604551437160704207508866481964709272392954477248411151647112642751667401332043112824364716305617491407448724357546337992985741038864944130182266235351562500000000000E-4965
$ ./a.out >tmp
$ cat t2.f90
real(16) x
read (*, '(E12000.0)') x
write (*, '(Z16)') x
end
$ flang t2.f90
$ ./a.out <tmp
1

Click here to read the complete article

Re: Subnormal anomaly

<8a51ac73-aa51-439f-8697-5cc928358c81n@googlegroups.com>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2952&group=comp.lang.fortran#2952

copy link Newsgroups: comp.lang.fortran

X-Received: by 2002:ac8:574a:0:b0:394:3388:9fc3 with SMTP id 10-20020ac8574a000000b0039433889fc3mr1055441qtx.292.1665685602816;
Thu, 13 Oct 2022 11:26:42 -0700 (PDT)
X-Received: by 2002:a05:6214:ac5:b0:4b3:203b:7393 with SMTP id
g5-20020a0562140ac500b004b3203b7393mr1105356qvi.63.1665685602696; Thu, 13 Oct
2022 11:26:42 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.fortran
Date: Thu, 13 Oct 2022 11:26:42 -0700 (PDT)
In-Reply-To: <8aad1cc0-4f05-4656-864c-7639cb342cb9n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2601:602:9700:4689:21d5:8b8e:cc4c:677c;
posting-account=gLDX1AkAAAA26M5HM-O3sVMAXdxK9FPA
NNTP-Posting-Host: 2601:602:9700:4689:21d5:8b8e:cc4c:677c
References: <ti913t$1pt36$1@dont-email.me> <aa9de517-532e-4db8-8608-0c09e5a36580n@googlegroups.com>
<8aad1cc0-4f05-4656-864c-7639cb342cb9n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8a51ac73-aa51-439f-8697-5cc928358c81n@googlegroups.com>
Subject: Re: Subnormal anomaly
From: gah4@u.washington.edu (gah4)
Injection-Date: Thu, 13 Oct 2022 18:26:42 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2147

by: gah4 - Thu, 13 Oct 2022 18:26 UTC

On Thursday, October 13, 2022 at 11:02:57 AM UTC-7, Peter Klausler US wrote:
> On Thursday, October 13, 2022 at 10:40:30 AM UTC-7, gah4 wrote:
> > Conversion between textual decimal representation and internal binary
> > representation is not easy. I would especially be surprised if any conversion
> > could use 722 digits in the conversion process.

> 128-bit IEEE is even more fun, but I don't know of a Fortran compiler that has a limit on digits that would preclude exact conversions.

I got interested in this in the Fortran 66 days, and had the OS/360
Fortran library to read, and figure out how they did it. I haven't tried
to follow actual library routines since then.

OK, more specifically on what I wrote.

Are there cases where changing the 722nd digit will change the value?

Re: Subnormal anomaly

<56c91370-2215-4bd8-a496-457ef06578ddn@googlegroups.com>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2954&group=comp.lang.fortran#2954

copy link Newsgroups: comp.lang.fortran

X-Received: by 2002:ad4:5ca3:0:b0:4b1:ab10:a4e2 with SMTP id q3-20020ad45ca3000000b004b1ab10a4e2mr1248656qvh.44.1665686640800;
Thu, 13 Oct 2022 11:44:00 -0700 (PDT)
X-Received: by 2002:a05:622a:15cf:b0:39c:4c04:107d with SMTP id
d15-20020a05622a15cf00b0039c4c04107dmr1124024qty.122.1665686640647; Thu, 13
Oct 2022 11:44:00 -0700 (PDT)
Path: i2pn2.org!i2pn.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.fortran
Date: Thu, 13 Oct 2022 11:44:00 -0700 (PDT)
In-Reply-To: <8a51ac73-aa51-439f-8697-5cc928358c81n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=12.154.207.45; posting-account=ZT-cAwoAAACx2tBPXm-WZoHIT8sjnGGy
NNTP-Posting-Host: 12.154.207.45
References: <ti913t$1pt36$1@dont-email.me> <aa9de517-532e-4db8-8608-0c09e5a36580n@googlegroups.com>
<8aad1cc0-4f05-4656-864c-7639cb342cb9n@googlegroups.com> <8a51ac73-aa51-439f-8697-5cc928358c81n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <56c91370-2215-4bd8-a496-457ef06578ddn@googlegroups.com>
Subject: Re: Subnormal anomaly
From: pklausler@nvidia.com (Peter Klausler US)
Injection-Date: Thu, 13 Oct 2022 18:44:00 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1652

by: Peter Klausler US - Thu, 13 Oct 2022 18:44 UTC

On Thursday, October 13, 2022 at 11:26:44 AM UTC-7, gah4 wrote:
> Are there cases where changing the 722nd digit will change the value?

I think that one could find such cases when it changes rounding, especially when those changed digits are being read back into a more precise kind of real.

Re: Subnormal anomaly

<26538f65-aae9-4ae7-82e3-400ec70892e2n@googlegroups.com>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2955&group=comp.lang.fortran#2955

copy link Newsgroups: comp.lang.fortran

X-Received: by 2002:a05:6214:623:b0:4b4:156a:cd98 with SMTP id a3-20020a056214062300b004b4156acd98mr1390115qvx.102.1665692540700;
Thu, 13 Oct 2022 13:22:20 -0700 (PDT)
X-Received: by 2002:a37:a98b:0:b0:6eb:c2c5:7af6 with SMTP id
s133-20020a37a98b000000b006ebc2c57af6mr1343349qke.409.1665692540540; Thu, 13
Oct 2022 13:22:20 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.fortran
Date: Thu, 13 Oct 2022 13:22:20 -0700 (PDT)
In-Reply-To: <ti913t$1pt36$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=115.189.130.46; posting-account=KnYfEgoAAAD1tUJTvdAUZ3XojNa5tezZ
NNTP-Posting-Host: 115.189.130.46
References: <ti913t$1pt36$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <26538f65-aae9-4ae7-82e3-400ec70892e2n@googlegroups.com>
Subject: Re: Subnormal anomaly
From: harperjf2@gmail.com (jfh)
Injection-Date: Thu, 13 Oct 2022 20:22:20 +0000
Content-Type: text/plain; charset="UTF-8"

by: jfh - Thu, 13 Oct 2022 20:22 UTC

On Friday, October 14, 2022 at 1:42:40 AM UTC+13, Thomas Schnurrenberger wrote:
> The following program gives an unexpected result when compiled and
> executed with gfortran on Windows:
>
> program test
> !
> use :: iso_fortran_env
> !
> implicit none
> !
> real(real64), parameter :: SUB1 = real(z'1', real64)
> real(real64), parameter :: SUB2 = real(z'2', real64)
> !
> character(len=1000) :: buff
> real(real64) :: got
> !
> ! Inexact representation of the smallest subnormal number:
> buff = '5e-324'
> read (buff, *) got
> print *, 'Expected:', SUB1, ', got:', got, ',', SUB1 == got
> !
> ! Inexact representation of the second smallest subnormal number.
> buff = '9e-324'
> read (buff, *) got
> print *, 'Expected:', SUB2, ', got:', got, ',', SUB2 == got
> !
> ! Exact representation of the number which is exactly halfway
> ! between the smallest and the second smallest subnormal number
> ! 2**(-1074) + 2**(-1075). This number should be rounded to the
> ! second smallest subnormal number according to the default IEEE
> ! 754 rounding rules:
> buff = '7.41098468761869816264853189302332058547589703921&
> &4871466383785237510132609053131277979497545424539&
> &8856969484704316857659638998506553390969459816219&
> &4016172817189451069785467106791768725751773473155&
> &5330779540854980960845750095811137303474765809687&
> &1009590975442271004757307809711118935784838675653&
> &9987835030152280559340465937397917907387238682993&
> &9581848166016912201945649993128979841136206248449&
> &8678713572180352209017023903285791732520220528974&
> &0208029068540216066123755499834026713000358124864&
> &7904138574340187552090159017259254714629617513415&
> &9774938718574737870961645638908718119841271673056&
> &0170454930047052695901657637768849082679869725733&
> &6652176556794107250876433756084600398490497214911&
> &7463085539556354188641513168478436313080237596295&
> &773983001708984375e-324'
> read (buff, *) got
> print *, 'Expected:', SUB2, ', got:', got, ',', SUB2 == got
> !
> end program test
>
> I tried the program on Windows 7 with gfortran 11.2.0 and on
> Windows 10 with gfortran 12.2.0. Both are from MSYS2/MinGW64
> and the results are identical:
>
> Expected: 4.9406564584124654E-324 , got: 4.9406564584124654E-324, T
> Expected: 9.8813129168249309E-324 , got: 9.8813129168249309E-324, T
> Expected: 9.8813129168249309E-324 , got: 2.2250738585072014E-308, F
>
> The third print should give the same result as the second one.
> The result looks like the smallest normal double precision number
> which is not quiet correct.
>
> On Windows 10 with the Intel ifort 64-Bit compiler version 2021.5.0
> Build 20211109_000000:
>
> Expected: 4.940656458412465E-324 , got: 4.940656458412465E-324, T
> Expected: 9.881312916824931E-324 , got: 9.881312916824931E-324, T
> Expected: 9.881312916824931E-324 , got: 9.881312916824931E-324, T
>
> Can someone please test the program on Linux to verify that this
> is not a Windows specific problem. Is this a known issue?
>
> Regards
>
> --
> Thomas

On my Linux Ubuntu system, after putting in this line after the declarations:

print *, 'version = ',compiler_version()

I got these results with gfortran and ifort.

version = GCC version 12.1.0
Expected: 4.9406564584124654E-324 , got: 4.9406564584124654E-324 , T
Expected: 9.8813129168249309E-324 , got: 9.8813129168249309E-324 , T
Expected: 9.8813129168249309E-324 , got: 9.8813129168249309E-324 , T

version =
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel
(R) 64, Version 2021.6.0 Build 20220226_000000
Expected: 4.940656458412465E-324 , got: 4.940656458412465E-324 , T
Expected: 9.881312916824931E-324 , got: 9.881312916824931E-324 , T
Expected: 9.881312916824931E-324 , got: 9.881312916824931E-324 , T

Re: Subnormal anomaly

<tia4b6$1sr80$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2956&group=comp.lang.fortran#2956

copy link Newsgroups: comp.lang.fortran

Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: sgk@REMOVEtroutmask.apl.washington.edu (Steven G. Kargl)
Newsgroups: comp.lang.fortran
Subject: Re: Subnormal anomaly
Date: Thu, 13 Oct 2022 22:43:50 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <tia4b6$1sr80$1@dont-email.me>
References: <ti913t$1pt36$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 13 Oct 2022 22:43:50 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="bdb549deda9bf974f475e107f7bffde0";
logging-data="1993984"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/nuC1wJUCWm+Wx4TeB9ems"
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
git.gnome.org/pan2)
Cancel-Lock: sha1:S2JIUF3/xwul55+L16V6xmL9ktg=

by: Steven G. Kargl - Thu, 13 Oct 2022 22:43 UTC

On Thu, 13 Oct 2022 14:42:37 +0200, Thomas Schnurrenberger wrote:

> The following program gives an unexpected result when compiled and
> executed with gfortran on Windows:
>
> program test
> !
> use :: iso_fortran_env
> !
> implicit none
> !
> real(real64), parameter :: SUB1 = real(z'1', real64)
> real(real64), parameter :: SUB2 = real(z'2', real64)
> !

Why do you think that there is a problem? REAL64 from
ISO_FORTRAN_ENV does not mean IEEE 754 binary64 type.
It means the type occupies 64 bits. That's it. In fact,
the type many not support subnormals at all.

If you want IEEE binary64, then use the IEEE 754 facilities
available in modern Fortran.

--
steve

Re: Subnormal anomaly

<30f09c8d-9364-4f84-94b0-07e9a6ad29fdn@googlegroups.com>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2957&group=comp.lang.fortran#2957

copy link Newsgroups: comp.lang.fortran

X-Received: by 2002:ac8:5d93:0:b0:398:3709:945c with SMTP id d19-20020ac85d93000000b003983709945cmr1964956qtx.459.1665702068190;
Thu, 13 Oct 2022 16:01:08 -0700 (PDT)
X-Received: by 2002:a05:6214:4014:b0:4b3:eff6:d9b with SMTP id
kd20-20020a056214401400b004b3eff60d9bmr1843064qvb.20.1665702068018; Thu, 13
Oct 2022 16:01:08 -0700 (PDT)
Path: i2pn2.org!i2pn.org!news.niel.me!glou.org!news.glou.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.fortran
Date: Thu, 13 Oct 2022 16:01:07 -0700 (PDT)
In-Reply-To: <ti913t$1pt36$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=12.154.207.45; posting-account=ZT-cAwoAAACx2tBPXm-WZoHIT8sjnGGy
NNTP-Posting-Host: 12.154.207.45
References: <ti913t$1pt36$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <30f09c8d-9364-4f84-94b0-07e9a6ad29fdn@googlegroups.com>
Subject: Re: Subnormal anomaly
From: pklausler@nvidia.com (Peter Klausler US)
Injection-Date: Thu, 13 Oct 2022 23:01:08 +0000
Content-Type: text/plain; charset="UTF-8"

by: Peter Klausler US - Thu, 13 Oct 2022 23:01 UTC

On Thursday, October 13, 2022 at 5:42:40 AM UTC-7, Thomas Schnurrenberger wrote:
> Expected: 4.9406564584124654E-324 , got: 4.9406564584124654E-324, T
> Expected: 9.8813129168249309E-324 , got: 9.8813129168249309E-324, T
> Expected: 9.8813129168249309E-324 , got: 2.2250738585072014E-308, F
>
> The third print should give the same result as the second one.
> The result looks like the smallest normal double precision number
> which is not quiet correct.

I checked your decimal numbers, and they are accurate. But the results *are* correct -- when the
default "round to nearest" mode is in effect, and the exact value is exactly between two representable
numbers, IEEE-754 rounds to the *even* one -- i.e., the one whose least-significant bit is zero. And
in this case, that's z'2', not z'1'.

Re: Subnormal anomaly

<tiath5$2196r$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2961&group=comp.lang.fortran#2961

copy link Newsgroups: comp.lang.fortran

Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: tsbg@gmx.net (Thomas Schnurrenberger)
Newsgroups: comp.lang.fortran
Subject: Re: Subnormal anomaly
Date: Fri, 14 Oct 2022 07:53:41 +0200
Organization: A noiseless patient Spider
Lines: 100
Message-ID: <tiath5$2196r$1@dont-email.me>
References: <ti913t$1pt36$1@dont-email.me>
<26538f65-aae9-4ae7-82e3-400ec70892e2n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 14 Oct 2022 05:53:41 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="5a7149a2e3757cfe17be19afe73240c0";
logging-data="2139355"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19u7+SERC6p4yi05vitHOCK"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.2
Cancel-Lock: sha1:uBbublOL5kpLTk4W5EQCMn6E3lI=
Content-Language: de-CH, en-US
In-Reply-To: <26538f65-aae9-4ae7-82e3-400ec70892e2n@googlegroups.com>

by: Thomas Schnurrenberg - Fri, 14 Oct 2022 05:53 UTC

On 13.10.2022 22:22, jfh wrote:
> On Friday, October 14, 2022 at 1:42:40 AM UTC+13, Thomas Schnurrenberger wrote:
>> The following program gives an unexpected result when compiled and
>> executed with gfortran on Windows:
>>
>> program test
>> !
>> use :: iso_fortran_env
>> !
>> implicit none
>> !
>> real(real64), parameter :: SUB1 = real(z'1', real64)
>> real(real64), parameter :: SUB2 = real(z'2', real64)
>> !
>> character(len=1000) :: buff
>> real(real64) :: got
>> !
>> ! Inexact representation of the smallest subnormal number:
>> buff = '5e-324'
>> read (buff, *) got
>> print *, 'Expected:', SUB1, ', got:', got, ',', SUB1 == got
>> !
>> ! Inexact representation of the second smallest subnormal number.
>> buff = '9e-324'
>> read (buff, *) got
>> print *, 'Expected:', SUB2, ', got:', got, ',', SUB2 == got
>> !
>> ! Exact representation of the number which is exactly halfway
>> ! between the smallest and the second smallest subnormal number
>> ! 2**(-1074) + 2**(-1075). This number should be rounded to the
>> ! second smallest subnormal number according to the default IEEE
>> ! 754 rounding rules:
>> buff = '7.41098468761869816264853189302332058547589703921&
>> &4871466383785237510132609053131277979497545424539&
>> &8856969484704316857659638998506553390969459816219&
>> &4016172817189451069785467106791768725751773473155&
>> &5330779540854980960845750095811137303474765809687&
>> &1009590975442271004757307809711118935784838675653&
>> &9987835030152280559340465937397917907387238682993&
>> &9581848166016912201945649993128979841136206248449&
>> &8678713572180352209017023903285791732520220528974&
>> &0208029068540216066123755499834026713000358124864&
>> &7904138574340187552090159017259254714629617513415&
>> &9774938718574737870961645638908718119841271673056&
>> &0170454930047052695901657637768849082679869725733&
>> &6652176556794107250876433756084600398490497214911&
>> &7463085539556354188641513168478436313080237596295&
>> &773983001708984375e-324'
>> read (buff, *) got
>> print *, 'Expected:', SUB2, ', got:', got, ',', SUB2 == got
>> !
>> end program test
>>
>> I tried the program on Windows 7 with gfortran 11.2.0 and on
>> Windows 10 with gfortran 12.2.0. Both are from MSYS2/MinGW64
>> and the results are identical:
>>
>> Expected: 4.9406564584124654E-324 , got: 4.9406564584124654E-324, T
>> Expected: 9.8813129168249309E-324 , got: 9.8813129168249309E-324, T
>> Expected: 9.8813129168249309E-324 , got: 2.2250738585072014E-308, F
>>
>> The third print should give the same result as the second one.
>> The result looks like the smallest normal double precision number
>> which is not quiet correct.
>>
>> On Windows 10 with the Intel ifort 64-Bit compiler version 2021.5.0
>> Build 20211109_000000:
>>
>> Expected: 4.940656458412465E-324 , got: 4.940656458412465E-324, T
>> Expected: 9.881312916824931E-324 , got: 9.881312916824931E-324, T
>> Expected: 9.881312916824931E-324 , got: 9.881312916824931E-324, T
>>
>> Can someone please test the program on Linux to verify that this
>> is not a Windows specific problem. Is this a known issue?
>>
>> Regards
>>
>> --
>> Thomas
>
> On my Linux Ubuntu system, after putting in this line after the declarations:
>
> print *, 'version = ',compiler_version()
>
> I got these results with gfortran and ifort.
>
> version = GCC version 12.1.0
> Expected: 4.9406564584124654E-324 , got: 4.9406564584124654E-324 , T
> Expected: 9.8813129168249309E-324 , got: 9.8813129168249309E-324 , T
> Expected: 9.8813129168249309E-324 , got: 9.8813129168249309E-324 , T
>
> version =
> Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel
> (R) 64, Version 2021.6.0 Build 20220226_000000
> Expected: 4.940656458412465E-324 , got: 4.940656458412465E-324 , T
> Expected: 9.881312916824931E-324 , got: 9.881312916824931E-324 , T
> Expected: 9.881312916824931E-324 , got: 9.881312916824931E-324 , T

Thanks for checking. It seems, the problem exists only on Windows.

Re: Subnormal anomaly

<tib0k2$21fbe$3@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2962&group=comp.lang.fortran#2962

copy link Newsgroups: comp.lang.fortran

Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: tsbg@gmx.net (Thomas Schnurrenberger)
Newsgroups: comp.lang.fortran
Subject: Re: Subnormal anomaly
Date: Fri, 14 Oct 2022 08:46:26 +0200
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <tib0k2$21fbe$3@dont-email.me>
References: <ti913t$1pt36$1@dont-email.me>
<30f09c8d-9364-4f84-94b0-07e9a6ad29fdn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 14 Oct 2022 06:46:26 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="5a7149a2e3757cfe17be19afe73240c0";
logging-data="2145646"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18S1QA02dcbIzsEWkd5bnK0"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.2
Cancel-Lock: sha1:8jESwcSmkBA/SmWQzUCcHOnVep4=
In-Reply-To: <30f09c8d-9364-4f84-94b0-07e9a6ad29fdn@googlegroups.com>
Content-Language: en-US

by: Thomas Schnurrenberg - Fri, 14 Oct 2022 06:46 UTC

On 14.10.2022 01:01, Peter Klausler US wrote:
> On Thursday, October 13, 2022 at 5:42:40 AM UTC-7, Thomas Schnurrenberger wrote:
>> Expected: 4.9406564584124654E-324 , got: 4.9406564584124654E-324, T
>> Expected: 9.8813129168249309E-324 , got: 9.8813129168249309E-324, T
>> Expected: 9.8813129168249309E-324 , got: 2.2250738585072014E-308, F
>>
>> The third print should give the same result as the second one.
>> The result looks like the smallest normal double precision number
>> which is not quiet correct.
>
> I checked your decimal numbers, and they are accurate. But the results *are* correct -- when the
> default "round to nearest" mode is in effect, and the exact value is exactly between two representable
> numbers, IEEE-754 rounds to the *even* one -- i.e., the one whose least-significant bit is zero. And
> in this case, that's z'2', not z'1'.

Thanks for verifying my numbers. I agree completely with you, except
that all the results are correct.

This is the output of the third print:

Expected: 9.8813129168249309E-324 , got: 2.2250738585072014E-308, F

The result is in my opinion not correct, and it is not a "simple"
rounding error. If you change the last digit of the input number from
5 to 4, gfortran returns the correct result, which is z'1'. If you
change the last digit from 5 to 6, gfortran returns also the correct
result which is z'2'. It is only this exact number which gives a
incorrect result. What do you expect as result when reading the large
input number?

Re: Subnormal anomaly

<4b19af9d-81d5-42b7-ab63-73d827f7bb37n@googlegroups.com>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2970&group=comp.lang.fortran#2970

copy link Newsgroups: comp.lang.fortran

X-Received: by 2002:a05:620a:17a5:b0:6ee:9c6a:208d with SMTP id ay37-20020a05620a17a500b006ee9c6a208dmr4562913qkb.337.1665767497001;
Fri, 14 Oct 2022 10:11:37 -0700 (PDT)
X-Received: by 2002:a37:f701:0:b0:6ce:f09b:9065 with SMTP id
q1-20020a37f701000000b006cef09b9065mr4541977qkj.268.1665767493784; Fri, 14
Oct 2022 10:11:33 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.fortran
Date: Fri, 14 Oct 2022 10:11:23 -0700 (PDT)
In-Reply-To: <tib0k2$21fbe$3@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=12.154.207.45; posting-account=ZT-cAwoAAACx2tBPXm-WZoHIT8sjnGGy
NNTP-Posting-Host: 12.154.207.45
References: <ti913t$1pt36$1@dont-email.me> <30f09c8d-9364-4f84-94b0-07e9a6ad29fdn@googlegroups.com>
<tib0k2$21fbe$3@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4b19af9d-81d5-42b7-ab63-73d827f7bb37n@googlegroups.com>
Subject: Re: Subnormal anomaly
From: pklausler@nvidia.com (Peter Klausler US)
Injection-Date: Fri, 14 Oct 2022 17:11:36 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1942

by: Peter Klausler US - Fri, 14 Oct 2022 17:11 UTC

On Thursday, October 13, 2022 at 11:46:29 PM UTC-7, Thomas Schnurrenberger wrote:
> This is the output of the third print:
> Expected: 9.8813129168249309E-324 , got: 2.2250738585072014E-308, F
> The result is in my opinion not correct, and it is not a "simple"
> rounding error. If you change the last digit of the input number from
> 5 to 4, gfortran returns the correct result, which is z'1'. If you
> change the last digit from 5 to 6, gfortran returns also the correct
> result which is z'2'. It is only this exact number which gives a
> incorrect result. What do you expect as result when reading the large
> input number?

4 should round down to z'1', 6 should round up to z'2', and 5 is exactly between them and should round to the even one, which is z'2'.

Re: Subnormal anomaly

<tijcr3$3e215$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2993&group=comp.lang.fortran#2993

copy link Newsgroups: comp.lang.fortran

Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: tsbg@gmx.net (Thomas Schnurrenberger)
Newsgroups: comp.lang.fortran
Subject: Re: Subnormal anomaly
Date: Mon, 17 Oct 2022 13:04:03 +0200
Organization: A noiseless patient Spider
Lines: 153
Message-ID: <tijcr3$3e215$1@dont-email.me>
References: <ti913t$1pt36$1@dont-email.me> <tia4b6$1sr80$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 17 Oct 2022 11:04:03 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="d5a13f71f80a71d16e8409dcef23e971";
logging-data="3606565"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+h+U9gl13S3XLbJKnyQSKt"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.3
Cancel-Lock: sha1:tAK+skD4XMzUixy9akb8yfR6QfE=
Content-Language: en-US
In-Reply-To: <tia4b6$1sr80$1@dont-email.me>

by: Thomas Schnurrenberg - Mon, 17 Oct 2022 11:04 UTC

On 14.10.2022 00:43, Steven G. Kargl wrote:
> On Thu, 13 Oct 2022 14:42:37 +0200, Thomas Schnurrenberger wrote:
>
>> The following program gives an unexpected result when compiled and
>> executed with gfortran on Windows:
>>
>> program test
>> !
>> use :: iso_fortran_env
>> !
>> implicit none
>> !
>> real(real64), parameter :: SUB1 = real(z'1', real64)
>> real(real64), parameter :: SUB2 = real(z'2', real64)
>> !
>
> Why do you think that there is a problem? REAL64 from
> ISO_FORTRAN_ENV does not mean IEEE 754 binary64 type.
> It means the type occupies 64 bits. That's it. In fact,
> the type many not support subnormals at all.
>
You are of course right.

> If you want IEEE binary64, then use the IEEE 754 facilities
> available in modern Fortran.
>
The following modified program is an attempt to use the IEEE 754
facilities correctly:

program test
!
use, intrinsic :: ieee_arithmetic
use, intrinsic :: ieee_features
use, intrinsic :: iso_fortran_env, only: compiler_version
!
implicit none
!
! Select a suitable IEEE real kind.
integer, parameter :: dp = ieee_selected_real_kind(15)
!
character(len=1000) :: buff
real(dp) :: expected, got
logical :: features(4)
!
print *, 'Compiler version = ', compiler_version()
print *, '-----'
if (dp < 0) stop 'No suitable IEEE real kind found.'
! Get IEEE features.
features(1) = ieee_support_subnormal(got)
features(2) = ieee_support_io(got)
features(3) = ieee_support_rounding(ieee_nearest, got)
features(4) = ieee_support_underflow_control(got)
print *, 'The selected real kind supports the following IEEE features:'
if (features(1)) print *, 'Subnormal numbers.'
if (features(2)) print *, 'Formatted input/output.'
if (features(3)) print *, 'Control of the rounding mode.'
if (features(4)) print *, 'Control of the underflow mode.'
if (.not. all(features)) stop &
'Not all required IEEE features are supported.'
print *, 'Set rounding mode and underflow control:'
! Set rounding mode to nearest.
call ieee_set_rounding_mode(ieee_nearest)
print *, 'Rounding mode set to nearest.'
! Enable gradual underflow.
call ieee_set_underflow_mode(.true.)
print *, 'Gradual underflow is enabled.'
print *, '-----'
!
! Inexact representation of the smallest subnormal number:
buff = '5e-324'
expected = ieee_scalb(1.0_dp, -1074)
read (buff, *) got
print *, '1: Expected:', expected, ', got:', got, ',', expected == got
!
! Inexact representation of the second smallest subnormal number.
buff = '9e-324'
expected = ieee_scalb(2.0_dp, -1074)
read (buff, *) got
print *, '2: Expected:', expected, ', got:', got, ',', expected == got
!
! Exact representation of the number which is exactly halfway
! between the smallest and the second smallest subnormal number
! 2**(-1074) + 2**(-1075). This number should be rounded to the
! second smallest subnormal number according to the default IEEE
! 754 rounding rules:
buff = '7.41098468761869816264853189302332058547589703921&
&4871466383785237510132609053131277979497545424539&
&8856969484704316857659638998506553390969459816219&
&4016172817189451069785467106791768725751773473155&
&5330779540854980960845750095811137303474765809687&
&1009590975442271004757307809711118935784838675653&
&9987835030152280559340465937397917907387238682993&
&9581848166016912201945649993128979841136206248449&
&8678713572180352209017023903285791732520220528974&
&0208029068540216066123755499834026713000358124864&
&7904138574340187552090159017259254714629617513415&
&9774938718574737870961645638908718119841271673056&
&0170454930047052695901657637768849082679869725733&
&6652176556794107250876433756084600398490497214911&
&7463085539556354188641513168478436313080237596295&
&773983001708984375e-324'
expected = ieee_scalb(3.0_dp, -1075)
read (buff, *) got
print *, '3: Expected:', expected, ', got:', got, ',', expected == got
!
end program test

Results from running the program on Windows 10
(results slightly edited for display purpose):

Compiler version = GCC version 12.2.0
-----
The selected real kind supports the following IEEE features:
Subnormal numbers.
Formatted input/output.
Control of the rounding mode.
Control of the underflow mode.
Set rounding mode and underflow control:
Rounding mode set to nearest.
Gradual underflow is enabled.
-----
1: Expected: 4.9406564584124654E-324, got: 4.9406564584124654E-324, T
2: Expected: 9.8813129168249309E-324, got: 9.8813129168249309E-324, T
3: Expected: 9.8813129168249309E-324, got: 2.2250738585072014E-308, F

Compiler version =
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running
on Intel
(R) 64, Version 2021.7.0 Build 20220726_000000
-----
The selected real kind supports the following IEEE features:
Subnormal numbers.
Formatted input/output.
Control of the rounding mode.
Control of the underflow mode.
Set rounding mode and underflow control:
Rounding mode set to nearest.
Gradual underflow is enabled.
-----
1: Expected: 4.940656458412465E-324, got: 4.940656458412465E-324, T
2: Expected: 9.881312916824931E-324, got: 9.881312916824931E-324, T
3: Expected: 9.881312916824931E-324, got: 9.881312916824931E-324, T

I would expect that the ifort and the gfortran compiler give the same
results. I'm very grateful for any hint, if I am doing something wrong.

Regards

--
Thomas

Re: Subnormal anomaly

<tik4hv$3g41l$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2994&group=comp.lang.fortran#2994

copy link Newsgroups: comp.lang.fortran

Path: i2pn2.org!i2pn.org!paganini.bofh.team!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: sgk@REMOVEtroutmask.apl.washington.edu (Steven G. Kargl)
Newsgroups: comp.lang.fortran
Subject: Re: Subnormal anomaly
Date: Mon, 17 Oct 2022 17:48:47 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 99
Message-ID: <tik4hv$3g41l$1@dont-email.me>
References: <ti913t$1pt36$1@dont-email.me> <tia4b6$1sr80$1@dont-email.me>
<tijcr3$3e215$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 17 Oct 2022 17:48:47 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="2e4ce6c89b6544a132e826274eda739f";
logging-data="3674165"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/LuA215/WpKtkNiH3/ibzS"
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
git.gnome.org/pan2)
Cancel-Lock: sha1:kdGciZTdrk5lerc/3GQjJPkvtOU=

by: Steven G. Kargl - Mon, 17 Oct 2022 17:48 UTC

On Mon, 17 Oct 2022 13:04:03 +0200, Thomas Schnurrenberger wrote:

> On 14.10.2022 00:43, Steven G. Kargl wrote:
>> On Thu, 13 Oct 2022 14:42:37 +0200, Thomas Schnurrenberger wrote:
>>
>>> The following program gives an unexpected result when compiled and
>>> executed with gfortran on Windows:
>>>
>>> program test
>>> !
>>> use :: iso_fortran_env
>>> !
>>> implicit none
>>> !
>>> real(real64), parameter :: SUB1 = real(z'1', real64)
>>> real(real64), parameter :: SUB2 = real(z'2', real64)
>>> !
>>
>> Why do you think that there is a problem? REAL64 from
>> ISO_FORTRAN_ENV does not mean IEEE 754 binary64 type.
>> It means the type occupies 64 bits. That's it. In fact,
>> the type many not support subnormals at all.
>>
> You are of course right.
>
>> If you want IEEE binary64, then use the IEEE 754 facilities
>> available in modern Fortran.
>>
> The following modified program is an attempt to use the IEEE 754
> facilities correctly:
>

(program removed to shorten response.

>
> Results from running the program on Windows 10

This is your problem.

>
> Compiler version = GCC version 12.2.0
....
> -----
> 1: Expected: 4.9406564584124654E-324, got: 4.9406564584124654E-324, T
> 2: Expected: 9.8813129168249309E-324, got: 9.8813129168249309E-324, T
> 3: Expected: 9.8813129168249309E-324, got: 2.2250738585072014E-308, F
>
> Compiler version =
> Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running
> on Intel
> (R) 64, Version 2021.7.0 Build 20220726_000000
....
> -----
> 1: Expected: 4.940656458412465E-324, got: 4.940656458412465E-324, T
> 2: Expected: 9.881312916824931E-324, got: 9.881312916824931E-324, T
> 3: Expected: 9.881312916824931E-324, got: 9.881312916824931E-324, T
>
>
> I would expect that the ifort and the gfortran compiler give the same
> results. I'm very grateful for any hint, if I am doing something wrong.
>

On FreeBSD, you get
1: Expected: 4.9406564584124654E-324 , got: 4.9406564584124654E-324 , T
2: Expected: 9.8813129168249309E-324 , got: 9.8813129168249309E-324 , T
3: Expected: 9.8813129168249309E-324 , got: 9.8813129168249309E-324 , T

Windows 10 is simply broken for your "BUF = 7.4..."; READ(BUF,*)".

This eventually gets reduced to a library function from the OS. If you
look into gcc/libgfortran/libgfortran.h, you find

#ifdef __MINGW32__
extern float __strtof (const char *, char **);
#define gfc_strtof __strtof
extern double __strtod (const char *, char **);
#define gfc_strtod __strtod
extern long double __strtold (const char *, char **);
#define gfc_strtold __strtold
#else
#define gfc_strtof strtof
#define gfc_strtod strtod
#define gfc_strtold strtold
#endif

On FreeBSD, I have
nm /usr/local/lib/gcc11/libgfortran.a | grep strtof
U strtof
w strtoflt128
U strtoflt128

So either __strtof or strtof on Windows 10 appears to be broken.

--
steve

Re: Subnormal anomaly

<0279c1f9-1582-42a2-8c4d-6233ad073b82n@googlegroups.com>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2995&group=comp.lang.fortran#2995

copy link Newsgroups: comp.lang.fortran

X-Received: by 2002:ae9:f214:0:b0:6e4:35ec:a7fe with SMTP id m20-20020ae9f214000000b006e435eca7femr402446qkg.253.1666059622080;
Mon, 17 Oct 2022 19:20:22 -0700 (PDT)
X-Received: by 2002:a37:f701:0:b0:6ce:f09b:9065 with SMTP id
q1-20020a37f701000000b006cef09b9065mr446800qkj.268.1666059621876; Mon, 17 Oct
2022 19:20:21 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.fortran
Date: Mon, 17 Oct 2022 19:20:21 -0700 (PDT)
In-Reply-To: <ti913t$1pt36$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2601:602:9700:4689:6073:fdf5:278e:7ec1;
posting-account=gLDX1AkAAAA26M5HM-O3sVMAXdxK9FPA
NNTP-Posting-Host: 2601:602:9700:4689:6073:fdf5:278e:7ec1
References: <ti913t$1pt36$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0279c1f9-1582-42a2-8c4d-6233ad073b82n@googlegroups.com>
Subject: Re: Subnormal anomaly
From: gah4@u.washington.edu (gah4)
Injection-Date: Tue, 18 Oct 2022 02:20:22 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1789

by: gah4 - Tue, 18 Oct 2022 02:20 UTC

On Thursday, October 13, 2022 at 5:42:40 AM UTC-7, Thomas Schnurrenberger wrote:
> The following program gives an unexpected result when compiled and
> executed with gfortran on Windows:

Reading the Wikipedia article:

https://en.wikipedia.org/wiki/IEEE_754#Character_representation

suggests that the standard requires one be able to take an internal binary value,
convert it to printable decimal with sufficient digits, and convert back with proper
rounding to the original binary value.

It does not seem to require 722 digit values to convert exactly.

But maybe that page doesn't have everything.

Is there a place where it says that 722 digits are required?

Re: Subnormal anomaly

<9401379b-0e76-44b7-bdf2-fa25251fb42bn@googlegroups.com>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2996&group=comp.lang.fortran#2996

copy link Newsgroups: comp.lang.fortran

X-Received: by 2002:a05:6214:c4b:b0:4b1:9e07:388 with SMTP id r11-20020a0562140c4b00b004b19e070388mr5758921qvj.76.1666169650603;
Wed, 19 Oct 2022 01:54:10 -0700 (PDT)
X-Received: by 2002:a37:f701:0:b0:6ce:f09b:9065 with SMTP id
q1-20020a37f701000000b006cef09b9065mr4769030qkj.268.1666169650442; Wed, 19
Oct 2022 01:54:10 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.fortran
Date: Wed, 19 Oct 2022 01:54:10 -0700 (PDT)
In-Reply-To: <0279c1f9-1582-42a2-8c4d-6233ad073b82n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2601:602:9700:4689:343f:94d0:71c0:d07a;
posting-account=gLDX1AkAAAA26M5HM-O3sVMAXdxK9FPA
NNTP-Posting-Host: 2601:602:9700:4689:343f:94d0:71c0:d07a
References: <ti913t$1pt36$1@dont-email.me> <0279c1f9-1582-42a2-8c4d-6233ad073b82n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9401379b-0e76-44b7-bdf2-fa25251fb42bn@googlegroups.com>
Subject: Re: Subnormal anomaly
From: gah4@u.washington.edu (gah4)
Injection-Date: Wed, 19 Oct 2022 08:54:10 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2213

by: gah4 - Wed, 19 Oct 2022 08:54 UTC

On Monday, October 17, 2022 at 7:20:23 PM UTC-7, gah4 wrote:
> On Thursday, October 13, 2022 at 5:42:40 AM UTC-7, Thomas Schnurrenberger wrote:
> > The following program gives an unexpected result when compiled and
> > executed with gfortran on Windows:
> Reading the Wikipedia article:
> https://en.wikipedia.org/wiki/IEEE_754#Character_representation
> suggests that the standard requires one be able to take an internal binary value,
> convert it to printable decimal with sufficient digits, and convert back with proper
> rounding to the original binary value.

Discussion on the above page gives the M+3 rule, which as well as I know it,
is you figure out how many decimal digits are needed to represent the
precision of the binary value, round up to the nearest integer, and add 3.

That is said to be what is needed such that the result, converted back to
binary, rounds to the original value.

I believe this is what Java uses for output conversion, whether you want
it or not.

Re: Subnormal anomaly

<tiohf3$p7v$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2997&group=comp.lang.fortran#2997

copy link Newsgroups: comp.lang.fortran

Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: tsbg@gmx.net (Thomas Schnurrenberger)
Newsgroups: comp.lang.fortran
Subject: Re: Subnormal anomaly
Date: Wed, 19 Oct 2022 11:53:39 +0200
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <tiohf3$p7v$1@dont-email.me>
References: <ti913t$1pt36$1@dont-email.me>
<0279c1f9-1582-42a2-8c4d-6233ad073b82n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 19 Oct 2022 09:53:39 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="952cac046fcdc61f2e2806503b484f1d";
logging-data="25855"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19pvo49sfpRgoq2y/dNreyi"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.3
Cancel-Lock: sha1:OYoUf+1l28ilVTRX1V4us7Ihti4=
Content-Language: en-US
In-Reply-To: <0279c1f9-1582-42a2-8c4d-6233ad073b82n@googlegroups.com>

by: Thomas Schnurrenberg - Wed, 19 Oct 2022 09:53 UTC

On 18.10.2022 04:20, gah4 wrote:
> On Thursday, October 13, 2022 at 5:42:40 AM UTC-7, Thomas Schnurrenberger wrote:
>> The following program gives an unexpected result when compiled and
>> executed with gfortran on Windows:
>
> Reading the Wikipedia article:
>
> https://en.wikipedia.org/wiki/IEEE_754#Character_representation
>
> suggests that the standard requires one be able to take an internal binary value,
> convert it to printable decimal with sufficient digits, and convert back with proper
> rounding to the original binary value.
>
> It does not seem to require 722 digit values to convert exactly.
>
> But maybe that page doesn't have everything.
>
> Is there a place where it says that 722 digits are required?

The blog of Rick Regan has a lot of interesting posts about floating
point numbers: https://www.exploringbinary.com/tag/floating-point/

Another interesting blog with articles about floating point numbers
is the blog from Bruce Dawson:
https://randomascii.wordpress.com/category/floating-point/

Regards

--
Thomas

Re: Subnormal anomaly

<tip172$23b2$3@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2998&group=comp.lang.fortran#2998

copy link Newsgroups: comp.lang.fortran

Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: tsbg@gmx.net (Thomas Schnurrenberger)
Newsgroups: comp.lang.fortran
Subject: Re: Subnormal anomaly
Date: Wed, 19 Oct 2022 16:22:26 +0200
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <tip172$23b2$3@dont-email.me>
References: <ti913t$1pt36$1@dont-email.me> <tia4b6$1sr80$1@dont-email.me>
<tijcr3$3e215$1@dont-email.me> <tik4hv$3g41l$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 19 Oct 2022 14:22:26 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="952cac046fcdc61f2e2806503b484f1d";
logging-data="68962"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/UMcx/t5IXQRLHC1MtHO2I"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.3
Cancel-Lock: sha1:1Snop1LtBASkk6RgdvG419ZW4/E=
Content-Language: en-US
In-Reply-To: <tik4hv$3g41l$1@dont-email.me>

by: Thomas Schnurrenberg - Wed, 19 Oct 2022 14:22 UTC

On 17.10.2022 19:48, Steven G. Kargl wrote:
> ...
>
> This eventually gets reduced to a library function from the OS. If you
> look into gcc/libgfortran/libgfortran.h, you find
>
> #ifdef __MINGW32__
> extern float __strtof (const char *, char **);
> #define gfc_strtof __strtof
> extern double __strtod (const char *, char **);
> #define gfc_strtod __strtod
> extern long double __strtold (const char *, char **);
> #define gfc_strtold __strtold
> #else
> #define gfc_strtof strtof
> #define gfc_strtod strtod
> #define gfc_strtold strtold
> #endif
>
That was the crucial hint, thank you very much. A short test with a
C program showed indeed that the __strtod() function is responsible for
the faulty result. After some investigation on the internet, I'm coming
to the following conclusion:

The __strto(x) functions are used by the MinGW/MinGW64 projects as
replacements for faulty implementations in the older Microsoft C
runtime libraries. Newer Microsoft C runtime libraries, such as the
"Universal CRT", have correctly working implementations of these
functions and need no replacements. It shouldn't be necessary to link
directly to the replacement functions, because the CRT's from
MinGW/MinGW64 decide themself if this is necessary.

I would suggest that the gfortran runtime library does not link to the
replacement functions. That means, the post-processor definitions for
__MINGW32__ can/should be removed.

I am not an expert in this area, so I would be very grateful if my
conclusions can be verified by a more involved person. Thanks again
for your help.

Regards

--
Thomas

Re: Subnormal anomaly

<tis16u$clvd$1@dont-email.me>

copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2999&group=comp.lang.fortran#2999

copy link Newsgroups: comp.lang.fortran

Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: sgk@REMOVEtroutmask.apl.washington.edu (Steven G. Kargl)
Newsgroups: comp.lang.fortran
Subject: Re: Subnormal anomaly
Date: Thu, 20 Oct 2022 17:40:46 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <tis16u$clvd$1@dont-email.me>
References: <ti913t$1pt36$1@dont-email.me> <tia4b6$1sr80$1@dont-email.me>
<tijcr3$3e215$1@dont-email.me> <tik4hv$3g41l$1@dont-email.me>
<tip172$23b2$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 20 Oct 2022 17:40:46 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="cbf7854ee658315b96d9f2a9e43f266d";
logging-data="415725"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX195IE4ZnbmqwA6LCbThebgd"
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
git.gnome.org/pan2)
Cancel-Lock: sha1:ay21LMg6sGg/WRckk47XQSNcwdk=

by: Steven G. Kargl - Thu, 20 Oct 2022 17:40 UTC

On Wed, 19 Oct 2022 16:22:26 +0200, Thomas Schnurrenberger wrote:

> On 17.10.2022 19:48, Steven G. Kargl wrote:
>> ...
>>
>> This eventually gets reduced to a library function from the OS. If you
>> look into gcc/libgfortran/libgfortran.h, you find
>>
>> #ifdef __MINGW32__
>> extern float __strtof (const char *, char **);
>> #define gfc_strtof __strtof
>> extern double __strtod (const char *, char **);
>> #define gfc_strtod __strtod
>> extern long double __strtold (const char *, char **);
>> #define gfc_strtold __strtold
>> #else
>> #define gfc_strtof strtof
>> #define gfc_strtod strtod
>> #define gfc_strtold strtold
>> #endif
>>
> That was the crucial hint, thank you very much. A short test with a
> C program showed indeed that the __strtod() function is responsible for
> the faulty result. After some investigation on the internet, I'm coming
> to the following conclusion:
>
> The __strto(x) functions are used by the MinGW/MinGW64 projects as
> replacements for faulty implementations in the older Microsoft C
> runtime libraries. Newer Microsoft C runtime libraries, such as the
> "Universal CRT", have correctly working implementations of these
> functions and need no replacements. It shouldn't be necessary to link
> directly to the replacement functions, because the CRT's from
> MinGW/MinGW64 decide themself if this is necessary.
>
> I would suggest that the gfortran runtime library does not link to the
> replacement functions. That means, the post-processor definitions for
> __MINGW32__ can/should be removed.
>
> I am not an expert in this area, so I would be very grateful if my
> conclusions can be verified by a more involved person. Thanks again
> for your help.

Unfortunately, there has never been a gfortran contributor whose
primary platform was MS Windows. The one time I interacted with
a MinGW developer, I was less than thrilled. MingW shadows some
POSIX function (don't remember, might fstat() or fread()), and I
asked if they could fix MingW to follow POSIX. The exchange left
me with little incentive to work on MS Window related gfortran
bugs.

You might considering raising a bug report in GCC's bugzilla, but
it may take awhile to get anyone to fix it.

--
steve
thought I suggested
>
> Regards

server_pubkey.txt

rocksolid light 0.9.81
clearnet tor