Windows Calculator invalid input with 10^x function(tenforums.com)
tenforums.com
Windows Calculator invalid input with 10^x function
https://www.tenforums.com/software-apps/111414-windows-calculator-invalid-input-10-x-function.html
92 comments
Very interesting. The XP calc.exe/Calculator Plus is able to compute 10^43429 (and the result is 1.e+43429), but not 10^43430.
What's the significance of 43430?
According to Mathematica,
Edit: some more interesting, possibly relevant search results for the numbers 43429 and 43430:
https://stackoverflow.com/questions/33515746/why-is-this-c-p...
http://delphiforfun.org/NewsLetters/Nbr32.htm
What's the significance of 43430?
e^99999 = 1.0325137485899245994533393888277e+43429
e^100000 = 2.8066633604261231793183858185717e+43429
e^100001 = Invalid input for function.
According to Mathematica,
e^100001 = 7.6293020112481304176946586569717e+43429
e^100002 = 2.0738593021001839250781552880629e+43430
ln(1e+43429) = 99998.968003638410011217350885487
ln(1e+43430) = 100001.27058873140405690136887694
Edit: some more interesting, possibly relevant search results for the numbers 43429 and 43430:
https://stackoverflow.com/questions/33515746/why-is-this-c-p...
http://delphiforfun.org/NewsLetters/Nbr32.htm
Nice work! The internal use of e^x also was confirmed below for the Windows 10 calc (using another method).
See https://news.ycombinator.com/item?id=17675777 on this page.
https://imgur.com/a/ukSUOhM
Holy crap. How on Earth did they manage to break Windows Calculator, of all things?
Holy crap. How on Earth did they manage to break Windows Calculator, of all things?
In a few years Windows will be just a red button that makes farting sound when pressed.
EDIT: and telemetry.
EDIT: and telemetry.
What’s even more bizarre is how often they update the Win10 calculator app from the Windows store. Never had any idea that a calculator would need bi-weekly updates, but shrug
By writing a whole new one without considering the 20%. It's also missing a lot of features compared to the old one. (Features that may not matter to everyone, granted, but I found that there were more things that weren't there for my typical uses than ones that were.) Installing the old calculator[1] isn't much of a problem, though - although you do need to pin it to make it easily accessible without finding yourself opening the new uselessness accidentally about 50% of the time.
[1] https://winaero.com/download.php?view.1795
[1] https://winaero.com/download.php?view.1795
They wrote a new calculator for Win10, but AFAIK this breakage wasn't because they actually rewrote it again (as evidenced by the fact that it hasn't changed in any other obvious ways), but because of some subtle and as-yet-unknown change --- exactly the type of thing that horrifies me about silent automatic updates. What used to work is now subtly broken, and no one knows why.
Googling around, I found another discussion on it:
https://www.eevblog.com/forum/chat/windows-10-calculator-bug...
Googling around, I found another discussion on it:
https://www.eevblog.com/forum/chat/windows-10-calculator-bug...
If you're going to add something, add something better than the old Calc, unless you really need some feature that only exists on that Calc. I use their PowerCalc Powertoy for Windows XP. [1] There's also SpeedCrunch which in some ways is probably better (minus the plotting) but personally I'm used to PowerCalc.
[1] https://imgur.com/gi0jmdI
[1] https://imgur.com/gi0jmdI
I prefer Microsoft Calculator Plus:
http://web.archive.org/web/20111213184700/http://download.mi...
(No, not the new abomination of the same name that comes up when you search for "Calculator Plus", but the original XP-era one that is now only available from archive.org. Irritatingly enough, MS removed the old --- and better --- one when they introduced the new one.)
The one from 7 up to 8.1 has its own problems:
https://news.ycombinator.com/item?id=10791667
http://web.archive.org/web/20111213184700/http://download.mi...
(No, not the new abomination of the same name that comes up when you search for "Calculator Plus", but the original XP-era one that is now only available from archive.org. Irritatingly enough, MS removed the old --- and better --- one when they introduced the new one.)
The one from 7 up to 8.1 has its own problems:
https://news.ycombinator.com/item?id=10791667
Confused, isn't that just the built-in Calculator with an optional (extremely ugly) skin enabled by default? What do you like about it?
It's easier to get than finding an XP installation or ISO to extract a calc.exe from. The installer is also signed by MS, which may be a factor in some highly locked-down corporate environments.
I launch apl in my terminal if the calculation I need to do is simple and Wolfram|Alpha otherwise
I just use an actual calculator.
APL as in... the programming language? Or something else? I'm not sure what you're referring to.
It wouldn't surprise me - I'll often do the same with Python on non-Windows systems rather than bothering with the native calculator; I'm not even sure if Linux has one (or if it's the same across distros), and Python is ubiquitous, fast, and has familiar syntax.
[deleted]
Same here, I don't have an actual calculator program so python is generally the quickest way for me.
Presumably APL the programming language.
Personally I used to use Maple for this kind of thing circa 2002. It used to launch on Windows in a fraction of a second (faster than the built in calculator tool!), and was an amazing calculator for pretty much any purpose.
Unfortunately some version of Maple around that time switched to a Java-based front end, and thereafter took forever to load, and had a UI littered with glitches.
Personally I used to use Maple for this kind of thing circa 2002. It used to launch on Windows in a fraction of a second (faster than the built in calculator tool!), and was an amazing calculator for pretty much any purpose.
Unfortunately some version of Maple around that time switched to a Java-based front end, and thereafter took forever to load, and had a UI littered with glitches.
I've used J (a language in the APL lineage) as an interactive calculator before. It makes some things pretty easy, especially if you need to operate on series of numbers.
What's the sum of the numbers from 15 to 20 inclusive?
What's the sum of the numbers from 15 to 20 inclusive?
i.6 N.B. Returns an array 0 1 2 3 4 5
15 + i.6 N.B. Returns an array 15 16 17 18 19 20
+/ 15 + i.6 N.B. returns the number 105
They're learning from GNOME! (GNOME whatever the latest version includes a new calculator that is an awful step backwards compared to the old one, luckily I can still install the old one).
And it is slower, really noticeably slower in terms of startup time than the old calc.exe in windows 7 and before. Not to mention it covers 50% of the screen for no reason.
They didn't write a whole new calculator engine, just a new UI and app wrapper for the old one.
If the new one just wraps the old one, but the new one breaks on certain inputs, how is it breaking? Maybe the outer "new" layer uses a new string to number parser than the inner "old" layer used to use, and that's where the bugs are being introduced?
They continued to update the underlying engine with new features and bug fixes and new bugs, they just didn't rewrite it from scratch.
Apparently a recent update also fixed a longstanding problem where the square root of a perfect square integer doesn't give you the exact right answer, so maybe there was a general change to the implementation of exponents and roots which may have introduced this bug too.
Apparently a recent update also fixed a longstanding problem where the square root of a perfect square integer doesn't give you the exact right answer, so maybe there was a general change to the implementation of exponents and roots which may have introduced this bug too.
If I had to take a first guess since 1e10000 is an overflow in the current version therefore x = 1e9999 is the last valid 10^x input. If that holds true my guess would be someone added a check for that input but did it as "5 or more digits" rather than "10,000 or more".
My second guess is they are using some weird algorithm that hits an error case due to the limits of whatever number type they are using.
My second guess is they are using some weird algorithm that hits an error case due to the limits of whatever number type they are using.
I wonder if they're using a fraction type to store decimals (a reasonable way to avoid floating-point error), and when the 10^x function is implemented naively on this type, 10^(3.1415) becomes 10^(31415/10000) = (10^31415 / 10^10000) = (overflow / overflow).
> 10^(31415/10000) = (10^31415 / 10^10000)
If n^(a/b) = (n^a)/(n^b) then 2^(1/2) = (2^1)/(2^2) = 2/4 = 0.5 but 2^(1/2) = sqrt(2) = 1.4...
If n^(a/b) = (n^a)/(n^b) then 2^(1/2) = (2^1)/(2^2) = 2/4 = 0.5 but 2^(1/2) = sqrt(2) = 1.4...
Dang, you're right, I should have known that. I apologize for my bad math.
It would be the 10000th root of 10^31415, and at this point what I'm saying is probably entirely unrelated to how it's really implemented.
It would be the 10000th root of 10^31415, and at this point what I'm saying is probably entirely unrelated to how it's really implemented.
Until last month doing sqrt of 4 or other perfect squares would give small errors
Wait, what? It works fine for me. https://imgur.com/a/LvZtIOd
Your windows might be out of date. It fails for me too.
I don't think so. See this thread: https://news.ycombinator.com/item?id=17675426 I'm on 10.0.17134.191 whereas it fails for people on both 10.0.17134.191 and 10.0.17134.167.
I think apps update separately from the OS
It may have been the same update that made this change https://blogs.msdn.microsoft.com/oldnewthing/20180704-00/?p=...
It may have been the same update that made this change https://blogs.msdn.microsoft.com/oldnewthing/20180704-00/?p=...
Who cares? It looks all flat and fashionable which is what you really care about.
Seems the issue occurs at some range (10^0,39794 - ?]
10^0,43407 - Invalid Input
10^0,00001 - OK
10^0,50001 - Invalid Input
10^0,40001 - Invalid Input
10^0,30001 - OK
10^0,35001 - OK
10^0,39999 - Invalid Input
10^0,37501 - OK
10^0,38751 - OK
10^0,39375 - OK
10^0,39794 - OK
10^0,39795 - Invalid Input 10^0,397941 - Invalid Input
10^0,397940000001 - Invalid Input 10^0,39375 - OK
10^0,393751 - Invalid Input
10^0,39376 - OK 10^0,123456 - Invalid InputThere seems to be a clear pattern for > 5 digits after the decimal:
5 digits - Valid: <=0.39794, Invalid: >=0.39795
10^0.39794 < 2.5
10^0.39795 > 2.5
6 digits - Valid: <=0.043429, Invalid: >=0.043431
7 digits - Valid: <=0.0043429, Invalid: >=0.0043431
8 digits - Valid: <=0.00043429, Invalid: >=0.00043431
10^0.043429 ~= e^0.1
10^0.0043429 ~= e^0.01
10^0.00043429 ~= e^0.001
So that gives some insight into the algorithm that is being used
10^0.0043429 ~= e^0.01
10^0.00043429 ~= e^0.001
So that gives some insight into the algorithm that is being used
Using this we can actually predict the smallest exponent that fails for other bases:
base exponent (6 digits)
10 0.043429
11 0.041703
12 0.040243
2 0.144271
3 0.091024
4 0.072135
1000 0.014476
Just checked, calc fails at 11^0.41703 (curiously not at 41703, but 41704, maybe a floating point thing). Maybe it changes base to e and uses the Taylor series for e^x, but fails if x is too precise for what it expects?
Fantastic, that confirms it! And kudos to barbegal for recognizing the base.
if only the source code were publicly available, then the real problem could be realized, patches proposed, etc. enjoy waiting on microsoft to patch it, they're probably too busy 'loving open source.'
Even from a strictly business standpoint it certainly makes sense to open-source things like the calculator, since I doubt the source contains any proprietary IP that gives it any particular competitive advantage --- and in the "basic calculator app" space, there is certainly a lot of competition.
Then again, the fact that they managed to break one of the most conceptually simple applications that comes with Windows --- for seemingly no good reason at all --- speaks volumes about the quality of MS products these days...
Then again, the fact that they managed to break one of the most conceptually simple applications that comes with Windows --- for seemingly no good reason at all --- speaks volumes about the quality of MS products these days...
https://www.macrumors.com/2017/10/30/ios-11-2-beta-fixes-cal...
http://nuclearrambo.com/wordpress/google-calculator-bug-3999...
Things break.
http://nuclearrambo.com/wordpress/google-calculator-bug-3999...
Things break.
I'm not sure what you're trying to say. Are we supposed to consider it normal that something which used to work is now broken? I hope not, especially with something as well-defined as a calculator.
> Then again, the fact that they managed to break one of the most conceptually simple applications that comes with Windows --- for seemingly no good reason at all --- speaks volumes about the quality of MS products these days...
[deleted]
I love how the first comment is from a "guru" with nothing better to say than:
> Do you really think it is going to make much difference to the final answer?
Doesn't matter, it should work.
> Do you really think it is going to make much difference to the final answer?
Doesn't matter, it should work.
Power users on many forums love to adopt this attitude.
This really stood out to me as well. That kind of response is, for lack of a better word, cringy. "You probably don't need that anyway so ignore the fact that it's broken!" Sure...
This!!! I've noticed how "forums" (as opposed to reddit-style discussion boards which are moderated) tend to have this sort of "first post!11!!!" behavior. If you look at that user's post history, he or she has contributed, but - also is providing lots, and lots of commentary. And while that commentary is useful, it's not necessarily moving the ball on solving whatever the problem of the day is.
I see the same thing in travel forums frequently.
I see the same thing in travel forums frequently.
Some guy answering every post with some generic "try these troubleshooting steps" which are all completely unrelated to the question. That guy should be a bot or a sticky post...
I'm wondering if there are sites that have people on agreements to answer "200 posts/month" for a fixed pay or something, or get paid per answered question within 48h. In any case: it's not helping.
I'm wondering if there are sites that have people on agreements to answer "200 posts/month" for a fixed pay or something, or get paid per answered question within 48h. In any case: it's not helping.
I get you're being a bit coy, but I have no trouble believing it's just some person who enjoys the small power rush of being "the guy w/ the answers". I've seen this tons of times with employees in Slack/Teams chat, ones who just chime in on virtually any topic with a copy/paste answer and a condescending attitude. It's a power thing, they enjoy being the one who knows everything and lays down the law.
From both a technical and managerial standpoint, it can be insanely frustrating, with the only bright-side being that for very basic questions you at least get good coverage.
From both a technical and managerial standpoint, it can be insanely frustrating, with the only bright-side being that for very basic questions you at least get good coverage.
I think about community quality content a lot. I see a lot of abuse of this all over reddit and other forums and stack overflow too. People have figured out how to game the system. I think the internet is ready for some forum software that uses machine learning to decide whether content is high or low quality. It could analyze the replies, the context, the content, the user's history, posting rates, all sorts of data is available to recognize low quality content and low quality users. Especially when you realize that a lot of reddit accounts are bots that farm points and then get sold. ML seems like the only real way to protect communities against this!
> People have figured out how to game the system. I think the internet is ready for some forum software that uses machine learning to decide whether content is high or low quality.
Great idea. Then there'll be absolutely no chance people will find a way to game the system.
Great idea. Then there'll be absolutely no chance people will find a way to game the system.
Mission accomplished:
https://xkcd.com/810/
[deleted]
You think that's bad? I once reported a bug in Apple's calculator in OS X, and it was fixed by the next release.
If you started out with a cleared calculator with default settings and computed 14479.14 - 152.36 you got 14326.78.
If you started out with a cleared calculator with default settings and computed 1143/78, and then computed 14479.14 - 152.36, you got something like 14326.779999999999.
The number of people on forums who completely missed the point and lectured me, often rather condescendingly, on how neither 14479.14 nor 152.36 are exactly representable in finite binary floating point and so that is why the subtraction was not exact was astonishing.
The bug is not that the subtraction is inexact. The bug is that the same subtraction result was displayed with different rounding depending on whether it was done immediately after a clear or done after computing 1143/78.
How 14479.14 - 152.36 displays should only depend on the calculator settings. That it changed depending on previous calculations suggest that there was probably a scratch variable used during calculations that was supposed to be reset before the next calculation but was not.
Speaking of the MacOS calculator, their RPN mode really annoys me (although not as much as Windows 10 calculator which doesn't even have an RPN mode!). Suppose you want to compute (2+3) x 4. The obvious key sequence works: 2 enter 3 + 4 x.
How about (2+3) x pi. The obvious key sequence is: 2 enter 3 + pi x. The result of that is an error beep with pi in the display, or, if you had anything on the stack before you started, that thing multiplied by pi.
That's because rather than pushing pi onto the stack, the pi key replaces whatever is on the bottom of the stack with pi. In other words, instead of acting as if you had hit the keys 3 . 1 4 1 5 9 ... 7 9 3, it acts as if it pops the stack, invokes the function
What you have to do is: 2 enter 3 + enter pi x.
Suppose you decide you don't want to have to remember the distinction between the pi key and numerical entry, and decide to just always put in that enter.
So: 2 enter 3 + enter 4 x. That gives you 20 like you would expect...but also leaves a 5 on the stack above that.
For comparison, that does not happen on an HP-15, or on software calculators that follow HP RPN rules, such as pcalc on iOS. On those, when you press enter it duplicates the item currently on the top of the stack, just like Apple's calculator, but it sets a flag that says if you immediately enter a number, that overwrites the top of stack instead of pushing.
This flag was a key thing that made data entry on the HP calculators feel natural.
On the HP-48 they made a significant change to this. When you pressed enter it did not immediately dup the stack and set the flag saying numerical entry should overwrite. Instead, pressing enter did not immediately do anything to the stack. Instead, it set a flag saying that if your next action was to enter a number, first dup the top of stack.
The RPN mode on pcalc lets you select if you want HP-48 stack behavior or classic RPN behavior (it is in advanced settings when you are in RPN mode).
Here's an article on how RPN evolved at HP: http://h20331.www2.hp.com/hpsub/downloads/S07%20HP%20RPN%20E...
If you started out with a cleared calculator with default settings and computed 14479.14 - 152.36 you got 14326.78.
If you started out with a cleared calculator with default settings and computed 1143/78, and then computed 14479.14 - 152.36, you got something like 14326.779999999999.
The number of people on forums who completely missed the point and lectured me, often rather condescendingly, on how neither 14479.14 nor 152.36 are exactly representable in finite binary floating point and so that is why the subtraction was not exact was astonishing.
The bug is not that the subtraction is inexact. The bug is that the same subtraction result was displayed with different rounding depending on whether it was done immediately after a clear or done after computing 1143/78.
How 14479.14 - 152.36 displays should only depend on the calculator settings. That it changed depending on previous calculations suggest that there was probably a scratch variable used during calculations that was supposed to be reset before the next calculation but was not.
Speaking of the MacOS calculator, their RPN mode really annoys me (although not as much as Windows 10 calculator which doesn't even have an RPN mode!). Suppose you want to compute (2+3) x 4. The obvious key sequence works: 2 enter 3 + 4 x.
How about (2+3) x pi. The obvious key sequence is: 2 enter 3 + pi x. The result of that is an error beep with pi in the display, or, if you had anything on the stack before you started, that thing multiplied by pi.
That's because rather than pushing pi onto the stack, the pi key replaces whatever is on the bottom of the stack with pi. In other words, instead of acting as if you had hit the keys 3 . 1 4 1 5 9 ... 7 9 3, it acts as if it pops the stack, invokes the function
def pi(x):
return 3.141592653589793
What you have to do is: 2 enter 3 + enter pi x.
Suppose you decide you don't want to have to remember the distinction between the pi key and numerical entry, and decide to just always put in that enter.
So: 2 enter 3 + enter 4 x. That gives you 20 like you would expect...but also leaves a 5 on the stack above that.
For comparison, that does not happen on an HP-15, or on software calculators that follow HP RPN rules, such as pcalc on iOS. On those, when you press enter it duplicates the item currently on the top of the stack, just like Apple's calculator, but it sets a flag that says if you immediately enter a number, that overwrites the top of stack instead of pushing.
This flag was a key thing that made data entry on the HP calculators feel natural.
On the HP-48 they made a significant change to this. When you pressed enter it did not immediately dup the stack and set the flag saying numerical entry should overwrite. Instead, pressing enter did not immediately do anything to the stack. Instead, it set a flag saying that if your next action was to enter a number, first dup the top of stack.
The RPN mode on pcalc lets you select if you want HP-48 stack behavior or classic RPN behavior (it is in advanced settings when you are in RPN mode).
Here's an article on how RPN evolved at HP: http://h20331.www2.hp.com/hpsub/downloads/S07%20HP%20RPN%20E...
How 14479.14 - 152.36 displays should only depend on the calculator settings. That it changed depending on previous calculations suggest that there was probably a scratch variable used during calculations that was supposed to be reset before the next calculation but was not.
...and my guess is that "scratch variable" is actually a flag that switches calculations between fixed-point and floating-point mode; the first subtraction was done in fixed-point mode, but when it did the division it used floating-point, and then kept that mode for future calculations until explicitly cleared.
...and my guess is that "scratch variable" is actually a flag that switches calculations between fixed-point and floating-point mode; the first subtraction was done in fixed-point mode, but when it did the division it used floating-point, and then kept that mode for future calculations until explicitly cleared.
As long as there are people like you, there is hope for the world....
I find galculator quite nice. And Free42 on my phone.
One day I will buy the DM42.
I don't really need it. But I _need_ it.
One day I will buy the DM42.
I don't really need it. But I _need_ it.
The differentiation is neither "digits" nor "significant figures". 10000 throws the "invalid input" error, while 0.00000001 does not. Both of these numbers have exactly one significant figure, and the latter clearly has more digits.
It seems that 0.00001 gives "Invalid Input", but 0.00000001 works.
EDIT: Strangely, now all inputs seem to work, even 0.00001 and even when I restart the calculator. Not sure why ...
EDIT: Strangely, now all inputs seem to work, even 0.00001 and even when I restart the calculator. Not sure why ...
Just tried again - .00001 works for me, but .43407 still doesn't...
Confirmed, on mine .43407 gives "Invalid input". I was getting "Invalid input" earlier for 0.00001 and 0.00003 (the first two examples I tried), but now they seem to work.
EDIT: Manually typing in 10, the x^y button, then 0.43407 also gives "Invalid input".
EDIT: Manually typing in 10, the x^y button, then 0.43407 also gives "Invalid input".
Someone in the comment thread suggested that perhaps the decimal point is ignored altogether, and some inputs get rejected as being too large.
If that is true, then 0.00001 is being tread the same as 1, but 12345 and 0.12345 are both considered being "too large".
FWIW, I can't reproduce the bug with my current Windows build (1703 / 15063.296).
If that is true, then 0.00001 is being tread the same as 1, but 12345 and 0.12345 are both considered being "too large".
FWIW, I can't reproduce the bug with my current Windows build (1703 / 15063.296).
It's baffling to me why they don't implement arbitrary precision arithmetic. bc (a calcuator for unix) can do that since 1975 :)
This is from June and looks like it is fixed, I can do 10^x functions on my work PC in the Windows calculator.
Edit: see comment below
Edit: see comment below
Not fixed for me, fully patched 1803.
> 1803
This made me check and apparently IT here (large international networking hardware company) hasn't patched Windows since April. I always assumed everything auto updated, evidently our policy is the exact opposite.
This made me check and apparently IT here (large international networking hardware company) hasn't patched Windows since April. I always assumed everything auto updated, evidently our policy is the exact opposite.
What is your full version number? If you open the command prompt it should say something like Microsoft Windows [Version 10.0.17134.???]. You could also run 'ver'.
Yeah, I guess I can tell you that. I'm on 10.0.17134.191
Yeah same as mine, that should be fully patched indeed. Except I can't reproduce the problem on mine, so this is really bizarre: https://news.ycombinator.com/item?id=17675413
You should probably be looking at the calculator version (menu button -> About. mine is 10.1806.1821.0, and has this problem) rather than the OS version. Apps can be updated independently of the OS.
Whoa, very interesting, great call! I see 10.1712.10601.0 as the version for mine. Why would it not have updated along with the rest of Windows? EDIT: Oh, because I've disabled automatic app updates. :-)
Mine fails.
[Version 10.0.17134.167]
[Version 10.0.17134.167]
Not fixed for me - I just tried 10^0.43407 and yup, "Invalid Input". And I know I'm up to date because I just came back to find my PC in the middle of updating the other day.
For me one of my updates had failed, so I was still getting security patches but not major version upgrades. Had to figure out the problem (media feature pack) and then update.
Some work, did you try greater than 5 digits like the post said?
I see this as perfect opportunity for Microsoft to show how they're all open and transparent.
1. Introduce a bug which only 1% would encounter. 2. Wait for it to get noticed. 3. Fix the bug, explain the causes in detail, thank everyone. 4. Profit ;)
1. Introduce a bug which only 1% would encounter. 2. Wait for it to get noticed. 3. Fix the bug, explain the causes in detail, thank everyone. 4. Profit ;)
Can confirm I have this and I'm on the fastest insider build ring. There seems to be differences between how input is made etc which leads me to think there is something more to it than just "makes the wrong calculation".
I wouldn't trust the windows calculator anyways for anything beyond trivial arithmetic. Use an environment where you have actual control over how the calculations are performed.
This doesn't appear to be only with the 10^x function - the x^y function exhibits the same behaviour (both for x=10 and at the least x=9; I haven't tried many others)
I guess when you are Microsoft you don't have to test software internally since millions will do it for you for free. Also for what it's worth I didn't have any problems with these numbers on `kcalc` in KDE (not that I expected to see it, but worth a shot)
In Windows 10, 4.3431 results in "Invalid input" but 4.3429 does not. (Nor does 4.3430, but obviously so.)
What's the significance of 43430?