 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> In assembly, you don't even "specify" how big a given data item is. This
>> is an implicit property of what instructions you use on that data.
>> Assembly isn't even high-level enough to pretend that it has data types.
>> It just supports what the hardware supports.
>
> Hence you are contradicting yourself. You *don't* have "total control"
> if you can't even specify the size of your integrals.
You have total control over what the size of the integrals is. It's just
that you don't explicitly write this down as "please declare a variable
X bits wide". You do it implicitly, by using instructions that operate
on a certain width. (And it's then of course wonderfully easy to get
things horribly wrong...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Like, in Haskell, if I want a 64-bit unsigned integer, I say "Word64".
I like Ada's method better, where you say "I need an integer that ranges
from -273 to +100. Please pick the appropriate size machine integer." Or "I
need a float that ranges from +1E29 to -1E13 with a maximum error of 1E-9,
please pick the appropriate floating point variable type." Saying the size
of your answer in terms of register bits seems pretty primitive no matter
what the language. (And less portable, if your machine isn't using 8-bit
bytes.)
> *Everything* with GNU in the name sucks on Windows!
The CLI stuff isn't too bad. Of course, it's hard to screw up something
like md5sum.
> You can (and people have) use it for things that aren't math.
You mean, you can use it to apply math to apparently non-mathematical
problems. ;-) You just described the basis of all formalisms.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>>> Like, in Haskell, if I want a 64-bit unsigned integer, I say "Word64".
>>> In C, I say...
>>
>> uint64_t
>>
>> (Yes, it has been standard for almost 12 years already.)
>
> Well, now I've seen everything... (All the sources I looked at said you
> have to write "long long unsigned int" or some mojo like that.)
You do. They just wrote into the standard that there's a header file that
comes with the compiler that says "Hey, when he says uint64_t, he means long
long unsigned int".
You can't declare a 64-bit integer. You can use someone else's declaration
that the standard says gives you a 64-bit integer in terms of
compiler-dependent long long unsigned int sorts of things.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> You do. They just wrote into the standard that there's a header file that
> comes with the compiler that says "Hey, when he says uint64_t, he means long
> long unsigned int".
> You can't declare a 64-bit integer. You can use someone else's declaration
> that the standard says gives you a 64-bit integer in terms of
> compiler-dependent long long unsigned int sorts of things.
Again with your fixation about "someone else's" declaration.
Whether uint64_t is declared in a header file or whether it's a reserved
keyword supported by the compiler directly makes little difference. It's
*standard* in any case. You can use it safely.
(And besides, nowhere it is said that 'long long' must be 64 bits in size.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> You do. They just wrote into the standard that there's a header file that
>> comes with the compiler that says "Hey, when he says uint64_t, he means long
>> long unsigned int".
>
>> You can't declare a 64-bit integer. You can use someone else's declaration
>> that the standard says gives you a 64-bit integer in terms of
>> compiler-dependent long long unsigned int sorts of things.
>
> Again with your fixation about "someone else's" declaration.
I'm trying to clarify for Andrew what's going on. He said "In C, I say...
um, well it seems to vary by compiler/OS. WTF?" And he's right. Except that
there's also part of the standard that says the compiler comes with a bit of
library code to let you write code that selects the right "thing that varies
by compiler" to give you the 64 bits you're looking for.
> Whether uint64_t is declared in a header file or whether it's a reserved
> keyword supported by the compiler directly makes little difference.
It only makes a difference if you actually want to understand what's
actually going on. If you're happy to do cargo-cult programming, then no,
you don't have to understand that uint64_t is a typedef and "long int" isn't.
For example, if Andrew now goes and declares something as "uint64_t" in his
program, it won't work, because you didn't tell him the right header to
include to get that declaration, while "long long int" will continue to work
because it needs no declaration prior to use.
In other words, I'm pointing out that uint64_t is in a standard library, not
part of the language per se. It's clear that "all the sources" Andrew looked
at didn't mention that this is in the library but rather were talking
specifically about the language itself.
> It's *standard* in any case. You can use it safely.
I didn't say you couldn't. I said that C per se doesn't let you declare "a
64-bit integer", in contrast to many other languages that do.
I'd also argue that C, per se, doesn't support I/O, but it comes with a
standard library that does and which you can rely on. Would you gripe at me
for clarifying that for someone coming from a Pascal or Fortran background?
> (And besides, nowhere it is said that 'long long' must be 64 bits in size.)
Which is exactly what prevents you from declaring a 64-bit integer and
instead requires the standard to define a typedef from some arbitrary
compiler-specific declaration to a standard name that will give you 64 bits.
The very fact that nowhere it is said that "long long" must be 64 bits in
size is exactly what has Andrew going "WTF?" Explaining the solution half
way is likely to be more confusing and (ime) would tend to lead to someone
thinking they don't actually understand the language as much as they do,
thinking they missed something in the language rather than simply having an
incomplete understanding of the extensive standard libraries.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Like, in Haskell, if I want a 64-bit unsigned integer, I say "Word64".
>
> I like Ada's method better, where you say "I need an integer that ranges
> from -273 to +100. Please pick the appropriate size machine integer." Or
> "I need a float that ranges from +1E29 to -1E13 with a maximum error of
> 1E-9, please pick the appropriate floating point variable type." Saying
> the size of your answer in terms of register bits seems pretty primitive
> no matter what the language. (And less portable, if your machine isn't
> using 8-bit bytes.)
OK. But given the ability to pick the number of bits you want, you can
implement the rest as a mere library.
>> *Everything* with GNU in the name sucks on Windows!
>
> The CLI stuff isn't too bad. Of course, it's hard to screw up something
> like md5sum.
Oh how ironic that you should pick md5sum - the one console application
that I've struggled with to find a working Win32 version!
(Depending on which port you pick, they don't like backslashes, or won't
handle directories at all, or maybe they just use a completely different
set of flags to the POSIX version, or...)
>> You can (and people have) use it for things that aren't math.
>
> You mean, you can use it to apply math to apparently non-mathematical
> problems. ;-) You just described the basis of all formalisms.
Well, yeah. But I mean, you can make it grok stuff that doesn't look
like algebra; it's flexible enough to do that.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> OK. But given the ability to pick the number of bits you want, you can
> implement the rest as a mere library.
If your language syntax is flexible enough to allow such a specification,
yes, that works. Ada also selectively enforces the ranges, optimizes based
on the ranges, and allows you to declare (for example) arrays whose index is
based on such a type. Oh, and pack such things into the minimum number of
bits needed if you have an array of such things. (The canonical example
being reading a FAT-formatted floppy FAT directly into a packed array of
0..4095 integers.) Sure, if your language supports that sort of thing as a
library, you can do it that way, but then you're *way* over the complexity
of putting it in the compiler.
I'm just saying that I prefer declarations of the form "I need a variable to
hold these following application-specific values" than saying "first, figure
out what machine type will hold these application-specific values, then use
that type." That latter step really ought to be done by the compiler, IMO.
>>> *Everything* with GNU in the name sucks on Windows!
>>
>> The CLI stuff isn't too bad. Of course, it's hard to screw up something
>> like md5sum.
>
> Oh how ironic that you should pick md5sum - the one console application
> that I've struggled with to find a working Win32 version!
This doesn't work? http://unxutils.sourceforge.net/
> Well, yeah. But I mean, you can make it grok stuff that doesn't look
> like algebra; it's flexible enough to do that.
Fair enough. :-)
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am Wed, 16 Feb 2011 14:16:15 +0000 schrieb Invisible:
>
> *Everything* with GNU in the name sucks on Windows!
As a sideremark - the gnu in gnuplot is not from GNU as in "GNU is not
Unix" but it is totally independent from the GNU project (originally it
was called newplot). I kind of like it, but than I'm the kind of
scientist it was written for. I would yet have to find a program having
as nice LaTeX pstricks output and being easily scriptable. I agree the
syntax is kind of clumsy but I probably would have come up with something
similar would I have written such program :).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm just saying that I prefer declarations of the form "I need a
> variable to hold these following application-specific values" than
> saying "first, figure out what machine type will hold these
> application-specific values, then use that type." That latter step
> really ought to be done by the compiler, IMO.
It's not something the programmer should have to figure out manually,
no. I guess whether it goes in the compiler or a library is moot.
>> Oh how ironic that you should pick md5sum - the one console
>> application that I've struggled with to find a working Win32 version!
>
> This doesn't work? http://unxutils.sourceforge.net/
The list at the top of the page indicates that this doesn't include md5sum.
>> Well, yeah. But I mean, you can make it grok stuff that doesn't look
>> like algebra; it's flexible enough to do that.
>
> Fair enough. :-)
Most CAS systems I've seen are hard-wired for algebra, and many of them
have the transformation rules hard-wired as well. Mathematica is more
general than that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/02/2011 10:39 PM, Florian Pesth wrote:
> As a sideremark - the gnu in gnuplot is not from GNU as in "GNU is not
> Unix" but it is totally independent from the GNU project (originally it
> was called newplot).
OK.
> I kind of like it, but than I'm the kind of
> scientist it was written for. I would yet have to find a program having
> as nice LaTeX pstricks output and being easily scriptable. I agree the
> syntax is kind of clumsy but I probably would have come up with something
> similar would I have written such program :).
It's nice that you can load it up and say "plot exp(-x**2)" and it
immediately plots something. (The alternative being to open Excel, make
an X column, fill it with suitable values, write the formula into a
cell, copy it down, select the column, run the chart wizard... are you
bored yet?)
As soon as you want to do anything even moderately complex, it becomes
an utter nightmare. The documentation is minimal to say the least. The
properties have utterly unintuitive names and no logical grouping. And
half the time it seems to be actually impossible to make it plot the way
you want it to.
On top of that, while the expression language is great for plotting
explicit functions, it's useless for plotting anything else. Even
something as trivial as a recurrence relation is beyond its power.
Now, if only it would support CSV input... You know, the de facto file
format for all numerical data? Yeah. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
