KThirtyDays = 3000 * 24;

The_MAZZTer

http://src.chromium.org/viewvc/chrome/trunk/src/chrome/installer/util/google_chrome_distribution.cc?r1=46994&r2=46993

from Google Chrome / Chromium :)

Bug talking about this change: http://code.google.com/p/chromium/issues/detail?id=43891

Though I am afraid I do not know what a "toast" is... I thought it was another word for a desktop notification but it doesn't make sense in this context. It could be one of their automated tests?

PJH

@The MAZZTer said:

Though I am afraid I do not know what a "toast" is... I thought it was another word for a desktop notification but it doesn't make sense in this context. It could be one of their automated tests?

http://en.wikipedia.org/wiki/Toast_%28computing%29

In software engineering, a toast is a small, informational window displayed by certain kinds of software,[...]

A Google employee, formerly a Microsoft Employee, is credited with coining the term during the development of MSN Messenger, since Messenger's small notification windows slide upward into view, like toast popping out of a toaster[citation needed].

Thief

Which is what the OP said he thought it meant, but it doesn't fit with its use behind that 2nd link.

PJH

@Thief^ said:

Which is what the OP said he thought it meant, but it doesn't fit with its use behind that 2nd link.

My reading was they're giving numbers to particular types of messages. Toast 4 = "30 days means 30 days," Toast 5 = "we'll ignore the name of the constant and redefine 30 days as 300 days and see if it'll end up on TDWTF."

Perhaps?

blakeyrat

@PJH said:

@Thief^ said:
Which is what the OP said he thought it meant, but it doesn't fit with its use behind that 2nd link.
My reading was they're giving numbers to particular types of messages. Toast 4 = "30 days means 30 days," Toast 5 = "we'll ignore the name of the constant and redefine 30 days as 300 days and see if it'll end up on TDWTF."

Perhaps?

Talky Toaster is on the dev staff.

derula

@Tracker said:

Changes the toast inactive duration to 3000 days to effectively disable it.

It's a shame that there's no integer constant for infinity.

bstorer

@derula said:

@Tracker said:
Changes the toast inactive duration to 3000 days to effectively disable it.

It's a shame that there's no integer constant for infinity.

What, your processor doesn't have an instruction to take the limit of 1/x as x approaches 0? Stupid RISC chips... they don't have anything useful.

Xyro

@bstorer said:

What, your processor doesn't have an instruction to take the limit of 1/x as x approaches 0? Stupid RISC chips... they don't have anything useful.

I really recommend not using that instruction. The limit does not converge...

bstorer

@Xyro said:

@bstorer said:
What, your processor doesn't have an instruction to take the limit of 1/x as x approaches 0? Stupid RISC chips... they don't have anything useful.
I really recommend not using that instruction. The limit does not converge...

I don't see what the big deal is; just drop the sign bit on the front and you're good to go.

Xyro

@bstorer said:

@Xyro said:
@bstorer said:
What, your processor doesn't have an instruction to take the limit of 1/x as x approaches 0? Stupid RISC chips... they don't have anything useful.
I really recommend not using that instruction. The limit does not converge...
I don't see what the big deal is; just drop the sign bits on the front and you're good to go.

PTFY. That floating point format uses two bits for signage: positive, negative, positive and/or negative, and FILE_NOT_FOUND.

SQLDave

This comment is most likey

PJH

@SQLDave said:

This comment is most likey

LOLWUT.

Even bothering to follow the post you (decided not to) quote from, I'm at a loss to ty and figure out, exactly what; in the context of this message board - and more pertantly to this thread, what the fuck are you agreeing to?

bstorer

@Xyro said:

@bstorer said:
@Xyro said:
@bstorer said:
What, your processor doesn't have an instruction to take the limit of 1/x as x approaches 0? Stupid RISC chips... they don't have anything useful.
I really recommend not using that instruction. The limit does not converge...
I don't see what the big deal is; just drop the sign bits on the front and you're good to go.
PTFY. That floating point format uses two bits for signage: positive, negative, positive and/or negative, and FILE_NOT_FOUND.

But we're talking about an integer format here. You don't need to do any of this for floating point. And, as we all know, the integer format has only the one sign bit, in addition to the bit which indicates whether the sign bit is relevant or not (because there's no such thing as negative zero, obviously).

SQLDave

@PJH said:

@SQLDave said:
This comment is most likey
LOLWUT.
Even bothering to follow the post you (decided not to) quote from, I'm at a loss to ty and figure out, exactly what; in the context of this message board - and more pertantly to this thread, what the fuck are you agreeing to?

Sorry, knee-jerk reaction from a hopeless spelling/grammar-nazi. See line 571 of the link in the OP.

I'll try not to let it happen again.

Xyro

@bstorer said:

@Xyro said:
@bstorer said:
@Xyro said:
@bstorer said:
What, your processor doesn't have an instruction to take the limit of 1/x as x approaches 0? Stupid RISC chips... they don't have anything useful.
I really recommend not using that instruction. The limit does not converge...
I don't see what the big deal is; just drop the sign bits on the front and you're good to go.
PTFY. That floating point format uses two bits for signage: positive, negative, positive and/or negative, and FILE_NOT_FOUND.
But we're talking about an integer format here. You don't need to do any of this for floating point. And, as we all know, the integer format has only the one sign bit, in addition to the bit which indicates whether the sign bit is relevant or not (because there's no such thing as negative zero, obviously).

What architecture are you using?? The bit format applies to the limit of integers, too. Check the footnotes for the LIM, LIMR, and LIML instructions. And there's totally a negative zero. Assembly pseudocode, ho!



set $1, %r1


set $0, %r2


lim %r3, %r1, %r2

This will take the limit of 1/x as x approaches 0 and store it in %r3. %r3 will then contain ±∞, which is typically not useful. However, if you take the limit from the negative (left) side:



liml %r3, %r1, %r2

then you'll have yourself a good old -∞. This is quite useful, as the limit of 1/x as x approaches negative infinity is



set %r3, %r2


limr %r3, %r1, %r2

negative zero!! See? It converges to zero, but asymptotically from the third quadrant, thus giving it mystical negative properties.

bstorer

@Xyro said:

@bstorer said:
@Xyro said:
@bstorer said:
@Xyro said:
@bstorer said:
What, your processor doesn't have an instruction to take the limit of 1/x as x approaches 0? Stupid RISC chips... they don't have anything useful.
I really recommend not using that instruction. The limit does not converge...
I don't see what the big deal is; just drop the sign bits on the front and you're good to go.
PTFY. That floating point format uses two bits for signage: positive, negative, positive and/or negative, and FILE_NOT_FOUND.
But we're talking about an integer format here. You don't need to do any of this for floating point. And, as we all know, the integer format has only the one sign bit, in addition to the bit which indicates whether the sign bit is relevant or not (because there's no such thing as negative zero, obviously).
What architecture are you using?? The bit format applies to the limit of integers, too. Check the footnotes for the LIM, LIMR, and LIML instructions. And there's totally a negative zero. Assembly pseudocode, ho!
set $1, %r1 set $0, %r2 lim %r3, %r1, %r2
This will take the limit of 1/x as x approaches 0 and store it in %r3. %r3 will then contain ±∞, which is typically not useful. However, if you take the limit from the negative (left) side:
liml %r3, %r1, %r2
then you'll have yourself a good old -∞. This is quite useful, as the limit of 1/x as x approaches negative infinity is
set %r3, %r2 limr %r3, %r1, %r2 negative zero!! See? It converges to zero, but asymptotically from the third quadrant, thus giving it mystical negative properties.

You're using the P9Q01331-99? Aren't you concerned with the critical bug in the Newton's Method implementation?

Anyway, I suppose I should have clarified that I was discussing the suplementary capabilities added with the Complex Operation eXtension. I'm sure you already know this, but for those that don't know, COX added the complex integer type, which is laid out like this:

Number  V S 31 30 ... 1 0
-------------------------
  Inf   1 0  0  0 ... 0 0
   3    1 0  0  0 ... 1 1
   2    1 0  0  0 ... 1 0
   1    1 0  0  0 ... 0 1
   0    0 0  0  0 ... 0 0
  -1    1 1  0  0 ... 0 1
  -2    1 1  0  0 ... 1 0
  -3    1 1  0  0 ... 1 1
 -Inf   1 1  0  0 ... 0 0

Obviously, I've omitted the complex portion for simplicity. As you can see, you have both the sign bit (1 if negative), and the bit which tells you whether the sign bit is valid (1 if the sign bit should be evaluated). Negative zero would be 0100..00, but since the validity bit is 0, the processor knows not to bother with the sign bit, thus the processor sees it as the same thing as +0.

Now, as to the limit instruction, the documentation for complex integer limits (LIMCI) states:

In situations where the limits do not converge, LIMCI may output the same value as either one-sided limit, LIMCIP or LIMCIN. LIMCI need not favor the same one-sided limit in all cases. Indeed, should only one direction converge, LIMCI must output the convergent value. In cases where both directions converge to different values, it is recommended that LIMCI output the more trivial value, favoring (in order from most preferred to least) 0, 1, -1, INF, -INF, pi, e, phi, 69, 42. Beyond these values, it is recommended but not required that the processor use predictive analysis to determine which limit can be solved most easily and output that result.

Therefore, in cases like this, you should really do something like this:

set $1, %c1 set $0, %c2 limci %c3, %c1, %c2 absc %c4, %c3

blakeyrat

Christ.

Xyro

Ack! This is exactly why those extensions fell out of favor in the academic community. I really don't care if they can model business applications in a practical sense, the fact is they're mathematically inconsistent! The limit of 1/x as x approaches 0 simply cannot be assumed to come from the right hand side, which the COX family of extensions do. Plus, the whole valid bit thing is totally a watered-down hack of the P9Qx family's Gödel bit, which is set iff the previous computation's minimum axioms are both consistent and complete. Of course, COX fans claim they innovated the idea.

Yes, the Newton's Method microcode may be flawed, but you can easily work around this. Any good P9Q01331-99 compiler can handle adding the algorithm in itself. Some operating systems can even swap out the NEWM instruction for the workaround algorithm as the program runs.

In any case, I was just referring to the P9Q01331-99 because I had its manual handy. My next computer is absolutely going to be powered by the P9Q1J88J-07. Talk about CISC and a half, you can compute Pi with one instruction! But as for it's limit calculations, oh man what a beauty. I think it's going to be the model upon which all future generations of chips will take for limit processing. Not only is it arbitrarily dimensional, but it can compute in parallel all possible limits from all dimensional directions in hyperbolic realtime! That's only one step away from a good parallel infinite map reduction implementation, which I hear is around the corner in 5-10 years. Frankly, I don't really care which side "wins" the limit format wars, I'm just glad we'll soon be able to toss aside these finite representations of calculus.

But in the mean time, your COX (COXa-88, I assume?) is totally bogus. Good luck finding the Laplace transformation of a Dirac delta function, sucker.

derula

I hate you all. Also:

@bstorer said:

In cases where both directions converge to different values, it is recommended that LIMCI output the more trivial value, favoring (in order from most preferred to least) 0, 1, -1, INF, -INF, pi, e, phi, 69, 42

Okay, shouldn't 42 be the most preferred? Also, what's so special about 69?

bstorer

@Xyro said:

Ack! This is exactly why those extensions fell out of favor in the academic community. I really don't care if they can model business applications in a practical sense, the fact is they're mathematically inconsistent!

I should've known you were an ivory tower egghead when you cited a P9Qx manual. In the real world, those chips are nothing more than a punchline. We can talk about the purity of their formal systems all you want, but at the end of the day, it's about market share, and nothing has ever defeated the x86 family. That's why I tune my code for the new 91486-1024c with COX.@Xyro said:

The limit of 1/x as x approaches 0 simply cannot be assumed to come from the right hand side, which the COX family of extensions do.

Have you ever pulled your head out of the academic journals at all? Read the specs, man. They don't have to come from the right, it's just that most of the major brands do. In fact, AMD's upcoming Phenomenon family all approach limits with x increasing. Sure, they generate enough heat to necessitate cooling with a continuous flow of Bose-Einstein condensate, but they're much cheaper than the new Intels.@Xyro said:

But in the mean time, your COX (COXa-88, I assume?) is totally bogus.

COXa-55, actually. Don't get me wrong; I love the potential of using sedenions. I'm waiting for the new PCI-HyperMegaUltraSuper 2.0 slots to become commonplace before I take the plunge. I just don't see the point without being able to have three projective hyperspace displays. How am I supposed to see the space at infinity without it?@Xyro said:

Good luck finding the Laplace transformation of a Dirac delta function, sucker.

There you go again, Professor. Everybody knows that the Mellin transform is more important for the average user's daily tasks.

bstorer

@derula said:

I hate you all. Also:
@bstorer said:
In cases where both directions converge to different values, it is recommended that LIMCI output the more trivial value, favoring (in order from most preferred to least) 0, 1, -1, INF, -INF, pi, e, phi, 69, 42

Okay, shouldn't 42 be the most preferred?

Of course not. The Answer to Life, the Universe, and Everything is hardly the most trivial. @derula said: