Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #123321 > unrolled thread

"Internationalis(z)ing Code - Computerphile"

Back to article view | Back to comp.lang.c++

Contents

  "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-01-23 21:35 -0600
    Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-24 04:46 +0000
      Re: "Internationalis(z)ing Code - Computerphile" Gary Scott <garylscott@sbcglobal.net> - 2026-01-24 10:11 -0600
    Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-01-25 17:13 +0000
      Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-01-25 15:21 -0600
        Re: "Internationalis(z)ing Code - Computerphile" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-01-26 01:00 +0100
          Re: "Internationalis(z)ing Code - Computerphile" scott@slp53.sl.home (Scott Lurndal) - 2026-01-26 15:04 +0000
        Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-26 01:42 +0000
          Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-01-26 00:45 -0600
            Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-01-26 14:17 +0200
              Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-01-26 16:50 -0600
          Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-01-26 09:07 +0100
            Re: "Internationalis(z)ing Code - Computerphile" Paavo Helde <eesnimi@osa.pri.ee> - 2026-01-30 14:56 +0200
              Re: "Internationalis(z)ing Code - Computerphile" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-01-30 14:37 +0100
            Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-01-30 20:28 +0000
              Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-01-31 12:50 +0100
                Re: "Internationalis(z)ing Code - Computerphile" G <g@nowhere.invalid> - 2026-01-31 18:50 +0000
                  Re: "Internationalis(z)ing Code - Computerphile" Gary Scott <garylscott@sbcglobal.net> - 2026-01-31 16:10 -0600
                    Re: "Internationalis(z)ing Code - Computerphile" ImperiusDamian <dgwrightauthor@gmail.com> - 2026-01-31 21:08 -0500
                    Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-01 09:06 +0000
                      Re: "Internationalis(z)ing Code - Computerphile" "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2026-02-02 11:18 +0100
                        Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-02 21:23 +0000
                          Re: "Internationalis(z)ing Code - Computerphile" "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2026-02-03 10:33 +0100
                            Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-03 21:29 +0000
                    Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-01 11:18 +0100
                      Re: "Internationalis(z)ing Code - Computerphile" Gary Scott <garylscott@sbcglobal.net> - 2026-02-01 08:28 -0600
                Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-01 09:42 +0000
                  Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-01 11:35 +0100
                    Re: "Internationalis(z)ing Code - Computerphile" James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-01 12:21 -0500
                      Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-01 23:01 +0100
                        Re: "Internationalis(z)ing Code - Computerphile" James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-01 19:11 -0500
                          Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-02 04:31 +0000
                          Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-02 11:27 +0100
                            Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-02 12:49 +0200
                              Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-02 13:14 +0100
                                Re: "Internationalis(z)ing Code - Computerphile" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-02 16:07 +0100
                            Re: "Internationalis(z)ing Code - Computerphile" James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-02 09:36 -0500
                              Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-02 16:01 +0100
                                Re: "Internationalis(z)ing Code - Computerphile" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-02 16:19 +0100
        Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-01-26 22:47 +0000
          Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-01-26 16:51 -0600
          Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-27 05:17 +0000
            Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-01-27 06:45 +0000
              Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-01-27 01:46 -0600
                Re: "Internationalis(z)ing Code - Computerphile" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-27 00:14 -0800
                  Re: "Internationalis(z)ing Code - Computerphile" scott@slp53.sl.home (Scott Lurndal) - 2026-01-27 15:22 +0000
                    Re: "Internationalis(z)ing Code - Computerphile" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-27 12:33 -0800
                Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-01-27 11:04 +0200
                  Re: "Internationalis(z)ing Code - Computerphile" Gary Scott <garylscott@sbcglobal.net> - 2026-01-27 08:35 -0600
            Re: "Internationalis(z)ing Code - Computerphile" scott@slp53.sl.home (Scott Lurndal) - 2026-01-27 15:21 +0000
    Re: "Internationalis(z)ing Code - Computerphile" Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-31 02:06 +0000
    Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-02 21:02 +0100
      Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-02 21:13 +0100
      Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-02 21:25 +0000
      Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-03 10:54 +0200
        Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-03 10:44 +0100
          Re: "Internationalis(z)ing Code - Computerphile" Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-03 09:47 -0500
            Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-03 16:02 +0100
              Re: "Internationalis(z)ing Code - Computerphile" Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-04 08:45 -0500
          Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-03 21:32 +0000
            Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-03 22:56 +0100
              Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-04 00:15 +0000
                Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-04 09:37 +0100
        Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-03 17:28 -0600
          Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-04 00:14 +0000
            Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-03 20:17 -0600
              Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-04 04:57 +0000
                Re: "Internationalis(z)ing Code - Computerphile" Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-04 08:54 -0500
                  Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-04 16:43 -0600
                    Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 09:09 +0000
                      Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-05 15:47 -0600
                        Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 22:35 +0000
            Re: "Internationalis(z)ing Code - Computerphile" scott@slp53.sl.home (Scott Lurndal) - 2026-02-04 15:44 +0000
              Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-04 16:53 -0600
                Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 09:10 +0000
                  Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-05 12:10 +0200
                Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-07 09:23 +0000
                  Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-09 15:25 -0600
          Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-04 14:24 +0200
            Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-04 16:57 +0100
            Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-04 17:16 +0100
              Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-04 16:57 -0600
                Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 09:11 +0000
            Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-04 16:55 -0600
              Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-05 12:24 +0200
          Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-04 19:20 +0000
            Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-04 17:07 -0600
              Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-05 07:23 +0000
                Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 09:14 +0000
                  Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-05 16:01 -0600
                    Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 22:30 +0000
                      Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-05 20:22 -0600
                        Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-06 04:50 +0000
                          Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-05 23:52 -0600
                        Re: "Internationalis(z)ing Code - Computerphile" Harold Stevens <wookie@aspen.localdomain> - 2026-02-06 04:24 -0600
                Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-05 12:02 +0200
                  Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-05 18:38 +0000
                    Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-13 17:21 -0600
                Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-05 11:13 +0100
                Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-05 15:58 -0600
                  Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-07 19:15 +0000
                    Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-07 20:34 +0000
                      Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-08 08:58 +0000
                        Re: "Internationalis(z)ing Code - Computerphile" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-08 04:07 -0800
                          Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-08 15:39 +0200
                        Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-08 23:35 +0000
                      Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-09 15:33 -0600
                        Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-10 20:55 +0000
                          Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-10 18:57 -0600
                            Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-11 05:57 +0000
                              Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-11 14:32 +0100
                                Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-11 20:46 +0000
                    Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-09 15:29 -0600
                      Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-10 06:10 +0000
                    Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-09 15:32 -0600
                      Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-10 06:07 +0000
                      Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-10 20:17 +0000
                        Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-10 20:07 -0600
                          Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-11 05:54 +0000
                            Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-11 14:42 +0100
      Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-03 17:32 -0600

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#123454

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

> The only conversion problem that I am worried about is that I have 
> Fortran 66 interpreter built into my software for my customers to write 
> custom calculations embedded in their datasets attached to any type of 
> object.  I will need to write a converter for the F66 format statements 
> to C formats.

I haven't used your software, but I have used Aspen (only very
little) and found it horrible.  How it is possible for a solution to
diverge when the starting solution is already converged is beyond
me, all explanations that occur to me could be considered insults,
so I am not toing to go into that.  That was worst; I hope your
software does better.

But the F66 interpreter in Aspen was a close second; IIRC, it was
not even possible to declare variables. Argh.

>Not a big deal though.  Some of my customers have over 
> 10,000 lines of F66 code in their datasets.  And yes, the F66 parser is 
> written in F77 code, we wrote that back in 1982.

If you used Fortran 77's runtime including internal formats,
that must have made your job a lot easier.  Converting this to
C formats... well, that is tricky.  Consider

      REAL A
      DIMENSION A(10)
      READ (10,'(4F12.5)') A

It is not possible to translate this into C printf formats
(which you seem to imply above), you need logic to handle
the format reversion.  Also, the handling of field overflow
(C just extends things, Fortran inserts asterisks) is tricky.

Why not just use the f2c runtime?
-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#123455

On Sat, 7 Feb 2026 19:15:07 -0000 (UTC), Thomas Koenig wrote:

> I haven't used your software, but I have used Aspen (only very
> little) and found it horrible. How it is possible for a solution to
> diverge when the starting solution is already converged is beyond
> me, all explanations that occur to me could be considered insults,
> so I am not toing to go into that. That was worst; I hope your
> software does better.
>
> But the F66 interpreter in Aspen was a close second; IIRC, it was
> not even possible to declare variables. Argh.

How do these tools compare to something like
<https://nwchemgit.github.io>?

[toc] | [prev] | [next] | [standalone]

#123456

Lawrence D’Oliveiro <ldo@nz.invalid> schrieb:
> On Sat, 7 Feb 2026 19:15:07 -0000 (UTC), Thomas Koenig wrote:
>
>> I haven't used your software, but I have used Aspen (only very
>> little) and found it horrible. How it is possible for a solution to
>> diverge when the starting solution is already converged is beyond
>> me, all explanations that occur to me could be considered insults,
>> so I am not toing to go into that. That was worst; I hope your
>> software does better.
>>
>> But the F66 interpreter in Aspen was a close second; IIRC, it was
>> not even possible to declare variables. Argh.
>
> How do these tools compare to something like
><https://nwchemgit.github.io>?

How does a hacksaw compare to a screwdriver?

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#123457

Thomas Koenig <tkoenig@netcologne.de> writes:
> Lawrence D’Oliveiro <ldo@nz.invalid> schrieb:
>> On Sat, 7 Feb 2026 19:15:07 -0000 (UTC), Thomas Koenig wrote:
>>> I haven't used your software, but I have used Aspen (only very
>>> little) and found it horrible. How it is possible for a solution to
>>> diverge when the starting solution is already converged is beyond
>>> me, all explanations that occur to me could be considered insults,
>>> so I am not toing to go into that. That was worst; I hope your
>>> software does better.
>>>
>>> But the F66 interpreter in Aspen was a close second; IIRC, it was
>>> not even possible to declare variables. Argh.
>>
>> How do these tools compare to something like
>><https://nwchemgit.github.io>?
>
> How does a hacksaw compare to a screwdriver?

A screwdriver is vodka and orange juice.  A hacksaw has orange soda
as well.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#123458

On Sun, 08 Feb 2026 04:07:44 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> Thomas Koenig <tkoenig@netcologne.de> writes:
> > Lawrence D’Oliveiro <ldo@nz.invalid> schrieb:  
> >> On Sat, 7 Feb 2026 19:15:07 -0000 (UTC), Thomas Koenig wrote:  
> >>> I haven't used your software, but I have used Aspen (only very
> >>> little) and found it horrible. How it is possible for a solution
> >>> to diverge when the starting solution is already converged is
> >>> beyond me, all explanations that occur to me could be considered
> >>> insults, so I am not toing to go into that. That was worst; I
> >>> hope your software does better.
> >>>
> >>> But the F66 interpreter in Aspen was a close second; IIRC, it was
> >>> not even possible to declare variables. Argh.  
> >>
> >> How do these tools compare to something like
> >><https://nwchemgit.github.io>?  
> >
> > How does a hacksaw compare to a screwdriver?  
> 
> A screwdriver is vodka and orange juice.  A hacksaw has orange soda
> as well.
> 

Use of orange juice in hacksaw is disputable.

[toc] | [prev] | [next] | [standalone]

#123460

On Sun, 8 Feb 2026 08:58:37 -0000 (UTC), Thomas Koenig wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> schrieb:
>>
>> On Sat, 7 Feb 2026 19:15:07 -0000 (UTC), Thomas Koenig wrote:
>>
>>> I haven't used your software, but I have used Aspen (only very
>>> little) and found it horrible. How it is possible for a solution
>>> to diverge when the starting solution is already converged is
>>> beyond me, all explanations that occur to me could be considered
>>> insults, so I am not toing to go into that. That was worst; I hope
>>> your software does better.
>>>
>>> But the F66 interpreter in Aspen was a close second; IIRC, it was
>>> not even possible to declare variables. Argh.
>>
>> How do these tools compare to something like
>><https://nwchemgit.github.io>?
>
> How does a hacksaw compare to a screwdriver?

So you’re talking more chemical cutting tools rather than ones for
chemical assembly?

[toc] | [prev] | [next] | [standalone]

#123465

On 2/7/2026 2:34 PM, Lawrence D’Oliveiro wrote:
> On Sat, 7 Feb 2026 19:15:07 -0000 (UTC), Thomas Koenig wrote:
> 
>> I haven't used your software, but I have used Aspen (only very
>> little) and found it horrible. How it is possible for a solution to
>> diverge when the starting solution is already converged is beyond
>> me, all explanations that occur to me could be considered insults,
>> so I am not toing to go into that. That was worst; I hope your
>> software does better.
>>
>> But the F66 interpreter in Aspen was a close second; IIRC, it was
>> not even possible to declare variables. Argh.
> 
> How do these tools compare to something like
> <https://nwchemgit.github.io>?

That is a different world.  This is me.
    https://www.winsim.com/design.html

Lynn

[toc] | [prev] | [next] | [standalone]

#123470

On Mon, 9 Feb 2026 15:33:12 -0600, Lynn McGuire wrote:

> On 2/7/2026 2:34 PM, Lawrence D’Oliveiro wrote:
>>
>> How do these tools compare to something like
>> <https://nwchemgit.github.io>?
>
> That is a different world.  This is me.
>     https://www.winsim.com/design.html

I noticed that it says “Microsoft® Windows® has become the standard
for desktop graphical computing”, and it seems like the text hasn’t
been updated since about October 2014. I would say that assertion is
getting a bit long in the tooth, wouldn’t you agree?

I had a look around, and this popped up <https://dwsim.org/>. It
certainly seems to have better cross-platform support.

Also I see you’re listed here
<https://en.wikipedia.org/wiki/List_of_chemical_process_simulators>,
along with a bunch of other alternatives. And here
<https://www.simulatelive.com/product-reviews/simulation/review-of-open-source-process-simulators>
is a review of various open-source products (including DWSIM), which
concludes that they lack nothing compared to the proprietary ones.

[toc] | [prev] | [next] | [standalone]

#123471

On 2/10/2026 2:55 PM, Lawrence D’Oliveiro wrote:
> On Mon, 9 Feb 2026 15:33:12 -0600, Lynn McGuire wrote:
> 
>> On 2/7/2026 2:34 PM, Lawrence D’Oliveiro wrote:
>>>
>>> How do these tools compare to something like
>>> <https://nwchemgit.github.io>?
>>
>> That is a different world.  This is me.
>>      https://www.winsim.com/design.html
> 
> I noticed that it says “Microsoft® Windows® has become the standard
> for desktop graphical computing”, and it seems like the text hasn’t
> been updated since about October 2014. I would say that assertion is
> getting a bit long in the tooth, wouldn’t you agree?
> 
> I had a look around, and this popped up <https://dwsim.org/>. It
> certainly seems to have better cross-platform support.

It is very hard to compete with the price of free.

> Also I see you’re listed here
> <https://en.wikipedia.org/wiki/List_of_chemical_process_simulators>,
> along with a bunch of other alternatives. And here
> <https://www.simulatelive.com/product-reviews/simulation/review-of-open-source-process-simulators>
> is a review of various open-source products (including DWSIM), which
> concludes that they lack nothing compared to the proprietary ones.

We have quite a few features that they do not have but that is for 
another day.  DWSIM has a very loyal following and many of them 
participate in the programming of new features.

Lynn

[toc] | [prev] | [next] | [standalone]

#123474

On Tue, 10 Feb 2026 18:57:21 -0600, Lynn McGuire wrote:

> It is very hard to compete with the price of free.

Tell that to the sellers of bottled water. ;)

> DWSIM has a very loyal following and many of them participate in the
> programming of new features.

That’s the way Open Source should be. Too often we see people
complaining that some app doesn’t have features that they desperately
need, so they have to go back to paid proprietary software. Completely
overlooking the fact that, if they put some of that money they would
pay the proprietary software vendor towards sponsoring the development
of some of the features they need, the result would benefit everybody.

[toc] | [prev] | [next] | [standalone]

#123475

On 11/02/2026 06:57, Lawrence D’Oliveiro wrote:
> On Tue, 10 Feb 2026 18:57:21 -0600, Lynn McGuire wrote:
> 
>> It is very hard to compete with the price of free.
> 
> Tell that to the sellers of bottled water. ;)
> 
>> DWSIM has a very loyal following and many of them participate in the
>> programming of new features.
> 
> That’s the way Open Source should be. Too often we see people
> complaining that some app doesn’t have features that they desperately
> need, so they have to go back to paid proprietary software. Completely
> overlooking the fact that, if they put some of that money they would
> pay the proprietary software vendor towards sponsoring the development
> of some of the features they need, the result would benefit everybody.

But would that be an advantage to that user?  Benefiting everybody means 
benefiting your competition as well.  I have no idea how competitive or 
cooperative the users of chemical simulators is, but it is not always 
the case that "benefits everyone" is a win for the person or company 
stumping up the cash.  In many markets, there is room for pure 
closed-source commercial software, pure free and open source software, 
and many combinations in between.  Simplistic "everybody wins" arguments 
are rarely applicable.

[toc] | [prev] | [next] | [standalone]

#123477

David Brown <david.brown@hesbynett.no> schrieb:
> On 11/02/2026 06:57, Lawrence D’Oliveiro wrote:
>> On Tue, 10 Feb 2026 18:57:21 -0600, Lynn McGuire wrote:
>> 
>>> It is very hard to compete with the price of free.
>> 
>> Tell that to the sellers of bottled water. ;)
>> 
>>> DWSIM has a very loyal following and many of them participate in the
>>> programming of new features.
>> 
>> That’s the way Open Source should be. Too often we see people
>> complaining that some app doesn’t have features that they desperately
>> need, so they have to go back to paid proprietary software. Completely
>> overlooking the fact that, if they put some of that money they would
>> pay the proprietary software vendor towards sponsoring the development
>> of some of the features they need, the result would benefit everybody.
>
> But would that be an advantage to that user?  Benefiting everybody means 
> benefiting your competition as well.  I have no idea how competitive or 
> cooperative the users of chemical simulators is, but it is not always 
> the case that "benefits everyone" is a win for the person or company 
> stumping up the cash.

The know-how is usually in the models, not in the tools.  When
running chemical simulators, or more generally scientific/technical
software, people are usually glad if they work for them at all.

I have to admit that there I do not work with chemical
simulation software.  There is an equivalent that I am more
familiar with.  https://openfoam.org/ , an open source CFD
software.  (There are actually two versions of OpenFOAM, but
that is another issue).  This software is developed by a few core
people and supported by a consortium from the chemical industry,
https://openfoam.org/chemical-process-engineering/ .  Each company
pays a certain amount and can influence the work done on the
program proportional to the money they contribute.

OpenFOAM is a bit special because of it is script-based and has
a fairly steep learning curve.  Universities use it a lot because
it is free of cost to them (unlike commercial programs like Ansys
Fluent), and somebody doing a PhD also has the time to learn it,
unlike in industry.  With the licensing policies of companies like
Ansys, which make software for universities very expensive, they
are disconnecting themselves from their own potential user base
of the future.


> kIn many markets, there is room for pure 
> closed-source commercial software, pure free and open source software, 
> and many combinations in between.  Simplistic "everybody wins" arguments 
> are rarely applicable.

Very much so.

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#123463

On 2/7/2026 1:15 PM, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> 
>> The only conversion problem that I am worried about is that I have
>> Fortran 66 interpreter built into my software for my customers to write
>> custom calculations embedded in their datasets attached to any type of
>> object.  I will need to write a converter for the F66 format statements
>> to C formats.
> 
> I haven't used your software, but I have used Aspen (only very
> little) and found it horrible.  How it is possible for a solution to
> diverge when the starting solution is already converged is beyond
> me, all explanations that occur to me could be considered insults,
> so I am not toing to go into that.  That was worst; I hope your
> software does better.
> 
> But the F66 interpreter in Aspen was a close second; IIRC, it was
> not even possible to declare variables. Argh.
> 
>> Not a big deal though.  Some of my customers have over
>> 10,000 lines of F66 code in their datasets.  And yes, the F66 parser is
>> written in F77 code, we wrote that back in 1982.
> 
> If you used Fortran 77's runtime including internal formats,
> that must have made your job a lot easier.  Converting this to
> C formats... well, that is tricky.  Consider
> 
>        REAL A
>        DIMENSION A(10)
>        READ (10,'(4F12.5)') A
> 
> It is not possible to translate this into C printf formats
> (which you seem to imply above), you need logic to handle
> the format reversion.  Also, the handling of field overflow
> (C just extends things, Fortran inserts asterisks) is tricky.
> 
> Why not just use the f2c runtime?

We force all loops in simulations to go through a minimum of three 
iterations.  What appears to be converged may not be converged in reality.

The f2c runtime is an undocumented mishmash of a nightmare given that 
they started with the unix f77 compiler.  I would prefer not to use it 
but, I could be forced into it from a time aspect.

Lynn

[toc] | [prev] | [next] | [standalone]

#123468

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> On 2/7/2026 1:15 PM, Thomas Koenig wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

>> I haven't used your software, but I have used Aspen (only very
>> little) and found it horrible.  How it is possible for a solution to
>> diverge when the starting solution is already converged is beyond
>> me, all explanations that occur to me could be considered insults,
>> so I am not toing to go into that.  That was worst; I hope your
>> software does better.

[...]

> We force all loops in simulations to go through a minimum of three 
> iterations.  What appears to be converged may not be converged in reality.

In this particular case, it is a converged solution from a prevous
iteration, which then promptly diverges, you have to perturb it to get
it to converge again.  How Aspen gets away with this, I don't know.
-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#123464

On 2/7/2026 1:15 PM, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> 
>> The only conversion problem that I am worried about is that I have
>> Fortran 66 interpreter built into my software for my customers to write
>> custom calculations embedded in their datasets attached to any type of
>> object.  I will need to write a converter for the F66 format statements
>> to C formats.
> 
> I haven't used your software, but I have used Aspen (only very
> little) and found it horrible.  How it is possible for a solution to
> diverge when the starting solution is already converged is beyond
> me, all explanations that occur to me could be considered insults,
> so I am not toing to go into that.  That was worst; I hope your
> software does better.
> 
> But the F66 interpreter in Aspen was a close second; IIRC, it was
> not even possible to declare variables. Argh.
...

Huh, that does not make sense.  One needs variables to decomplicate 
complex calculations.  We even support common blocks in our F66 
interpreter user code so that variables can be stored from one iteration 
to the next.

Lynn

[toc] | [prev] | [next] | [standalone]

#123467

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> On 2/7/2026 1:15 PM, Thomas Koenig wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>> 
>>> The only conversion problem that I am worried about is that I have
>>> Fortran 66 interpreter built into my software for my customers to write
>>> custom calculations embedded in their datasets attached to any type of
>>> object.  I will need to write a converter for the F66 format statements
>>> to C formats.
>> 
>> I haven't used your software, but I have used Aspen (only very
>> little) and found it horrible.  How it is possible for a solution to
>> diverge when the starting solution is already converged is beyond
>> me, all explanations that occur to me could be considered insults,
>> so I am not toing to go into that.  That was worst; I hope your
>> software does better.
>> 
>> But the F66 interpreter in Aspen was a close second; IIRC, it was
>> not even possible to declare variables. Argh.
> ...
>
> Huh, that does not make sense.  One needs variables to decomplicate 
> complex calculations.  We even support common blocks in our F66 
> interpreter user code so that variables can be stored from one iteration 
> to the next.

You could use them via implicit typing, but you could not declare
them.  So, REAL A did not work (DIMENSION probably did).

Actually, the way I used them was mainly for a colleague who had
zero Fortran experience, and I got a few needed routines running.
More than 10 years ago)

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#123469

On Mon, 9 Feb 2026 15:32:10 -0600, Lynn McGuire wrote:

> We even support common blocks in our F66 interpreter user code so
> that variables can be stored from one iteration to the next.

I expect your customers would appreciate having an extension language
that works at a somewhat higher level than Fortran -- and an
antediluvian version of Fortran, at that.

[toc] | [prev] | [next] | [standalone]

#123472

On 2/10/2026 2:17 PM, Lawrence D’Oliveiro wrote:
> On Mon, 9 Feb 2026 15:32:10 -0600, Lynn McGuire wrote:
> 
>> We even support common blocks in our F66 interpreter user code so
>> that variables can be stored from one iteration to the next.
> 
> I expect your customers would appreciate having an extension language
> that works at a somewhat higher level than Fortran -- and an
> antediluvian version of Fortran, at that.

an·te·di·lu·vi·an
/ˌan(t)ēdəˈlo͞ovēən,ˌan(t)ədīˈlo͞ovēən/
adjective
adjective: antediluvian
     of or belonging to the time before the biblical Flood.

One of my long term goals is to support a Basic interpreter in my 
calculation engine.  But, I have many long term goals.

Lynn

[toc] | [prev] | [next] | [standalone]

#123473

On Tue, 10 Feb 2026 20:07:37 -0600, Lynn McGuire wrote:

> One of my long term goals is to support a Basic interpreter in my 
> calculation engine.

Gosh. That would take you up to the Middle Ages.

[toc] | [prev] | [next] | [standalone]

#123476

On 11/02/2026 06:54, Lawrence D’Oliveiro wrote:
> On Tue, 10 Feb 2026 20:07:37 -0600, Lynn McGuire wrote:
> 
>> One of my long term goals is to support a Basic interpreter in my
>> calculation engine.
> 
> Gosh. That would take you up to the Middle Ages.

Why are you being so hard on the guy?  He started a thread that has had 
broad appeal and interest, and successfully pulled in participants from 
two language groups in an amicable discussion.  He has been nothing but 
open and honest, discussing his company's design choices and giving 
reasons for them (whether they are good technical reasons or not).

A Basic or Basic-like interpreter can be a very useful addition to large 
software.  It can make it easy to write small snippets or scripts for 
automation purposes, and can be learned quickly and easily even by those 
with no programming experience.  It's a language that has scaled from 
microcontrollers to mainframes.  There are plenty of alternatives for 
embedded languages in software, but let the guy who knows the program, 
the code, the development team, the company, its customers, and the 
software's market pick the best choice (or choices).  Stop 
second-guessing him just because you read a Wikipedia page.

[toc] | [prev] | [next] | [standalone]

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

Back to top | Article view | comp.lang.c++

csiph-web