[Announcement] Coming soon: "neonumeral" - a free C++ library for arbitrary-precision arithmetic (permissive software license)

[Mr Flibble]

Hi!

Coming soon!

neonumeral - a free C++ library for arbitrary-precision arithmetic
(permissive software license).

https://github.com/i42output/neonumeral

neonumeral will be used by my project "neos" - a universal compiler that
can compile any programming language.

/Flibble

--
"Talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[Rick C. Hodgin]

On Friday, June 7, 2019 at 3:31:13 PM UTC-4, Mr Flibble wrote:
> https://github.com/i42output/neonumeral

Noticed something. Your logic's not consistent.

Here you return lhs if <=.

inline constexpr uint32_t min(uint32_t aLhs, uint32_t aRhs)
{
return aLhs <= aRhs ? aLhs : aRhs;
}

Here you return lhs if >=.

inline constexpr uint32_t max(uint32_t aLhs, uint32_t aRhs)
{
return aLhs >= aRhs ? aLhs : aRhs;
}

To be consistent, you should return lhs in max only on >, or lhs
in min only on < (your choice), changing one of them and leaving
the other.

--
Rick C. Hodgin

[Alf P. Steinbach]

On 07.06.2019 21:31, Mr Flibble wrote:
> Hi!
>
> Coming soon!
>
> neonumeral - a free C++ library for arbitrary-precision arithmetic
> (permissive software license).
>
> https://github.com/i42output/neonumeral
>
> neonumeral will be used by my project "neos" - a universal compiler that
> can compile any programming language.

I guess we can expect even more universal compiler spin-off projects in
the near future, judging by my own habit of delving into things.

But, does it support Roman numerals?

<url: https://github.com/tcbrindle/numeris_romanis>


Cheers!,

- Alf

[Mr Flibble]

Nonsense: they behave the same as std::min and std::max. Your god is
clouding your thinking.

[Rick C. Hodgin]

On Friday, June 7, 2019 at 5:00:45 PM UTC-4, Mr Flibble wrote:
> On 07/06/2019 20:38, Rick C. Hodgin wrote:
> > On Friday, June 7, 2019 at 3:31:13 PM UTC-4, Mr Flibble wrote:
> >> https://github.com/i42output/neonumeral
> >
> > Noticed something. Your logic's not consistent.
> >
> > Here you return lhs if <=.
> >
> > inline constexpr uint32_t min(uint32_t aLhs, uint32_t aRhs)
> > {
> > return aLhs <= aRhs ? aLhs : aRhs;
> > }
> >
> > Here you return lhs if >=.
> >
> > inline constexpr uint32_t max(uint32_t aLhs, uint32_t aRhs)
> > {
> > return aLhs >= aRhs ? aLhs : aRhs;
> > }
> >
> > To be consistent, you should return lhs in max only on >, or lhs
> > in min only on < (your choice), changing one of them and leaving
> > the other.
>
> Nonsense: they behave the same as std::min and std::max. Your god is
> clouding your thinking.

My God is an upper-case "G" God. He doesn't cloud thinking, He
makes it true:

https://www.biblegateway.com/passage/?search=1+Corinthians+14%3A33&version=KJV

33 For God is not the author of confusion, but of peace, as
in all churches of the saints.

My min/max functions are the same way ... I was just pointing
out the logic's not consistent in the way you have it setup.
I've never noticed it before, but it stood out today when I
saw yours written like that. Makes sense why it is that way.
Very little difference in assembly if you switch it. It
would depend on how good your branch prediction logic is. I
suppose there's some logic in looking at a two-weighted test
as having a more probable branch condition.

--
Rick C. Hodgin

[Mr Flibble]

More nonsense. My logic isn't inconsistent at all: as I said in my first
reply what I am doing is equivalent to what std::min and std::max do. The
only reason I am not using < is because I am dealing with a scalar type in
a non-template context and there is no requirement to do that in this
context. The stuff on branch prediction logic is further nonsense
bordering on word salad as one can not make any assumptions about the
values of the arguments. Your god is definitely clouding your thinking.

/Flibble

--
"Snakes didn't evolve, instead talking snakes with legs changed into

[Rick C. Hodgin]

FWIW, I agreed with you after your reply.

> The stuff on branch prediction logic is further nonsense
> bordering on word salad as one can not make any assumptions about the

> values of the arguments...

Branch prediction logic is the source of one of the most signifi-
cant performance gains between processor generations.

--
Rick C. Hodgin

[David Brown]

Branch prediction is important, yes - so the compiler (assuming a solid,
modern optimising compiler with optimisations enabled) will know about
it and take it into account for things like branch direction, hints (for
processors that support them), etc. And the compiler will know that in
this pattern, "<" and "<=" are equivalent - it will use whichever makes
the most sense in the context in which the code is used. (Especially
for inline functions, context is everything.)

The programmer's job here is to write the code in a clear and logical
manner, giving the compiler as much information as possible. It is the
compiler's job to do the micro-optimising and figure out what
re-arrangements are most efficient.