What's the syntax for the maximum of 2 INTEGERS?
Eiffel documentation is so bad, literally could not find the answer to this simple question anywhere!
Or does it not exist and I have to use if-statements?
In most cases in Eiffel, the source is all the documentation you need. By right-clicking on a class' name in EiffelStudio, you can see its ancestor tree. You can also use the flat view feature to see all the inherited features of a class within the same editor.
Typically, INTEGER is an alias for INTEGER_32. INTEGER_32 inherits from COMPARABLE (through INTEGER_32_REF). COMPARABLE provides the max and min features. Their signature is
max (other: like Current): like Current
meaning all descendants of COMPARABLE take and return another value of the same type as themselves.
Therefore:
local
a, b, maximum: INTEGER
do
a := <some value>
b := <some value>
maximum := a.max(b) -- or b.max(a)
end
Eiffel has a unified type system, which means every type is defined as a class, even 'primitive' types that get special treatments in most other languages. INTEGER, CHARACTER, BOOLEAN, ARRAY and other such basic types thus come with a rich set of features you can consult in their own class files like you would with any other type. Since operators are defined as regular features too, this is also the way to figure out exactly what operators exist for any given class.
Related
I am trying to use the Z3 solver (which works over SMT-LIB) to reason over C programs involving structs. I would like some way to represent that the struct is a variable that contains other variables in SMT-LIB, but I can't find a way to do that. Does anyone know of a way to represent C structs in SMT-LIB?
You can use algebraic data types feature of SMTLib 2.6 to model structs. See Section 4.2.3 of http://smtlib.cs.uiowa.edu/papers/smt-lib-reference-v2.6-r2017-07-18.pdf
This feature allows not only regular struct declarations but also recursive ones; i.e., you can also model structs that have fields of the same type.
I should add that algebraic data types in SMT are actually more general than what you need, they actually can be used to model values constructed with different algebraic constructors. (For the straightforward record case, you'll simply use one constructor.)
Algebraic-data types are rather a new feature in SMTLib, but both Z3 and CVC4 support it. Solver quality might vary depending on the features you use, but if you simply use datatypes to construct and deconstruct values it should work pretty much out of the box.
Why they didn't create numeric type like "integer1,integer2", why i have to calculate the sum of both sides for p (i need to subtract s from p to get actual amount)?
The SQL standard is designed for a specific purpose: to query data
contained in a relational database.
Here are some of the implementations of this standard:
So, basically, a long time ago, the people who were working over the standard have decided that, for 6.1 <data type> of the numeric we have:
and
However, extensions to Standard SQL exists but each implementation try to follow it.
Not sure if this is within the realm of SO but:
Using VDM-SL, I have been looking around for the 'best' way of describing a single, finite subset of ℕ. In my travels I have found several ways that people are conveying this but I wonder which is the most accepted.
I initially thought that F(ℕ) would do but I believe that this is the set of finite subsets of ℕ, rather than a single subset.
Would it be enough to say, "Let S be finite: S ⊂ ℕ?"
Or does such a notation exist?
All sets in VDM language are finite by definition, so I believe there is no need to explicitly specify that part. As defined here http://wiki.overturetool.org/images/c/cb/VDM10_lang_manV2.pdf section 3.2.1
Now, to model a type which is a subset of a set s2 , one of the ways is to use an invariant on that type. such as "inv t == s1 subset s2".
I am trying to analyze the following file which is supposed to be VHDL-2008 compatible.
entity closely_related is
end;
architecture example of closely_related is
type integer_vector is array (natural range <>) of integer;
type real_vector is array (natural range <>) of real;
begin
process
variable int_vect: integer_vector(1 to 3);
variable real_vect: real_vector(1 to 3);
begin
real_vect := ( 1.0, 2.0, 3.0 );
int_vect := integer_vector( real_vect );
wait;
end process;
end;
This is supposed to be an experiment about closely related types. According to the LRM, there are two cases of closely related types:
— Abstract numeric types—Any abstract numeric type is closely related to any other abstract numeric
type.
— Array types—Two array types are closely related if and only if the types have the same
dimensionality and the element types are closely related
I understand that reals and integers are closely related; type conversion (aka type casting) between them works ok. Then why doesn't it work for the above array types?
GHDL gives the following error:
conversion not allowed between not closely related types
And Modelsim Altera 10.1e (with -2008 switch) is no better:
Illegal type conversion from std.STANDARD.REAL_VECTOR to std.STANDARD.INTEGER_VECTOR
(array element type difference).
Just to be thorough, I tried to do the same operation one element at a time:
int_vect(1) := integer( real_vect(1) );
int_vect(2) := integer( real_vect(2) );
int_vect(3) := integer( real_vect(3) );
And it works perfectly. Any ideas?
Shouldn't these types be closely related?
Not for ghdl which is strictly -1993 compliant by default.
This is from IEEE Std 1076-1993, 7.3.5 Type conversions:
A type conversion provides for explicit conversion between closely related types.
...
b. Array Types -- Two array types are closely related if and only if
-- The types have the same dimensionality;
-- For each index position, the index types are either the same or are closely related; and
-- The element types are the same.
...
No other types are closely related.
So the issue is that the element types are not the same.
In -2008, 9.3.6 Type conversions:
— Abstract numeric types—Any abstract numeric type is closely related to any other abstract numeric type.
— Array types — Two array types are closely related if and only if the types have the same dimensionality and the element types are closely related
Which tells us that any abstract numeric type (integer, real) are closely related and that array types are now closely related when their element types are closely related.
So it looks like either the Modelsim version you specifiy isn't compliant with the change or something stopped the invocation of your -2008 flag for it.
I don't have the -2008 versions of the libraries loaded for ghdl on my Mac. I wouldn't bet it would with the --std=08 flag, either.
I checked out the the latest ghdl source code from ghdl-updates on Sourceforge, The change implementing closely related array types with closely related elements has not been incorporated. See sem_names.adb lines 1024 - 1047.
When we find things that don't get implemented due to revisions in the standard like this it's generally because there isn't a test case that fails or passes when it should, and because there is no way to see changes between standards versions.
You need a diff PDF and a way of correlating requirements between various clauses and subclauses as well as determining whether a statement in standard is testable, and if so by what code. It's safe to say that copyright is getting in the way of implementation.
The thud factor (page count) of the -2008 standard also affects the likelihood compliance gotchas will occur.
Any ideas?
int_vect := integer_vector'(integer(real_vect(1)),integer(real_vect(2)), integer(real_vect(3)));
This is from RFC 3749 (Transport Layer Security Protocol Compression Methods):
Compression Methods
TLS [2] includes the following compression method structure in
sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6:
enum { null(0), (255) } CompressionMethod;
I'm not really familiar with C, but I know enough to mark it as resemblant of C enum. What I can't understand though, are the null(0) and (255) parts. I can't seem to find anywhere what parentheses and null would mean in this context.
(I seems hard to even come up with a (Google?) search pattern that would consist of something less ubiquitous than "rfc", "null", "c", "parentheses" and would lead me to other places than questions on "null function pointer" or the most fundamental basics.)
So what do these notations mean syntactically?
Why is 255 in parentheses?
Why null looks like a function call?
Is this even supposed to be C? Or is it a common notation shared across RFCs? And if it's C, is it specific to enum?
How is this different from enum { 0, 255 } CompressionMethod; or enum { NULL, 255 } CompressionMethod;?
You may be overreasoning a bit here :)
You should have quoted the lines that follow your quote:
which allows for later specification of up to 256 different
compression methods.
That already explains what the line means. Now, if you follow the [2] to the list of references, you'll notice it refers to RFC 2246. And that document contains the following paragraph:
4. Presentation language
This document deals with the formatting of data in an external
representation. The following very basic and somewhat casually
defined presentation syntax will be used. The syntax draws from
several sources in its structure. Although it resembles the
programming language "C" in its syntax and XDR [XDR] in both its
syntax and intent, it would be risky to draw too many parallels. The
purpose of this presentation language is to document TLS only, not to
have general application beyond that particular goal.
So, the authors of that RFC seem to have concocted a simple syntax from familiar elements to simplify the representation of the subject of the RFC, namely TLS. For enumerateds, they specify the language used in 4.5:
4.5. Enumerateds
An additional sparse data type is available called enum. A field of
type enum can only assume the values declared in the definition.
Each definition is a different type. Only enumerateds of the same
type may be assigned or compared. Every element of an enumerated must
be assigned a value, as demonstrated in the following example. Since
the elements of the enumerated are not ordered, they can be assigned
any unique value, in any order.
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
Enumerateds occupy as much space in the byte stream as would its
maximal defined ordinal value. The following definition would cause
one byte to be used to carry fields of type Color.
enum { red(3), blue(5), white(7) } Color;
One may optionally specify a value without its associated tag to
force the width definition without defining a superfluous element.
In the following example, Taste will consume two bytes in the data
stream but can only assume the values 1, 2 or 4.
enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
The names of the elements of an enumeration are scoped within the
defined type. In the first example, a fully qualified reference to
the second element of the enumeration would be Color.blue. Such
qualification is not required if the target of the assignment is well
specified.
Color color = Color.blue; /* overspecified, legal */
Color color = blue; /* correct, type implicit */
For enumerateds that are never converted to external representation,
the numerical information may be omitted.
enum { low, medium, high } Amount;
What it's saying is CompressionMethod.null has the value 0 and then 255 slots are reserved:
which allows for later specification of up to 256 different
compression methods
(255) informs you the size of this field. So for encoding you know how many bytes you need. If it was (400) you would require 2 bytes to specify the 0 for compressionMethod.nullor 0x00 + 0x00. Because 255 can be represented as 1 byte you only need 0x00.
Essentially it lets you know the size of the enum field.