|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> when people do write out numbers
>> they are *right justified*
>
> Not really.
>
> 3.44444
> 4.5
> 34424
OK smartass :-) You line up the decimal point if not dealing with integers.
Anyway, you still work from the LSB first when doing anything with them.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Anyway, you still work from the LSB first when doing anything with them.
When was the last time *you* did long-division? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Anyway, you still work from the LSB first when doing anything with them.
>
> When was the last time *you* did long-division? :-P
Hehe, not since doing it with polynomials at university.
But since then I was messing about with writing an unlimited precision
integer program, implementing the +,- and * by hand. I dunno, it just
seemed the obvious thing to do to put the LSB of the number in array
position zero, putting the MSB in position zero would have made things quite
awkward.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Anyway, you still work from the LSB first when doing anything with them.
>>
>> When was the last time *you* did long-division? :-P
>
> Hehe, not since doing it with polynomials at university.
>
> But since then I was messing about with writing an unlimited precision
> integer program, implementing the +,- and * by hand. I dunno, it just
> seemed the obvious thing to do to put the LSB of the number in array
> position zero, putting the MSB in position zero would have made things
> quite awkward.
Well, clearly I'm not going to win this one because I am apparently the
*only* person here who thinks this is a very, very bad idea. But I
reserve the right to continue to be irked when I have to take my
beautiful code and litter it with statements to turn the numbers
backwards at the start, and then turn them back round the right way
again afterwards, just because somebody somewhere decided to design
their cryptosystem to follow Intel's broken design. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> But I reserve the right to continue to be irked when I have to take my
> beautiful code and litter it with statements to turn the numbers backwards
> at the start,
If you had them round the right way to start with you wouldn't need to
litter your code with anything :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> But I reserve the right to continue to be irked when I have to take my
>> beautiful code and litter it with statements to turn the numbers
>> backwards at the start,
>
> If you had them round the right way to start with you wouldn't need to
> litter your code with anything :-P
Take the MD5 hash kernel, for example. Essentially you're supposed to
load a word of data from the current block and mix it into the hash state.
Except for the minor detail that you can't just *load* it, you have to
turn it backwards first, or you'll get the "wrong" answer (i.e., not the
answer listed in the MD5 spec). It's not that the data you're trying to
hash is backwards, it's just that MD5 is defined to operate backwards.
Except, of course, that working completely backwards would be
comparatively simple; no, MD5 is defined to work on words forwards, but
each word must be written backwards. *sigh*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Darren New" <dne### [at] sanrrcom> wrote in message
news:4ae76041$1@news.povray.org...
> Captain Jack wrote:
>> Technically, in T-SQL, that would be a CROSS JOIN. JOIN all by itself
>> defaults to a LEFT INNER JOIN, for which the results could vary.
>
> Actually, I thought you couldn't do JOIN all by itself at all. Every JOIN
> has to be part of a SELECT, right?
Sorry... I meant to say "JOIN without a qualifier" rather than "JOIN all by
itself". A JOIN clause always follows a FROM clause (essentially acting as a
binary operator on two tables, creating a complex FROM) and the FROM has to
follow a query directive like SELECT.
I always think of SQL as a weird language, but I guess English is a tad
weirder. :D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Captain Jack wrote:
> I always think of SQL as a weird language, but I guess English is a tad
> weirder. :D
Just a tad, yeah...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Captain Jack schrieb:
> SELECT C.Name, U.UserName
> FROM tblClients AS C
> OUTER JOIN tblUsers AS U ON U.UserId = C.LastEditUserID
>
> In that case, the column LastEditUserID is zero (another way of logically
> saying Null, I s'pose) when the client row is new and has never been edited.
> I do that so that in that query I always get the client data, with the user
> name being optional.
In theory, you'd solve this by adding another entry to tblUsers with
default values to use for new clients.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <ano### [at] anonymousorg> wrote in message
news:4ae9b09e$1@news.povray.org...
> Captain Jack schrieb:
>
>> SELECT C.Name, U.UserName
>> FROM tblClients AS C
>> OUTER JOIN tblUsers AS U ON U.UserId = C.LastEditUserID
>>
>> In that case, the column LastEditUserID is zero (another way of logically
>> saying Null, I s'pose) when the client row is new and has never been
>> edited. I do that so that in that query I always get the client data,
>> with the user name being optional.
>
> In theory, you'd solve this by adding another entry to tblUsers with
> default values to use for new clients.
Which hikes up my filtering costs later... When I show a list of users to
select for, say, a report, I have to filter out the "special cases" that
aren't actually users. I'm effectively making the User table track two
different kinds of data, and I have to take that into account in all my
future use of the table. Probably by adding a column to the table to flag
how it's used. Then I have extra documentation tasks, more maintenance
problems...
Okay, now I'm whining. Sorry about that... I just got out of a three hour
design meeting where we ran out of coffee, and my head hurts. :D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |