search

Airini / FEECa

FEECa: Finite Element Exterior Calculus in Haskell
BSD 3-Clause "New" or "Revised" License
34 stars 7 forks source link

Remove "synthetic/implementation" class functions #3

Open Airini opened 7 years ago

Airini commented 7 years ago

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.

simonpf commented 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:

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 .

patrikja commented 7 years ago

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:

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 .

simonpf commented 7 years ago

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:

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 .

Airini commented 7 years ago

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 commented 7 years ago

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 .