On "quite long posts", yes. I'm trying not to do that and the pendulum, may have swung too far in the other direction.. I was actually trying to not have many questions - be to the point, but was a little hasty and the interesting point was maybe too implicit. But there was A question:
"Should you use ::Real at every point to not get those [runtime errors] with Complex [eliminated]?" Trying again: A. "[higher generalizations of] numbers are not supported, but are they [available] in libraries or needed? Not available, I think. Needed? Maybe not, as they are just very obscure concepts (at least sedenions), but my general question applies even just to complex numbers, that is in the standard library: B. Is Julia, being a generic language, a good fit for them (and higher math/numbers) because it is generic, by default? A manifest typed language has no "problem" with numbers and new types. At least they just work and do not produce runtime errors. In a generic language you are writing code, you can't check even theoretically, as the code is generic and you expect it to work for even code not yet written.. That just seems not possible.. You will, however, not get wrong answers, just runtime exceptions. I guess that is a good thing. People advocating static languages, with separate compilatin, regard it as a good thing, that the compiler shakes out the bugs AND avoid runtime errors. C. Do all these generalization of numbers belong, or fit well, in a language like Julia? Or at least in packages. Sedenions, seem just very obscure. :) [I do not even know what "multiplicative normedness" is..] commutativity and associativity are common concepts you usually associate (and order) with numbers/reals (but a pitfall for floating point..). I wander when Julia knows that "rules" like these, I assume, like in C etc. they just know to special case floating point. Would "multiplicative normedness" trip Julia up? I do not even know if an operator applies to that.. Some context, that I maybe should have quoted, not just the linked: http://math.stackexchange.com/questions/86434/what-lies-beyond-the-sedenions "Reals" โ "Complex" โ "Quaternions" โ "Octonions" โ "Sedenions" With the following "properties": >From R to C you gain "algebraic-closure"-ness (but you throw away ordering). >From C to H we throw away commutativity. >From H to O we throw away associativity. >From O to S we throw away multiplicative normedness. Is it clear now? It is longer.. -- Palli. On Friday, August 28, 2015 at 11:43:52 AM UTC, Kristoffer Carlsson wrote: > > I am confused, what is the question? > > You seem to generally write quite long posts and it is hard to understand > what the actual question is. > > Usually, a short, to the point, example followed with the question makes > it easier to get good answers. > > On Friday, August 28, 2015 at 11:50:45 AM UTC+2, Pรกll Haraldsson wrote: >> >> Mostly about math (that I do not know to well, this advanced, above >> complex numbers), just seems relevant to generic programming..: >> >> In e.g.: >> https://en.wikipedia.org/wiki/Complex_number >> >> in the template at the bottom: >> >> Real numbers and extensions: >> >> Real numbers (โ) Complex numbers (โ) Quaternions (โ) Octonions (๐) >> Sedenions (๐) CayleyโDickson construction Dual numbers Split-complex >> numbers Bicomplex numbers Hypercomplex numbers Superreal numbers Irrational >> numbers Transcendental numbers Hyperreal numbers Levi-Civita field Surreal >> numbers >> >> >> http://math.stackexchange.com/questions/86434/what-lies-beyond-the-sedenions >> >> >> I see that dual numbers are supported already with a library, and know >> what Julia does support. >> >> >> Since Julia IS a scientific language, I checked: >> >> julia> 1+0im < 2+0im >> ERROR: `isless` has no method matching isless(::Complex{Int64}, >> ::Complex{Int64}) >> in < at operators.jl:32 >> >> that is the right thing. I wander what MATLAB does, since all numbers(?) >> are stored as complex. 0im special cased? >> >> >> real numbers have properties that floating point already doesn't support, >> so loosing those properties with higher order numbers seems not to be an >> issue, but is it for the even higher order numbers and those properties? I >> assume not, as there are no operators/functions and even if there where >> operators (really just functions), then they would just stop working. >> >> In a language where everything is typed (not generic), this might not be >> a problem, but leads to run-time "ERROR"s/exceptions. Should you use ::Real >> at every point to not get those with Complex? What about other possible >> numbers? >> >> >> Thanks in advance, >> -- >> Palli. >> >> >>
