Pentium100

Yeah, I can understand a good character not wanting to kill the bad guy because "he won't stoop that low" and the bad guy deserves to be tried and punished according to the law.

But a bad guy, who probably killed many people, not wanting to kill the good guy is annoying. Also annoying is that if the bad guy decides to kill the good guy, he uses some elaborate method (that allows the good guy to escape) and does not even watch to make sure. Just grab a gun and shoot him multiple times until you are 100% sure he's dead.

The only argument against just shooting the good guy I can accept is that if the bad guy has a personal reason (as in the good guy did something to the bad guy before, instead of being just a random cop etc) to kill the good guy and wants to torture him for a while before killing him. This does not excuse not watching the process and having a gun just in case though (as I would expect the bad guy wanting to watch his enemy getting slowly tortured to death).

Quote

Maybe dragons can't really distinguish between shades of purple.

Well, to be fair, Twilight and Starlight look similar, if Ember has not seen Twilight or Starlight frequently, she can easily confuse them. Their colors are similar, cutie marks have a star in them (though Starlight also has some green smoke or something coming from it, but maybe Ember though it was rude to stare at the cutie marks for too long). There is one problem though - Twilight has wings. Either Ember is really inattentive or she thought it was normal for a pony to lose and then grow back wings multiple times per day.

"I am your father's, brother's, nephew's, cousin's, former roommate."

I like the song from this episode.

On 5/6/2020 at 11:45 PM, Brony Number 42 said:

And from what I remember in Voyager, they said they couldn't use the holodeck power grid for other things

Well, the writers wanted to show that the Voyager crew has limited resources, not enough power for the replicators, but also wanted to have the holodeck episodes, so we get the stupid explanation that the ship uses a dedicated and incompatible power source for the holodeck.

On 5/6/2020 at 11:45 PM, Brony Number 42 said:

Probably small objects get replicated, and dereplicated when the program is done. But what about the gun?

Probably the gun gets either replicated or uses forcefields to appear solid and fires a bullet that also appears solid. The safety would destroy the bullet when it comes within a safe distance of a human.

At least it looks like that. Safety was an after thought and it shows. So, in-universe the holodeck design is stupid and unsafe. Out-of-universe it makes sense, otherwise the holodeck episodes would be pointless if they could just turn it off.

Oh yeah. The holodeck safety protocols turning off at the slightest problem, but the program itself not turning off.

I get it, holodeck technology is dangerous and the safety measures are probably "active" instead of "passive", that is, a holo-axe has the same properties as the real one, but the computer actively monitors ir and removes it if the blade gets too close to a human body. This, of course, means that it is possible for that monitoring to fail and you get hit with an axe. OK, let's say this is how the technology works and it is not possible to make the axe inherently safe (say, behaving like rubber) without destroying the immersion. So, why doesn't the program immediately turn off if the safety is compromised?

Also, "shutting down the holodeck, we will lose the characters" - I guess games in the future will not have saves or backups.

However, speaking out-of-universe, the holodeck episodes were a way for the creators to have different styles of episodes and safety being enabled all the time would make it boring to watch (well, the characters are not in any kind of real danger, they are just playing a game), so the safety has to fail in order for the holodeck episodes to count for something.

Similar is how Voyager pretty much never had a backup of the EMH, except in one episode where the backup was stolen. I get it, the EMH can be considered a sentient being and there are moral issues with copying him, but then say so in the episode, you can even have characters debating whether they should or shouldn't keep a backup of the EMH when he goes somewhere dangerous.

Just now, Justin_Case001 said:

Our microwave has a little musical jingle instead of an obnoxious beep, and it's just a tiny little speaker.

It's more expensive. Only a tinybit more expensive, but that is also the reason why a lot of devices have low quality capacitors that fail soon.

My microwave oven just beeps. Every time I press a button and four times when the timer runs out.

1 minute ago, Justin_Case001 said:

Does it really have to be a fire alarm?!

Yes, the fast food place can probably be quite noisy some times (the place is full of people etc). Those times would also usually be when the employees are distracted the most and need the sound.

I understood that you are mostly complaining about the volume, not the sound itself. I mean if it was two or three tone but at the same dB level, would it be better for you?

The reason high frequencies are used is to have it more audible and because it needs a smaller speaker (just look at the size difference between a double bass and a violin). Your proposed sound would probably require a transducer that's at least 50cm wide and it would be less audible over engine noise.

Well, that is how it is done on paper:

1234 x 5678 in decimal of course.

    1234
    5678
--------
    9872  (1234 * 8)
   8638.  (1234 * 7 << 1)
  7404..  (1234 * 6 << 2)
 6170...  (1234 * 5 << 3)
--------
9872+86380+740400+6170000=7006652

There should be zeroes in place of the dots, but normally they are not written. They are used when adding the total product.

So, it's the same way that multiplication is done on paper (with the exception of additional operations for negative numbers). Some CPUs have dedicated circuits for that instead of taking many cycles to multiply.

3 minutes ago, Eniac said:

But the issue is that I would still feel as if I was being lazy becuase of all the other things I could have done in that time.

I guess the difference between us is that I do not care about that. If I decide to do X instead of Y, then I do not worry that I cannot do both at the same time or "why I chose X".

Am I lazy? I think so. Would I overwork myself? Hell no, I'm lazy, overworking is kinda the opposite of that.

When I read or hear about some kid who has skipped a few grades and will be studying in a University at 14 or whatever, my thoughts are always like "He is really good at studying, but boy is he stupid". Fail some tests intentionally and you'll have easy time at school. Being able to finish University and get a job a few years earlier is not worth it.

While I am in some ways similar to Twilight, if I was in her place (with her abilities etc) Equestria would be doomed.

On x86 the output of MUL is in two registers instead of one, so it's double the width. 
Same with 8051 (an 8bit CPU) - the result of MUL of two 8bit registers is stored in two 8bit registers.
On both x86 and 8051, overflow flag indicates if the result would fit in one register, if it's set, you need to handle both result registers.

255*255=65025, so the result will always fit in two registers.

Just now, Splashee said:

a parity flag (I wonder what purpose to use that one?)

So that you can have the parity without calculating it separately, for example, if you want to transmit data on RS-232, you may use parity to detect errors (it's not really used , for some reason the settings are always 8n1, but you can have parity). Parity is rather difficult to calculate (you would probably need a loop for that or a lookup table), but easy to implement in hardware (a few XOR gates). However, it seems that the parity flag in x86 is also used for other purposes than just showing the actual parity. 

Overflow bit in a CPU is essentially the 9th (or whatever) bit of the register, when the register goes from 255 to 0 by adding one, the overflow bit is set (and in theory you could use the overflow bit to kinda-have a slightly bigger register). 

0|11111111
+
0|11111111
----------
1|11111110

the bit before the pipe is the overflow bit.

And it all started by me wishing to show that overflow is not such foreign concept and not exclusive to computers, but is common to all fixed-length counters and such..

This is the same with binary and decimal:

000 - 1 = 999 (decimal)
000 - 1 = 111 (binary)

So that part works. The difference is how we can define negative numbers in our decimal "computer" (though I wonder how they did this in actual decimal-based computers, but most of those were still kind-of binary, like BCD).

Anyway, let's try. If we copy from the binary version, we should define somewhere near the midpoint as the line between positive and negative numbers. Let's say that 499 = +499, 500 = -500, 599 = -401, 999 = -1. Sign indicator is the first digit. If it's >=5, it means that the number is negative.

Adding numbers works OK. 100 + 1 = 101, 998 (-2) + 1 = 999 (-1).

To negate a number you need to subtract it from 1000 (1000 - 1 = 999). You can also do it, like in binary, by manipulating each digit wheel separately. You need to set it to 9-current_value, for example (9->0; 8->1; 0->9 and so on) and then add one. Let's try negating some numbers:

001 -> 998 +1 = 999
400 -> 599 + 1 = 600
499 -> 500 + 1 = 501
000 -> 999 +1 = 000
To get a positive value from negative you need to subtract one and then turn the wheel to 9-current_value:
999 -> 999 -1 -> 998 -> 001
501 -> 501 -1 -> 500 -> 499
500 -> 500 -1 -> 499 -> 500

Seems to work. The special cases (0 and -500) turn into themselves, but it's similar to binary as well, since there is no positive number available.

56 minutes ago, Splashee said:

Decimal numbers keeps going forever, and applying wrapping does things that (at least I) cannot be used.

So do binary numbers. The difference is that the way binary numbers are used in PCs is fixed-length variables, just like the mechanical counter with fixed number of wheels. Just like the mechanical counter with 3 wheels wraps around at 999+1 (because there is no fourth wheel), a 3 bit binary variable wraps around at 111+1 (because there is no fourth bit).

If I set the three wheel odometer to zero and drive 1500km, the odometer will show 500. Just like your wrapped space. If I did not notice it going to 999, I could just say that I drove 500km. This means that if I manage to drive my car 1100000km, the odometer would only show 100000 and it would be perfectly legal because I did not tamper with it.

56 minutes ago, Splashee said:

Like the Most Significant Bit representing the minus sign, is required to be the bit before the wrap around, no matter how many digits the binary number has, because it is required to act as the negative side (below zero).

And if you want to convert a signed 8bit integer to a signed 16bit integer, you need to pad the most significant bits of the bigger variable with the most significant bit of the smaller one.

You talk about how wrapping around is such a difficult concept, but this happens with decimal numbers as well. 

Take a look at an odometer from a car:

Once it reaches 999999km (or the bottom one to 999.9km), driving one more km (or 100m) makes it go to zero, because there are not enough digits in the counter. Binary numbers wrapping work exactly the same.

4 hours ago, Brony Number 42 said:

Maybe we should talk about base 16 and how it is easy to take a binary number and group the digits 4 at a time and easily make a hex number.

Or take three bits at a time and make an octal number, like they are used in aircraft transponders and Linux file permissions (chmod 750...). But hex is better, since a byte fits in exactly two hex digits.

2 hours ago, CypherHoof said:

i think it is more ironic that you looking to a Pentium for maths 

Especially floating point 

I learned in school that you indicate a repeating part of a decimal fraction with parenthesis (1/30 = 0.0(3) ), though I guess just like division on paper is slightly different in different countries based on what @Brony Number 42 wrote, maybe the repeating fraction is marked differently as well.

2 minutes ago, CypherHoof said:

But it works in binary too (1/3 decimal is by definition 1/11 in binary :D)

Yes . I chose that as an example of more than one digit repeating - 1/3 = 0.(3), but 1/11 = 0.(09) - to show that this is how I mark the repeating part. 

By the way, just look at us nerds, discussing math .

Just for clarification, "1/11" in my previous post was used as an example of decimal recurring fraction, one divided by eleven.

1 minute ago, Splashee said:

Just to be clear, 0.0011 would be (1/8 + 1/16)? Wouldn't that be 0.1875 in decimal? Am I off by one digit? Or am I reading your numbers or parenthesis wrong?

 

I noticed that I get closer to 0.3 decimal if I do (1/4 + 1/16), which is binary 0.0101? Decimal 0.3125.

When doing this, you can never go over the original number and 0.3125 is closer, but it's too big.

Oh, and I made a mistake, I converted 0.2 to binary, which is 0.(0011), but wrote 0.3 Oops...
0.3 in binary would be 0.01(0011) 

0.0011 would be 0.1875. The parenthesis indicate that the part is repeating forever, so 0.2 = 0.001100110011001100110011...

0.0011 = 0.1875
0.00110011 = 0.19921875
0.001100110011 = 0.199951172

And for 0.3 (for real this time) it's:
0.01 = 0.25
0.010011 = 0.296875
0.0100110011 = 0.299804688
0.01001100110011 = 0.299987793
and so on. If you kept adding the ever smaller fractions to infinity, you would end up with 0.3

Just like trying to write 1/11 as a decimal fraction you end up with 0.(09).

Now, you can round up those numbers, for example, say that 1/11 = 0.09091 or that 0.2 in binary is 0.0011001101, but it's still not precise. So, just liek it's impossible to write 1/11 as a decimal fraction precisely in a finite amount of space, so is writing 0.2 as a binary fraction. 

3 hours ago, Splashee said:

I assumed something like for the first position, it would be 1/2 (0.5), then 1/4 (0.25), then 1/8 (0.125)... But adding those together will never get 0.2 or 0.3.

It is exactly like that. And 0.2 or 0.3 in binary is like 1/3 or 1/11 in decimal - repeating forever. This is why floating point cannot completely precisely represent these values.

4 hours ago, Brony Number 42 said:

13 | 430.000

Interesting, the way I learned this in school was the opposite, that is, if I want to divide 430/13, I would have to write 

430 | 13

(yes, the 13 is in a "corner" and IIRC we called this "dalyba kampu" which literally means "division by corner"). The result is written under the divisor.d):

29 minutes ago, Splashee said:

If you are at position 0, you are in grid [0]. If you are at position 15, you are still in grid [0]. As soon as you are at position 16, you are in grid [1].
Obviously, by looking at the order of the grid, if you are at position -1, you should be in grid [-1]. Computer division by binary shifting will give you that answer! But pure math doesn't:

This is because your positions are shifted . If you put the "0" position in the middle of the grid (or rather, have -1 and +1 positions near the center of the grid or divide the grid into odd number of positions so that 0 can be in the center), then you could get the grid value as position/9. (0 -> 0, +8 -> 0, -8 -> 0, +9 ->1, -9 -> -1)

Your way, however, works great in computers with twos' complement integers as long as the bit shift operation keeps the MSB in place.

Floating point is very similar to the scientific notation, except in binary.

So, you want to represent 0.00134277343, you can write it in binary as 0.0000000001011, but, like with decimal, this takes up a lot of space for very large and very small numbers because of the leading or trailing zeros. 

Using the same rules for scientific notation (but in binary) you can represent that number as 1.011 * 2^-10, which takes up less space. This is how it is done in floating point - you have one bit for the sign, some bits for the exponent (the -10) and some bits for the fraction. Since there is always a 1 in front of the decimal point (because you move the point until there is 1 in front of it), it is not stored, so this could be stored as a floating point variable as

sign = 0b0 (positive)
exponent = this is stored as 127+e, so 127-10 = 117 = 0b01110101
fraction = 0b0110000
so, you get a 16bit float as 0b0011101010110000 = 0x3AB0

There are special values for zero, infinities and NaN. By the way, ones' complement integers also have negative zero.

The problems with precision come down to the limited space for the fraction, just like it would take a lot of space to write 1420000000000.000123, it does take a lot of space to write that in binary. It's all about significant digits, just like if somebody 5 years ago told you that some fossil is 100 million years old, it does not mean that the fossil now is 100 million and 5 years old, since the original age of the fossil probably was not determined with the precision of one year.

Or course the problem with floating point and how we use it is also because "normal" decimal numbers are not possible to fully represent in binary. For example, 0.3 in binary would be 0.(0011), so, no matter how big a floating point variable you use, you will not be able to represent 0.2 completely accurately, like you can represent 0.125 or similar. Just like representing 1/3 in decimal = 0.(3), sooner or later you will run out of space for the digits and the number still won't be completely precise.