From Newsgroup: comp.lang.fortran

On Tue, 3 Feb 2026 10:33:55 +0100, Fred. Zwarts wrote:

What I meant is that the calender should be added in the output.

The usual assumption (at least internationally) is proleptic
Gregorian, unless otherwise stated.

Also, this:

ldo@theon:~> TZ=UTC date -d 01-jan-0
Sat 01 Jan 0000 00:00:00 UTC
ldo@theon:~> TZ=UTC date -d 01-jan-0 +%s
-62167219200
ldo@theon:~> TZ=UTC date -d '@-62167219100'
Sat 01 Jan 0000 00:01:40 UTC
ldo@theon:~> TZ=UTC date -d '@-62167219300'
Fri 31 Dec -001 23:58:20 UTC
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Thu, 5 Feb 2026 15:47:11 -0600, Lynn McGuire wrote:

You are really telling me to rip out a working feature in my
software and spend months replacing it ???

The question was whether you needed to write the whole thing in C or
C++ to get the best performance. You do not.

Typically, code performance follows a sort of 90/10 rule: 90% of the
time will be spent in 10% of the code (or something skewed along those
lines, maybe even 95%/5% or 99%/1%). It is a waste of time to optimize
100% of the code for speed; you will get most gain for least pain from concentrating on that critical 10% or 5% or 1%.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

On 2/4/2026 9:44 AM, Scott Lurndal wrote:

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:

On Tue, 3 Feb 2026 17:28:35 -0600, Lynn McGuire wrote:

I am swinging huge datasets for simulation models from 1 MB to 1,000 MB. >>>> Nothing besides C++ has the oomph and speed to make this happen.

Lots of Pythoneers are doing data science at this sort of scale.

Even "R" can handle datasets larger than that.

We are not 64 bit yet. 1,000 MB is about the largest dataset we can
swing in Win32 due to our inefficiency in managing memory. We do
compress all strings above 1,000 bytes which means that our datasets are actually 2X to 3X bigger than the binary version of the dataset.

Wow, this must hurt, both for speed and complexity...

Depending on what your database is like, it might make sense to
convert into a suitable binary format, map it into your address
space (I am fairly sure that Windows can do memory-mapped I/O,
although I am *not* a Windows person, at least not as far as
programming is concerned) and then immediately do things with it.
You could then reduce your startup time by only "recompiling"
from the text representation when needed.

If this makes sense to your application or not, I don't know (of course) because I do not know what exactly your database does and does not do.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

Lawrence DrCOOliveiro <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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On 11/02/2026 06:57, Lawrence DrCOOliveiro 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.

ThatrCOs the way Open Source should be. Too often we see people
complaining that some app doesnrCOt 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.


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On 11/02/2026 06:54, Lawrence DrCOOliveiro 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.


--- Synchronet 3.21d-Linux NewsLink 1.2