Base types, Collections, Diagnostics, IO, RegEx…
I'm pleased to let you all know that Microsoft released the first beta version of the next version of Visual Studio, Visual Studio Team System and Visual Studio Team Foundation Server. This of course also includes the next version of the .NET Framework and most of the new BCL features we've been blogging about in the last few months.
Read Soma's blog entry announcing Orcas Beta 1.
Visit the Visual Studio Code Name "Orcas" Download site for links to the downloads.
After releasing the BigInteger type in earlier CTPs we have received some good and constructive feedback from customers and partners that are interested in extended numerical types. We have learned that there are some potential improvements that we can make to this type to better serve their needs. As such, we decided to remove BigInteger from the Beta 1 release of Orcas so that we can address these issues and concerns. We would ask that you let us know if and how this affects you and what you would expect in a BigInteger class.
Inbar GazitThe BCL Team
Huh, what do you want to know? I guess to tell, you would need to let us know whether BigInteger is removed for good or just for Beta 1. Plus what sort of feedback you got that lead to this decision. Just stating "for some reasons it is gone, but we don't tell you the reasons nor whether it is gone for good" is a bit weird info.
What we would like to know is:
1. Do you have a need for an Integer type that is bigger than 64 bits?
2. What is the primary purpose/scenario for usage with such a type for you?
3. What operations are important for you?
4. What are your performance expectations?
5. Anything else you can tell us about how you intended to use BigInteger
At this point we did not make a final decision about the fate of BigInteger and your input may help us do so.
I would use a BigInt for scientific calculations. However, it's useless to me unless you add someway of knowing which types are ARITHMETIC!!! It's nearly impossible to make generic classes without this information. Please add an IArithmetic interface.
Scientific calculations. I often need to store arbitrarily large numbers where I do not know how many bits I will ultimately need.
At a bare minimum addition, subtraction, multiplication, and division. Later (such as post-Orcas), I would like to see power, roots, logarithm, and trig functions.
Generally scientific calculations. Accuracy and precision are paramount to efficiency.
I also second an IArithmetic interface. It is really difficult to design generic classes without it. (Especially since operator overloading --such as addition--is not possible with generics as they are implemented as static methods.)
It's difficult to make any concrete comments since it was removed from Beta 1.
Yes, I do have a need for an integer type larger than 64 bits. At present, I have my own custom implementation. It has a few rough spots that I would like to fix or replace with a better alternative. I use it in a number of situations when I can not have an upper limit.
I also request an IArithmetic interface for the above reasons. I believe that I made a similar request during Whidbey, as well. There does not appear to be any work on addressing generic operator overloading, which I must say is disappointing. At least an IArithmetic interface would be a compromise.
I BigInteger(accennati da Antonio in questo post ) sono numeri a lunghezza arbitraria. Oggi volevo proprio
Calculations on integers larger than 8 bytes, storing really large numbers, converting between Guids and 128-bit integers.
At the least, I would expect it to behave just like other integer types and I would expect all mathematical methods to have an overload available for it. It should be usable in ADO.NET as well for handling massive numeric types in databases.
Like other integers, there should be an implicit cast to be available from smaller integer types.
I would actually prefer an Int128 class and a BigInteger class which expands infinitely.
I would agree adding something like IArithmetic to all numeric types would be useful for generic methods/classes.
I would like it to be as fast as possible, but I realize this will depend on the machine it's running on and just how large the number is.
Maybe implementing an Int128 class would give a performance improvement over BigInteger for those who don't need more than 16 bytes of storage.
Were there flaws (errors, bugs, whatever) in the implementation? Or just improvements to be made?
I personally have not needed an integer type that large, but can see value, especially in the scientific/research community (F# users?). I would expect it to behave just like Int64, 32, 16, etc. as far as operations go.
I haven't had a chance to look at Orcas at all yet. Is there a BigFloat as well?
bitwise (two's complement most of all), basic arithmetic
as good as you can get it
I recently developed a fractal application using my own "complex" (based on two doubles) class. I found that after zooming in a few times I reach the limit of the double type resolution.
I was hoping for a quad precision type, but I think I'd do better with with a BigRational type, with which I can create classes such as BigComplex, PointBig, and RectangleBig. Then I can zoom into a fractal indefinitely.
I'd also use the Log function to use for the coloring scheme. (Maybe there's a work-around for that one.
The Dynamic Language Runtime has a Microsoft.Scripting.Math namespace with a BigInteger and a Complex64 type.
What is the relationship, if any, between this namespace and System.Numeric? Will there be two separate implementations, or will one of the two be discarded?