The Channel logo

* Posts by Bryan Hall

6 posts • joined Saturday 12th August 2006 13:16 GMT

Bryan Hall
Happy

Re: Before anyone says "here comes big brother"...

Are you serious? Hard to tell... I guess that doesn't apply to Top Gear eh? :-)

I regularly pass a series of three or four semis (lorry's) on two lane roads out in West Texas around 120 MPH in my Corrado. If you don't - you may need to wait another 20 minutes for a chance of good clear road, going maybe 55 MPH in the mean time.

At least over here - we are to spend as little time in the opposing lane as possible. I have no problem with that myself! Not that it is really any different than a track day, other than the rather large "cars" I'm passing.

Bryan Hall

F1 and Top Gear on the BBC

I'm all for it! Please do this.

Being in the US, I would definitely be willing to pay-per-view (if you will) for both online F1 coverage and Top Gear UK, and occasionally news coverage. Maybe with this model change they could even carry the entire season, again, next year. I don't see Sky doing this - and I really dread having to watch racing interrupted by long commercial breaks (on a cable service you have to PAY for) - with commentators who generally have no clue about what is going on. More than likely I will just wait for a torrent instead of having to put myself through that pain.

As it is now, although I would send something to the BBC so I can legally watch both of these live on the iPlayer - but there is no way to do so. Now when I pay for this, I will expect a good quality feed - as glitch free as possible.

Bryan Hall

License costs drive hardware choice

Beyond IBM's chips - what RISC chips are out there that are remotely competitive with x64 chips for servers? Not some specific benchmark - but TCO including software.

For years we were a Sun SPARC / Windows shop. About 4 years ago we dumped SPARC for x64 (AMD in that case). We still run Solaris / Windows, but on x64.

Why? Performance per socket or core depending on licensing. Software licenses are MUCH more expensive to buy and maintain per unit than hardware. The RISC cores were just too slow to justify their costs.

Instead of buying more licenses as loads increase, we just buy the latest / quickest hardware available - it is much cheaper to do so, especially for the socket license models where you can now have 8+ cores per socket.

One of our big cost apps is Oracle Enterprise with Spatial and Label Security. The last go around we moved from a Sun SPARC v880 to a 16-core monster AMD box. This year we are dumping that and moving DOWN to a 12-core Intel box with TMS flash for all storage. The money we save in license renewals will pay for the new hardware. And we calculate that it will be about an order of magnitude quicker to boot. THAT is a no brainier upgrade - even for the US Govt.

Bryan Hall

Rubish - Zero Emissions?

Agree entirely. Something at the bottom really caught my eye however...

"The zero-emission Roadster"

That is a false statement (lie) for almost 100% of the potential owners.

At least in the US, it is mainly a Coal-Powered car, hardly zero-emission.

Bryan Hall

GEM

True, GEM on the PC stinked, at least in comparison to the version on the Atari ST's due to the Apple lawsuit. I tried it and couldn't believe how stripped down it was.

Too bad, at least the Atari version was much better than the early crappy versions of Windows.The final blow was Microsoft making Windows incompatible with DR-DOS.

Bryan Hall

No rounding required

We don't do these kinds of calculations using IEEE math for this reason. Since the data is in the database, and CPU costs are the same for application or database servers, we just do the math using Oracle's number format, which is exact in storage.

Here is an example of the results from the topic text in PL/SQL:

SQL>SET NUMWIDTH 38 SERVEROUTPUT ON

SQL> DECLARE

2 num1 NUMBER;

3 num2 NUMBER;

4 BEGIN

5 num1 := 0.37;

6 num2 := 0.37;

7 DBMS_OUTPUT.put_line (num1 + num2);

8 num1 := 59.00;

9 num2 := 1.125;

10 DBMS_OUTPUT.put_line (num1 * num2);

11 END;

12 /

.74

66.375

We actually get the results you would expect. 0.37 is stored as:

SQL> select dump(0.37,10) from dual;

DUMP(0.37,10)

-------------------

Typ=2 Len=2: 192,38

That is, two bytes, shown here in base 10 as 192 and 38.

To decode the precision, take the 2nd to last (only one here) numbers and subtract 1:

38 - 1 = 37

To decode the scale, find the difference from 193, and if negative, divide by 100 that many of times:

192 = 193 - 1 so 37 / 100 = 0.37

In case you are wondering, here are the other two values as they are stored:

SQL> select dump(1.125,10) from dual;

DUMP(1.125,10)

------------------------

Typ=2 Len=4: 193,2,13,51

193 (one whole digit), 2-1= 1, 13-1= 12, 50-1=50 -> 1.1250

SQL> select dump(59,10) from dual;

DUMP(59,10)

-------------------

Typ=2 Len=2: 193,60

Thus, Oracle can store "at least" 38 digits of precision using this method in its NUMBER format. No trickery with 1/2's here, exact numbers are actually stored, and in less space.

For more information see: http://www.jlcomp.demon.co.uk/number_format.html

Forums

Forgotten password

Opinion

euros_channel_money

Tim Worstall

Time to take a sniff at the coffee, perhaps
joe_tucci_emc_channel

Chris Mellor

Will they have to drag him back like last time?
chain_relationship_channel

Features

cloud_accounting
Playing the SLA long game
channel_teaser_money_top
cloud computing Fight
Applications must work for the cloud to float
Paul Cormier, Red Hat
How a Unix killer crawled from the dot-com bust