.Net 和 C# 中的多态数值

发布于 2024-08-24 12:43:21 字数 942 浏览 12 评论 0原文

令人遗憾的是，.Net 中没有数字的多态性，即没有统一不同类型数字类型（如 bool、byte、uint、int 等）的 INumeric 接口。在极端情况下，人们会想要一个完整的抽象包代数类型。

Joe Duffy 有一篇关于此问题的文章：

http ://www.bluebytesoftware.com/blog/CommentView,guid,14b37ade-3110-4596-9d6e-bacdcd75baa8.aspx

你会如何用 C# 表达这一点，以便对其进行改造，而不影响 .Net还是C#？

我有一个想法，首先定义一个或多个抽象类型（接口，例如 INumeric - 或更抽象），然后定义实现这些类型的结构并包装类型，例如 int，同时提供返回新类型的操作（例如 Integer32 ： INumeric; 其中加法被定义为

public Integer32 Add(Integer32 other)
{
    return Return(Value + other.Value);
}

我有点担心这段代码的执行速度，但至少它是抽象的......

其他

想法吗？

还有如果它不能具有这种抽象，我认为 -

抽象就是重用

更新：

这是迄今为止的一个示例实现类型签名：

public struct Integer32 : INumeric<Integer32, Int32>, IOrder<Integer32, Int32>

补偿协变返回类型的缺乏。

原文

It's a real shame that in .Net there is no polymorphism for numbers, i.e. no INumeric interface that unifies the different kinds of numerical types such as bool, byte, uint, int, etc. In the extreme one would like a complete package of abstract algebra types.

Joe Duffy has an article about the issue:

http://www.bluebytesoftware.com/blog/CommentView,guid,14b37ade-3110-4596-9d6e-bacdcd75baa8.aspx

How would you express this in C#, in order to retrofit it, without having influence over .Net or C#?

I have one idea that involves first defining one or more abstract types (interfaces such as INumeric - or more abstract than that) and then defining structs that implement these and wrap types such as int while providing operations that return the new type (e.g. Integer32 : INumeric; where addition would be defined as

public Integer32 Add(Integer32 other)
{
    return Return(Value + other.Value);
}

I am somewhat afraid of the execution speed of this code but at least it is abstract.

No operator overloading goodness...

Any other ideas?

.Net doesn't look like a viable long-term platform if it cannot have this kind of abstraction I think - and be efficient about it.

Abstraction is reuse.

update:

This is an example implementation type signature so far:

public struct Integer32 : INumeric<Integer32, Int32>, IOrder<Integer32, Int32>

Compensating for the lack of covariant return types.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

沧桑㈠ 2024-08-31 12:43:22

csharp 语言团队已经在研究这个问题。如果您想了解 C# 中类型类的未来，请开始阅读

https://github。 com/dotnet/csharplang/issues/164

它似乎得到了 Mads Torgesson 的支持，因此这不仅仅是一个流浪的 Haskell 粉丝的随机帖子。

C# 领域中给出的类型类或形状示例请

public shape SGroup<T>
{
    static T operator +(T t1, T t2);
    static T Zero { get; }
}

注意，这与接口不同。它正在声明属于 SGroup 的静态方法。继续阅读以了解更多详细信息和讨论。

The csharp language team is already looking into this. If you want a view onto the future of type classes in C# start reading at

https://github.com/dotnet/csharplang/issues/164

It seems to have the support of Mads Torgesson so it's not just a random post by a wandering Haskell fanboy.

The example given of a typeclass or shape in C# land is

public shape SGroup<T>
{
    static T operator +(T t1, T t2);
    static T Zero { get; }
}

notice this is not like an interface. It is declaring static method that belong to SGroup. Read on for more details and discussion.

回复收藏 0 原文

月依秋水 2024-08-31 12:43:22

如果您计划使用 C# 4.0，那么您可以使用 dynamic 轻松模拟通用数学运算。这是一个简单的加法函数的示例（有关详细信息查看此博客)：

public static T Add<T>(T a, T b) {
  dynamic ad = a;
  dynamic bd = b;
  return ad + bd;
}

我还没有玩过这个，所以我不能对性能说太多。使用动态肯定会付出一些性能代价，但我认为如果您多次调用该函数，DLR 应该能够进行非常有效的优化。事实上，如果它具有与上面提到的通用运算符类似的性能特征，我不会感到惊讶。

If you plan to use C# 4.0 then you can easily simulate generic mathematical operations using dynamic. Here is an example of a simple addition function (for more information see this blog):

public static T Add<T>(T a, T b) {
  dynamic ad = a;
  dynamic bd = b;
  return ad + bd;
}

I haven't played with this, so I can't say much about the performance. There will certainly be some performance price for using dynamic, but I think the DLR should be able to do very effective optimizations if you'll invoke the function multiple times. In fact, I won't be surprised if it had similar performance profile as Generic Operators mentioned above.

回复收藏 0 原文