From Newsgroup: comp.lang.c

On Fri, 27 Jun 2025 02:40:58 +0100, Richard Heathfield wrote:

On 27/06/2025 01:39, Lawrence D'Oliveiro wrote:

[...]if C is going to become more suitable for such high-
precision calculations, it might need to become more Python-like.

C is not in search of a reason to exist.

Not in traditional fixed-precision arithmetic, anyway -- at least after it fully embraced IEEE 754.

With higher-precision arithmetic, on the other hand, the traditional C paradigms may not be so suitable.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 15/07/2025 20:41, Lawrence D'Oliveiro wrote:

On Fri, 27 Jun 2025 02:40:58 +0100, Richard Heathfield wrote:

On 27/06/2025 01:39, Lawrence D'Oliveiro wrote:

[...]if C is going to become more suitable for such high-
precision calculations, it might need to become more Python-like.

C is not in search of a reason to exist.

Not in traditional fixed-precision arithmetic, anyway -- at least after it fully embraced IEEE 754.

With higher-precision arithmetic, on the other hand, the traditional C paradigms may not be so suitable.

If you want something else, you know where to find it. There is
no value in eroding the differences in all languages until only
one universal language emerges. Vivat differentia.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Wed, 16 Jul 2025 03:55:14 +0100, Richard Heathfield wrote:

On 15/07/2025 20:41, Lawrence D'Oliveiro wrote:

On Fri, 27 Jun 2025 02:40:58 +0100, Richard Heathfield wrote:

On 27/06/2025 01:39, Lawrence D'Oliveiro wrote:

[...]if C is going to become more suitable for such high-
precision calculations, it might need to become more Python-like.

C is not in search of a reason to exist.

Not in traditional fixed-precision arithmetic, anyway -- at least
after it fully embraced IEEE 754.

With higher-precision arithmetic, on the other hand, the
traditional C paradigms may not be so suitable.

If you want something else, you know where to find it. There is no
value in eroding the differences in all languages until only one
universal language emerges. Vivat differentia.

You sound as though you donrCOt want languages copying ideas from each
other.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 20/07/2025 01:16, Lawrence D'Oliveiro wrote:

On Wed, 16 Jul 2025 03:55:14 +0100, Richard Heathfield wrote:

On 15/07/2025 20:41, Lawrence D'Oliveiro wrote:

On Fri, 27 Jun 2025 02:40:58 +0100, Richard Heathfield wrote:

On 27/06/2025 01:39, Lawrence D'Oliveiro wrote:

[...]if C is going to become more suitable for such high-
precision calculations, it might need to become more Python-like.

C is not in search of a reason to exist.

Not in traditional fixed-precision arithmetic, anyway -- at least
after it fully embraced IEEE 754.

With higher-precision arithmetic, on the other hand, the
traditional C paradigms may not be so suitable.

If you want something else, you know where to find it. There is no
value in eroding the differences in all languages until only one
universal language emerges. Vivat differentia.

You sound as though you donrCOt want languages copying ideas from each
other.

Good, because I don't.

There's nothing wrong with new languages pinching ideas from old
languages - that's creativity and progress, especially when those
ideas are combined in new and interesting ways, and you can keep
on adding those ideas right up until your second reference
implementation goes public.

But going the other way turns a programming language into a
constantly moving target that it's impossible for more than a
handful of people to master - the handful in question being those
who decide what's in and what's out. This is bad for programmers'
expertise and bad for the industry.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 20.07.2025 08:58, Richard Heathfield wrote:

On 20/07/2025 01:16, Lawrence D'Oliveiro wrote:

On Wed, 16 Jul 2025 03:55:14 +0100, Richard Heathfield wrote:

[...]

You sound as though you donrCOt want languages copying ideas from each
other.

Hmm.. - this is an interesting thought. In an instant reflex I'd agree
with the advantage of picking "good" ideas from other languages. Upon reconsideration I have some doubts though; not only because some ideas
may fit in a language but others not really. To me many language give
the impression to have been patched-up instead of being well designed
from scratch. Either evolving by featuritis of "good ideas" or needing
changes to address inherent shortcomings of the basic language design.

[...]
There's nothing wrong with new languages pinching ideas from old
languages - that's creativity and progress, especially when those ideas
are combined in new and interesting ways, and you can keep on adding
those ideas right up until your second reference implementation goes
public.

But going the other way turns a programming language into a constantly
moving target that it's impossible for more than a handful of people to master - the handful in question being those who decide what's in and
what's out. This is bad for programmers' expertise and bad for the
industry.

Incompatibilities or change of semantics between versions would be bad!
For coherently designed and consistently enhanced languages that might
be less a problem. Having a well designed "Common Language Base" would
not impose too much effort to master [coherently matching] extensions.
Of course here we are speaking (only) about "C", specifically, so the
basic language preconditions are set (and its decades long evolution
path clearly visible).

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 29 Jun 2025 09:23:01 -0400, James Kuyper wrote:

It's somewhat more complicated than that. IEEE-784 is a
radix-independent standard, otherwise equivalent to IEEE-754.

Did you mean IEEE-854?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

(Sorry for delay, this got stuck)

On Mon, 14 Apr 2025 15:56:56 -0700, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Huge numbers of systems already use the perfectly reasonable POSIX
epoch, 1970-01-01 00:00:00 UTC. I can think of no good reason to
standardize anything else.

NNTP uses unsigned-32bit seconds from 1900-01-01 'UTC' (really a blend
of GMT then TAI aligned like UTC but not actually representing the
leapseconds; yes that's a bodge). It will wrap in 2036, about 2 years
before progams and data (still) using signed-32bit seconds from 1970
more famously will.

Astronomers count Julian Day Numbers from 4713 BC proleptic Julian.
This was chosen to ensure that all astronomical observations or events
in recorded history have positive dates.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-07-28 20:56, Lawrence D'Oliveiro wrote:

On Sun, 29 Jun 2025 09:23:01 -0400, James Kuyper wrote:

It's somewhat more complicated than that. IEEE-784 is a
radix-independent standard, otherwise equivalent to IEEE-754.

Did you mean IEEE-854?

Yes - Sorry for the confusion.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-07-29 10:49, dave_thompson_2@comcast.net wrote:
...

Astronomers count Julian Day Numbers from 4713 BC proleptic Julian.
This was chosen to ensure that all astronomical observations or events
in recorded history have positive dates.

While that is one benefit of using that date, it was in fact chosen
because several different astronomical cycles associated with common
ancient calendar systems all align together at that time. That makes
conversion between Julian Days and any of those calendars simpler.
--- Synchronet 3.21a-Linux NewsLink 1.2