On Thu, 03 Mar 2011 21:28:35 +0100 Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 03/03/2011 17:10, Chad Nelson wrote:
Not the same case at all. XInt isn't a language, it's a library that's explicitly designed for very large numbers. If someone didn't need numbers larger than the built-in types can handle, they wouldn't use it.
So you're already limiting the application area of XInt.
The problem is that the application area you're restricting it to doesn't seem to be the one that is the most likely to require arithmetic with infinite precision.
That makes no sense. It's a large-integer library. How does designing it specifically for large integers make it unsuitable for its purpose?
- So that the library is easily extendable
What would you want to do to the internals of it that it doesn't already provide, and that I wouldn't be willing or even eager to add?
There are hundreds of functions that you can use with integers, each with their own algorithms documented in various research papers. Do you really claim that your library can provide all of them?
Do they require specialized bit-twiddling? Or are they arithmetic operations that can be described in terms of functions that the library already provides?
[...] If the user provides a SIMD type as a digit, you'll get optimized SIMD code for free, for example, in a completely externalized way. Now *that* would be awesome. [...]
Yes, it would. But it would come at a cost.
The design I am proposing would allow you to "outsource" the low-level optimizations and concentrate on the algorithms.
Do you not see the value in this?
Certainly, but it doesn't outweigh the cost.
Something else, I went through a code a bit, and I saw virtual inheritance. Just why do you need dynamic dispatch in a design where all information is purely static?
For the policy-based options.
I don't see how that requires virtual inheritance.
Yes, it's always much easier to attack something than to build it in the first place. -- Chad Nelson Oak Circle Software, Inc. * * *