|
History
| Log In
|
|
|
|
If
I attached a sample that uses the dnAnalytics complex number class. Read the comments at the top of the file for instructions. Here's a sample: I put in support for both "i" and "j". If we had to decide, I'd say use "i" since it is what most people normally use, even though python uses "j" for some reason. import dnA.Math from "dnA" I've been making a science library for boo that uses the unit literals, and I have included Complex number support for it.
svn://ckknight.no-ip.org/Science Nice work! Would be great if this were to find its way into the standard library.
One basic issue remains, though: Is there a chance for one standard complex type that can be used across various libraries or should every numerics library reinvent the wheel? I fear that ultimately, the only one who could set a standard is Microsoft. If boo introduced a standard complex type, libraries like dnA or math.Net will not see it. If Mono introduces it, one cannot use it with microsoft .NET Just for the record: 'i' or 'j' are not necessarily "more or less common", but they are used by different communities. Physics and mathematics generally use 'i' while engineering uses 'j'. This is also why Python has the 'j'. However: neither of the two letters is used for any physical unit or as a type suffix for any type but complex in any other language (to my knowledge) So there is no harm in simply allowing both letters as synonyms. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Wish
Open
Major
Complex number literals and builtin type
This means: every library dealing with complex arithmetics has to define its own complex type. Which again means that all these libraries are incompatible with each other. Not a good idea at all!
For the moment, boo could probably just define some standard complex type but keep everything modular enough that it could be easily replaced by a more standard version in .NET or somewhere else.