Glas :Re: [glas] value_type |
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-10-03 06:53:12
Theodore Papadopoulo wrote:
>On Mon, 2005-10-03 at 12:46 +0200, Herman Bruyninckx wrote:
>
>
>>On Mon, 3 Oct 2005, Karl Meerbergen wrote:
>>
>>
>>
>>>We now have started the development of some functions for vectors
>>>
>>>
>>since
>>
>>
>>>a few weeks. All of them rely on the fact that the value_type's are
>>>numerical value types (NumericValue concept). In the first document
>>>about GLAS we supposed that vectors and matrices only contain
>>>
>>>
>>numerical
>>
>>
>>>values. I recall vague suggestions on the mailing list on expanding
>>>
>>>
>>the
>>
>>
>>>value_type to other than float, double, std::complex<float>,
>>>std::complex<double>.
>>>
>>>Before continuing with any more new algorithms, it might be good to
>>>
>>>
>>know
>>
>>
>>>which other value_type's should be supported.
>>>
>>>
>>>
>>I can imagine some use cases for ints (e.g., computer vision, where
>>each
>>image is matrix of integer values, from 0-256, or 0-2^16), and for
>>"bools"
>>(e.g., vectors of digital IO, or "incidence" representations for
>>graphs,
>>etc.).
>>
>>
>
>I think it might also be extremely interesting to have interval
>arithmetic... It would make glas a tool offering some real new
>possibilities as compared to blas and co...
>
>That being said it would make sense to have any kind of values that
>belong to a mathematical field (whatever that means in their computer
>implementatiion): quaternions, modular arithmetic comes to mind.
>
>Now, it's certainly not the goal to have glas to implement directly all
>of those. It is sufficient to document the necessary operations and to
>keep their number as low as possible.
>
There is something called a NumericValue concept. Any type that is a
model of NumericValue can use the numerical algorithms. I should perhaps
add some more chat to the NumericValue concept to make some functions
clearer and explain why they are there.
Some mathematical structure would indeed be useful. We have spent a lot
of time in getting maths concepts. They might be very handy now.
NumericValue could be split up in concepts that reflect algebraic
structure. I would do this only when it is very natural and required.
Karl
X | A type that is a model of NumericValue |
abs_value_traits<X>::type | Type of modulus or absolute value of type X |
x,y | Objects of type X |
z | Object of type convertible to X |
Name | Expression | Type requirements | Return type |
---|---|---|---|
Constructor | X(z) | X | |
Zero member | zero<X>() | X | |
One member | one<X>() | X | |
Addition | x + y | X | |
Addition | x += y | X | |
Negation | - x | X | |
Subtraction | x - y | X | |
Subtraction | x -= y | X | |
Multiplication | x * y | X | |
Multiplication | x *= y | X | |
Division | x / y | X | |
Division | x /= y | X | |
Modulus | abs(x) | abs_value_traits<X>::type | |
Square of modulus | abs_square(x) | abs_value_traits<X>::type | |
Sum of the absolute value of real and imaginary parts | scalar_abs_sum(x) | abs_value_traits<X>::type | |
Maximum of the absolute value of real and imaginary parts | scalar_abs_max(x) | abs_value_traits<X>::type | |
Conjugate | conj(x) | X |
Name | Expression | Precondition | Semantics | Postcondition |
---|---|---|---|---|
Constructor | X(z) | |||
Zero member | zero<X>() | The zero member is such that a + zero<X>() == a. | ||
One member | one<X>() | The one member is such that a * one<X>() == a. | ||
Addition | x + y | |||
Addition | x += y | Is equivalent to x = x + y | ||
Negation | - x | |||
Subtraction | x - y | |||
Subtraction | x -= y | Is equivalent to x = x - y | ||
Multiplication | x * y | |||
Multiplication | x *= y | Is equivalent to x = x * y | ||
Division | x / y | y != zero<X>() | ||
Division | x /= y | y != zero<X>() | Is equivalent to x = x / y | |
Modulus | abs(x) | |||
Square of modulus | abs_square(x) | |||
Sum of the absolute value of real and imaginary parts | scalar_abs_sum(x) | |||
Maximum of the absolute value of real and imaginary parts | scalar_abs_max(x) | |||
Conjugate | conj(x) |