I don't know why some of the tests are failing, I think it is because of rounding errors, but I didn't change anything that would affect what the test is testing

Thanks, but to be honest, this all looks overly complicated to me for something that interest isn't even very high.

Why is it so complicated? Do you even bother to do anything on the bit-level? I can understand working with the mantissa and exponent of the integer. But I would hope we can keep it at that at most. If this doesn't condense down to a fraction of the complexity, I think this will be a very hard to impossible sell.

(There are other issues also in the mantissa code, but we can work on that later.)

Thanks, but to be honest, this all looks overly complicated to me for something that interest isn't even very high.

I understand the interest is not that high, but it was something that I have never worked with before and I wanted to challenge myself.

Why is it so complicated?

I also understand that the code is complicated, because this is a complicated problem. Most of my issues came from reading thepython long, and extracting the correct information from an arbitrarily sized number (I've seen apython long of 3 kilo bytes). That's why each helper function has a clear purpose.

Do you even bother to do anything on the bit-level?

I don't understand this question. I do use bit-level operations, although the general case doesn't because there is no standard of what along double is and how it is stored (Just means something bigger than a double).

If this doesn't condense down to a fraction of the complexity, I think this will be a very hard to impossible sell.

I understand, but it would be a big help if you could point out the more complex parts. But I do feel this is less complex than the code before.

(There are other issues also in the mantissa code, but we can work on that later.)

I would love to know the issues you've found, as I know the code is not perfect.

Side comment: The bitwise code was made before the general one, as I made it to try to understand how it all works; Then during testing I found it was up to 3x faster than the general code.

Thanks for the feedback@seberg, I'm still kind of new to contributing to numpy so all feedback is welcome

I would love to know the issues you've found, as I know the code is not perfect.

For one, you are neither checking for Python errors, nor doing reference counting.

Then during testing I found it was up to 3x faster than the general code.

OK, I see you have a generic version, but I suspect the take-away should be that the generic version is doing something odd if it is 3x slower. For small numbers, it's a trivial cast (basically) and for large numbers all that Python work you are doing should be far slower anyway. I.e. I would expect the Python computation there to be the interesting part that we should spend time on thinking about.

For example, useldexpl, rather thanexpl. But even if huge numbers were 3x slower, I wouldn't care, the goal is for this to be much faster and avoid a crash. But if it is much more complex then there is little point.

@seberg I can remove the part that has the bitwise operations, and just leave the general case if that would be best?

@seberg I can remove the part that has the bitwise operations, and just leave the general case if that would be best?

Yes, I think I was clear I don't want to consider any non-generic solution, it'll just be a potential bug magnet with very little gain. You might convince someone in a follow-up PR if there is a massive speed-up to a real world use-case.

@seberg I removed any non generic solutions