Post Reply 
newRPL - Updated to build 1510 [official build remains at 1487]
09-08-2021, 10:40 PM
Post: #186
RE: newRPL - Updated to build 1497 [official build remains at 1487]
(09-08-2021 09:28 PM)Claudio L. Wrote:  As far as TAGs, all tagged objects TYPE is 10000 + the type of the tagged object, so you don't really need to strip the tag to type check it.

Huh, didn't realize it!

Quote:Perhaps we could use exact/approximated numbers in the list to indicate a "loose" comparison.
where:
* First the objects are type-matched exactly.
* Tagged objects are type-matched after subtracting 10000 to the type
If the number in the argument list is exact, comparison ends here.
If there's no match, it continues as follows...
If the number in the list is approximate, additional checks are done:
* Variable names are recalled and their content is type-matched.
* Constants are replaced with their numeric values then type-matched
* Symbolic expressions are evaluated with ->NUM and the result is type-matched
* Programs are executed with XEQ and the result type-matched (that program better leave one result on the stack...)

Some examples:
10. ----> Match a real number, even when inside a variable, or an expression that evaluates to a real number, or a tagged real.
10010 -----> Match a tagged real number only, tag is required.
10010. -----> Match a tagged real inside a variable
10000 -----> Match any tagged object

We still have the negative sign to do other stuff.

But this would mean to devise a comparison schema that is radically different from the one used by TYPEE. We would end having two incomplete features instead of one.

Inspired by the initial implementation of TYPEE I drafted a proposal that can be adapted to all object types and it's based on the principle that each property is encoded by a decimal digit different from zero. The zero being a wildcard when the extended type is interpreted in the context of type matching.

For example, the extended type for real numbers would be like this:

   

Therefore the extended type of 123.45. becomes 10.12122 and you can extract (with DIGITS perhaps?) all the info you might need.

In type-checking this value would still match against 10(.00000) if you need a simple real or against 10.1002 if you need a finite approx.

Real numbers are the building block of more complicate types therefore if you need to check for a temperature increment greater or equal to zero (or a variable containing it) you would do

Code:

IF 1 { 54.04 -54.04 } ARGCKTF THEN ->NUM UVAL END
1 { 10.100011 } ARGCK

Since unit subtype describes only properties relevant to unit objects and not relevant to the "payload".


Attached File(s)
.xlsx  NewRPL_Types.xlsx (Size: 11.75 KB / Downloads: 10)
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: newRPL - Updated to build 1497 [official build remains at 1487] - JoJo1973 - 09-08-2021 10:40 PM
Navigating through sub-menus - Gilles - 05-13-2023, 11:31 AM
It's a mystery to me... - Klaus - 11-27-2023, 12:24 PM



User(s) browsing this thread: 2 Guest(s)