On 9/24/2022 11:42 AM, Timothy Golden wrote:

> If we sit here and nod our heads
> while mathematicians claim that
> the continuum is found by dividing one integer
> by another integer and landing with a float
> then the game is given away.

That's not the continuum.
Floats are not real numbers, whatever you call them.
Floats are not points in the continuum.

The _continuum_ is what is needed in order for
a _continuous_ function to behave how we intend
it to behave, given what we mean by "continuous".

A _continuous_ function is:
if you give me a bound on variation in output,
I can give you some bound on variation in input
that will keep the output within your bound.
OR
_Continuous_ functions don't jump.
Where a function jumps,
where it's discontinuous,
a bound on output less than the jump cannot be
obeyed by any non-zero variation in input.

A continuous function is continuous at
every point: no jumps anywhere.

However,
some notions of "every point" do not have
enough points. Not having jumps _at those points_
is not enough.

For example,
we might declare the rationals to be _all the points_
The function f,
f(x) =
{ 0 x*x < 2
{ 1 2 < x*x

is continuous at all the (rational) points.
And yet it jumps!

There needs to be a point sqrt(2)
for f(x) to be continuous at.

More generally,
for any partition of the continuum into
_all one side_ and _all the other side_
there needs to be a point between sides at
which continuous functions can be continuous.

Anywhere there are sides without a point-between
there can be a jump in a (by definition)
"continuous" function.

That's why floats are not reals.
Floats don't do the job we want done.
Reals do that job.

----
Requiring a point between sides
is Dedekind completeness.

Requiring that,
if
f(x) is continuous at each point of
closed interval [a,b]
then
f(x) has each value between f(a) and f(b)

is the Intermediate Value Theorem.

On Sunday, September 25, 2022 at 10:33:09 AM UTC-7, Jim Burns wrote:
> On 9/24/2022 11:42 AM, Timothy Golden wrote:
>
> > If we sit here and nod our heads
> > while mathematicians claim that
> > the continuum is found by dividing one integer
> > by another integer and landing with a float
> > then the game is given away.
> That's not the continuum.
> Floats are not real numbers, whatever you call them.
> Floats are not points in the continuum.
>
> The _continuum_ is what is needed in order for
> a _continuous_ function to behave how we intend
> it to behave, given what we mean by "continuous".
>
> A _continuous_ function is:
> if you give me a bound on variation in output,
> I can give you some bound on variation in input
> that will keep the output within your bound.
> OR
> _Continuous_ functions don't jump.
> Where a function jumps,
> where it's discontinuous,
> a bound on output less than the jump cannot be
> obeyed by any non-zero variation in input.
>
> A continuous function is continuous at
> every point: no jumps anywhere.
>
> However,
> some notions of "every point" do not have
> enough points. Not having jumps _at those points_
> is not enough.
>
> For example,
> we might declare the rationals to be _all the points_
> The function f,
> f(x) =
> { 0 x*x < 2
> { 1 2 < x*x
>
> is continuous at all the (rational) points.
> And yet it jumps!
>
> There needs to be a point sqrt(2)
> for f(x) to be continuous at.
>
> More generally,
> for any partition of the continuum into
> _all one side_ and _all the other side_
> there needs to be a point between sides at
> which continuous functions can be continuous.
>
> Anywhere there are sides without a point-between
> there can be a jump in a (by definition)
> "continuous" function.
>
> That's why floats are not reals.
> Floats don't do the job we want done.
> Reals do that job.
>
> ----
> Requiring a point between sides
> is Dedekind completeness.
>
> Requiring that,
> if
> f(x) is continuous at each point of
> closed interval [a,b]
> then
> f(x) has each value between f(a) and f(b)
>
> is the Intermediate Value Theorem.

There's usually a small floating point constant defined,
according to single or double precision floating point,
its name is epsilon and two floating points differing less epsilon
aren't distinguishable or ordered.

Which otherwise they all are, ....

"Gaplessness", will do, right? Completeness?

The intermediate value theorem is then used right away
to arrive at the fundamental theorems of calculus, usually.

Of course, floating point and fixed point and extended precision
are only finite precision, it's totally agreeable, while at the same time,
any symbolic calculator is free to deal in algebra, then about
perfect algebraic and transcendental constants and their neighborhoods.

The, "interval arithmetic", basically can hold up, "significant values".

You describe a revered and accepted formalization of real analysis.

There are others, ..., or rather, there's line reals, and first.

Basically a continuous space of numbers fills our discrete space of words.

On 9/24/2022 8:28 AM, Ross A. Finlayson wrote:
> On Friday, September 23, 2022 at 10:57:43 PM UTC-7, Chris M. Thomasson wrote:
>> On 9/23/2022 10:56 PM, Chris M. Thomasson wrote:
>>> On 9/21/2022 7:53 AM, Timothy Golden wrote:
>>>> On Tuesday, September 20, 2022 at 5:04:22 PM UTC-4, Chris M. Thomasson
>>>> wrote:
>>>>> On 9/20/2022 2:01 PM, Chris M. Thomasson wrote:
>>>>>> I got a direct solution, Sergio. This direct solution does not need a
>>>>>> successor.
>>>>>>
>>>>>> i[n] = floor((1/3) * 10^(n+2) + 1)
>>>>> [...]
>>>>>
>>>>> I does not depend on a predecessor or a successor, its direct.
>>>>>
>>>>> So any result can be reached directly just by providing an index.
>>>>
>>>> As computer programmers I think we have a very different mindset than
>>>> the traditional formal mathematician.
>>>
>>> Perhaps. Humm... I think so.
>>>
>>>
>>>> As to whose logic wins: clearly the computer as a logical machine has
>>>> to be correct. Ambiguities are not to be taken lightly.
>>>> For those of us who use a compiled language the integrity of the
>>>> compiler as a tool; and hopefully one without bugs; is paramount.
>>>> To claim the same of the mathematicians is to pose them as a class of
>>>> individuals who have been schooled under one or another curricular
>>>> habit, almost like we treat Pascal or C, or C++ versus C#, and this
>>>> latter I'll have to confess I know very little about. [...]
>>>
>>> Love C and C++. Special place in my heart for C. I have used C# several
>>> times as a benchmark for its garbage collector vs manual memory
>>> management in C. I know a lot about writing synchronization algorithms
>>> in C using POSIX, memory barriers and atomic RMW. Good thing that C and
>>> C++ have fairly low level access to them.
>> I should point out that "modern" C and C++ have C11, C++11 have access
>> to membars and atomics
>>>
>>> Wrt to a GC, well, JavaScript is fun.
>>>
>>>
>>>
>
> What is fence?
>

They are meant to define a memory visibility order in a multi-threaded
program. Now, there are two kinds of fences, compiler and one for
memory. In C/C++ a compiler fence would be atomic_signal_fence, and a
memory barrier would be an atomic_thread_fence. The compiler fences are
meant to prevent a compiler from making optimizations that can break a
single threaded program that has to deal with signals. The memory fences
are meant to order memory visibility. A memory fence implies a compiler
fence, but no the other way around.

On 9/24/2022 8:51 AM, Ross A. Finlayson wrote:
> On Saturday, September 24, 2022 at 8:38:09 AM UTC-7, Ibes Confortola wrote:
>> Ross A. Finlayson wrote:
>>
>>>>> Love C and C++. Special place in my heart for C. I have used C#
>>>>> several times as a benchmark for its garbage collector vs manual
>>>>> memory management in C. I know a lot about writing synchronization
>>>>> algorithms in C using POSIX, memory barriers and atomic RMW. Good
>>>>> thing that C and C++ have fairly low level access to them.
>>>> I should point out that "modern" C and C++ have C11, C++11 have access
>>>> to membars and atomics
>>>>>
>>>>> Wrt to a GC, well, JavaScript is fun.
>>>>>
>>> What is fence?
>> an atomic instruction a semaphore is using, to protect a region from
>> changing its data.
>
> Or, allow it to change its data according to access and store.
>
> Fence
>
> Write-only RAM, Read-Write RAM, ....
>
> I think fences are offsets, also in the usual instruction
> I think it's offset not the allocator. [Consume to the fence.]
>
> There's fence and boundaries and barriers, I suppose.
>
> My organizations are very simple and for example API is fence.
>
> The mode, in terms of fence, is also for real fence in mode.
>
> How about a "very simple General Purpose Unit abstraction"?
>
> I studied the Itanium and x86, Sparc, RTL, general purpose,
> multiprocessing, ....
>
> Then there's "MiX" or something, way too complicated.
>
> Though, it also has a tape abstraction, ....
>
> When fence is boundary, ..., barrier.
>
> Usually computing the bounds for the allocator,
> in terms of "move the fence once" or allocate,
> aligned allocation and access can be incredibly performant,
> over usual step fault.
>
>
> "The usual step fault of the general purpose."
>

Oh cool. You programmed for the SPARC as well? Remember the good ol'
MEMBAR instruction? Iirc, an acquire barrier is:

membar #LoadStore | #LoadLoad

and a release is:

membar #LoadStore | #StoreStore

works perfectly for a mutex. Now, remember that deadly performance
destroying #StoreLoad? IT had to be used for more exotic algorithms that
depended on a store followed by a load to a different address. Think of
the SMR, or hazard pointer, algorithm if you will.

Remember back on SPARC where is is a no-no to put a membar instruction
in a branch delay slot?

Good times. Actually, I won a contest called CoolThreads by Sun. My
project was called vZOOM. I won a SunFire T2000 server!

Programming for the SPARC in RMO mode was always fun. ;^)

On 9/24/2022 9:31 AM, Ross A. Finlayson wrote:
> On Saturday, September 24, 2022 at 9:20:19 AM UTC-7, Ibes Confortola wrote:
>> Ross A. Finlayson wrote:
>>
>>>>> What is fence?
>>>> an atomic instruction a semaphore is using, to protect a region from
>>>> changing its data.
>>>
>>> Or, allow it to change its data according to access and store.
>>> Fence Write-only RAM, Read-Write RAM, ....
>> not sure, too advanced for me. Actually today you never read from RAM in a
>> semaphore situation. No time for it.
>
>
> Also there's where the generation of pemutations can
> be parallelized, and where parameters result constant
> time, ..., the "adaptive" has that "every data distribution
> defines a perfect implementation", while though "each does not".
[...]

Have you ever developed adaptive mutexs? They can be useful by trying to
avoid a trip to the kernel to wait. Call that a slow-path. The trick to
creating scalable sync is to cleverly avoid a slow-path when you can.

Btw, have you ever worked with RCU?

On 9/24/2022 8:51 AM, Ross A. Finlayson wrote:
> On Saturday, September 24, 2022 at 8:38:09 AM UTC-7, Ibes Confortola wrote:
>> Ross A. Finlayson wrote:
>>
>>>>> Love C and C++. Special place in my heart for C. I have used C#
>>>>> several times as a benchmark for its garbage collector vs manual
>>>>> memory management in C. I know a lot about writing synchronization
>>>>> algorithms in C using POSIX, memory barriers and atomic RMW. Good
>>>>> thing that C and C++ have fairly low level access to them.
>>>> I should point out that "modern" C and C++ have C11, C++11 have access
>>>> to membars and atomics
>>>>>
>>>>> Wrt to a GC, well, JavaScript is fun.
>>>>>
>>> What is fence?
>> an atomic instruction a semaphore is using, to protect a region from
>> changing its data.
>
> Or, allow it to change its data according to access and store.
>
> Fence
>
> Write-only RAM, Read-Write RAM, ....
>
> I think fences are offsets, also in the usual instruction
> I think it's offset not the allocator. [Consume to the fence.]
>
> There's fence and boundaries and barriers, I suppose.
>
> My organizations are very simple and for example API is fence.
>
> The mode, in terms of fence, is also for real fence in mode.
>
> How about a "very simple General Purpose Unit abstraction"?
>
> I studied the Itanium and x86, Sparc, RTL, general purpose,
> multiprocessing, ....
[...]

Remember that odd instruction for Itanium, iirc, cmp8xchg16? Had to be a
special way to avoid the ABA problem in some lock-free algorithms.

On 9/25/2022 2:43 PM, Ross A. Finlayson wrote:
> On Sunday, September 25, 2022
> at 10:33:09 AM UTC-7, Jim Burns wrote:

>> The _continuum_ is what is needed in order for
>> a _continuous_ function to behave how we intend
>> it to behave, given what we mean by "continuous".

>> A continuous function is continuous at
>> every point: no jumps anywhere.
>>
>> However,
>> some notions of "every point" do not have
>> enough points. Not having jumps _at those points_
>> is not enough.
>>
>> For example,
>> we might declare the rationals to be _all the points_
>> The function f,
>> f(x) =
>> { 0 x*x < 2
>> { 1 2 < x*x
>>
>> is continuous at all the (rational) points.
>> And yet it jumps!
>>
>> There needs to be a point sqrt(2)
>> for f(x) to be continuous at.

> There's usually a small floating point constant
> defined, according to single or double precision
> floating point, its name is epsilon and
> two floating points differing less epsilon aren't
> distinguishable or ordered.

And that would not be the continuum,
That's not even the rationals.

The continuum fills a certain role:
Enough points in order that "continuous"
functions can't jump.

We would not discuss whether triangles
"really" have three sides, would we?
That's what we're doing.

> "Gaplessness", will do, right? Completeness?

There are two kinds of gaps to consider.

Interval-gaps, where two distinct points
have no points between them.
Your floating-point constant epsilon
has interval-gaps.
Rationals eliminate interval-gaps.

One-point-gaps, where points on one side and
the other are closer than any non-zero distance,
but there is no point-between.
The rationals have one-point-gaps, like sqrt(2).
The reals eliminate one-point-gaps.

Yes, eliminating one-point gaps is
Dedekind completeness.

> The intermediate value theorem is then
> used right away to arrive at the
> fundamental theorems of calculus, usually.

Agreed.
IVT provides the means to prove a value exists,
from very general conditions.

We want to prove a derivative _exists_
an integral _exists_
IVT is useful here.

> You describe a revered and accepted
> formalization of real analysis.
> There are others, ..., or rather,
> there's line reals, and first.
> Basically a continuous space of numbers
> fills our discrete space of words.

If there aren't enough points for
a point between each split,
then what you describe does not fill the role
which we intend to have filled.
"Continuous" functions might have jumps.

If there are enough points for
a point between each split,
then what you describe are
the Good Old-Fashioned Real Numbers.

Consider two versions ℝ₁ and ℝ₂

Map
0₁ ⟷ 0₂
1₁ ⟷ 1₂
if n₁ ⟷ n₂ then n₁+1₁ ⟷ n₂+1₂
If p₁ ⟷ q₂ and q₁ ⟷ q₂ then (p/q)₁ ⟷ (p/q)₂
For 𝐴₁ ⊆ ℚ₁ and 𝐴₂ ⊆ ℚ₂
if 𝐴₁ ⟷ 𝐴₂ then lub 𝐴₁ ⟷ lub 𝐴₂

Thus
for x₁ ∈ ℝ₁ and x₂ ∈ ℝ₂
x₁ ⟷ x₂

On Sunday, September 25, 2022 at 1:59:31 PM UTC-7, Chris M. Thomasson wrote:
> On 9/24/2022 9:31 AM, Ross A. Finlayson wrote:
> > On Saturday, September 24, 2022 at 9:20:19 AM UTC-7, Ibes Confortola wrote:
> >> Ross A. Finlayson wrote:
> >>
> >>>>> What is fence?
> >>>> an atomic instruction a semaphore is using, to protect a region from
> >>>> changing its data.
> >>>
> >>> Or, allow it to change its data according to access and store.
> >>> Fence Write-only RAM, Read-Write RAM, ....
> >> not sure, too advanced for me. Actually today you never read from RAM in a
> >> semaphore situation. No time for it.
> >
> >
> > Also there's where the generation of pemutations can
> > be parallelized, and where parameters result constant
> > time, ..., the "adaptive" has that "every data distribution
> > defines a perfect implementation", while though "each does not".
> [...]
>
> Have you ever developed adaptive mutexs? They can be useful by trying to
> avoid a trip to the kernel to wait. Call that a slow-path. The trick to
> creating scalable sync is to cleverly avoid a slow-path when you can.
>
> Btw, have you ever worked with RCU?

I mostly tried to understand that Sparc is ring registers and
about how fault works, while, x86, is, after eax and so on,
the, Itanium, was designed in some superscalar many more registers,
also it had its thread context notion basically designing in the
Itanium chip, what would've resulted its server class.

So, otherwise besides "mostly I just studied the instruction
manuals and read all the program developer documentation",
just to understand what computing architecture is and along
the lines of 286 through later Intel chips and commodity chips,
that I theoretically understand how computers work and know
enough to write my own routine, basically from "PC".

Mostly from PC, I was just looking at writing UEFI modules and
using Secure Boot to make an executive or operating system,
in terms of that a really simple real-time system or even a clunky
software stack, could run a program like a web browser, while
having all throughout the entire usual software stack, ..., what
comprises a CPU and a disk controller and the bus and GPIO and
the USB controller and the video output and the network and
"programming the PC" and "building PC systems".

I like the idea of basically programming an emulator on the
PC though that it emulates a PC.

Let's start with all computer machinery as real simple, for where
"user mode and kernel mode are about same, ...",
or something like "write Orange Book like Sun Sparc or NT",
for making the world of virtual adapters a very "open" book.

You're talking resources, concurrency, a usual distributed
locking might be opportunistic or in a protocol itself of
consistent concurrency and the "eventually consistent", besides,
whereas according to resources synchronized, the CPU is free to melt.

I wish I was a demo coder but I'm only a specs collector.

Anyways though "writing an OS" can be at least pretty simple.

Write an OS, ..., write a controller boss, write an executive, make a
memory manager, reflect on BeOS and why it was the coolest thing
along with Amiga, implement the protocol stacks and their layers,
implement a disk and I/O access routine, employ the controller bus
and GPIO, manage USB and AT code the wifi chipsets, make for the
display controller a frame buffer or drive it, computers these days
are _way_ more complicated than they need to be.

So, Sparc fundamentally to me is ring registers, unique that way,
while Power and x86, ..., the 68000 and 86 are so different, ...,
the Itanium was or is about carrier class, then really it's the bus
and controller DMA, GPIO, ..., vector I/O, DMA, ..., DMA.

The DMA is "Direct Memory Access", really though USB chipset
usually has all sorts devices in its world just like PC, exact same.

(My approach these days for protocol is cooperative multithreading
the "re-routine".) I live in a world of runtimes.

What's an RCU? Yeah, maybe.

I've programmed variable bit-length coding and so on before if that makes sense.

Mostly I implemented some machines in word operations for linear speedup
the alignment for consuming bit-streams, low-level.

Certainly though I depend on usual flow of control and
context and state and according to that non-blocking I/O's
employment of DMA is very critical to its performance as
an example of what isn't just linear speedup but traction, at all.

My current synchronization primitive, is the slique, it's a queue,
that allows, reading into the mark and then atomic swap on that,
so that when it's determined a message can be consumed, ,
it's not a linear operation except to consume the queue.
This is for vector I/O with DMA pretty much the idea from
the "Meta: a usenet for just sci.math", ..., thread.

"Murphy's world of distributed business routines".

Anyways let's talk about how easy it is to write an OS for a PC for an example.

On Sunday, September 25, 2022 at 2:10:37 PM UTC-7, Chris M. Thomasson wrote:
> On 9/24/2022 8:51 AM, Ross A. Finlayson wrote:
> > On Saturday, September 24, 2022 at 8:38:09 AM UTC-7, Ibes Confortola wrote:
> >> Ross A. Finlayson wrote:
> >>
> >>>>> Love C and C++. Special place in my heart for C. I have used C#
> >>>>> several times as a benchmark for its garbage collector vs manual
> >>>>> memory management in C. I know a lot about writing synchronization
> >>>>> algorithms in C using POSIX, memory barriers and atomic RMW. Good
> >>>>> thing that C and C++ have fairly low level access to them.
> >>>> I should point out that "modern" C and C++ have C11, C++11 have access
> >>>> to membars and atomics
> >>>>>
> >>>>> Wrt to a GC, well, JavaScript is fun.
> >>>>>
> >>> What is fence?
> >> an atomic instruction a semaphore is using, to protect a region from
> >> changing its data.
> >
> > Or, allow it to change its data according to access and store.
> >
> > Fence
> >
> > Write-only RAM, Read-Write RAM, ....
> >
> > I think fences are offsets, also in the usual instruction
> > I think it's offset not the allocator. [Consume to the fence.]
> >
> > There's fence and boundaries and barriers, I suppose.
> >
> > My organizations are very simple and for example API is fence.
> >
> > The mode, in terms of fence, is also for real fence in mode.
> >
> > How about a "very simple General Purpose Unit abstraction"?
> >
> > I studied the Itanium and x86, Sparc, RTL, general purpose,
> > multiprocessing, ....
> [...]
>
> Remember that odd instruction for Itanium, iirc, cmp8xchg16? Had to be a
> special way to avoid the ABA problem in some lock-free algorithms.

comp exchange remembers!

Makes me think of muldiv. Ah, ..., muldiv.

You know the dining philosophers was a thing about ring buffers,
wow then besides Sparc, for example x86 is so great in some of string
rep branch, ffs or find first set, population count, still the 68000 had
a very strong affinity, what's called a Motorola DSP.

I knew much strong coders than me, Ataris, ..., 8, 16-bit.

I knew code, though, and there was poke. (Which sets a value in the frame buffer.)

Then all this "world of ARM" and "meh".

Yeah I think computers can be really simple for people to employ.

On 9/25/2022 2:32 PM, Ross A. Finlayson wrote:
> On Sunday, September 25, 2022 at 1:59:31 PM UTC-7, Chris M. Thomasson wrote:
>> On 9/24/2022 9:31 AM, Ross A. Finlayson wrote:
>>> On Saturday, September 24, 2022 at 9:20:19 AM UTC-7, Ibes Confortola wrote:
>>>> Ross A. Finlayson wrote:
>>>>
>>>>>>> What is fence?
>>>>>> an atomic instruction a semaphore is using, to protect a region from
>>>>>> changing its data.
>>>>>
>>>>> Or, allow it to change its data according to access and store.
>>>>> Fence Write-only RAM, Read-Write RAM, ....
>>>> not sure, too advanced for me. Actually today you never read from RAM in a
>>>> semaphore situation. No time for it.
>>>
>>>
>>> Also there's where the generation of pemutations can
>>> be parallelized, and where parameters result constant
>>> time, ..., the "adaptive" has that "every data distribution
>>> defines a perfect implementation", while though "each does not".
>> [...]
>>
>> Have you ever developed adaptive mutexs? They can be useful by trying to
>> avoid a trip to the kernel to wait. Call that a slow-path. The trick to
>> creating scalable sync is to cleverly avoid a slow-path when you can.
>>
>> Btw, have you ever worked with RCU?
>
>
>
>
> I mostly tried to understand that Sparc is ring registers and
> about how fault works, while, x86, is, after eax and so on,
> the, Itanium, was designed in some superscalar many more registers,
> also it had its thread context notion basically designing in the
> Itanium chip, what would've resulted its server class.
>
> So, otherwise besides "mostly I just studied the instruction
> manuals and read all the program developer documentation",
> just to understand what computing architecture is and along
> the lines of 286 through later Intel chips and commodity chips,
> that I theoretically understand how computers work and know
> enough to write my own routine, basically from "PC".
>
> Mostly from PC, I was just looking at writing UEFI modules and
> using Secure Boot to make an executive or operating system,
> in terms of that a really simple real-time system or even a clunky
> software stack, could run a program like a web browser, while
> having all throughout the entire usual software stack, ..., what
> comprises a CPU and a disk controller and the bus and GPIO and
> the USB controller and the video output and the network and
> "programming the PC" and "building PC systems".
>
> I like the idea of basically programming an emulator on the
> PC though that it emulates a PC.
>
> Let's start with all computer machinery as real simple, for where
> "user mode and kernel mode are about same, ...",
> or something like "write Orange Book like Sun Sparc or NT",
> for making the world of virtual adapters a very "open" book.
>
> You're talking resources, concurrency, a usual distributed
> locking might be opportunistic or in a protocol itself of
> consistent concurrency and the "eventually consistent", besides,
> whereas according to resources synchronized, the CPU is free to melt.
>
> I wish I was a demo coder but I'm only a specs collector.
>
> Anyways though "writing an OS" can be at least pretty simple.
>
> Write an OS, ..., write a controller boss, write an executive, make a
> memory manager, reflect on BeOS and why it was the coolest thing
> along with Amiga, implement the protocol stacks and their layers,
> implement a disk and I/O access routine, employ the controller bus
> and GPIO, manage USB and AT code the wifi chipsets, make for the
> display controller a frame buffer or drive it, computers these days
> are _way_ more complicated than they need to be.
>
> So, Sparc fundamentally to me is ring registers, unique that way,
> while Power and x86, ..., the 68000 and 86 are so different, ...,
> the Itanium was or is about carrier class, then really it's the bus
> and controller DMA, GPIO, ..., vector I/O, DMA, ..., DMA.
>
>
> The DMA is "Direct Memory Access", really though USB chipset
> usually has all sorts devices in its world just like PC, exact same.
>
>
> (My approach these days for protocol is cooperative multithreading
> the "re-routine".) I live in a world of runtimes.

Nice! Have you ever explored the Cell processor, iirc ps3 had them. The
inherent distributed nature of its programming. I think it had a PPC or
two for its main work.

>
> What's an RCU? Yeah, maybe.

RCU is Read-Copy Update. It's a highly scalable method for thread
synchronization in read-mostly workloads. Here is a talk on it:

https://youtu.be/Gi3EjaIq_gE

[...]

On 9/25/2022 2:32 PM, Ross A. Finlayson wrote:
> On Sunday, September 25, 2022 at 1:59:31 PM UTC-7, Chris M. Thomasson wrote:
>> On 9/24/2022 9:31 AM, Ross A. Finlayson wrote:
>>> On Saturday, September 24, 2022 at 9:20:19 AM UTC-7, Ibes Confortola wrote:
>>>> Ross A. Finlayson wrote:
[...]
> What's an RCU? Yeah, maybe.

[...]

https://youtu.be/qcD2Zj9GgI4

https://patents.google.com/patent/US5442758

On Sunday, September 25, 2022 at 5:29:06 PM UTC-4, Jim Burns wrote:
> On 9/25/2022 2:43 PM, Ross A. Finlayson wrote:
> > On Sunday, September 25, 2022
> > at 10:33:09 AM UTC-7, Jim Burns wrote:
>
> >> The _continuum_ is what is needed in order for
> >> a _continuous_ function to behave how we intend
> >> it to behave, given what we mean by "continuous".
> >> A continuous function is continuous at
> >> every point: no jumps anywhere.
> >>
> >> However,
> >> some notions of "every point" do not have
> >> enough points. Not having jumps _at those points_
> >> is not enough.
> >>
> >> For example,
> >> we might declare the rationals to be _all the points_
> >> The function f,
> >> f(x) =
> >> { 0 x*x < 2
> >> { 1 2 < x*x
> >>
> >> is continuous at all the (rational) points.
> >> And yet it jumps!
> >>
> >> There needs to be a point sqrt(2)
> >> for f(x) to be continuous at.
> > There's usually a small floating point constant
> > defined, according to single or double precision
> > floating point, its name is epsilon and
> > two floating points differing less epsilon aren't
> > distinguishable or ordered.
> And that would not be the continuum,
> That's not even the rationals.
>
> The continuum fills a certain role:
> Enough points in order that "continuous"
> functions can't jump.
>
> We would not discuss whether triangles
> "really" have three sides, would we?
> That's what we're doing.
> > "Gaplessness", will do, right? Completeness?
> There are two kinds of gaps to consider.
>
> Interval-gaps, where two distinct points
> have no points between them.
> Your floating-point constant epsilon
> has interval-gaps.
> Rationals eliminate interval-gaps.
>
> One-point-gaps, where points on one side and
> the other are closer than any non-zero distance,
> but there is no point-between.
> The rationals have one-point-gaps, like sqrt(2).
> The reals eliminate one-point-gaps.
>
> Yes, eliminating one-point gaps is
> Dedekind completeness.
> > The intermediate value theorem is then
> > used right away to arrive at the
> > fundamental theorems of calculus, usually.
> Agreed.
> IVT provides the means to prove a value exists,
> from very general conditions.
>
> We want to prove a derivative _exists_
> an integral _exists_
> IVT is useful here.
> > You describe a revered and accepted
> > formalization of real analysis.
> > There are others, ..., or rather,
> > there's line reals, and first.
> > Basically a continuous space of numbers
> > fills our discrete space of words.
> If there aren't enough points for
> a point between each split,
> then what you describe does not fill the role
> which we intend to have filled.
> "Continuous" functions might have jumps.
>
> If there are enough points for
> a point between each split,
> then what you describe are
> the Good Old-Fashioned Real Numbers.
>
> Consider two versions ℝ₁ and ℝ₂
>
> Map
> 0₁ ⟷ 0₂
> 1₁ ⟷ 1₂
> if n₁ ⟷ n₂ then n₁+1₁ ⟷ n₂+1₂
> If p₁ ⟷ q₂ and q₁ ⟷ q₂ then (p/q)₁ ⟷ (p/q)₂
> For 𝐴₁ ⊆ ℚ₁ and 𝐴₂ ⊆ ℚ₂
> if 𝐴₁ ⟷ 𝐴₂ then lub 𝐴₁ ⟷ lub 𝐴₂
>
> Thus
> for x₁ ∈ ℝ₁ and x₂ ∈ ℝ₂
> x₁ ⟷ x₂

There are continuous functions that your analysis cannot touch, such as the three body problem.
The computer will have no trouble crunching out a five body problem.
Other problems that analysis cannot solve but the computer simply goes piecemeal and works out the integral just as Newton's method describes.

https://math.stackexchange.com/questions/2603031/unsolved-elementary-integrals

In that real numbers are an idea and that these concepts fill or cover the ground about them: the rational value as the division of two integers is a compromised birth of the continuum. Did you expect to multiply a real by an integer and get an integer back? That would be the reverse operation, but you see the product is the fundamental operation; not division. And so the very usage of division is suspect.

On Sunday, September 25, 2022 at 8:10:04 PM UTC-7, Chris M. Thomasson wrote:
> On 9/25/2022 2:32 PM, Ross A. Finlayson wrote:
> > On Sunday, September 25, 2022 at 1:59:31 PM UTC-7, Chris M. Thomasson wrote:
> >> On 9/24/2022 9:31 AM, Ross A. Finlayson wrote:
> >>> On Saturday, September 24, 2022 at 9:20:19 AM UTC-7, Ibes Confortola wrote:
> >>>> Ross A. Finlayson wrote:
> >>>>
> >>>>>>> What is fence?
> >>>>>> an atomic instruction a semaphore is using, to protect a region from
> >>>>>> changing its data.
> >>>>>
> >>>>> Or, allow it to change its data according to access and store.
> >>>>> Fence Write-only RAM, Read-Write RAM, ....
> >>>> not sure, too advanced for me. Actually today you never read from RAM in a
> >>>> semaphore situation. No time for it.
> >>>
> >>>
> >>> Also there's where the generation of pemutations can
> >>> be parallelized, and where parameters result constant
> >>> time, ..., the "adaptive" has that "every data distribution
> >>> defines a perfect implementation", while though "each does not".
> >> [...]
> >>
> >> Have you ever developed adaptive mutexs? They can be useful by trying to
> >> avoid a trip to the kernel to wait. Call that a slow-path. The trick to
> >> creating scalable sync is to cleverly avoid a slow-path when you can.
> >>
> >> Btw, have you ever worked with RCU?
> >
> >
> >
> >
> > I mostly tried to understand that Sparc is ring registers and
> > about how fault works, while, x86, is, after eax and so on,
> > the, Itanium, was designed in some superscalar many more registers,
> > also it had its thread context notion basically designing in the
> > Itanium chip, what would've resulted its server class.
> >
> > So, otherwise besides "mostly I just studied the instruction
> > manuals and read all the program developer documentation",
> > just to understand what computing architecture is and along
> > the lines of 286 through later Intel chips and commodity chips,
> > that I theoretically understand how computers work and know
> > enough to write my own routine, basically from "PC".
> >
> > Mostly from PC, I was just looking at writing UEFI modules and
> > using Secure Boot to make an executive or operating system,
> > in terms of that a really simple real-time system or even a clunky
> > software stack, could run a program like a web browser, while
> > having all throughout the entire usual software stack, ..., what
> > comprises a CPU and a disk controller and the bus and GPIO and
> > the USB controller and the video output and the network and
> > "programming the PC" and "building PC systems".
> >
> > I like the idea of basically programming an emulator on the
> > PC though that it emulates a PC.
> >
> > Let's start with all computer machinery as real simple, for where
> > "user mode and kernel mode are about same, ...",
> > or something like "write Orange Book like Sun Sparc or NT",
> > for making the world of virtual adapters a very "open" book.
> >
> > You're talking resources, concurrency, a usual distributed
> > locking might be opportunistic or in a protocol itself of
> > consistent concurrency and the "eventually consistent", besides,
> > whereas according to resources synchronized, the CPU is free to melt.
> >
> > I wish I was a demo coder but I'm only a specs collector.
> >
> > Anyways though "writing an OS" can be at least pretty simple.
> >
> > Write an OS, ..., write a controller boss, write an executive, make a
> > memory manager, reflect on BeOS and why it was the coolest thing
> > along with Amiga, implement the protocol stacks and their layers,
> > implement a disk and I/O access routine, employ the controller bus
> > and GPIO, manage USB and AT code the wifi chipsets, make for the
> > display controller a frame buffer or drive it, computers these days
> > are _way_ more complicated than they need to be.
> >
> > So, Sparc fundamentally to me is ring registers, unique that way,
> > while Power and x86, ..., the 68000 and 86 are so different, ...,
> > the Itanium was or is about carrier class, then really it's the bus
> > and controller DMA, GPIO, ..., vector I/O, DMA, ..., DMA.
> >
> >
> > The DMA is "Direct Memory Access", really though USB chipset
> > usually has all sorts devices in its world just like PC, exact same.
> >
> >
> > (My approach these days for protocol is cooperative multithreading
> > the "re-routine".) I live in a world of runtimes.
> Nice! Have you ever explored the Cell processor, iirc ps3 had them. The
> inherent distributed nature of its programming. I think it had a PPC or
> two for its main work.
> >
> > What's an RCU? Yeah, maybe.
> RCU is Read-Copy Update. It's a highly scalable method for thread
> synchronization in read-mostly workloads. Here is a talk on it:
>
> https://youtu.be/Gi3EjaIq_gE
>
> [...]

The "update" problem is one of those really critical things you mention.

This is where "update is epochal", for a small event, besides for example,
a transaction, in terms of that when update completes, the resources exist again.
(The resources to complete the transaction.)

Combining operations on the state of what is a context, say, read, copy, update, ...,
that can be "epochal" in what otherwise is "three serial operations", that "serializing
the context", makes one, giving amazing speedup and dropping down blocking in
resources, to allow that constant-rate type flow results, "scaling the resources".

Here for example with "time-series and universal identifiers", in a world of "no drops,
no dupes", the contents of data, we have the serial and we have the parallel and
protocols and atomicity in critical sections and "eventual consistency", according
to protocol in resources "drives lifecycle events in interactive and mechanical work-flows".

Then, for making a simple user mode, here what we're talking about ".333, 4", at
least we're all clear here that it's not ".333, 44". I.e., it is _all 3's_, at most only one 4.

Now that in the geometric and those roots, then also we can talk about what it
meangs when it starts going ".333 ... 444..." that that's _not_ the result of division
that fraction and ratio, but, it is very like division at least having all 3's in the front,
while different from division "according the geometric series this is how it is rounding".

I.e., when that drops to "half 3's, and, half 4's, its expected in a few operations that
it will round over to .444...".

Now it's a machine.

On Sunday, September 25, 2022 at 2:29:06 PM UTC-7, Jim Burns wrote:
> On 9/25/2022 2:43 PM, Ross A. Finlayson wrote:
> > On Sunday, September 25, 2022
> > at 10:33:09 AM UTC-7, Jim Burns wrote:
>
> >> The _continuum_ is what is needed in order for
> >> a _continuous_ function to behave how we intend
> >> it to behave, given what we mean by "continuous".
> >> A continuous function is continuous at
> >> every point: no jumps anywhere.
> >>
> >> However,
> >> some notions of "every point" do not have
> >> enough points. Not having jumps _at those points_
> >> is not enough.
> >>
> >> For example,
> >> we might declare the rationals to be _all the points_
> >> The function f,
> >> f(x) =
> >> { 0 x*x < 2
> >> { 1 2 < x*x
> >>
> >> is continuous at all the (rational) points.
> >> And yet it jumps!
> >>
> >> There needs to be a point sqrt(2)
> >> for f(x) to be continuous at.
> > There's usually a small floating point constant
> > defined, according to single or double precision
> > floating point, its name is epsilon and
> > two floating points differing less epsilon aren't
> > distinguishable or ordered.
> And that would not be the continuum,
> That's not even the rationals.
>
> The continuum fills a certain role:
> Enough points in order that "continuous"
> functions can't jump.
>
> We would not discuss whether triangles
> "really" have three sides, would we?
> That's what we're doing.
> > "Gaplessness", will do, right? Completeness?
> There are two kinds of gaps to consider.
>
> Interval-gaps, where two distinct points
> have no points between them.
> Your floating-point constant epsilon
> has interval-gaps.
> Rationals eliminate interval-gaps.
>
> One-point-gaps, where points on one side and
> the other are closer than any non-zero distance,
> but there is no point-between.
> The rationals have one-point-gaps, like sqrt(2).
> The reals eliminate one-point-gaps.
>
> Yes, eliminating one-point gaps is
> Dedekind completeness.
> > The intermediate value theorem is then
> > used right away to arrive at the
> > fundamental theorems of calculus, usually.
> Agreed.
> IVT provides the means to prove a value exists,
> from very general conditions.
>
> We want to prove a derivative _exists_
> an integral _exists_
> IVT is useful here.
> > You describe a revered and accepted
> > formalization of real analysis.
> > There are others, ..., or rather,
> > there's line reals, and first.
> > Basically a continuous space of numbers
> > fills our discrete space of words.
> If there aren't enough points for
> a point between each split,
> then what you describe does not fill the role
> which we intend to have filled.
> "Continuous" functions might have jumps.
>
> If there are enough points for
> a point between each split,
> then what you describe are
> the Good Old-Fashioned Real Numbers.
>
> Consider two versions ℝ₁ and ℝ₂
>
> Map
> 0₁ ⟷ 0₂
> 1₁ ⟷ 1₂
> if n₁ ⟷ n₂ then n₁+1₁ ⟷ n₂+1₂
> If p₁ ⟷ q₂ and q₁ ⟷ q₂ then (p/q)₁ ⟷ (p/q)₂
> For 𝐴₁ ⊆ ℚ₁ and 𝐴₂ ⊆ ℚ₂
> if 𝐴₁ ⟷ 𝐴₂ then lub 𝐴₁ ⟷ lub 𝐴₂
>
> Thus
> for x₁ ∈ ℝ₁ and x₂ ∈ ℝ₂
> x₁ ⟷ x₂

Well yeah that's "agreeable" though when you have
least upper bound there as a property, the model provides it.

Here the lines real's inclusive property is courtesy construction, ....
("Least upper bound property", another gaplessness, "inside the
open and closed".)

So, reducing your R_1 and R_2 to copies of the unit interval, ....

On 9/25/2022 4:32 PM, Ross A. Finlayson wrote:
> On Sunday, September 25, 2022 at 1:59:31 PM UTC-7, Chris M. Thomasson wrote:
>> On 9/24/2022 9:31 AM, Ross A. Finlayson wrote:
>>> On Saturday, September 24, 2022 at 9:20:19 AM UTC-7, Ibes Confortola wrote:
>>>> Ross A. Finlayson wrote:
>>>>
>>>>>>> What is fence?
>>>>>> an atomic instruction a semaphore is using, to protect a region from
>>>>>> changing its data.
>>>>>
>>>>> Or, allow it to change its data according to access and store.
>>>>> Fence Write-only RAM, Read-Write RAM, ....
>>>> not sure, too advanced for me. Actually today you never read from RAM in a
>>>> semaphore situation. No time for it.
>>>
>>>
>>> Also there's where the generation of pemutations can
>>> be parallelized, and where parameters result constant
>>> time, ..., the "adaptive" has that "every data distribution
>>> defines a perfect implementation", while though "each does not".
>> [...]
>>
>> Have you ever developed adaptive mutexs? They can be useful by trying to
>> avoid a trip to the kernel to wait. Call that a slow-path. The trick to
>> creating scalable sync is to cleverly avoid a slow-path when you can.
>>
>> Btw, have you ever worked with RCU?
>
>
>
>
> I mostly tried to understand that Sparc is ring registers and
> about how fault works, while, x86, is, after eax and so on,
> the, Itanium, was designed in some superscalar many more registers,
> also it had its thread context notion basically designing in the
> Itanium chip, what would've resulted its server class.
>
> So, otherwise besides "mostly I just studied the instruction
> manuals and read all the program developer documentation",
> just to understand what computing architecture is and along
> the lines of 286 through later Intel chips and commodity chips,
> that I theoretically understand how computers work and know
> enough to write my own routine, basically from "PC".
>
> Mostly from PC, I was just looking at writing UEFI modules and
> using Secure Boot to make an executive or operating system,
> in terms of that a really simple real-time system or even a clunky
> software stack, could run a program like a web browser, while
> having all throughout the entire usual software stack, ..., what
> comprises a CPU and a disk controller and the bus and GPIO and
> the USB controller and the video output and the network and
> "programming the PC" and "building PC systems".
>
> I like the idea of basically programming an emulator on the
> PC though that it emulates a PC.
>
> Let's start with all computer machinery as real simple, for where
> "user mode and kernel mode are about same, ...",
> or something like "write Orange Book like Sun Sparc or NT",
> for making the world of virtual adapters a very "open" book.
>
> You're talking resources, concurrency, a usual distributed
> locking might be opportunistic or in a protocol itself of
> consistent concurrency and the "eventually consistent", besides,
> whereas according to resources synchronized, the CPU is free to melt.
>
> I wish I was a demo coder but I'm only a specs collector.
>
> Anyways though "writing an OS" can be at least pretty simple.

write an OS using FORTH...

>
> Write an OS, ..., write a controller boss, write an executive, make a
> memory manager, reflect on BeOS and why it was the coolest thing
> along with Amiga, implement the protocol stacks and their layers,
> implement a disk and I/O access routine, employ the controller bus
> and GPIO, manage USB and AT code the wifi chipsets, make for the
> display controller a frame buffer or drive it, computers these days
> are _way_ more complicated than they need to be.
>
> So, Sparc fundamentally to me is ring registers, unique that way,
> while Power and x86, ..., the 68000 and 86 are so different, ...,
> the Itanium was or is about carrier class, then really it's the bus
> and controller DMA, GPIO, ..., vector I/O, DMA, ..., DMA.
>
>
> The DMA is "Direct Memory Access", really though USB chipset
> usually has all sorts devices in its world just like PC, exact same.
>
>
> (My approach these days for protocol is cooperative multithreading
> the "re-routine".) I live in a world of runtimes.
>
>
>
>
> What's an RCU? Yeah, maybe.
>
> I've programmed variable bit-length coding and so on before if that makes sense.
>
> Mostly I implemented some machines in word operations for linear speedup
> the alignment for consuming bit-streams, low-level.
>
> Certainly though I depend on usual flow of control and
> context and state and according to that non-blocking I/O's
> employment of DMA is very critical to its performance as
> an example of what isn't just linear speedup but traction, at all.
>
> My current synchronization primitive, is the slique, it's a queue,
> that allows, reading into the mark and then atomic swap on that,
> so that when it's determined a message can be consumed, ,
> it's not a linear operation except to consume the queue.
> This is for vector I/O with DMA pretty much the idea from
> the "Meta: a usenet for just sci.math", ..., thread.
>
> "Murphy's world of distributed business routines".
>
> Anyways let's talk about how easy it is to write an OS for a PC for an example.
>
>

On Monday, September 26, 2022 at 8:57:21 AM UTC-7, Sergi o wrote:
> On 9/25/2022 4:32 PM, Ross A. Finlayson wrote:
> > On Sunday, September 25, 2022 at 1:59:31 PM UTC-7, Chris M. Thomasson wrote:
> >> On 9/24/2022 9:31 AM, Ross A. Finlayson wrote:
> >>> On Saturday, September 24, 2022 at 9:20:19 AM UTC-7, Ibes Confortola wrote:
> >>>> Ross A. Finlayson wrote:
> >>>>
> >>>>>>> What is fence?
> >>>>>> an atomic instruction a semaphore is using, to protect a region from
> >>>>>> changing its data.
> >>>>>
> >>>>> Or, allow it to change its data according to access and store.
> >>>>> Fence Write-only RAM, Read-Write RAM, ....
> >>>> not sure, too advanced for me. Actually today you never read from RAM in a
> >>>> semaphore situation. No time for it.
> >>>
> >>>
> >>> Also there's where the generation of pemutations can
> >>> be parallelized, and where parameters result constant
> >>> time, ..., the "adaptive" has that "every data distribution
> >>> defines a perfect implementation", while though "each does not".
> >> [...]
> >>
> >> Have you ever developed adaptive mutexs? They can be useful by trying to
> >> avoid a trip to the kernel to wait. Call that a slow-path. The trick to
> >> creating scalable sync is to cleverly avoid a slow-path when you can.
> >>
> >> Btw, have you ever worked with RCU?
> >
> >
> >
> >
> > I mostly tried to understand that Sparc is ring registers and
> > about how fault works, while, x86, is, after eax and so on,
> > the, Itanium, was designed in some superscalar many more registers,
> > also it had its thread context notion basically designing in the
> > Itanium chip, what would've resulted its server class.
> >
> > So, otherwise besides "mostly I just studied the instruction
> > manuals and read all the program developer documentation",
> > just to understand what computing architecture is and along
> > the lines of 286 through later Intel chips and commodity chips,
> > that I theoretically understand how computers work and know
> > enough to write my own routine, basically from "PC".
> >
> > Mostly from PC, I was just looking at writing UEFI modules and
> > using Secure Boot to make an executive or operating system,
> > in terms of that a really simple real-time system or even a clunky
> > software stack, could run a program like a web browser, while
> > having all throughout the entire usual software stack, ..., what
> > comprises a CPU and a disk controller and the bus and GPIO and
> > the USB controller and the video output and the network and
> > "programming the PC" and "building PC systems".
> >
> > I like the idea of basically programming an emulator on the
> > PC though that it emulates a PC.
> >
> > Let's start with all computer machinery as real simple, for where
> > "user mode and kernel mode are about same, ...",
> > or something like "write Orange Book like Sun Sparc or NT",
> > for making the world of virtual adapters a very "open" book.
> >
> > You're talking resources, concurrency, a usual distributed
> > locking might be opportunistic or in a protocol itself of
> > consistent concurrency and the "eventually consistent", besides,
> > whereas according to resources synchronized, the CPU is free to melt.
> >
> > I wish I was a demo coder but I'm only a specs collector.
> >
> > Anyways though "writing an OS" can be at least pretty simple.
> write an OS using FORTH...
> >
> > Write an OS, ..., write a controller boss, write an executive, make a
> > memory manager, reflect on BeOS and why it was the coolest thing
> > along with Amiga, implement the protocol stacks and their layers,
> > implement a disk and I/O access routine, employ the controller bus
> > and GPIO, manage USB and AT code the wifi chipsets, make for the
> > display controller a frame buffer or drive it, computers these days
> > are _way_ more complicated than they need to be.
> >
> > So, Sparc fundamentally to me is ring registers, unique that way,
> > while Power and x86, ..., the 68000 and 86 are so different, ...,
> > the Itanium was or is about carrier class, then really it's the bus
> > and controller DMA, GPIO, ..., vector I/O, DMA, ..., DMA.
> >
> >
> > The DMA is "Direct Memory Access", really though USB chipset
> > usually has all sorts devices in its world just like PC, exact same.
> >
> >
> > (My approach these days for protocol is cooperative multithreading
> > the "re-routine".) I live in a world of runtimes.
> >
> >
> >
> >
> > What's an RCU? Yeah, maybe.
> >
> > I've programmed variable bit-length coding and so on before if that makes sense.
> >
> > Mostly I implemented some machines in word operations for linear speedup
> > the alignment for consuming bit-streams, low-level.
> >
> > Certainly though I depend on usual flow of control and
> > context and state and according to that non-blocking I/O's
> > employment of DMA is very critical to its performance as
> > an example of what isn't just linear speedup but traction, at all.
> >
> > My current synchronization primitive, is the slique, it's a queue,
> > that allows, reading into the mark and then atomic swap on that,
> > so that when it's determined a message can be consumed, ,
> > it's not a linear operation except to consume the queue.
> > This is for vector I/O with DMA pretty much the idea from
> > the "Meta: a usenet for just sci.math", ..., thread.
> >
> > "Murphy's world of distributed business routines".
> >
> > Anyways let's talk about how easy it is to write an OS for a PC for an example.
> >
> >

Isn't forth like modula?

If forth's like modula, modula's about the greatest.

About "update", the key here seems "invalidation", basically that invalidation is
free to cascade what drives conditional update. (For example that it drives
unconditional update.)

Or, it's a key simple approach what makes in a framework a default well-defined
event model, that happens to include abstractly Murphy's law or the failed connection
or dropped item, in events, while at the same time that concretely, those drops are
only abstract, and the memory-machine is in--place. (It's high-performance.)

Still the bottleneck is maintaining a unique ID for the ID item, the key, then,
maintaining the forward-safe, self-healing, well-defined forward state machine,
distributed model of distributed operation. (Or, I serialize asynchronous I/O this way.)
Then the critical section can be truncated after dailies or bad rows / latelies.

Here there's no .333, 2, at all, though the idea of what happens when the thirds are a dial
and bending the handle of the dial toward .444 or .222 just results a bend in the handle,
where the dial is parallel to one third, .333... while the handle is parallel to 4/9, .444, ...,
then that after the dial moves the dial is parallel also. (A flex.)

Which, according to a readout of an atomic clock lattice, is a number.

On Monday, September 26, 2022 at 9:06:29 AM UTC-7, Ross A. Finlayson wrote:
> On Monday, September 26, 2022 at 8:57:21 AM UTC-7, Sergi o wrote:
> > On 9/25/2022 4:32 PM, Ross A. Finlayson wrote:
> > > On Sunday, September 25, 2022 at 1:59:31 PM UTC-7, Chris M. Thomasson wrote:
> > >> On 9/24/2022 9:31 AM, Ross A. Finlayson wrote:
> > >>> On Saturday, September 24, 2022 at 9:20:19 AM UTC-7, Ibes Confortola wrote:
> > >>>> Ross A. Finlayson wrote:
> > >>>>
> > >>>>>>> What is fence?
> > >>>>>> an atomic instruction a semaphore is using, to protect a region from
> > >>>>>> changing its data.
> > >>>>>
> > >>>>> Or, allow it to change its data according to access and store.
> > >>>>> Fence Write-only RAM, Read-Write RAM, ....
> > >>>> not sure, too advanced for me. Actually today you never read from RAM in a
> > >>>> semaphore situation. No time for it.
> > >>>
> > >>>
> > >>> Also there's where the generation of pemutations can
> > >>> be parallelized, and where parameters result constant
> > >>> time, ..., the "adaptive" has that "every data distribution
> > >>> defines a perfect implementation", while though "each does not".
> > >> [...]
> > >>
> > >> Have you ever developed adaptive mutexs? They can be useful by trying to
> > >> avoid a trip to the kernel to wait. Call that a slow-path. The trick to
> > >> creating scalable sync is to cleverly avoid a slow-path when you can.
> > >>
> > >> Btw, have you ever worked with RCU?
> > >
> > >
> > >
> > >
> > > I mostly tried to understand that Sparc is ring registers and
> > > about how fault works, while, x86, is, after eax and so on,
> > > the, Itanium, was designed in some superscalar many more registers,
> > > also it had its thread context notion basically designing in the
> > > Itanium chip, what would've resulted its server class.
> > >
> > > So, otherwise besides "mostly I just studied the instruction
> > > manuals and read all the program developer documentation",
> > > just to understand what computing architecture is and along
> > > the lines of 286 through later Intel chips and commodity chips,
> > > that I theoretically understand how computers work and know
> > > enough to write my own routine, basically from "PC".
> > >
> > > Mostly from PC, I was just looking at writing UEFI modules and
> > > using Secure Boot to make an executive or operating system,
> > > in terms of that a really simple real-time system or even a clunky
> > > software stack, could run a program like a web browser, while
> > > having all throughout the entire usual software stack, ..., what
> > > comprises a CPU and a disk controller and the bus and GPIO and
> > > the USB controller and the video output and the network and
> > > "programming the PC" and "building PC systems".
> > >
> > > I like the idea of basically programming an emulator on the
> > > PC though that it emulates a PC.
> > >
> > > Let's start with all computer machinery as real simple, for where
> > > "user mode and kernel mode are about same, ...",
> > > or something like "write Orange Book like Sun Sparc or NT",
> > > for making the world of virtual adapters a very "open" book.
> > >
> > > You're talking resources, concurrency, a usual distributed
> > > locking might be opportunistic or in a protocol itself of
> > > consistent concurrency and the "eventually consistent", besides,
> > > whereas according to resources synchronized, the CPU is free to melt.
> > >
> > > I wish I was a demo coder but I'm only a specs collector.
> > >
> > > Anyways though "writing an OS" can be at least pretty simple.
> > write an OS using FORTH...
> > >
> > > Write an OS, ..., write a controller boss, write an executive, make a
> > > memory manager, reflect on BeOS and why it was the coolest thing
> > > along with Amiga, implement the protocol stacks and their layers,
> > > implement a disk and I/O access routine, employ the controller bus
> > > and GPIO, manage USB and AT code the wifi chipsets, make for the
> > > display controller a frame buffer or drive it, computers these days
> > > are _way_ more complicated than they need to be.
> > >
> > > So, Sparc fundamentally to me is ring registers, unique that way,
> > > while Power and x86, ..., the 68000 and 86 are so different, ...,
> > > the Itanium was or is about carrier class, then really it's the bus
> > > and controller DMA, GPIO, ..., vector I/O, DMA, ..., DMA.
> > >
> > >
> > > The DMA is "Direct Memory Access", really though USB chipset
> > > usually has all sorts devices in its world just like PC, exact same.
> > >
> > >
> > > (My approach these days for protocol is cooperative multithreading
> > > the "re-routine".) I live in a world of runtimes.
> > >
> > >
> > >
> > >
> > > What's an RCU? Yeah, maybe.
> > >
> > > I've programmed variable bit-length coding and so on before if that makes sense.
> > >
> > > Mostly I implemented some machines in word operations for linear speedup
> > > the alignment for consuming bit-streams, low-level.
> > >
> > > Certainly though I depend on usual flow of control and
> > > context and state and according to that non-blocking I/O's
> > > employment of DMA is very critical to its performance as
> > > an example of what isn't just linear speedup but traction, at all.
> > >
> > > My current synchronization primitive, is the slique, it's a queue,
> > > that allows, reading into the mark and then atomic swap on that,
> > > so that when it's determined a message can be consumed, ,
> > > it's not a linear operation except to consume the queue.
> > > This is for vector I/O with DMA pretty much the idea from
> > > the "Meta: a usenet for just sci.math", ..., thread.
> > >
> > > "Murphy's world of distributed business routines".
> > >
> > > Anyways let's talk about how easy it is to write an OS for a PC for an example.
> > >
> > >
> Isn't forth like modula?
>
> If forth's like modula, modula's about the greatest.
>
>
> About "update", the key here seems "invalidation", basically that invalidation is
> free to cascade what drives conditional update. (For example that it drives
> unconditional update.)
>
> Or, it's a key simple approach what makes in a framework a default well-defined
> event model, that happens to include abstractly Murphy's law or the failed connection
> or dropped item, in events, while at the same time that concretely, those drops are
> only abstract, and the memory-machine is in--place. (It's high-performance.)
>
> Still the bottleneck is maintaining a unique ID for the ID item, the key, then,
> maintaining the forward-safe, self-healing, well-defined forward state machine,
> distributed model of distributed operation. (Or, I serialize asynchronous I/O this way.)
> Then the critical section can be truncated after dailies or bad rows / latelies.
>
>
> Here there's no .333, 2, at all, though the idea of what happens when the thirds are a dial
> and bending the handle of the dial toward .444 or .222 just results a bend in the handle,
> where the dial is parallel to one third, .333... while the handle is parallel to 4/9, .444, ...,
> then that after the dial moves the dial is parallel also. (A flex.)
>
> Which, according to a readout of an atomic clock lattice, is a number.

No, modula is not from forth.

On 9/26/2022 11:06 AM, Ross A. Finlayson wrote:
> On Monday, September 26, 2022 at 8:57:21 AM UTC-7, Sergi o wrote:
>> On 9/25/2022 4:32 PM, Ross A. Finlayson wrote:
>>> On Sunday, September 25, 2022 at 1:59:31 PM UTC-7, Chris M. Thomasson wrote:
>>>> On 9/24/2022 9:31 AM, Ross A. Finlayson wrote:
>>>>> On Saturday, September 24, 2022 at 9:20:19 AM UTC-7, Ibes Confortola wrote:
>>>>>> Ross A. Finlayson wrote:
>>>>>>
>>>>>>>>> What is fence?
>>>>>>>> an atomic instruction a semaphore is using, to protect a region from
>>>>>>>> changing its data.
>>>>>>>
>>>>>>> Or, allow it to change its data according to access and store.
>>>>>>> Fence Write-only RAM, Read-Write RAM, ....
>>>>>> not sure, too advanced for me. Actually today you never read from RAM in a
>>>>>> semaphore situation. No time for it.
>>>>>
>>>>>
>>>>> Also there's where the generation of pemutations can
>>>>> be parallelized, and where parameters result constant
>>>>> time, ..., the "adaptive" has that "every data distribution
>>>>> defines a perfect implementation", while though "each does not".
>>>> [...]
>>>>
>>>> Have you ever developed adaptive mutexs? They can be useful by trying to
>>>> avoid a trip to the kernel to wait. Call that a slow-path. The trick to
>>>> creating scalable sync is to cleverly avoid a slow-path when you can.
>>>>
>>>> Btw, have you ever worked with RCU?
>>>
>>>
>>>
>>>
>>> I mostly tried to understand that Sparc is ring registers and
>>> about how fault works, while, x86, is, after eax and so on,
>>> the, Itanium, was designed in some superscalar many more registers,
>>> also it had its thread context notion basically designing in the
>>> Itanium chip, what would've resulted its server class.
>>>
>>> So, otherwise besides "mostly I just studied the instruction
>>> manuals and read all the program developer documentation",
>>> just to understand what computing architecture is and along
>>> the lines of 286 through later Intel chips and commodity chips,
>>> that I theoretically understand how computers work and know
>>> enough to write my own routine, basically from "PC".
>>>
>>> Mostly from PC, I was just looking at writing UEFI modules and
>>> using Secure Boot to make an executive or operating system,
>>> in terms of that a really simple real-time system or even a clunky
>>> software stack, could run a program like a web browser, while
>>> having all throughout the entire usual software stack, ..., what
>>> comprises a CPU and a disk controller and the bus and GPIO and
>>> the USB controller and the video output and the network and
>>> "programming the PC" and "building PC systems".
>>>
>>> I like the idea of basically programming an emulator on the
>>> PC though that it emulates a PC.
>>>
>>> Let's start with all computer machinery as real simple, for where
>>> "user mode and kernel mode are about same, ...",
>>> or something like "write Orange Book like Sun Sparc or NT",
>>> for making the world of virtual adapters a very "open" book.
>>>
>>> You're talking resources, concurrency, a usual distributed
>>> locking might be opportunistic or in a protocol itself of
>>> consistent concurrency and the "eventually consistent", besides,
>>> whereas according to resources synchronized, the CPU is free to melt.
>>>
>>> I wish I was a demo coder but I'm only a specs collector.
>>>
>>> Anyways though "writing an OS" can be at least pretty simple.
>> write an OS using FORTH...
>>>
>>> Write an OS, ..., write a controller boss, write an executive, make a
>>> memory manager, reflect on BeOS and why it was the coolest thing
>>> along with Amiga, implement the protocol stacks and their layers,
>>> implement a disk and I/O access routine, employ the controller bus
>>> and GPIO, manage USB and AT code the wifi chipsets, make for the
>>> display controller a frame buffer or drive it, computers these days
>>> are _way_ more complicated than they need to be.
>>>
>>> So, Sparc fundamentally to me is ring registers, unique that way,
>>> while Power and x86, ..., the 68000 and 86 are so different, ...,
>>> the Itanium was or is about carrier class, then really it's the bus
>>> and controller DMA, GPIO, ..., vector I/O, DMA, ..., DMA.
>>>
>>>
>>> The DMA is "Direct Memory Access", really though USB chipset
>>> usually has all sorts devices in its world just like PC, exact same.
>>>
>>>
>>> (My approach these days for protocol is cooperative multithreading
>>> the "re-routine".) I live in a world of runtimes.
>>>
>>>
>>>
>>>
>>> What's an RCU? Yeah, maybe.
>>>
>>> I've programmed variable bit-length coding and so on before if that makes sense.
>>>
>>> Mostly I implemented some machines in word operations for linear speedup
>>> the alignment for consuming bit-streams, low-level.
>>>
>>> Certainly though I depend on usual flow of control and
>>> context and state and according to that non-blocking I/O's
>>> employment of DMA is very critical to its performance as
>>> an example of what isn't just linear speedup but traction, at all.
>>>
>>> My current synchronization primitive, is the slique, it's a queue,
>>> that allows, reading into the mark and then atomic swap on that,
>>> so that when it's determined a message can be consumed, ,
>>> it's not a linear operation except to consume the queue.
>>> This is for vector I/O with DMA pretty much the idea from
>>> the "Meta: a usenet for just sci.math", ..., thread.
>>>
>>> "Murphy's world of distributed business routines".
>>>
>>> Anyways let's talk about how easy it is to write an OS for a PC for an example.
>>>
>>>
>
> Isn't forth like modula?

no, but its dead like modula, forth is RPN stack machine , great for small fast controllers, but troubleshooting is extremely hard

https://en.wikipedia.org/wiki/Forth_(programming_language)

>
> If forth's like modula, modula's about the greatest.
>
>
> About "update", the key here seems "invalidation", basically that invalidation is
> free to cascade what drives conditional update. (For example that it drives
> unconditional update.)
>
> Or, it's a key simple approach what makes in a framework a default well-defined
> event model, that happens to include abstractly Murphy's law or the failed connection
> or dropped item, in events, while at the same time that concretely, those drops are
> only abstract, and the memory-machine is in--place. (It's high-performance.)
>
> Still the bottleneck is maintaining a unique ID for the ID item, the key, then,
> maintaining the forward-safe, self-healing, well-defined forward state machine,
> distributed model of distributed operation. (Or, I serialize asynchronous I/O this way.)
> Then the critical section can be truncated after dailies or bad rows / latelies.
>
>
> Here there's no .333, 2, at all, though the idea of what happens when the thirds are a dial
> and bending the handle of the dial toward .444 or .222 just results a bend in the handle,
> where the dial is parallel to one third, .333... while the handle is parallel to 4/9, .444, ...,
> then that after the dial moves the dial is parallel also. (A flex.)
>
> Which, according to a readout of an atomic clock lattice, is a number.
>
>

On 9/26/2022 8:52 AM, Timothy Golden wrote:
> On Sunday, September 25, 2022
> at 5:29:06 PM UTC-4, Jim Burns wrote:

>> If there aren't enough points for
>> a point between each split,
>> then what you describe does not fill the role
>> which we intend to have filled.
>> "Continuous" functions might have jumps.
>>
>> If there are enough points for
>> a point between each split,
>> then what you describe are
>> the Good Old-Fashioned Real Numbers.

> There are continuous functions that your analysis
> cannot touch, such as the three body problem.
>
> The computer will have no trouble crunching out
> a five body problem.
> Other problems that analysis cannot solve
> but the computer simply goes piecemeal and
> works out the integral
> just as Newton's method describes.

By "cannot touch", you seem to mean
"don't know how to compute".

Yes.
That's a feature, not a bug.

The paradigm we're using is
| | Finite you finitely make a finite claim
| which is true of each one of certain things,
| infinitely-many certain things.

We describe a _function_ in a broad sense,
making claims which are true of each thing
we consider a _function_ (of infinitely-many).

And then, we proceed from there, to further
claims, carefully, so that our claims _remain_
true of each thing we consider of function.

This paradigm gives us the ability to refer to
and reason about functions which we don't know
how to compute.

Sometimes, we learn how to compute them.
That will always start by describing them.

When we use a computer to crunch the numbers
for something like a five-body problem,
_how we know what to crunch_ is a result of
describing functions in that broad sense.

That particular number-crunching answers
a question. The question is rooted in our notion
of continuum:
enough points that no jumps are allowed.

On 9/26/2022 11:45 AM, Ross A. Finlayson wrote:
> On Sunday, September 25, 2022
> at 2:29:06 PM UTC-7, Jim Burns wrote:

>> If there aren't enough points for
>> a point between each split,
>> then what you describe does not fill the role
>> which we intend to have filled.
>> "Continuous" functions might have jumps.
>>
>> If there are enough points for
>> a point between each split,
>> then what you describe are
>> the Good Old-Fashioned Real Numbers.

>> For 𝐴₁ ⊆ ℚ₁ and 𝐴₂ ⊆ ℚ₂
>> if 𝐴₁ ⟷ 𝐴₂ then lub 𝐴₁ ⟷ lub 𝐴₂

> Well yeah that's "agreeable"
> though when you have least upper bound
> there as a property, the model provides it.

"A point between each split" is equivalent to
the least upper bound property.

Suppose you have a bounded non-empty set 𝐴 of
points in the continuum.

A split 𝑈,𝐷 exists such that, on one side, all
the bounds of 𝐴 are, and, on the other, all the
other points of the continuum are.

Each split has a point-between.
For the split 𝑈,𝐷, the point-between is lub 𝐴

The least upper bound property,
Dedekind completeness,
a-point-between-each-split,
...

One more way to describe the reason that
we pay more attention to the real numbers
than to some arbitrary theory is that,
if, two _continuous_ curves cross,
then they intersect at one or more points.

Not everything is like that.
Not everything is what we mean by "continuum".

On Monday, September 26, 2022 at 11:02:23 AM UTC-7, Jim Burns wrote:
> On 9/26/2022 11:45 AM, Ross A. Finlayson wrote:
> > On Sunday, September 25, 2022
> > at 2:29:06 PM UTC-7, Jim Burns wrote:
>
> >> If there aren't enough points for
> >> a point between each split,
> >> then what you describe does not fill the role
> >> which we intend to have filled.
> >> "Continuous" functions might have jumps.
> >>
> >> If there are enough points for
> >> a point between each split,
> >> then what you describe are
> >> the Good Old-Fashioned Real Numbers.
> >> For 𝐴₁ ⊆ ℚ₁ and 𝐴₂ ⊆ ℚ₂
> >> if 𝐴₁ ⟷ 𝐴₂ then lub 𝐴₁ ⟷ lub 𝐴₂
> > Well yeah that's "agreeable"
> > though when you have least upper bound
> > there as a property, the model provides it.
> "A point between each split" is equivalent to
> the least upper bound property.
>
> Suppose you have a bounded non-empty set 𝐴 of
> points in the continuum.
>
> A split 𝑈,𝐷 exists such that, on one side, all
> the bounds of 𝐴 are, and, on the other, all the
> other points of the continuum are.
>
> Each split has a point-between.
> For the split 𝑈,𝐷, the point-between is lub 𝐴
>
>
> The least upper bound property,
> Dedekind completeness,
> a-point-between-each-split,
> ..
>
> One more way to describe the reason that
> we pay more attention to the real numbers
> than to some arbitrary theory is that,
> if, two _continuous_ curves cross,
> then they intersect at one or more points.
>
> Not everything is like that.
> Not everything is what we mean by "continuum".

What you figure is the gainer, here what you provide here is for something
like a smooth integument, described under cuts and completeness and also
"what is maintained in splits, or cuts", splits are usually in the middle while
cuts are on the ends, of the integrable regions.

Two lines cross on a plane, while, they converge on whatever surface they are on.

Lines that touch either cross, and touch once, or converge, and touch forever,
or at the point of tangency, contact.

Parallel lines in perspective to infinity all converge to a point at infinity.

Here the point is these two segments make a translation-invariance,
the integer part is free of the non-integer part in the ordered field,
which essentially has no integer part, as the usual set that models it
in equivalence classes of values, which for example are written in usual conventions.

After courtesy properties of the real numbers "after upholding least-upper-bound property".

Angle-preserving is pretty much box-preserving. (Integrable integument.)
So, for example triangle inequality is one of the next properties there.

Triangle inequality is really great and about a key feature in what all
results most usual linear terms in the physics derivations from school.

On Monday, September 26, 2022 at 10:49:29 PM UTC-4, Ross A. Finlayson wrote:
> On Monday, September 26, 2022 at 11:02:23 AM UTC-7, Jim Burns wrote:
> > On 9/26/2022 11:45 AM, Ross A. Finlayson wrote:
> > > On Sunday, September 25, 2022
> > > at 2:29:06 PM UTC-7, Jim Burns wrote:
> >
> > >> If there aren't enough points for
> > >> a point between each split,
> > >> then what you describe does not fill the role
> > >> which we intend to have filled.
> > >> "Continuous" functions might have jumps.
> > >>
> > >> If there are enough points for
> > >> a point between each split,
> > >> then what you describe are
> > >> the Good Old-Fashioned Real Numbers.
> > >> For 𝐴₁ ⊆ ℚ₁ and 𝐴₂ ⊆ ℚ₂
> > >> if 𝐴₁ ⟷ 𝐴₂ then lub 𝐴₁ ⟷ lub 𝐴₂
> > > Well yeah that's "agreeable"
> > > though when you have least upper bound
> > > there as a property, the model provides it.
> > "A point between each split" is equivalent to
> > the least upper bound property.
> >
> > Suppose you have a bounded non-empty set 𝐴 of
> > points in the continuum.
> >
> > A split 𝑈,𝐷 exists such that, on one side, all
> > the bounds of 𝐴 are, and, on the other, all the
> > other points of the continuum are.
> >
> > Each split has a point-between.
> > For the split 𝑈,𝐷, the point-between is lub 𝐴
> >
> >
> > The least upper bound property,
> > Dedekind completeness,
> > a-point-between-each-split,
> > ..
> >
> > One more way to describe the reason that
> > we pay more attention to the real numbers
> > than to some arbitrary theory is that,
> > if, two _continuous_ curves cross,
> > then they intersect at one or more points.
> >
> > Not everything is like that.
> > Not everything is what we mean by "continuum".
> What you figure is the gainer, here what you provide here is for something
> like a smooth integument, described under cuts and completeness and also
> "what is maintained in splits, or cuts", splits are usually in the middle while
> cuts are on the ends, of the integrable regions.
>
>
> Two lines cross on a plane, while, they converge on whatever surface they are on.
>
> Lines that touch either cross, and touch once, or converge, and touch forever,
> or at the point of tangency, contact.
>
> Parallel lines in perspective to infinity all converge to a point at infinity.
>
> Here the point is these two segments make a translation-invariance,
> the integer part is free of the non-integer part in the ordered field,
> which essentially has no integer part, as the usual set that models it
> in equivalence classes of values, which for example are written in usual conventions.

And doesn't this bring into question the validity of the split or cut?
These are unremarkable on the discrete version, whereas issues of an open or closed point on one side of a cut or another arise within the real segment. Graphically a closed circle and an open circle must be presented for a cut at 2.000...
You had to have put the 2.000... on one side of the cut or the other in order for the surgery to reassemble perfectly.
Actually I do see options here, but I don't mean to digress. In the integer form you just 'cut' somewhere between 2 and 3 and there is no slop nor open nor closed point to worry about.

This graphically is problematic in that we just put the integers on the real line. It looks valid from traditional analysis, but in that a discrete system should remain discrete, and maybe the cut should remain at two in this way rather than getting that little lift I gave it, well, it seems to me again that the options to allow the two to go to both sides is fine. So long as the reverse operation recovers the original then all is well, isn't it? the whole segmented notion here is actually not so applicable to the construction of number itself. At least not when the modulo system is engaged. Leaving out the modulo mechanics within this analysis is the worst failing of this analysis.

Engaging the modulo mechanics we see that digits form our numbers. We see that we can freely construct numbers. We see that man has already constructed
0.333...
and so to construct
333...33
is not so far off, and then neither is
333...34
so far off again.

This freedom to construct has not been falsified by these analyses. That these numbers are natural with the exception of the successor problem is fine.. That the Peano axioms are not necessarily consistent with this representation is not a stopper. The consistency of these values as inductive by nature is obvious.

>
> After courtesy properties of the real numbers "after upholding least-upper-bound property".
>
>
> Angle-preserving is pretty much box-preserving. (Integrable integument.)
> So, for example triangle inequality is one of the next properties there.
>
> Triangle inequality is really great and about a key feature in what all
> results most usual linear terms in the physics derivations from school.

On 9/27/2022 9:42 AM, Timothy Golden wrote:

> We see that we can freely construct numbers.
> We see that man has already constructed
> 0.333...
> and so to construct
> 333...33
> is not so far off, and then neither is
> 333...34
> so far off again.
>
> This freedom to construct has not been falsified
> by these analyses.

There exists a great deal of freedom to construct.

Also, a great deal of freedom to describe.
So much freedom that we can describe things
which cannot exist.

Yay, freedom, but that isn't a particularly useful
thing to do. The point of constructions is to
prove that what's been described exists.

( We start with an agreement that certain other
( things exist, such as sets of some description.
( I am not aware of any other kind of construction.

The description is prior to the construction.
The description provides the reason for the construction.

I wouldn't be at all shocked if we could construct
some model of 333...34 and its ilk in ZFC.
But are they natural numbers?

That is entirely a question of what a natural number
and its ilk are. A question of description.

> That these numbers are natural with the exception
> of the successor problem is fine.
> That the Peano axioms are not necessarily consistent
> with this representation is not a stopper.

I see you addressing the question of what a
natural number is. Thank you.

However,
I think that what we mean by "natural number"
should be consistent with the Peano axioms.
That would make it a stopper.

> The consistency of these values as inductive
> by nature is obvious.

No, I don't think so.
It's not clear to me what 333...34 is intended
to represent. I've suggested that it comes
after each of
4 34
334
3334
...

and you responded in a way that took the
correctness of my suggestion for granted.
So, I'll assume that's what you mean.

_That_ -- the thing after each of _those_ --
represented by 333...34, is not a natural number.

It is a common metaphor to say that induction
_reaches_ infinitely-many natural numbers.
It is a misleading metaphor.
It suggest that some kind of infinite procedure
of reaching is performed when we use induction.
No infinite actions are performed.

It is less picturesque, but also less misleading
to say that induction _is true of_ infinitely-many
natural numbers.

But what is a natural number?
How I would say it is that a natural number is
something which can be counted to.

You have emphasized successors and predecessors,
and they are certainly needed, but the ability to
be counted to depends upon the territory
between a candidate-natural and 0

I imagine some sort of map like
4 34
334
3334
...
----------------------------
...
(Here Be Sea Monsters. Arrr!)
...
333...34

If 333...34 can be counted to,
wherever that map is split, there needs to be
a step from one side to the other.
Or else, you can't get there from here.

333...34 fails that test of being a natural number
because,
whatever Sea Monsters be after the line,
no step crosses the line.

No step crosses the line
because
each step which starts on the near side
ends on the near side.

The presence or absence of Sea Monsters
doesn't enter the discussion.
It follows from the nature of 4, 34, 334, ...

That is why I say 333...34 is not a natural number.

On Tuesday, September 27, 2022 at 1:56:45 PM UTC-4, Jim Burns wrote:
> On 9/27/2022 9:42 AM, Timothy Golden wrote:
>
> > We see that we can freely construct numbers.
> > We see that man has already constructed
> > 0.333...
> > and so to construct
> > 333...33
> > is not so far off, and then neither is
> > 333...34
> > so far off again.
> >
> > This freedom to construct has not been falsified
> > by these analyses.
> There exists a great deal of freedom to construct.
>
> Also, a great deal of freedom to describe.
> So much freedom that we can describe things
> which cannot exist.
>
> Yay, freedom, but that isn't a particularly useful
> thing to do. The point of constructions is to
> prove that what's been described exists.
>
> ( We start with an agreement that certain other
> ( things exist, such as sets of some description.
> ( I am not aware of any other kind of construction.
>
> The description is prior to the construction.
> The description provides the reason for the construction.
>
> I wouldn't be at all shocked if we could construct
> some model of 333...34 and its ilk in ZFC.
> But are they natural numbers?
>
> That is entirely a question of what a natural number
> and its ilk are. A question of description.
> > That these numbers are natural with the exception
> > of the successor problem is fine.
> > That the Peano axioms are not necessarily consistent
> > with this representation is not a stopper.
> I see you addressing the question of what a
> natural number is. Thank you.
>
> However,
> I think that what we mean by "natural number"
> should be consistent with the Peano axioms.
> That would make it a stopper.
> > The consistency of these values as inductive
> > by nature is obvious.
> No, I don't think so.
> It's not clear to me what 333...34 is intended
> to represent. I've suggested that it comes
> after each of
> 4
> 34
> 334
> 3334
> ..
>
> and you responded in a way that took the
> correctness of my suggestion for granted.
> So, I'll assume that's what you mean.
>
> _That_ -- the thing after each of _those_ --
> represented by 333...34, is not a natural number.
>
> It is a common metaphor to say that induction
> _reaches_ infinitely-many natural numbers.
> It is a misleading metaphor.
> It suggest that some kind of infinite procedure
> of reaching is performed when we use induction.
> No infinite actions are performed.
>
> It is less picturesque, but also less misleading
> to say that induction _is true of_ infinitely-many
> natural numbers.
>
> But what is a natural number?
> How I would say it is that a natural number is
> something which can be counted to.
>
> You have emphasized successors and predecessors,
> and they are certainly needed, but the ability to
> be counted to depends upon the territory
> between a candidate-natural and 0
>
> I imagine some sort of map like
> 4
> 34
> 334
> 3334
> ..
> ----------------------------
> ..
> (Here Be Sea Monsters. Arrr!)
> ..
> 333...34
>
> If 333...34 can be counted to,
> wherever that map is split, there needs to be

I don't understand this usage of 'split'.
If you go ahead and demonstrate the conflict that would be fine.
It's obviously an infinite value, so denying its inductive nature isn't going to fly.
A natural number can be regarded as a series of digits.
Clearly this is an infinite series. Do you deny other infinite series?
Or just this one?

What we have is a new interpretation of infinity here.
It is unusual to be able to name multiple instances of infinity that do have successors.
333...33 + 1 = 333...34
Obviously we cannot count to infinity. I am not going to be able to deny that.
Still, with the numerous concerns around large values these do inform the user very well.
In some regards WM is correct on his interpretations. In other regards though he is wrong.
I can say this based on these infinite values and their computable behaviors.
Whatever 'the line' is these numbers have definitely crossed it.
They will only ever work via induction but it is a very simple form of induction.
The fact that such a simplistic form exists: the ones who wrote 1/3=0.3333... have helped enable me to develop this value.
Claims that the real number has an infinite trail of digits helps enable these values.
Reinterpreting the decimal point in terms of a secondary form of unity exposes that the number without any decimal point is a natural value.
Taking this approach on interpretations of unity exposes that the rational value as well may be done via this secondary unity reasoning. This then eliminates the need of worry about closure and the usage of division, for when six become one then one becomes one sixth. That this feature is only little different from our modulo usage of number is enlightening and exposes a breach that no clear-minded thinker will care to look back from. This attack, and I say that from the stance of game theory, is strong and will stand freely. The results expose that the real number is little more than a rescaled natural number. The conflicts of operator theory have evaporated. For instance claims that the square root of two is a number are falsified directly by recognizing that the expression contains an operator and so is not a pure value. This sort of contamination has been lived with and inbred into the mathematics curriculum. Likewise the value one sixth is not a pure value; it is two values and an operator, and so the 'rational value' is a barrier to clear thought. That it is followed by an 'irrational value' merely is icing on the cake that is now on your face.
> a step from one side to the other.
> Or else, you can't get there from here.
>
> 333...34 fails that test of being a natural number
> because,
> whatever Sea Monsters be after the line,
> no step crosses the line.
>
> No step crosses the line
> because
> each step which starts on the near side
> ends on the near side.
>
> The presence or absence of Sea Monsters
> doesn't enter the discussion.
> It follows from the nature of 4, 34, 334, ...
>
> That is why I say 333...34 is not a natural number.

On 9/25/2022 2:40 PM, Ross A. Finlayson wrote:
> On Sunday, September 25, 2022 at 2:10:37 PM UTC-7, Chris M. Thomasson wrote:
>> On 9/24/2022 8:51 AM, Ross A. Finlayson wrote:
>>> On Saturday, September 24, 2022 at 8:38:09 AM UTC-7, Ibes Confortola wrote:
>>>> Ross A. Finlayson wrote:
>>>>
>>>>>>> Love C and C++. Special place in my heart for C. I have used C#
>>>>>>> several times as a benchmark for its garbage collector vs manual
>>>>>>> memory management in C. I know a lot about writing synchronization
>>>>>>> algorithms in C using POSIX, memory barriers and atomic RMW. Good
>>>>>>> thing that C and C++ have fairly low level access to them.
>>>>>> I should point out that "modern" C and C++ have C11, C++11 have access
>>>>>> to membars and atomics
>>>>>>>
>>>>>>> Wrt to a GC, well, JavaScript is fun.
>>>>>>>
>>>>> What is fence?
>>>> an atomic instruction a semaphore is using, to protect a region from
>>>> changing its data.
>>>
>>> Or, allow it to change its data according to access and store.
>>>
>>> Fence
>>>
>>> Write-only RAM, Read-Write RAM, ....
>>>
>>> I think fences are offsets, also in the usual instruction
>>> I think it's offset not the allocator. [Consume to the fence.]
>>>
>>> There's fence and boundaries and barriers, I suppose.
>>>
>>> My organizations are very simple and for example API is fence.
>>>
>>> The mode, in terms of fence, is also for real fence in mode.
>>>
>>> How about a "very simple General Purpose Unit abstraction"?
>>>
>>> I studied the Itanium and x86, Sparc, RTL, general purpose,
>>> multiprocessing, ....
>> [...]
>>
>> Remember that odd instruction for Itanium, iirc, cmp8xchg16? Had to be a
>> special way to avoid the ABA problem in some lock-free algorithms.
>
> comp exchange remembers!
>
> Makes me think of muldiv. Ah, ..., muldiv.
>
> You know the dining philosophers was a thing about ring buffers,
> wow then besides Sparc, for example x86 is so great in some of string
> rep branch, ffs or find first set, population count, still the 68000 had
> a very strong affinity, what's called a Motorola DSP.
>
> I knew much strong coders than me, Ataris, ..., 8, 16-bit.
>
> I knew code, though, and there was poke. (Which sets a value in the frame buffer.)
>
> Then all this "world of ARM" and "meh".
>
> Yeah I think computers can be really simple for people to employ.
>

Fwiw, here is some of my i686 asm code from a while back:

https://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html

2005? Wow, how times goes by.