Constrained Genericity - NUMERIC and COMPARABLE

[Brother Bill]

Let's say we want VECTOR [G], where G is constrained to be both COMPARABLE and NUMERIC.  That is use operators such as <,=, > as well as +, -, *, /.

Is this possible, and if so how is it done?

[Finnian Reilly]

Answer:

VECTOR [G -> {COMPARABLE, NUMERIC}]

Let's say we want VECTOR [G], where G is constrained to be both COMPARABLE and NUMERIC.  That is use operators such as <,=, > as well as +, -, *, /.

Is this possible, and if so how is it done?

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/d35845a1-a524-4b5d-be86-2bcfb95737ban%40googlegroups.com.

-- 
SmartDevelopersUseUnderScoresInTheirIdentifiersBecause_it_is_much_easier_to_read

[rfo amalasoft.com]

Just curious.  Why, after all these years, is NUMERIC not already COMPARABLE?

R

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Finnian Reilly <fin...@eiffel-loop.com>
Sent: Friday, June 7, 2024 1:27 PM
To: eiffel...@googlegroups.com <eiffel...@googlegroups.com>
Subject: Re: [eiffel-users] Constrained Genericity - NUMERIC and COMPARABLE

 

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/60a0e64a-3afb-6e1d-a4dd-bea2d73d065e%40eiffel-loop.com.

[rfo amalasoft.com]

Integer_ref and its cousins inherit PART_COMPARABLE, so the concept is certainly not that far off

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Finnian Reilly <fin...@eiffel-loop.com>
Sent: Friday, June 7, 2024 1:27 PM
To: eiffel...@googlegroups.com <eiffel...@googlegroups.com>
Subject: Re: [eiffel-users] Constrained Genericity - NUMERIC and COMPARABLE

 

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/60a0e64a-3afb-6e1d-a4dd-bea2d73d065e%40eiffel-loop.com.

[Rosivaldo Fernandes Alves]

Because not all numeric is comparable. E.g. complex numbers.

Rosivaldo F Alves

[rfo amalasoft.com]

---

From: rfo amalasoft.com <r...@amalasoft.com>
Sent: Friday, June 7, 2024 2:42 PM
To: Mischa Megens <mischa...@gmail.com>

Subject: Re: [eiffel-users] Constrained Genericity - NUMERIC and COMPARABLE

 

Seems rational (so to speak), but maybe there should be a "plain vanilla numeric" that is comparable, and another "not so fast, buddy, numeric" that is not, and each of those a child of "even more abstract numeric" or some such thing.

thanks

R

---

From: Mischa Megens <mischa...@gmail.com>
Sent: Friday, June 7, 2024 2:34 PM
To: rfo amalasoft.com <r...@amalasoft.com>

Subject: Re: [eiffel-users] Constrained Genericity - NUMERIC and COMPARABLE

> Just curious.  Why, after all these years, is NUMERIC not already COMPARABLE?

It thought it might be because some NUMERIC types, like complex numbers and quaternions, are not straightforwardly COMPARABLE?

Best,
Mischa

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CYXPR08MB96100A47A749CE9885D2FC5DA0FB2%40CYXPR08MB9610.namprd08.prod.outlook.com.

[Mischa Megens]

On 07/06/2024 12:18, rfo amalasoft.com wrote:

Seems rational (so to speak), but maybe there should be a "plain vanilla numeric" that is comparable, and another "not so fast, buddy, numeric" that is not, and each of those a child of "even more abstract numeric" or some such thing.

thanks

R

---

Well, you're at liberty to define your own PLAIN_VANILLA_NUMERIC, inheriting from NUMERIC and COMPARABLE, if you are so inclined.
And if you like, you could also throw in HASHABLE, for good measure.
The good news is, it will still work with REAL and DOUBLE and INTEGER and all their variations, automatically, in Eiffel :)

The NOT_SO_FAST_BUDDY_NUMERIC would be just identical to the NUMERIC that we have now, I think, so I don't quite see the need.

Also, the PLAIN_VANILLA_NUMERIC might not be the simpler thing, compared with that other NUMERIC class - while it is true that the inheritance from COMPARABLE puts restrictions on the plain vanilla aspect of it (no complex numbers, no quaternion...), it also means that the plain vanilla numbers have to have all the functionality of COMPARABLE (and perhaps HASHABLE too). So in  way, the PLAIN_VANILLA_NUMERIC is more complicated; and that's not what the name would suggest.

Best,
Mischa

[Bertrand Meyer]

Let me point again (in line with what Mischa Mengens also wrote) to my earlier response referring  to the mathematical models, respectively ring (https://en.wikipedia.org/wiki/Ring_(mathematics)) and total order (https://en.wikipedia.org/wiki/Total_order). On the latter I think my discussion of order relations in the chapter on topological sort, chapter 15, of my Touch of Class book is a good introduction.

 

There may be a tendency to forget that a library is an embodiment of a theory of a certain target domain. A good library is a set of classes that correctly implements a well-thought-out theory. Much  of the time when you start building the theory you have to invent, but when the target domain is mathematical, as here, it is wise to start with the kind of theorization and classification that mathematicians have performed over many decades and many iterations. Not necessarily to take them 100% for granted, but one must have pretty serious arguments before beginning to disagree with the likes of Cantor, Russell, Hilbert, Bourbaki et tutti quanti.

 

With best regards,

 

-- Bertrand Meyer

Latest book: Handbook of Requirements and Business Analysis, Springer, 2022

A treatise and textbook on requirements, see https://se.ethz.ch/requirements

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CYXPR08MB9610996D590A62097D04C001A0FB2%40CYXPR08MB9610.namprd08.prod.outlook.com.

[Ulrich Windl]

Bertrand,

as a mathematician would you say the Eiffel implementation is "complete and correct", or would you say it's "mostly complete and correct"?
That is: Do you know any problems or details you would do differently now?
As someone put it: You don't learn from success; you only learn from failures.

Kind regards
Ulrich

[Ulrich Windl]

[Bertrand Meyer]

Dear Ulrich,

I would never claim perfection of course. I would just say we did our best. We have to deal with engineering and other constraints. (Also, thanks for assuming I am a mathematician but I would not call myself one. I know enough true mathematicians to understand the difference.) As to doing things differently, not anything that comes to mind right now. This is not arrogance but simply a consequence of how we have been working in the development of Eiffel over the years: whenever we found something that we considered to have been a mistake we have tried to correct it.

Thanks for the comments,

-- BM

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/1b3c8d43-5441-4f8c-babf-e03945af0d34%40gmail.com.

[Jimmy Johnson]

I certainly don't want to question all of them, but we do need classes between NUMERIC and the _REF classes that are COMPARABLE and HASHABLE and maybe other features such as bit operations.  See discussion at  https://groups.google.com/g/eiffel-users/c/OWMr554Wm7U/m/gesO-KprAAAJ

I did that with the NATURAL classes, adding a class between NUMERIC and the NATURAL_xx classes.  With the ability to use my JJ_NATURAL class generically, it  greatly simplified development of a SHA library (see https://github.com/boxer41a/jj_sha), eliminating code duplication.  I also used it for a big-numbers library (see https://github.com/boxer41a/jj_big_numbers), simplifying debugging (much easier to work with eight-bit numbers than 32- or 64-bit numbers).

To remark on Mischa's comment that you can define your own PLAIN_VALILLA_NUMERIC...  Messing with the basic types seems to not always work out as expected.  My JJ_NATURAL class seems to sit nicely in the hierarchy, and I don't think it would break existing code, however, it loses some of the "build-in" compiler features, such as optimizing away explicit calls to twin (see https://groups.google.com/g/eiffel-users/c/65rjsLyGonE/m/QgM3bFzcAwAJ), meaning it will run unacceptably slower than the built-in classes.

So, I think we need the compiler geniuses (no sarcasm here) to see what can be done.  Maybe?

jjj

[Ulrich Windl]

It would be interesting to have some "implementers' notes": Obviously the compiler needs to know some basics for convenience and efficiency reasons.
Does anybody want to implement integer addition, and even if so: based on which primitives?
So part of the basics must be hard-coded in the compiler and/or runtime libraries.

Regards,
Ulrich