Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

A Fortran compiler is the hobgoblin of little minis.


programming / comp.lang.fortran / latest

Re: program convert in fortran 77 to fortran 95 (thread)

comp.lang.fortran

Posted: 6 Hours 22 Minutes ago by: gah4

(snip) I suppose so. But about as likely, a function that is an extension, or otherwise supported by some compiler. Last time I ran into that, was porting a program that is older than Fortran 66, which used a LINK function. (I belie

Re: program convert in fortran 77 to fortran 95 (thread)

comp.lang.fortran

Posted: 6 Hours 49 Minutes ago by: jfh

There is a way for a valid f77 program to be invalid f95. The f77 program may have included a function with the same name as an intrinsic function new in f90 or f95, but with quite different arguments, if it did not have to be labelled E

Re: program convert in fortran 77 to fortran 95 (thread)

comp.lang.fortran

Posted: 7 Hours 40 Minutes ago by: gah4

There was once, and I presume still is, a program to convert Fortran 77 to free-form Fortran 90 or 95. Most people (but not programs) writing fixed-form Fortran will put in blanks between keywords and variable names, for readability.

program convert in fortran 77 to fortran 95

comp.lang.fortran

Posted: 14 Hours 21 Minutes ago by: arames asus

program convert in fortran 77 to fortran 95

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 1 Day 21 Hours ago by: Phillip Helbig (undr

In article <i0xdK.9778$gc62.7492@fx45.iad>, Ron Shepard <nospam@nowhere.org> writes: But IMPLICIT LOGICAL was almost as good.

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 7 Days 8 Hours ago by: Robin Vowels

.. .. I was merely pointing out that bit strings and character strings had been available in FORTRAN VI for more than a decade prior to F77. Of course, FORTRAN VI was better known as PL/I.

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 7 Days 16 Hours ago by: Walter Spector

I was posting in the context of Fortran. Of course there were many languages prior to Fortran 77, dating back to the 1950s, that had character and even bit-level data types.

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 8 Days ago by: Robin Vowels

.. Not in FORTRAN, but available in COBOL and PL/I for more than a decade. .. .. .. PL/I provided character strings of arbitrary length from 1966 -- in both fixed-length and varying-length. An advantage of varying-length character strings

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 8 Days 3 Hours ago by: Walter Spector

Prior to Fortran 77, there was no character data type. Hollerith constants were used to set character strings into numeric variables. String size fixed to the number of characters a 'numeric storage unit' (NSU) could hold. Various machi

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 8 Days 12 Hours ago by: John

I agree, although I think g95 saved it, then gfortran sustained it.

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 8 Days 13 Hours ago by: Ron Shepard

Yes, there were several useful extensions that were in the MIL-STD document, including IMPLICIT NONE, INCLUDE, and the set of bit operators that were all eventually included in f90. I think most programmers were expecting a revision to

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 8 Days 14 Hours ago by: Ron Shepard

i also used implicit character declarations in my codes for a while as a work-around for the lack of implicit none in f77. Then something strange happened on a compiler. I was doing some bit-packing with shift(), and(), or(), and so on

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 8 Days 18 Hours ago by: FortranFan

And that remains yet another unfortunate event in the history of Fortran. ANSI X3.9-1978 document toward FORTRAN 77 was approved by ANSI on April 3, 1978 that became the de facto standard reference for FORTRAN 77. Now consider MILITARY

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 9 Days ago by: Thomas Koenig

Possibly, but the people who wrote up the advice at the time didn't think of it, and neither did I :-) After I moved my development to UNIX-based Fortran compilers which supported IMPLICIT NONE, the point became moot. f2c also supports

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 9 Days 5 Hours ago by: James Van Buskirk

"Thomas Koenig" wrote in message news:t56tfm$u2s$1@newsreader4.netcologne.de... Wouldn't IMPLICIT CHARACTER*(*) (A-Z) have caught a couple more errors?

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 9 Days 8 Hours ago by: Thomas Koenig

I used to use IMPLICT CHARACTER*1 (A-Z) which caught many, if not all, errors. Inventing a variable name in a subroutine argument was not caught this way, for example. Having Toolpack and, later, ftnchek also helped a lot.

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 9 Days 11 Hours ago by: Gary Scott

But we still don't have a lot of those necessary extensions, still having to use extensions. Like mechanisms to access shared memory areas across processes and hardware. Ability to create and/or initiate other processes and threads.

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 9 Days 11 Hours ago by: gah4

(snip) I remember stories about some using: IMPLICIT LOGICAL (A-$) and then the compiler (unless it has other extensions) will complain about the use of LOGICAL variables. Or printing them would give a T or F, and not a number

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 9 Days 15 Hours ago by: Ron Shepard

This has been mentioned a couple of times now in this thread, and just as a reminder IMPLICIT NONE was not part of standard fortran until f90. So if one wanted to write standard code in the 1980s, this was not an option. On the other

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 9 Days 17 Hours ago by: Thomas Koenig

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 9 Days 17 Hours ago by: Steve Lionel

The no-parenthesis PARAMETER syntax was part of the FORTRAN-77 draft right up until the published standard. DEC went ahead and implemented it, assuming it would be part of the final standard. When it wasn't, they had to support both. I

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 9 Days 20 Hours ago by: Ev. Drikos

Implementing it in a LALR based parser is also tricky (gfortran is RD). All the replies were very helpful and here is what I've understood or better what a Fortran developer may expect or much better what finally worked in my case. With

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 10 Days 5 Hours ago by: Lynn McGuire

I converted my 240,000 line Win16 Smalltalk app to a 350,000 line Win32 C++ app in 2002. The problem with Smalltalk is that it is 100X slower than C++ (I timed it !) and the late binding. Plus my Smalltalk compiler and linker did not

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 10 Days 8 Hours ago by: Robin Vowels

Use IMPLICIT NONE

Re: Speed of writing formatted matrices of floats in Fortran and C++ (thread)

comp.lang.fortran

Posted: 10 Days 15 Hours ago by: Beliavsky

Great story. Please consider also posting it at https://fortran-lang.discourse.group/t/anecdotal-fortran/704 .

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 10 Days 15 Hours ago by: John

x parameters = 2.0 print *, 's=', s print *, 'parameters=', parameters end For something that short to be so surprising is interesting; some compilers even have problems with the above. Note to self: do no

Re: Speed of writing formatted matrices of floats in Fortran and C++ (thread)

comp.lang.fortran

Posted: 10 Days 15 Hours ago by: Ron Shepard

In addition to treating the i/o list as a sequence of scalars or as a vector, there is also the question, in both languages, of how often the format string is parsed. With FORMAT statements, compilers would typically parse the format s

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 10 Days 15 Hours ago by: Liam Proven

That is good to hear. Thanks for the reassurance.

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 10 Days 15 Hours ago by: Liam Proven

I do try. :-D Aha! So your email is the origin of this Quora thread? https://www.quora.com/What-does-Alan-Kay-mean-when-he-said-OOP-to-me-means-only-messaging-local-retention-and-protection-and-hiding-of-state-process-and-extreme-late-

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 10 Days 15 Hours ago by: John

You nailed it. The program is a DEC extension that allows for a PARAMETER statement to be indistinguishable from a variable declaration, so if you force standards compliance the problem goes away. That little example is a true classic. Of

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 10 Days 15 Hours ago by: Ron Shepard

Gfortran has always been an f90 compiler, so PARAMETERS is being interpreted as an implicitly typed real variable. The first line is an executable statement assigning the value of 2.0 to that variable. The code is interpreted the same

gcc 12.1 has been released

comp.lang.fortran

Posted: 10 Days 16 Hours ago by: Thomas Koenig

Hi, gcc 12.1 has been released, which includes gfortran 12.1. Here are the sections relevant to Fortran in the changes file: Fortran: * WG5/N1942, "TS 29113 Further Interoperability of Fortran with C", is now fully supported. In addi

Re: What results this legacy code should give? (thread)

comp.lang.fortran

Posted: 10 Days 17 Hours ago by: Arjen Markus

I compiled the program without -fdec and -ffixed-form and got this error: 1 | parameters = 2.0 | 1 Warning: Legacy Extension: PARAMETER without '()' at (1) I think I understand - a bit - what is going on: your code is

Re: Speed of writing formatted matrices of floats in Fortran and C++ (thread)

comp.lang.fortran

Posted: 10 Days 17 Hours ago by: Stefan Ram

Console output can be very slow. If one is writing to a console, one should make sure to use the same console system for all languages tested. Writing to a file on disk often will be faster. I/O usually is deemed to be slow, so

What results this legacy code should give?

comp.lang.fortran

Posted: 10 Days 18 Hours ago by: Ev. Drikos

Hello, Currently, my attention is on Legacy code, DEC/VMS. IMOH, the results I see seem to be confusing. Maybe it's my fault or GNU Fortran after version 8 gives different results or what else?. Results from other compilers that support

Speed of writing formatted matrices of floats in Fortran and C++

comp.lang.fortran

Posted: 10 Days 19 Hours ago by: Beliavsky

I am finding that writing 100x100 matrices of floats is about 25% faster with gfortran than g++ using printf on Windows and 4 times faster with gfortran than g++ on WSL2. I wonder what people see on Linux and if the C++ performance can be i

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 11 Days 16 Hours ago by: Stefan Ram

....

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 11 Days 18 Hours ago by: FortranFan

@Liam Proven, Please - if you are coming to Fortran from the days of FORTRAN 77 and related earlier dialects - there is no need to get hung up on OOP. There is a lot in the current standard other than OOP to work with if you so choose,

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 11 Days 18 Hours ago by: Beliavsky

Not every Fortran program needs to use inheritance, and it's not clear to me that type-bound procedures have a better syntax than procedures with derived type arguments. But I think OOP can reduce duplication when the same procedures are

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 11 Days 20 Hours ago by: David Jones

I partly agree with this, except that to me OOP has little to do with the programming language being used but is rather abut doing pre-programming thinking ... thinking about what parts of a system of sub-programs will need access to wha

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 11 Days 22 Hours ago by: Liam Proven

That seems a little sweeping. It seems to me that OOP has nearly as many different purposes as there are people using it. My cynical suspicion is that Rob Pike (of Plan 9 and Go fame) nailed it with his line: "Object-oriented design

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 12 Days 1 Hour ago by: Ron Shepard

This issue has absolutely nothing to do with decimal arithmetic and whether a particular processor supports it or not. In the original code, there was an if statement that compared to the literal value 0.1. That literal value is transl

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 12 Days 3 Hours ago by: gah4

(snip) I now have an IBM Power7 machines, which (like Power6) has decimal floating point. I haven't gotten to install an OS yet, with AIX and Linux being two choices, and don't know which compilers have support for it.

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 12 Days 9 Hours ago by: Gary Scott

Ah, terminology. To me a "type" is an intrinsic thing. When you define a "derived type", you're creating a "container" (structure) of intrinsic types. Is that "container" then a type? To me, no, it's a container, for convenience. (

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 12 Days 12 Hours ago by: Stefan Ram

Supersedes: <differentiation-20220504183830@ram.dialup.fu-berlin.de> [correcting the integral via "PS" below] Thomas Koenig <tkoenig@netcologne.de> writes: I since have cancelled my post, because I only learned about the meaning of "

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 12 Days 13 Hours ago by: Stefan Ram

Supersedes: <distribution-20220504185458@ram.dialup.fu-berlin.de> [to use a more common notation] Thomas Koenig <tkoenig@netcologne.de> writes: As far as I understand it, what is a distribution is the mapping from f to f(0) S_0^oo f(

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 12 Days 13 Hours ago by: Stefan Ram

As far as I understand it, what is a distribution is the mapping g(y) from f to S_0^oo f(x) delta(y) dx, while "delta" in isolaton still just is a symbol. With more Unicode symbols: the mapping g(y) from f to ∫₀°° f(x)

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 12 Days 14 Hours ago by: Stefan Ram

I since have cancelled my post, because I only learned about the meaning of "automatic differentiation" after writing it. Given 1 if x > 0.1 x -1 , otherwise. , what would be the integral? I think it woul

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 12 Days 14 Hours ago by: Thomas Koenig

There is no "exactly x=0.1" in binary floating point (and I'm not sure that even a single Fortran compiler supports decimal floating point, despite radix being present in selected_real_kind), which is why I chose that particular number, t

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 12 Days 14 Hours ago by: Stefan Ram

There is /numeric/ and /symbolic/ differentiation. Numerically, one can easily get an approximation for anything as a difference quotient for a small difference, but needs to take care, because some results might not be correct

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 12 Days 15 Hours ago by: Stefan Ram

The point of OOP is to be able to easily add new data types without having to modify existing code. For example, in Python, there is a "print" procedure that can print objects of many built-in data types like "string" and "int"

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 12 Days 16 Hours ago by: Ron Shepard

[...] I think it only works on intel and AMD hardware and on linux and windows software. Their classic compiler works also on intel+MacOS. At least the last I checked, it did not work on IBM PowerPC hardware or on Apple ARM hardware, a

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 12 Days 18 Hours ago by: bruno

No more need to use gfortran, the onePAI of Intel works on all platforms ( compilers and many tools are free to use) My lenovo T430 with Linux works fine

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 13 Days 10 Hours ago by: John McCue

Same here Same here, very confusing and in fact I do not see the point of OO. Luckily I never had to deal with it professionally. I also have been playing around with Fortran (gfortran) with an eye to relearn it, hope to be retiring

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 17 Days 11 Hours ago by: Louis Krupp

You've probably tried this, but the ANL partnerships page also mentions adifor@mcs.anl.gov in what looks like a screwed-up link. Louis

Re: Does OpenMP (5.1) Invalidate this code? (thread)

comp.lang.fortran

Posted: 17 Days 17 Hours ago by: Ev. Drikos

This is also what I'd understood, yet it's valid with older compilers, ie gfortran-4.8.5 (I think OMP-3.0 or so) accepts my example as valid. Thank you. I'd not yet reached that point. In this case there might be another issue with the

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 17 Days 18 Hours ago by: Liam Proven

Oh good. Glad to hear it's not just me. Interesting info... thank you.

Re: Relearning Fortran (thread)

comp.lang.fortran

Posted: 17 Days 18 Hours ago by: Liam Proven

:-) with other readers using Fortran syntax-highlighted posting and reading for code snippets, file attachments, URL links that highlight headlines (and summary), etc. I have a Discourse account, but to be honest, I do not like web fo

Re: Does OpenMP (5.1) Invalidate this code? (thread)

comp.lang.fortran

Posted: 18 Days 2 Hours ago by: gah4

(snip) OK, note that it says that some are optional. If an optional OpenMP END closes your block, then the actual END statement that you supply would be an error. It should diagnose that error, which would tell you that the block was

Re: Does OpenMP (5.1) Invalidate this code? (thread)

comp.lang.fortran

Posted: 18 Days 3 Hours ago by: Ev. Drikos

Silence! Possibly, I've missed some details but I hope to eventually get the point, which shall normally be genius. On the hand, if older code is indeed invalidated, the chances are that such cases would be rare.

Re: Optimization options (thread)

comp.lang.fortran

Posted: 18 Days 18 Hours ago by: Steve Lionel

comment that -fast also turns on -xHost, and is best used when compiling and running on the same processor. Like the gfortran option, the things turned on by -fast can also change results. The suggestion of using -Og to debug difference

Optimization options

comp.lang.fortran

Posted: 19 Days 17 Hours ago by: Beliavsky

Regarding compiler options to maximize speed I may tweet The ifort -fast and gfortran -O3 -march=native options can be used to increase speed. Gfortran -Ofast turns on -ffast-math and can give a further 2x speedup in some cases, but it can

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 20 Days 11 Hours ago by: Ian Gay

In this case, use ln(x) as your variable instead of x.

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 20 Days 13 Hours ago by: Thomas Koenig

And, of course, 0.1 is not even exactly representable in your typical binary floating-point type (which is why I chose it that way). The question is: What should automatic differentiation do with this sort of thing? Agreed. There is a

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 20 Days 14 Hours ago by: gah4

(snip) Reading this one: https://en.wikipedia.org/wiki/PROSE_modeling_language reminded me of the difference between symbolic derivatives and AD (automatic derivatives). For AD, with each mathematical operation, and for that matter,

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 20 Days 15 Hours ago by: gah4

(snip on discontinuous derivatives) They are. And presumably this would show up in doing numerical derivatives using those functions, though I don't know that I have ever seen the problem. Might not be hard to find, though.

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 20 Days 17 Hours ago by: Ron Shepard

The left derivative is defined at x=0.1, but the right derivative is not. And the function is discontinuous there. This is a common situation with physical simulations, for example at phase transitions where some physical properties ar

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 20 Days 18 Hours ago by: Arjen Markus

So you have been able to find it? I failed to do so. Regards, Arjen

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 20 Days 18 Hours ago by: Arjen Markus

The function is continuous and differentiable on intervals not include x = 0.1. And that is exactly how it can be treated. Mind you, you do get results that are geared to precisely the surroundings of the input So, with discontinuous or

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 20 Days 19 Hours ago by: Spiros Bousbouras

Actually the derivative is not defined for x = 0.1 , foo is not even continuous for x = 0.1

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 20 Days 19 Hours ago by: Daniel Feenberg

I have a program that calculates income tax liability for any year from 1960-2023, and for any state. It is used by economists and others to estimate after tax income and prices in survey or administrative data. You can see it at http://t

Does OpenMP (5.1) Invalidate this code?

comp.lang.fortran

Posted: 20 Days 19 Hours ago by: Ev. Drikos

Hello, Possibly I miss some details with a new OpenMP-5.1 feature. An OpenMP End Statement becomes optional if the opening statement of an OpenMP construct is followed by a block-construct. An example is given in the second program belo

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 20 Days 22 Hours ago by: Arjen Markus

If a commercial solution is somehow acceptable, then NAG may have an alternative. I have worked with it a couple of years and it does what you want. I do not know more about ADIFOR than you. Regards, Arjen PS I removed the email addre

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 21 Days 7 Hours ago by: Jeff Ryman

Although it hasn't been worked on in some time there is also GRESS 3.0 from RSICC. See https://rsicc.ornl.gov/codes/psr/psr2/psr-231.html . It was only for Fortran 77. Although software with CCC- and DLC- designations have a fee, the last

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 21 Days 8 Hours ago by: David Duffy

http://www.autodiff.org/?module=Tools&language=Fortran77 lists quite a few that still seem to be free. I last used TAPENADE, which still offers a service where you upload your subroutine(s) that you want to equip. Some posters upthread

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 21 Days 10 Hours ago by: Thomas Koenig

A few decades ago, I started using REDUCE for automatically calculating derivatives, which I then transferred to FORTRAN to do some calculations with equations of state, and then transferred them to F77 using an editor. It was nice, but

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 21 Days 11 Hours ago by: gah4

(snip) What it should do is easy, but what you do with the result, is where it gets harder: if (x > 0.1) then foo = 1+x dfoodx = 1 else foo = -1-x dfoodx = -1 end if It does help to have a good understanding of the problem y

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 21 Days 11 Hours ago by: Thomas Koenig

With IFs, it is really hard - what should the derivative of if (x > 0.1) then foo = 1+x else foo = -1-x end if be? Also, you usually want many derivatives for a filling a Jacobi matrix, which should be well-behaved, and

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 21 Days 11 Hours ago by: gah4

This reminds me of a system I knew years ago called Prose. It seems to be mentioned here, along with the follow-on: fortranCalculus: https://goal-driven.net/compiler-intro-&-history/history.html Prose was developed and available in th

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 21 Days 11 Hours ago by: gah4

(snip) (snip) I read just a little of the description, which mentions functions and subroutines. Yes there are a few ways to differentiate an expression, in Fortran or not, and get the result. But now consider a whole Fortran fu

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 21 Days 15 Hours ago by: Thomas Koenig

What exactly do you need differentiated? If you want fully automated Fortran-to-Fortran conversion, then I don't have anything. If you can massage your formulas so Maxima can accept them, like (%i1) display2d:false; (%o1) false (%i2)

Re: Automatic Differentiation (thread)

comp.lang.fortran

Posted: 21 Days 15 Hours ago by: Ron Shepard

The Paul Hovland contact should be active. This is still an active area of research for that group. The code works also with f90+ (modules, operators, defined types, etc.), but I do not know the current status regarding the most recent

Automatic Differentiation

comp.lang.fortran

Posted: 21 Days 19 Hours ago by: Daniel Feenberg

There are a number of hits to "fortran automatic differentiation" but the only one that claims to be available without cost is ADIFOR, from the Argonne Laboratory. On various web pages I have found 5 email addresses and 3 phone numbers. Acc

gtk-fortran 4.2 released (a fpm dependency)

comp.lang.fortran

Posted: 21 Days 23 Hours ago by: MAGNIN Vincent

* gtk-fortran 4.2.1 offers interfaces to GTK 4.6.2 and GLib 2.72.1. You can of course use it with lower GTK 4 versions, provided that you don't call new functions. It was tested on Linux, MSYS2/Windows 10, macOS and FreeBSD. See https:/

Re: User-defined list-directed input (thread)

comp.lang.fortran

Posted: 23 Days 9 Hours ago by: FortranFan

Nor supporting it in the standard. You may want to inquire at the J3 mailing list about the r*c form of list-directed input and defined IO is supposed to work with it. You will know feeding "1,1" to that program will work and print you

Re: C to Fortran converter (C2F.ZIP)

comp.lang.fortran

Posted: 23 Days 9 Hours ago by: Beliavsky

A prior thread discussing C2F is https://fortran-lang.discourse.group/t/c-to-fortran-converter/885 .

Re: beliavsky@aol.com (thread)

comp.lang.fortran

Posted: 23 Days 9 Hours ago by: Beliavsky

Do you really need to translate it? Read about how to call C code from Fortran in a standard way by searching "Fortran C interoperability". Maybe the author addressed me because I uploaded https://github.com/Beliavsky/c2f . He could try

User-defined list-directed input

comp.lang.fortran

Posted: 23 Days 11 Hours ago by: Thomas Koenig

I'm not quite sure how user-defined I/O and list-directed input go together. For example, can I just write module x implicit none type foo real :: r end type foo interface read(formatted) module procedure read_formatted

Re: beliavsky@aol.com (thread)

comp.lang.fortran

Posted: 23 Days 13 Hours ago by: FortranFan

https://fortran-lang.discourse.group/

Re: C to Fortran converter (C2F.ZIP)

comp.lang.fortran

Posted: 23 Days 13 Hours ago by: FortranFan

@nabil amine, you may want to cross-post this at Fortran Discourse and readers of that forum can also try to help you with such translation: https://fortran-lang.discourse.group/

Re: C to Fortran converter (C2F.ZIP)

comp.lang.fortran

Posted: 23 Days 15 Hours ago by: nabil amine

can someone tel how i can run c2f in windows11

Re: C to Fortran converter (C2F.ZIP)

comp.lang.fortran

Posted: 23 Days 15 Hours ago by: nabil amine

beliavsky@aol.com

comp.lang.fortran

Posted: 23 Days 15 Hours ago by: nabil amine

hello i need your help please i need to transalte a c code to fortran language can you help me please

Re: C to Fortran converter (C2F.ZIP)

comp.lang.fortran

Posted: 23 Days 15 Hours ago by: nabil amine

i need to transalte a c code to fortran code can u help me

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 27 Days 2 Hours ago by: David Duffy

Reading bitcodes from C integer(c_int) :: ir character (len=2), dimension(0:3), parameter :: sizes = & (/'16', '32', '64', 'Ot'/) ir=zlibcompileflags() write(outstr, '(2a)', advance='no') ' uInt:', sizes(ibits(ir,0,2)) write(out

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 27 Days 9 Hours ago by: Beliavsky

Thanks to you and others for the informative replies.

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 27 Days 10 Hours ago by: Gary Scott

In aerospace/avionics, we had to interface dozens to 100s of small embedded processors communicating via serial bus. Because bandwidth was limited, we defined our data as efficiently as possible to fit within the 16-bit words of the se

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 27 Days 11 Hours ago by: gah4

(snip) Without bit shifting and IOR, though usually without using the sign bit, you can easily do it with divide and MOD. Even more, with divide and MOD, you are not limited to only powers of two, thought it might be a little slower.

Re: Spacing of real numbers around zero (thread)

comp.lang.fortran

Posted: 27 Days 11 Hours ago by: gah4

Which I never thought was a good idea. You get the equivalent of about 0.04 extra exponent bits, for a lot of extra work and/or hardware. Note that the actual smallest number has zero significant bits. It especially complicates par

Re: Spacing of real numbers around zero (thread)

comp.lang.fortran

Posted: 27 Days 12 Hours ago by: steve kargl

If your processor supports subnormal number, first nonzero positive closest to 0 is 2**(-p-emin). % cat z.f90 program foo print *, 2.**(minexponent(1.) - digits(1.)) end % gfcx -o z a.f90 && ./z 1.40129846E-45 The IEEE facilities

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 27 Days 15 Hours ago by: Robin Vowels

.. .. Or you could check whether your compiler offers 1-byte integers, which can hold signed values to 127. .. .. In the old days, 16-bit integers were available, and decimal integers in the range -9 through 9 were available for arrays con

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 27 Days 15 Hours ago by: James Van Buskirk

"Beliavsky" wrote in message news:16a16dc4-9458-43f6-b769-4a8ea6dd5c76n@googlegroups.com... Well, there is the sieve of Eratosthenes. A big sieve table takes less memory when implemented as a bit array. At some point the algorithm will

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 27 Days 15 Hours ago by: Ron Shepard

Probably the most common application in my field is to pack small values into larger integer words. If you have some integers that are known to be between 0 and 31, or example, then they only need 5 bits to represent their value. So yo

Spacing of real numbers around zero

comp.lang.fortran

Posted: 27 Days 15 Hours ago by: Beliavsky

Spacing(0.0_wp) is supposed to give the number adjacent to zero, but it looks like that is actually given by epsilon(x) * tiny(x) , which is smaller. The output of the program program main use iso_fortran_env, only: int32, real32 implicit

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 27 Days 16 Hours ago by: Robin Vowels

On Tuesday, April 19, 2022 at 12:35:42 PM UTC+10, Beliavsky wrote:

Re: Applications of bit manipulation functions in Fortran (thread)

comp.lang.fortran

Posted: 28 Days 1 Hour ago by: gah4

A fair number of problems consider bits as bits, and not as numbers. One common one is bitmap graphics, especially the case where pixels are either on or off, white or black. You can address a pixel by the location of a byte or larger wo

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 28 Days 2 Hours ago by: jfh

I would welcome weak interfaces - they would make it easier to write programs to run with both gfortran which has 4 real kinds (precisions 6,15,18,33) in my system and ifort which has 3 (omitting 18).

Applications of bit manipulation functions in Fortran

comp.lang.fortran

Posted: 28 Days 5 Hours ago by: Beliavsky

The BTEST intrinsic function can be used to extract bits from the representation of an integer. It's useful to be able to store 32 booleans in an int32. What are some applications of the Fortran bit manipulation intrinsic functions, discus

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 28 Days 13 Hours ago by: gah4

(snip) Could be nice for all declarations. If I dimension an array twice, to the same dimension, ignore the second one. Most languages don't do that. C #include files often include a test and #ifdef to avoid the problem of declaring

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 28 Days 15 Hours ago by: Thomas Koenig

Here's what I came up with. I finally got around to setting size of int and long as preprocessor variables, -DSIZEOF_INT=4 -DSIZEOF_LONG=8 in a to-be-preprocessed Fortran file, and then use interface operator(+) module procedure

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 28 Days 15 Hours ago by: Ev. Drikos

.... It's the silent generation of wrong code that afraid me in a recent discussion about some user defined interfaces: https://groups.google.com/g/comp.lang.fortran/c/Akmj_d0opWE/m/ozWk72OJAgAJ

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 28 Days 16 Hours ago by: Thomas Koenig

Not possible in this case - the type is fixed (and for good reason, too).

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 28 Days 17 Hours ago by: FortranFan

Clearly code that uses facilities with standard C and also follows *good practices* will face little to no issues of the kind mentioned in the original post when interoperating with Fortran, here it is assumed the types involved are inte

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 28 Days 18 Hours ago by: Thomas Koenig

I have already explained that size_t is not good enough for what I have in mind. Sure. And if c_int happens to be the same kind as that of the default integer, then the code will work. If not, it will fail. There are two possibilit

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 28 Days 19 Hours ago by: FortranFan

See the fully worked out example upthread with c_size_t: https://groups.google.com/g/comp.lang.fortran/c/JgeUMfTHIuA/m/GFMazEQUEgAJ Note again in the Fortran standard, no interoperability is indicated of a Fortran "standard integer" with

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 28 Days 23 Hours ago by: Thomas Koenig

This would fail for the code (on the Fortran side) of a = b + 1 when c_size_t does not match Fortran's standard integer.

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 29 Days 1 Hour ago by: Thomas Koenig

I can then chose a module procedure, but it would silently generate wrong code if "long" is 32 bits and I am trying to pass a 64-bit integer from Fortran. As for a runtime check... either such a program should compile, or not.

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 29 Days 3 Hours ago by: David Ruben

I haven't been following this discussion all that closely, but I think that FortranFan had the right idea. The compiler doesn't choose a particular module procedure on the basis of the text strings "c_int" or "c_long". It chooses on the

Re: Integer overflow (thread)

comp.lang.fortran

Posted: 29 Days 13 Hours ago by: gah4

(snip) C allows for two's complement, ones' complement, or sign magnitude for signed integers, but only one representation for unsigned. Last I knew, Unisys was still selling ones' complement hardware, along with a C compiler. The C

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 29 Days 13 Hours ago by: FortranFan

Another thing I would try is c_size_t instead of c_int / c_long kinds in the Fortran INTERFACE construct and with a single function definition in that construct: module m use, intrinsic :: iso_c_binding, only : c_int, c_size_t typ

Re: Integer overflow (thread)

comp.lang.fortran

Posted: 29 Days 13 Hours ago by: Ron Shepard

Here is the wikipedia article about twos-complement arithmetic. https://en.wikipedia.org/wiki/Two%27s_complement As you can see there, the term "twos-complement" can be regarded both as an operation applied to a string of bits and

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 29 Days 14 Hours ago by: Thomas Koenig

Unfortunately, this does not work for what I had in mind (which I also explained upthread). The problem I am trying to address is on the Fortran side, in the interface block, when c_int == c_long. So, I guess there is no way to do what

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 29 Days 14 Hours ago by: FortranFan

Perhaps you will see my minimal but fully working example upthread: https://groups.google.com/g/comp.lang.fortran/c/JgeUMfTHIuA/m/so1jiycPEgAJ Give it a try on 64-bit Linux where, if I understood correctly, GCC uses 64-bit integer for lo

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 29 Days 14 Hours ago by: Thomas Koenig

Unfortunately, this does not work for defining an interface for operator(+).

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 29 Days 14 Hours ago by: Thomas Koenig

The prototype is (paraphrased) foo_add (foo_type *, foo_type * const, long); where foo_add is from an external library I have no control over. On the Fortran side, I would like to do type(foo_type) :: a, b b = a + 1 where additio

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 29 Days 15 Hours ago by: FortranFan

Shown below is what I mean: @Thomas Koening and anyone else interested can try out to see my recommendation: 1. C code, file c.c #include <stdio.h> typedef struct t { int x; } T; T foo(T*, int*); T bar(T*, long*); T foo(T* a, int* b)

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 29 Days 15 Hours ago by: FortranFan

It will be better to illustrate the approach I recommend to teams I work with in industry with a fair bit of success using an minimal example. Toward this, it will be useful to know about these existing C functions. Since C does NOT pe

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 29 Days 15 Hours ago by: Ron Shepard

Can you do something like if ( c_int32_t .eq. c_long ) then ... elseif ( c_int64_t .eq. c_long ) then ... else ... to straighten out the possibilities? The if statements themselves will probably be eval

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 29 Days 15 Hours ago by: Thomas Koenig

Re: Operator interface with integer(c_int) and integer(c_long) (thread)

comp.lang.fortran

Posted: 29 Days 15 Hours ago by: FortranFan

The standard intrinsic module "ISO_C_BINDING" also includes the named constants of c_int32_t and c_int64_t (and also c_int16_t and c_int8_t). Toward generic interfaces these named constants are to be preferred over c_int, c_long, etc. p

Operator interface with integer(c_int) and integer(c_long)

comp.lang.fortran

Posted: 29 Days 16 Hours ago by: Thomas Koenig

The following is slightly simplified. I have a C functions I want to interface to, which takes a long argument. I also want to have a wrapper function in Fortran around it, and operator overloading for it which works for as many kinds as

Re: Integer overflow (thread)

comp.lang.fortran

Posted: 29 Days 18 Hours ago by: Robin Vowels

.. .. You are mistaken. It is only negative values that are represented in twos complement form. .. .. .. You are still mistaken. A twos complement operation is used to negate a value. When the argument represents a positive integer, th

132 recent articles found.

rocksolid light 0.7.2
clearneti2ptor