On 2/1/2023 8:17 AM, Simon Clubley wrote:
> Something just occurred to me while writing this: does the latest solution
> to everything :-) (ie: Rust) still allow you to directly compare two floating
> point numbers ?
>
> Based on a quick search, the answer would appear to be yes, which was
> a bit of a surprise...

It does but Clippy complains unless you instruct it not to.

#[allow(clippy::float_cmp)]

fn main() {
let x:f64 = 123.456;
let y:f64 = 123.456;
let eq1:bool = x == y;
println!("{0} = {1} is {2}", x, y, eq1);
}

Arne

Den 2023-02-01 kl. 15:11, skrev Arne Vajhøj:
> On 2/1/2023 8:17 AM, Simon Clubley wrote:
>> Something just occurred to me while writing this: does the latest solution
>> to everything :-) (ie: Rust) still allow you to directly compare two
>> floating
>> point numbers ?
>>
>> Based on a quick search, the answer would appear to be yes, which was
>> a bit of a surprise...
>
> It does but Clippy complains unless you instruct it not to.
>
> #[allow(clippy::float_cmp)]
>
> fn main() {
>     let x:f64 = 123.456;
>     let y:f64 = 123.456;
>     let eq1:bool = x == y;
>     println!("{0} = {1} is {2}", x, y, eq1);
> }
>
>
> Arne
>
>

Is that true for < or > compares also?
That seems as less of an issue...

On 2/1/2023 10:40 AM, Jan-Erik Söderholm wrote:
> Den 2023-02-01 kl. 15:11, skrev Arne Vajhøj:
>> On 2/1/2023 8:17 AM, Simon Clubley wrote:
>>> Something just occurred to me while writing this: does the latest
>>> solution
>>> to everything :-) (ie: Rust) still allow you to directly compare two
>>> floating
>>> point numbers ?
>>>
>>> Based on a quick search, the answer would appear to be yes, which was
>>> a bit of a surprise...
>>
>> It does but Clippy complains unless you instruct it not to.
>>
>> #[allow(clippy::float_cmp)]
>>
>> fn main() {
>>      let x:f64 = 123.456;
>>      let y:f64 = 123.456;
>>      let eq1:bool = x == y;
>>      println!("{0} = {1} is {2}", x, y, eq1);
>> }
>
> Is that true for < or > compares also?
> That seems as less of an issue...

Docs says:

<quote>
What it does

Checks for (in-)equality comparisons on floating-point values
</quote>

so I guess only == and !=.

Arne

Den 2023-02-01 kl. 17:25, skrev Arne Vajhøj:
> On 2/1/2023 10:40 AM, Jan-Erik Söderholm wrote:
>> Den 2023-02-01 kl. 15:11, skrev Arne Vajhøj:
>>> On 2/1/2023 8:17 AM, Simon Clubley wrote:
>>>> Something just occurred to me while writing this: does the latest solution
>>>> to everything :-) (ie: Rust) still allow you to directly compare two
>>>> floating
>>>> point numbers ?
>>>>
>>>> Based on a quick search, the answer would appear to be yes, which was
>>>> a bit of a surprise...
>>>
>>> It does but Clippy complains unless you instruct it not to.
>>>
>>> #[allow(clippy::float_cmp)]
>>>
>>> fn main() {
>>>      let x:f64 = 123.456;
>>>      let y:f64 = 123.456;
>>>      let eq1:bool = x == y;
>>>      println!("{0} = {1} is {2}", x, y, eq1);
>>> }
>>
>> Is that true for < or > compares also?
>> That seems as less of an issue...
>
> Docs says:
>
> <quote>
> What it does
>
> Checks for (in-)equality comparisons on floating-point values
> </quote>
>
> so I guess only == and !=.
>
> Arne
>

OK, sounds logical... :-)

On 2/1/2023 8:17 AM, Simon Clubley wrote:
> On 2023-01-31, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>> On 2023-01-31 14:07:05 +0000, Simon Clubley said:
>>
>>> I would not disagree with that. Having never really used DEC Basic, I
>>> had forgotten about them until you brought them up.
>>>
>>> Did they exist back in the V4 days when David started writing his code ?
>>
>> VAX/VMS V3.x BASIC apps usually used integers, and used numeric strings
>> via the VAX/VMS RTLs.
>>
>
> Actually, the V4 reference here was to RSTS/E, not VAX/VMS... :-)
>
> Interesting story however, and shows just how easy it is to screw up
> using FP.
>
> Something just occurred to me while writing this: does the latest solution
> to everything :-) (ie: Rust) still allow you to directly compare two floating
> point numbers ?
>
> Based on a quick search, the answer would appear to be yes, which was
> a bit of a surprise...
>
> Simon.
>

I'm assuming you're referring to comparisons for equality, but, greater than and
less than are also comparisons.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2023-02-01 13:17:06 +0000, Simon Clubley said:

> Something just occurred to me while writing this: does the latest
> solution to everything :-) (ie: Rust) still allow you to directly
> compare two floating point numbers ?

Rust crates:

https://docs.rs/float-cmp/latest/float_cmp/

https://docs.rs/efloat/latest/efloat/

Swift has a deliberately-obscurely-named equivalent to machine epsilon,
as do some other languages.

https://en.wikipedia.org/wiki/Machine_epsilon

Unfortunately, stuff that's labeled "epsilon" is all too often not what
you want to use.

And (more general, not specific to Rust) background on floating point:

https://randomascii.wordpress.com/category/floating-point/

https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
(part of a longer series)

The last OpenVMS port had a fairly long write-up on floating point, and
the x86-64 probably has an update to same, as floating point is always
"fun".

--
Pure Personal Opinion | HoffmanLabs LLC

In article <trdooi$blc0$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2023-01-31, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>> On 2023-01-31 14:07:05 +0000, Simon Clubley said:
>>
>>> I would not disagree with that. Having never really used DEC Basic, I
>>> had forgotten about them until you brought them up.
>>>
>>> Did they exist back in the V4 days when David started writing his code ?
>>
>> VAX/VMS V3.x BASIC apps usually used integers, and used numeric strings
>> via the VAX/VMS RTLs.
>>
>
>Actually, the V4 reference here was to RSTS/E, not VAX/VMS... :-)
>
>Interesting story however, and shows just how easy it is to screw up
>using FP.
>
>Something just occurred to me while writing this: does the latest solution
>to everything :-) (ie: Rust) still allow you to directly compare two floating
>point numbers ?
>
>Based on a quick search, the answer would appear to be yes, which was
>a bit of a surprise...

It depends on how you do it, but yes, Rust lets you compare
two floating point numbers for equality:

: igor; rustc --version
rustc 1.67.0 (fc594f156 2023-01-24)
: igor; cat >test.rs
fn main() {
let x = 0.6;
let y = 0.6;

if x == y {
println!("comparison on floats is true");
}

match x {
0.6 => println!("match on floats...for now"),
_ => println!("bah, humbug."),
}
} : igor; rustc test.rs
warning: floating-point types cannot be used in patterns
--> test.rs:10:9
|
10 | 0.6 => println!("match on floats...for now"),
| ^^^
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #41620 <https://github.com/rust-lang/rust/issues/41620>
= note: `#[warn(illegal_floating_point_literal_pattern)]` on by default

warning: 1 warning emitted

: igor; ./test
comparison on floats is true
match on floats...for now
: igor;

Note the warning on `match` against floats.

I suspect that tests for equality are permitted since testing
for partial equality (e.g., <=, >=) may be important and there's
not an easy way to turn off equality testing if you support
partial orderings.

Note that Rust does treat things somewhat specially when it
comes to floating point. cf the PartialOrd and PartialEq
traits:
https://doc.rust-lang.org/std/cmp/trait.PartialEq.html
https://doc.rust-lang.org/std/cmp/trait.PartialOrd.html

- Dan C.

On 2/1/2023 11:52 AM, Stephen Hoffman wrote:
> Swift has a deliberately-obscurely-named equivalent to machine epsilon,
> as do some other languages.

The reality is that a relevant epsilon for floating point comparison
depends on the context.

When I am exposed to the problem then it is typical regarding
testing for convergence of iterative algorithms. Is Xt
the same as Xt-1.

And the right epsilon depends on the scale of the data.

Arne

On Wed, 2023-02-01 at 09:11 -0500, Arne Vajhøj wrote:
> > Based on a quick search, the answer would appear to be yes, which
> > was
> > a bit of a surprise...
>
> It does but Clippy complains unless you instruct it not to.
>
> #[allow(clippy::float_cmp)]
>
> fn main() {
>      let x:f64 = 123.456;
>      let y:f64 = 123.456;
>      let eq1:bool = x == y;
>      println!("{0} = {1} is {2}", x, y, eq1);
> }

I'm currently teaching myself Rust and have been for the past two
years. It is a most interesting programming language.
--
Tactical Nuclear Kittens

On Wednesday, February 1, 2023 at 12:02:14 PM UTC-7, Single Stage to Orbit wrote:
> On Wed, 2023-02-01 at 09:11 -0500, Arne Vajhøj wrote:
> > > Based on a quick search, the answer would appear to be yes, which
> > > was
> > > a bit of a surprise...
> >
> > It does but Clippy complains unless you instruct it not to.
> >
> > #[allow(clippy::float_cmp)]
> >
> > fn main() {
> > let x:f64 = 123.456;
> > let y:f64 = 123.456;
> > let eq1:bool = x == y;
> > println!("{0} = {1} is {2}", x, y, eq1);
> > }
> I'm currently teaching myself Rust and have been for the past two
> years. It is a most interesting programming language.
> --
> Tactical Nuclear Kittens

It would be interesting to make this available on the new VMS. I had some notes on this, but I don't think I kept them.

On Thu, 2023-02-02 at 06:40 -0800, plugh wrote:
> > I'm currently teaching myself Rust and have been for the past two
> > years. It is a most interesting programming language.
>
> It would be interesting to make this available on the new VMS. I had
> some notes on this, but I don't think I kept them.

LLVM supports x86_64 and ELF out the box, so I imagine the truly hard
bits wil be the bindings to OpenVMS calls and data structures. Async
and locking primitives will need to be implemented, that won't be easy.
--
Tactical Nuclear Kittens

https://groups.google.com/g/comp.os.vms/c/IThxF57t9PU/m/JDmJQHI7AQAJ
is the reference I was thinking of

In article <tre863$ecn5$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/1/2023 11:52 AM, Stephen Hoffman wrote:
>> Swift has a deliberately-obscurely-named equivalent to machine epsilon,
>> as do some other languages.
>
>The reality is that a relevant epsilon for floating point comparison
>depends on the context.
>
>When I am exposed to the problem then it is typical regarding
>testing for convergence of iterative algorithms. Is Xt
>the same as Xt-1.
>
>And the right epsilon depends on the scale of the data.

I interpreted Stephen Hoffman's mention of epsilon as
referring to the constant (e.g., in IEEE754 floating
point). This is well defined for each representation.
https://en.wikipedia.org/wiki/Machine_epsilon

- Dan C.

On 2/2/2023 5:44 PM, Dan Cross wrote:
> In article <tre863$ecn5$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/1/2023 11:52 AM, Stephen Hoffman wrote:
>>> Swift has a deliberately-obscurely-named equivalent to machine epsilon,
>>> as do some other languages.
>>
>> The reality is that a relevant epsilon for floating point comparison
>> depends on the context.
>>
>> When I am exposed to the problem then it is typical regarding
>> testing for convergence of iterative algorithms. Is Xt
>> the same as Xt-1.
>>
>> And the right epsilon depends on the scale of the data.
>
> I interpreted Stephen Hoffman's mention of epsilon as
> referring to the constant (e.g., in IEEE754 floating
> point). This is well defined for each representation.
> https://en.wikipedia.org/wiki/Machine_epsilon

That is possible. It sort of fit the context.

But that is very rarely a good epsilon/delta/whatever
value when testing for equality.

Arne

On 2/2/2023 10:08 AM, Single Stage to Orbit wrote:
> On Thu, 2023-02-02 at 06:40 -0800, plugh wrote:
>>> I'm currently teaching myself Rust and have been for the past two
>>> years. It is a most interesting programming language.
>>
>> It would be interesting to make this available on the new VMS. I had
>> some notes on this, but I don't think I kept them.
>
> LLVM supports x86_64 and ELF out the box, so I imagine the truly hard
> bits wil be the bindings to OpenVMS calls and data structures.

I suspect that there is a bit more to get a LLVM based compiler
working on VMS x86-64 than that.

> Async
> and locking primitives will need to be implemented, that won't be easy.

Isn't async build on top of threads?

Arne

On Thu, 2023-02-02 at 18:49 -0500, Arne Vajhøj wrote:
> > LLVM supports x86_64 and ELF out the box, so I imagine the truly
> > hard
> > bits wil be the bindings to OpenVMS calls and data structures.
>
> I suspect that there is a bit more to get a LLVM based compiler
> working on VMS x86-64 than that.
>

Probably. That was just hand-wavey bits. VSI is working on using LLVM
for their compilers, yes?
                                                               
> > Async
> > and locking primitives will need to be implemented, that won't be
> > easy.
>
> Isn't async build on top of threads?

Perhaps, I'm still not an expert Rust coder yet.
--
Tactical Nuclear Kittens

On 2/2/2023 7:15 PM, Single Stage to Orbit wrote:
> On Thu, 2023-02-02 at 18:49 -0500, Arne Vajhøj wrote:
>>> LLVM supports x86_64 and ELF out the box, so I imagine the truly
>>> hard
>>> bits wil be the bindings to OpenVMS calls and data structures.
>>
>> I suspect that there is a bit more to get a LLVM based compiler
>> working on VMS x86-64 than that.
>
> Probably. That was just hand-wavey bits. VSI is working on using LLVM
> for their compilers, yes?

They are using LLVM yes.

Arne

> |What position does PostgreSQL have on the list of opensource software?
> |
> |We have no plans to port PostgreSQL to OpenVMS.
>
> Huh ?

This just hit my inbox:

<quote>
International OpenVMS Forum

Eindhoven, March 7th , 2023
....
13:30 – 14:30 Jan Karremans: OpenVMS and PostgreSQL, the dawn of a new era

Jan Karremans is a database technologist at EDB, working with people and
organizations to maximize their potential in a data centric world. He is
a Postgres advocate.

Postgres is gaining more and more momentum as enterprise database on
OpenVMS. The key benefits are obvious: a high-performing database,
considerable savings on license fees, and access to a large pool of
skilled resources.
</quote>

Either "enterprise database on OpenVMS" means "PostgreSQL client on
OpenVMS accessing PostgreSQL server on Linux" or he believes
PostgreSQL server on VMS will show up.

Arne

In article <trhi5t$13ikm$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/2/2023 10:08 AM, Single Stage to Orbit wrote:
>> On Thu, 2023-02-02 at 06:40 -0800, plugh wrote:
>>>> I'm currently teaching myself Rust and have been for the past two
>>>> years. It is a most interesting programming language.
>>>
>>> It would be interesting to make this available on the new VMS. I had
>>> some notes on this, but I don't think I kept them.
>>
>> LLVM supports x86_64 and ELF out the box, so I imagine the truly hard
>> bits wil be the bindings to OpenVMS calls and data structures.
>
>I suspect that there is a bit more to get a LLVM based compiler
>working on VMS x86-64 than that.
>
>> Async
>> and locking primitives will need to be implemented, that won't be easy.
>
>Isn't async build on top of threads?

No, not necessarily. async can be used to build threads,
and async executors can run in threads, but the two are
in many ways duals of one another.

- Dan C.

On 2/3/2023 8:58 AM, Dan Cross wrote:
> In article <trhi5t$13ikm$2@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/2/2023 10:08 AM, Single Stage to Orbit wrote:
>>> On Thu, 2023-02-02 at 06:40 -0800, plugh wrote:
>>>>> I'm currently teaching myself Rust and have been for the past two
>>>>> years. It is a most interesting programming language.
>>>>
>>>> It would be interesting to make this available on the new VMS. I had
>>>> some notes on this, but I don't think I kept them.
>>>
>>> LLVM supports x86_64 and ELF out the box, so I imagine the truly hard
>>> bits wil be the bindings to OpenVMS calls and data structures.
>>
>> I suspect that there is a bit more to get a LLVM based compiler
>> working on VMS x86-64 than that.
>>
>>> Async
>>> and locking primitives will need to be implemented, that won't be easy.
>>
>> Isn't async build on top of threads?
>
> No, not necessarily. async can be used to build threads,
> and async executors can run in threads, but the two are
> in many ways duals of one another.

It is two very different programming models.

But the usual async await model is that it is syntactic
sugar that under the hood creates a task that get scheduled
to run in a thread pool.

From as programming model perspective it is:

async await - task and thread pool - raw threads

But implementation wise it is different levels of abstraction:

async await
|
task and thread pool
|
raw threads

For someone developing applications in Rust then the
programming model is what is important.

But for porting Rust compiler and runtime to a new OS,
then the implementation matters.

My expectation would be that if the OS expose a
working pthreads C library then Rust could do
async await on that platform as all the layers
in between would work.

Of course all this stuff is most useful if
there is support for async IO. VMS most definitely
support that. But depending on what Rust rely on
then there may be a gap between what the Rust
runtime expects and what VMS has.

Bridging *nix centric IO and VMS IO can be
tricky. Just look at the Java IO on VMS
mess.

So I am not definitely not saying that getting
Rust running on VMS will be easy.

Arne

In article <trj666$1epo9$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/3/2023 8:58 AM, Dan Cross wrote:
>>> Isn't async build on top of threads?
>>
>> No, not necessarily. async can be used to build threads,
>> and async executors can run in threads, but the two are
>> in many ways duals of one another.
>
>It is two very different programming models.
>
>But the usual async await model is that it is syntactic
>sugar that under the hood creates a task that get scheduled
>to run in a thread pool.

You're conflating async/await and the executor model generally
with executors running in thread pools. The two are separable,
and one can write a totally custom executor that runs completely
independently of an underlying thread abstraction.

> From as programming model perspective it is:
>
>async await - task and thread pool - raw threads
>
>But implementation wise it is different levels of abstraction:
>
>async await
> |
>task and thread pool
> |
>raw threads

Nope. See above.

>For someone developing applications in Rust then the
>programming model is what is important.
>
>But for porting Rust compiler and runtime to a new OS,
>then the implementation matters.

I'm talking about the implementation.

There is no, "Rust Runtime" per se, which is one of the things
that makes it so pleasant for bare-metal and kernel development:
turn on the computer, get running wherever you're linked at, set
up a stack, and jump into Rust code. For example, here's the
boot loader I wrote for our machines. It runs from the x86
reset vector: https://github.com/oxidecomputer/phbl/

There _is_ a standard library, but how it's implemented varies
based on target.

>My expectation would be that if the OS expose a
>working pthreads C library then Rust could do
>async await on that platform as all the layers
>in between would work.

Pthreads, or any other such thread implementation, are not
required for async Rust to be implemented on a system. For
example, look at "lilos", which is targeted towards
microcontrollers, and makes heavy use of `async`:
https://github.com/cbiffle/lilos/

System developers, e.g., those doing an OpenVMS port, may
_choose_ to run executors in terms of the underlying thread
primitives provided by the OS, but that's not at all required.

>Of course all this stuff is most useful if
>there is support for async IO. VMS most definitely
>support that. But depending on what Rust rely on
>then there may be a gap between what the Rust
>runtime expects and what VMS has.

Again, there is no, "Rust runtime" in the sense you're implying.

>Bridging *nix centric IO and VMS IO can be
>tricky. Just look at the Java IO on VMS
>mess.
>
>So I am not definitely not saying that getting
>Rust running on VMS will be easy.

I don't see why not, honestly. Bringing over the standard
library may be a bit of work, but there's a Windows port and in
an ironic twist of fate, that may well serve as an example of
how to implement the VMS-specific bits.

- Dan C.