Open Airini opened 7 years ago
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 https://github.com/Airini/FEECa/issues/3, or mute the thread https://github.com/notifications/unsubscribe-auth/AGnOhcfmXA9Ks3yIDTGgUq5cNhvFWUs0ks5q-e80gaJpZM4Ky0RU .
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 https://github.com/Airini/FEECa/issues/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 https://github.com/Airini/FEECa/issues/3#issuecomment-261044039, or mute the thread https://github.com/notifications/unsubscribe-auth/AAodYyXK7pp3Rmxcxv2aOs3ofkf5RCB9ks5q-1dlgaJpZM4Ky0RU .
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 https://github.com/Airini/FEECa/issues/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 https://github.com/Airini/FEECa/issues/3#issuecomment-261044039, 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 https://github.com/Airini/FEECa/issues/3#issuecomment-261057197, or mute the thread https://github.com/notifications/unsubscribe-auth/AGnOhT90wj_ZkYHBHlmicGAraXs6Yh5_ks5q-2MAgaJpZM4Ky0RU .
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.
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 https://github.com/Airini/FEECa/issues/3#issuecomment-261246105, or mute the thread https://github.com/notifications/unsubscribe-auth/AGnOhZIOfozCjqA3-xXANGDEQ50XSiIfks5q_FZ0gaJpZM4Ky0RU .
Such as those converting to and from 'Double' in 'Field'. So far, they are seen in:
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.