Remove "synthetic/implementation" class functions

[Airini]

Such as those converting to and from 'Double' in 'Field'. So far, they are seen in:

• (pretty) printing
• testing, e.g. 'eqNum' to account for margins of numerical error
• matrix related computations in those modules using HMatrix (note its replacement for Data.Matrix in branch WIP, but should still check for feasible component classes/types in the latter library)
• computing projections, due to 'sqrt', see 'project' in 'Simplex'
• computations involving 'factorial' and 'choose' in 'Combinatorics'

Initially, the existence of these class functions stemmed mostly from the numerics behind integration of polynomials and other computations of the like. Even though most practical uses of the library might involve ℝⁿ, it would be preferable to keep the classes neat and general.

[simonpf]

I agree, this would indeed be nice. But how would you go on about this? How
should we handle square roots? Moreover, I think we also need to be able
to programmatically introduce constants into the computations. How can we
do that without the conversion functions?

On 15 November 2016 at 18:43, Irene Lobo Valbuena notifications@github.com
wrote:

Such as those converting to and from 'Double' in 'Field'
https://github.com/Airini/FEECa/blob/master/src/FEECa/Internal/Spaces.hs.
So far, they are seen in:

• (pretty) printing
• testing, e.g. 'eqNum'
  https://github.com/Airini/FEECa/blob/master/src/FEECa/Utility/Utility.hs
  to account for margins of numerical error
• matrix related computations in those modules using HMatrix (note its
  replacement for Data.Matrix in branch WIP
  https://github.com/Airini/FEECa/tree/WIP, but should still check for
  feasible component classes/types in the latter library)
• computing projections, due to 'sqrt', see 'project' in 'Simplex'
  https://github.com/Airini/FEECa/blob/master/src/FEECa/Internal/Simplex.lhs
• computations involving 'factorial' and 'choose' in 'Combinatorics'
  https://github.com/Airini/FEECa/blob/master/src/FEECa/Utility/Combinatorics.lhs

Initially, the existence of these class functions stemmed mostly from the
numerics behind integration of polynomials and other computations of the
like. Even though most practical uses of the library might involve ℝn, it
would be preferable to keep the classes neat and general.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3, or mute the thread
https://github.com/notifications/unsubscribe-auth/AGnOhcfmXA9Ks3yIDTGgUq5cNhvFWUs0ks5q-e80gaJpZM4Ky0RU
.

[patrikja]

To TODO came from me (also to me;-) and I have not studied the code enough
to know the answers yet, but one plausible direction is

1. introduce sqrt as an operation if that is what is needed
2. the constants (of a polynomial, form, etc.) are reasonably of the type
   of scalars underlying the form, and that need not (in general) be Double.
3. when, in the end, a concrete polynomial, form, etc. is constructed it
   will (normally) have scalars from Double (or Complex Double) but that
   should not restrict the degree of polymorphism of the library

There may be good reason to tie the class to Double, but if feels strange
(especially the toDouble part which basically precludes even complex
numbers).

/P

On 16 November 2016 at 20:20, simonpf notifications@github.com wrote:

I agree, this would indeed be nice. But how would you go on about this? How
should we handle square roots? Moreover, I think we also need to be able
to programmatically introduce constants into the computations. How can we
do that without the conversion functions?

On 15 November 2016 at 18:43, Irene Lobo Valbuena <
notifications@github.com>
wrote:

Such as those converting to and from 'Double' in 'Field'
<https://github.com/Airini/FEECa/blob/master/src/FEECa/
Internal/Spaces.hs>.
So far, they are seen in:

• (pretty) printing
• testing, e.g. 'eqNum'
  <https://github.com/Airini/FEECa/blob/master/src/FEECa/
  Utility/Utility.hs>
  to account for margins of numerical error
• matrix related computations in those modules using HMatrix (note its
  replacement for Data.Matrix in branch WIP
  https://github.com/Airini/FEECa/tree/WIP, but should still check for
  feasible component classes/types in the latter library)
• computing projections, due to 'sqrt', see 'project' in 'Simplex'
  <https://github.com/Airini/FEECa/blob/master/src/FEECa/
  Internal/Simplex.lhs>
• computations involving 'factorial' and 'choose' in 'Combinatorics'
  <https://github.com/Airini/FEECa/blob/master/src/FEECa/
  Utility/Combinatorics.lhs>

Initially, the existence of these class functions stemmed mostly from the
numerics behind integration of polynomials and other computations of the
like. Even though most practical uses of the library might involve ℝn, it
would be preferable to keep the classes neat and general.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3, or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AGnOhcfmXA9Ks3yIDTGgUq5cNhvFWUs0ks5q-e80gaJpZM4Ky0RU>

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAodYyXK7pp3Rmxcxv2aOs3ofkf5RCB9ks5q-1dlgaJpZM4Ky0RU
.

[simonpf]

I am definitely curious about this because I couldn't find a solution that
I was satisfied with.

But in the end every finite dimensional space is isomorphic to R^n so, if
I am not mistaken,
we are not loosing generality here.

On 16 November 2016 at 21:09, Patrik Jansson notifications@github.com
wrote:

To TODO came from me (also to me;-) and I have not studied the code enough
to know the answers yet, but one plausible direction is

1. introduce sqrt as an operation if that is what is needed
2. the constants (of a polynomial, form, etc.) are reasonably of the type
   of scalars underlying the form, and that need not (in general) be Double.
3. when, in the end, a concrete polynomial, form, etc. is constructed it
   will (normally) have scalars from Double (or Complex Double) but that
   should not restrict the degree of polymorphism of the library

There may be good reason to tie the class to Double, but if feels strange
(especially the toDouble part which basically precludes even complex
numbers).

/P

On 16 November 2016 at 20:20, simonpf notifications@github.com wrote:

I agree, this would indeed be nice. But how would you go on about this?
How
should we handle square roots? Moreover, I think we also need to be able
to programmatically introduce constants into the computations. How can we
do that without the conversion functions?

On 15 November 2016 at 18:43, Irene Lobo Valbuena <
notifications@github.com>
wrote:

Such as those converting to and from 'Double' in 'Field'
<https://github.com/Airini/FEECa/blob/master/src/FEECa/
Internal/Spaces.hs>.
So far, they are seen in:

• (pretty) printing
• testing, e.g. 'eqNum'
  <https://github.com/Airini/FEECa/blob/master/src/FEECa/
  Utility/Utility.hs>
  to account for margins of numerical error
• matrix related computations in those modules using HMatrix (note its
  replacement for Data.Matrix in branch WIP
  https://github.com/Airini/FEECa/tree/WIP, but should still check for
  feasible component classes/types in the latter library)
• computing projections, due to 'sqrt', see 'project' in 'Simplex'
  <https://github.com/Airini/FEECa/blob/master/src/FEECa/
  Internal/Simplex.lhs>
• computations involving 'factorial' and 'choose' in 'Combinatorics'
  <https://github.com/Airini/FEECa/blob/master/src/FEECa/
  Utility/Combinatorics.lhs>

Initially, the existence of these class functions stemmed mostly from
the
numerics behind integration of polynomials and other computations of
the
like. Even though most practical uses of the library might involve ℝn,
it
would be preferable to keep the classes neat and general.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3, or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AGnOhcfmXA9Ks3yIDTGgUq5cNhvFWUs0ks5q-e80gaJpZM4Ky0RU>

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#3 (comment), or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AAodYyXK7pp3Rmxcxv2aOs3ofkf5RCB9ks5q-1dlgaJpZM4Ky0RU>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGnOhT90wj_ZkYHBHlmicGAraXs6Yh5_ks5q-2MAgaJpZM4Ky0RU
.

[Airini]

That would be the case if the vector space were over ℝ itself, or another field isomorphic to it. There are finite fields (finite in cardinality, not basis cardinality), for instance.

Maybe you were referring to Euclidean spaces (?).

In any case, 'toDouble'/'fromDouble' wouldn't "belong" in the definition of the 'Field' class since for finite/Galois fields these embeddings (respecting the structure) would not exist. 'Double' is a concrete representation of what we understand ℝ to be but is not exact, in addition.

[simonpf]

Yes, you are right. I didn't consider fields different from $\mathbb{R}$ or
$\mathbb{C}$. Sorry for the confusion.

On 17 November 2016 at 14:28, Irene Lobo Valbuena notifications@github.com
wrote:

That would be the case if the vector space is over ℝ itself, or another
field isomorphic to it. There are finite fields (finite in cardinality, not
basis cardinality), for instance.

Maybe you were referring to Euclidean spaces (?).

In any case, 'toDouble'/'fromDouble' wouldn't "belong" in the definition
of the 'Field' class since for finite/Galois fields these embeddings
(respecting the structure) would not exist. 'Double' is a concrete
representation of what we understand ℝ to be but is not exact, in addition.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGnOhZIOfozCjqA3-xXANGDEQ50XSiIfks5q_FZ0gaJpZM4Ky0RU
.