More complete fixes, including integer stuff #96
Conversation
|
Also, is this PR of yours independent from the previous PR? |
|
|
||
| #if defined(PRINTF_SUPPORT_FLOAT) | ||
| // | ||
| // This is actually a fairly efficient implementation compared to pow() as it's |
There was a problem hiding this comment.
It may be more time efficient, but it's not more space efficient.
|
Interesting. On my current project, where I’ve worked hard to remove the use of as many standard library math functions as possible, this resulted in a much smaller implementation. The pow() library call depends on a whole set of other complex and large functions which can otherwise be avoided (obviously different if you are using pow() elsewhere.)
My use case has changed slightly and stack usage is my primary concern so I’ve written a different implementation (based on many of the concepts in your great implementation!) — so I’m not using the version below any more. So the PR’s are there for your use if you see anything useful, if not, then so be it.
Cheers,
Lee.
… On 30 Jun 2021, at 08:13, Eyal Rozenberg ***@***.***> wrote:
@eyalroz commented on this pull request.
In printf.c <#96 (comment)>:
> // import float.h for DBL_MAX
#if defined(PRINTF_SUPPORT_FLOAT)
#include <float.h>
#endif
+//
+// Helper macro to record and remove negativity (also works for -0.0)
+//
+#define _ISIGNCHECK(i,n) if (i < 0) { i = -i; n = 1; } else { n = 0; }
+#define _FSIGNCHECK(f,n) if (1.0/f < 0.0) { f = -f; n = 1; } else { n = 0; }
+
+#if defined(PRINTF_SUPPORT_FLOAT)
+//
+// This is actually a fairly efficient implementation compared to pow() as it's
It may be more time efficient, but it's not more space efficient.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#96 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAK4K3FYN2ETWJUUJ3NZ7XLTVK7XZANCNFSM4YU5GXIQ>.
|
Yes, but even then - you could use a loop to multiply (you only need ~log(p) steps, not p, if you square each time or square-and-multiply). That's slower than the lookup (typically), but might be smaller. Although TBH I haven't checked the size anywhere. In asymptotic terms you've certainly traded space to gain time, but that depends on how big the compiled multiplication loop ends up being. |
I think you're mistaking me for @mpaland ... I'm just trying to pick up PRs to add to my fork. |
Hi,
Further to my previous pull request, this one also sorts out the duplicate out_rev from the previous pull, but also fixes an issue with integer processing as well.
%#3x would truncate a two digit hex number (because of the 0x) previously which it shouldn't do. This is now fixed.
All tests still pass with the same exceptions as before (one incorrect and one "improved precision" related.)
Lee.