 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ever heard of it? Have an opinion? Just curious. Been kinda poking
around it, neat little graphical DSP type thingy. Though looks crude, is
quite flexible, a lot you can do with it.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Have an opinion?
You know what they say about opinions...
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/02/2011 03:17 PM, Warp wrote:
> You know what they say about opinions...
They're like onions?
No, wait, that's ogres...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/02/2011 02:05 PM, Mike Raiford wrote:
> Ever heard of it? Have an opinion? Just curious. Been kinda poking
> around it, neat little graphical DSP type thingy. Though looks crude, is
> quite flexible, a lot you can do with it.
Looks very hackish to me. I probably wouldn't like it.
The (very expensive) Reaktor software I have already does approximately
this with audio. (But with cleaner abstractions.) And there's WinAmp's
AVS and Milkdrop plugins that do roughly the same for video.
(Unfortunately, those are quite hackish as well.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 14/02/2011 16:38, Invisible a écrit :
> On 14/02/2011 03:17 PM, Warp wrote:
>
>> You know what they say about opinions...
>
> They're like onions?
>
> No, wait, that's ogres...
IIRC, opinions are like a**h*l*s... everybody get one...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/14/2011 9:49 AM, Le_Forgeron wrote:
> Le 14/02/2011 16:38, Invisible a écrit :
>> On 14/02/2011 03:17 PM, Warp wrote:
>>
>>> You know what they say about opinions...
>>
>> They're like onions?
>>
>> No, wait, that's ogres...
>
> IIRC, opinions are like a**h*l*s... everybody get one...
Yeah ... But, I have a morbid curiosity of Andrew's opinion :P
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/14/2011 9:46 AM, Invisible wrote:
>
> ... I probably wouldn't like it.
>
0 for two... lol.
First Maxima, now this :P
Of course, Maxima just about lives on my desktop now... Has come in
rather handy at times.
For me, PD is a novel toy...
Interestingly, I did some searches on the software just to see what it
was all about. It was apparently used as a basis for the algorithmic
music in Spore (OK, that isn't saying much ... given what a horrible,
horrible disaster Spore was), but still, it's been incorporated in some
other products/systems as well. I haven't really messed with the GL
stuff. But, again, for me, its a platform for experimentation, basically.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> ... I probably wouldn't like it.
>
> 0 for two... lol.
>
> First Maxima, now this :P
>
> Of course, Maxima just about lives on my desktop now... Has come in
> rather handy at times.
I had a trial version of Mathematica for a while. It turns out most of
the questions I can't answer are mathematically impossible. And for the
handful of questions which can be answered, there's Wolfram Alpha.
Heck, even Mathematica annoyed my a little by being less perfect than I
wanted. :-P
(Also... this thing costs £7,000 and it can't do anti-aliased graphics?
WTF?)
> For me, PD is a novel toy...
As I say, it looks too low-level for me.
I use GNUplot from time to time, and that annoys me with its lame
interface too. I keep promising myself that some day I'll make a proper
graphing tool...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 14 Feb 2011 16:49:17 +0100, Le_Forgeron wrote:
> IIRC, opinions are like a**h*l*s... everybody get one...
And they all stink. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 14/02/2011 18:00, Jim Henderson nous fit lire :
> On Mon, 14 Feb 2011 16:49:17 +0100, Le_Forgeron wrote:
>
>> IIRC, opinions are like a**h*l*s... everybody get one...
>
> And they all stink. ;-)
Nah, mine is smelling a fine perfurm of subtile vanilla, rose and lily;
A real delicacy.
And as usual, our own fart have no odor at all. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/14/2011 10:16 AM, Invisible wrote:
>> For me, PD is a novel toy...
>
> As I say, it looks too low-level for me.
It is low-level. But, really, its not supposed to be a high-level tool.
But-- If you're working on a softsynth, or fooling around with DSP
techniques, it beats coding up a program, since it already has the
framework laid down, all you need to do is make the connections. It can
also do things live, which can be interesting.
> I use GNUplot from time to time, and that annoys me with its lame
> interface too. I keep promising myself that some day I'll make a proper
> graphing tool...
Yeah, GNUPlot sucks. My use for Maxima is mostly for simply quickly
plugging something in, and solving it w/o having to manually do the
algebra.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 14 Feb 2011 18:47:09 +0100, Le_Forgeron wrote:
> Le 14/02/2011 18:00, Jim Henderson nous fit lire :
>> On Mon, 14 Feb 2011 16:49:17 +0100, Le_Forgeron wrote:
>>
>>> IIRC, opinions are like a**h*l*s... everybody get one...
>>
>> And they all stink. ;-)
>
> Nah, mine is smelling a fine perfurm of subtile vanilla, rose and lily;
> A real delicacy.
I don't want to know how you determined that. ;-)
> And as usual, our own fart have no odor at all. ;-)
But of course! But in keeping with the original idea of the statement,
one never thinks one's own opinions are wrong - just everyone else's. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.02.2011 18:47, schrieb Le_Forgeron:
> Le 14/02/2011 18:00, Jim Henderson nous fit lire :
>> On Mon, 14 Feb 2011 16:49:17 +0100, Le_Forgeron wrote:
>>
>>> IIRC, opinions are like a**h*l*s... everybody get one...
>>
>> And they all stink. ;-)
>
> Nah, mine is smelling a fine perfurm of subtile vanilla, rose and lily;
> A real delicacy.
>
> And as usual, our own fart have no odor at all. ;-)
... except for the /really/ satisfying ones. They /have/ to :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.02.2011 16:46, schrieb Invisible:
> On 14/02/2011 02:05 PM, Mike Raiford wrote:
>> Ever heard of it? Have an opinion? Just curious. Been kinda poking
>> around it, neat little graphical DSP type thingy. Though looks crude, is
>> quite flexible, a lot you can do with it.
>
> Looks very hackish to me. I probably wouldn't like it.
>
> The (very expensive) Reaktor software I have already does approximately
> this with audio. (But with cleaner abstractions.) And there's WinAmp's
> AVS and Milkdrop plugins that do roughly the same for video.
> (Unfortunately, those are quite hackish as well.)
... and not to forget Matlab/Simulink.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> As I say, it looks too low-level for me.
>
> It is low-level. But, really, its not supposed to be a high-level tool.
Same reason I dislike C. ;-)
> But-- If you're working on a softsynth, or fooling around with DSP
> techniques, it beats coding up a program, since it already has the
> framework laid down, all you need to do is make the connections. It can
> also do things live, which can be interesting.
Same goes for Reaktor. Except that that has a pretty GUI and comes with
a truckload of soft synths that are useful out-of-the-box. (OTOH, it's a
very expensive product...)
>> I use GNUplot from time to time, and that annoys me with its lame
>> interface too. I keep promising myself that some day I'll make a proper
>> graphing tool...
>
> Yeah, GNUPlot sucks. My use for Maxima is mostly for simply quickly
> plugging something in, and solving it w/o having to manually do the
> algebra.
Doesn't Maxima (and every other CAS that isn't Mathematica) use GNUplot
for all its graphing?
Anyway, Wolfram Alpha lets you solve most things for free. If you can
convince it to comprehend the question, and if Wolfram haven't
deliberately disabled it. For that is the biggest problem with WA;
Wolfram talks the big talk about "making everything computable", but if
that were true, there would be little incentive to shell out £7,000 for
the full version of Mathematica, would there? Thus, they have
deliberately disabled certain queries.
If only I had the time and the expertise to build something similar
myself... (Ha! Like anybody has that much time and energy.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/15/2011 3:20 AM, Invisible wrote:
>>> As I say, it looks too low-level for me.
>>
>> It is low-level. But, really, its not supposed to be a high-level tool.
>
> Same reason I dislike C. ;-)
>
And why I so very much love C and C++. I like the whole down to the
metal thing. Granted C# is a nice departure, and can actually be rather
pleasant to work with at times, and it will, if you ask it to allow you
plenty of opportunity to shoot yourself in the foot quite well. You just
have to say "Now, I'd like the opportunity to shoot myself in the foot,
can you look the other way for a moment" ...
then after attempting to shoot yourself in the foot:
"Ok, all done here. You can turn around now. There's good news, and bad
news: The good news is I missed. The bad news is left a big gaping hole
in the floor; I hope you don't fall in."
To which the CLR will reply "Oh, crap. Not again."
>> But-- If you're working on a softsynth, or fooling around with DSP
>> techniques, it beats coding up a program, since it already has the
>> framework laid down, all you need to do is make the connections. It can
>> also do things live, which can be interesting.
>
> Same goes for Reaktor. Except that that has a pretty GUI and comes with
> a truckload of soft synths that are useful out-of-the-box. (OTOH, it's a
> very expensive product...)
>
Does it have a demo? I'd like to play with it. But yeah, PD's UI is
quite ...primitive (That should get understatement of the year)
What I don't like, is there's no good way to visualize how multiple
inputs are being sent to a control port. They're sent in the order of
creation. Which is nice, the user has total control on how messages are
ordered when passed, but is also a bitch when looking at it after you've
created something and wondering why it doesn't seem to be working the
way you need it to.
>
> Doesn't Maxima (and every other CAS that isn't Mathematica) use GNUplot
> for all its graphing?
>
Yes, Maxima does. Hence why I've learned it sucks. Especially on the
Windows platform. That's OK. I have a graphing calculator program that
works quite well for drawing pretty graphs.
> Anyway, Wolfram Alpha lets you solve most things for free. If you can
> convince it to comprehend the question, and if Wolfram haven't
> deliberately disabled it. For that is the biggest problem with WA;
> Wolfram talks the big talk about "making everything computable", but if
> that were true, there would be little incentive to shell out £7,000 for
> the full version of Mathematica, would there? Thus, they have
> deliberately disabled certain queries.
So does Maxima, and it lives on the computer as a desktop application,
and doesn't need to do a web query and can generally pop results back
quicker. Which allows a bit of fiddling with the inputs. You can also
save the worksheet for later.
> If only I had the time and the expertise to build something similar
> myself... (Ha! Like anybody has that much time and energy.)
Heh.... Yeah, I'm not exactly keen on writing a CAS in my spare time
either.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> It is low-level. But, really, its not supposed to be a high-level tool.
>>
>> Same reason I dislike C. ;-)
>>
>
> And why I so very much love C and C++. I like the whole down to the
> metal thing.
No, see, that's why I like writing in *assembly*. But C pretends to be
high-level, but isn't.
Like, in Haskell, if I want a 64-bit unsigned integer, I say "Word64".
In C, I say... um, well it seems to vary by compiler/OS. WTF? And this
is supposedly a language *designed* for low-level programming? Yeah, right.
Assembly gives you total control, if that's what you want. Haskell lets
you get on with writing a complex algorithm, if that's what you want. C
lets you do neither of these things.
>> Same goes for Reaktor. Except that that has a pretty GUI and comes with
>> a truckload of soft synths that are useful out-of-the-box. (OTOH, it's a
>> very expensive product...)
>>
>
> Does it have a demo? I'd like to play with it. But yeah, PD's UI is
> quite ...primitive (That should get understatement of the year)
Yes - but it's temporarily unavailable. (How typical!)
The product page is at
http://www.native-instruments.com/#/en/products/producer/reaktor-5/
From there you can look at screenshots, listen to some of the demo
tunes, and if you click "downloads" you can download the complete User
Manual, which will tell you something about what the product can and
can't do.
Normally the downloads page would also have a "request a demo" button,
which sends you an email with a unique URL to a download. The program
runs for 30 days with saving disabled, but otherwise it's fully
functional. (If you type in a registration key, it becomes the full
product.)
I presume you've also heard by rendition of Silhouettes? That was made
using nothing but one single synth that comes with the default Reaktor
install. (A synth called Steam Pipe.) It uses waveguide synthesis to
make quite authentic wind and string sounds. In case you wanted to know
what Reaktor sounds like in the hands of a typical person, not the NI
marketing department. ;-)
> What I don't like, is there's no good way to visualize how multiple
> inputs are being sent to a control port. They're sent in the order of
> creation. Which is nice, the user has total control on how messages are
> ordered when passed, but is also a bitch when looking at it after you've
> created something and wondering why it doesn't seem to be working the
> way you need it to.
Reaktor has a few annoying limitations too.
- You can create "components", but changing one instance of a component
doesn't affect any of the other instances.
- There are no looping constructs.
The first one doesn't bite too much if you implement your components
correctly first time. If you don't, it's a PITA.
The second one means that if, say, you wanted a bank of 200 filters each
tuned to a different frequency... you have to insert all 200 filters by
hand, one at a time.
[There's a hack: Create a synth with 200 notes polyphonic, put one
filter into it, and use the voiceID to set the filter's frequency.
Needless to say, this trick only works once per synth...]
>> Doesn't Maxima (and every other CAS that isn't Mathematica) use GNUplot
>> for all its graphing?
>
> Yes, Maxima does. Hence why I've learned it sucks.
LOL!
> Especially on the Windows platform.
*Everything* with GNU in the name sucks on Windows!
>> Anyway, Wolfram Alpha lets you solve most things for free.
>
> So does Maxima, and it lives on the computer as a desktop application,
> and doesn't need to do a web query and can generally pop results back
> quicker. Which allows a bit of fiddling with the inputs. You can also
> save the worksheet for later.
Wolfram knows things like unit conversion factors, and it knows formulas
that you'd have to look up in a textbook if you wanted Maxima to compute
them. Plus you can use it to look up statistics that Maxima doesn't have
access to.
On the other hand, it can only answer questions simple enough to be
written as a single question. Maxima (or any other desktop application)
has the killer advantage that you can build far more complex scenarios
with it.
>> If only I had the time and the expertise to build something similar
>> myself... (Ha! Like anybody has that much time and energy.)
>
> Heh.... Yeah, I'm not exactly keen on writing a CAS in my spare time
> either.
At its core, Mathematica is a transformation engine. The engine knows
nothing about mathematics; it just takes an expression and applies any
applicable transformation rules to it, repeatedly until no more rules
apply. You can (and people have) use it for things that aren't math.
Implementing Mathematica's transformation engine is a relatively
straight-forward task. Duplicating Mathematica's extensive library of
mathematical transformations is not. (!) They've put 20+ years of R&D
into that library. There's no way one person is going to duplicate it in
ten minutes.
(It's a bit like saying that writing an OS kernel is easy, but building
a complete desktop OS is not.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> 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.)
> Assembly gives you total control, if that's what you want.
And how do you specify a 64-bit unsigned integer in assembly, exactly?
(Remember: You complained how C integral types are system-dependent.)
> Haskell lets
> you get on with writing a complex algorithm, if that's what you want. C
> lets you do neither of these things.
Depends on the algorithm. (C++ is definitely better in this aspect
because in many cases it removes the need to worry about memory management
so you can just concentrate on the algorithm itself, although not always.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.)
>> Assembly gives you total control, if that's what you want.
>
> And how do you specify a 64-bit unsigned integer in assembly, exactly?
> (Remember: You complained how C integral types are system-dependent.)
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.
There's a reason most people don't write assembly any more.
>> Haskell lets
>> you get on with writing a complex algorithm, if that's what you want. C
>> lets you do neither of these things.
>
> Depends on the algorithm.
I would imagine so.
> C++ is definitely better in this aspect
Agreed. Writing programs that work properly seems a lot easier in C++
than in C.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> >> Assembly gives you total control, if that's what you want.
> >
> > And how do you specify a 64-bit unsigned integer in assembly, exactly?
> > (Remember: You complained how C integral types are system-dependent.)
> 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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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] 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.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <lef### [at] freefr> wrote:
> Le 14/02/2011 16:38, Invisible a écrit :
> > On 14/02/2011 03:17 PM, Warp wrote:
> >
> >> You know what they say about opinions...
> >
> > They're like onions?
> >
> > No, wait, that's ogres...
>
> IIRC, opinions are like a**h*l*s... everybody get one...
Opinions are like anthills?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> The list at the top of the page indicates that this doesn't include md5sum.
Sorry. It was in my history, and I'd recently (like 2 weeks ago) downloaded
an md5sum.exe that works fine, so I thought that's where I got it. Generally
speaking, "gnu win32" is an excellent pair of keywords for google to find
such stuff. Does the attached work for you?
> 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.
I see what you mean, yes.
--
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
Attachments:
Download 'md5sum.exe.dat' (28 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am Thu, 17 Feb 2011 09:22:07 +0000 schrieb Invisible:
> 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?)
>
Well, right tool for the right job...
> As soon as you want to do anything even moderately complex, it becomes
> an utter nightmare. The documentation is minimal to say the least.
Nah - the build in help covers everything, but I give you that some stuff
is really hard to find.
> 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.
I don't know what exactly you want to do, but googling for "recurrence
relation gnuplot" came up with this nice mandelbrot fractal:
http://t16web.lanl.gov/Kawano/gnuplot/fractal/mandelbrot-e.html
That's already a quite old version of povray and I guess you can do more
stuff with newer versions - I think the most difficult part is telling
gnuplot what you want to do.
But I guess the stuff gnuplot is really good at is plotting data
(experimental results or computer simulation results) and it does a good
job at this. Usually we write the program putting out data ourself, so if
gnuplot likes spaces instead of commas as separator its usually not a big
deal (And then there is awk and such stuff ;)). It is not made for the
data processing itself, that is usually done outside of gnuplot (even
though you can hack quite some stuff in it).
>
> Now, if only it would support CSV input... You know, the de facto file
> format for all numerical data? Yeah. :-P
I think it does? See
http://gnuplot.sourceforge.net/docs_4.2/node173.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
>
> Well, right tool for the right job...
It also can do certain types of plot that Excel can't do at all. On the
other hand, with Excel, if I want to change the font size of the X-axis
labels, I just right-click it and press "format". Good luck finding out
how to do that in GNUplot (or even *if* you can do that in GNUplot - it
varies by OS and output target!)
> Nah - the build in help covers everything, but I give you that some stuff
> is really hard to find.
Really *really* hard to find, yes.
>> 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.
>
> I don't know what exactly you want to do, but googling for "recurrence
> relation gnuplot" came up with this nice mandelbrot fractal:
>
> http://t16web.lanl.gov/Kawano/gnuplot/fractal/mandelbrot-e.html
I have literally no idea how that's possible.
> That's already a quite old version of povray
Uh... POV-Ray?
> But I guess the stuff gnuplot is really good at is plotting data
Yes, that's really its design purpose.
Of course, the fact that this data was to be in THE EXACT RIGHT FORMAT
or it refuses to plot anything isn't very helpful.
>> Now, if only it would support CSV input... You know, the de facto file
>> format for all numerical data? Yeah. :-P
>
> I think it does? See
>
> http://gnuplot.sourceforge.net/docs_4.2/node173.html
All these years I've been using GNUplot and I've never once been able to
make it plot any data from an external source. (That should tell you how
good the documentation is...)
OK, so that's how you tell it to load CSV. Now how do you specify which
columns to plot?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/16/2011 10:20 AM, Invisible wrote:
>
> There's a reason most people don't write assembly any more.
>
It's called pipelined instructions with multiple simultaneous units that
require operations in a certain order in order to be most efficient, and
sometimes even a strategic NOP just to get the instructions to pipe
properly. A compiler is faster at implementing these rules than a person.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> There's a reason most people don't write assembly any more.
>
> It's called pipelined instructions with multiple simultaneous units that
> require operations in a certain order in order to be most efficient, and
> sometimes even a strategic NOP just to get the instructions to pipe
> properly. A compiler is faster at implementing these rules than a person.
This only matters if you're interested in performance.
If you're interested in reliability and maintainability, there's the
fact that there is almost no machinery to stop you shooting yourself in
the foot.
If you're interested in portability...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/17/2011 3:15 AM, Invisible wrote:
>
> 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.
Underneath it all, Maxima is similar. Its all symbolic. Certain things
have certain meanings. All functionality and rules are defined in
libraries, it has a standard set that it loads when started that gives
pretty standard algebra and calculus. Depending on how far down the
rabbit hole you want to go, you can even from the Maxima command line
give it instructions in Lisp.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
>
> Underneath it all, Maxima is similar. Its all symbolic. Certain things
> have certain meanings. All functionality and rules are defined in
> libraries, it has a standard set that it loads when started that gives
> pretty standard algebra and calculus. Depending on how far down the
> rabbit hole you want to go, you can even from the Maxima command line
> give it instructions in Lisp.
Many of these CAS programs have a parser written in C that snips up text
and turns it into internal data structures. Then other C code does
algebraic transformations such as collecting like terms and so forth. If
you want to input something that isn't algebra, or expressions in a
non-associative algebra... sorry, you can't do that.
Mathematica doesn't work this way. The core implements a transformation
engine, and arbitrary precision math. Beyond that, the parser, the
printer, the simplification rules, *everything* is Mathematica source
code, which can be altered at will (if you're so-inclined).
I have no idea about the architecture of Maxima, but it wouldn't
surprise me. There are advantages to doing it this way. (The main
disadvantage is performance...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/18/2011 8:16 AM, Invisible wrote:
>
> This only matters if you're interested in performance.
>
Why else would you use assembly?
> If you're interested in reliability and maintainability, there's the
> fact that there is almost no machinery to stop you shooting yourself in
> the foot.
>
There are plenty of languages that allow better maintainability.
> If you're interested in portability...
Assembly isn't portable by its very nature ;)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> This only matters if you're interested in performance.
>
> Why else would you use assembly?
Perhaps because you need to perform specific hardware-level operations
that C doesn't support. (E.g., selecting a different processor mode or
something.) There's usually a few bits of the OS written in assembly
because they do very low-level stuff.
> There are plenty of languages that allow better maintainability.
>
> Assembly isn't portable by its very nature ;)
...which leads us back to my "there are *reasons* why nobody uses
assembler any more". ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/18/2011 8:22 AM, Invisible wrote:
> Mathematica doesn't work this way. The core implements a transformation
> engine, and arbitrary precision math. Beyond that, the parser, the
> printer, the simplification rules, *everything* is Mathematica source
> code, which can be altered at will (if you're so-inclined).
>
> I have no idea about the architecture of Maxima, but it wouldn't
> surprise me. There are advantages to doing it this way. (The main
> disadvantage is performance...)
Yep :) pretty much how Maxima works. You can define your own operators,
their associativity (if any), precedence, and a number of other things.
Rules are defined in much the way you described. They're all written in
Maxima's language. There are a few intrinsic things: assignment,
function calls, and some other syntax glue.... But just about anything
can be defined as just about anything else.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/18/2011 8:56 AM, Invisible wrote:
>>> This only matters if you're interested in performance.
>>
>> Why else would you use assembly?
>
> Perhaps because you need to perform specific hardware-level operations
> that C doesn't support. (E.g., selecting a different processor mode or
> something.) There's usually a few bits of the OS written in assembly
> because they do very low-level stuff.
>
Oh, right ... I forgot about that.
> ...which leads us back to my "there are *reasons* why nobody uses
> assembler any more". ;-)
Well, if you don't want to write portable code... then go for it.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Mathematica doesn't work this way. The core implements a transformation
>> engine, and arbitrary precision math. Beyond that, the parser, the
>> printer, the simplification rules, *everything* is Mathematica source
>> code, which can be altered at will (if you're so-inclined).
>
> Yep :) pretty much how Maxima works. You can define your own operators,
> their associativity (if any), precedence, and a number of other things.
> Rules are defined in much the way you described. They're all written in
> Maxima's language. There are a few intrinsic things: assignment,
> function calls, and some other syntax glue.... But just about anything
> can be defined as just about anything else.
I haven't tried this, but I understand that the actual input parser for
Mathematica is user-defined. You can make it parse, e.g., chemical
formulas rather than algebra. You can change what function-call syntax
looks like. And so on.
Then again, you don't buy a £7,000 CAS system in order to modify it into
something that doesn't do math. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>> This only matters if you're interested in performance.
>>>
>>> Why else would you use assembly?
>>
>> Perhaps because you need to perform specific hardware-level operations
>> that C doesn't support.
>
> Oh, right ... I forgot about that.
Never forget. ;-)
>> ...which leads us back to my "there are *reasons* why nobody uses
>> assembler any more". ;-)
>
> Well, if you don't want to write portable code... then go for it.
I'm sure if you're trying to program a toaster, it might actually be
worth it. (How complex can it possibly be?)
It's surprising how many Project Euler problems have solutions (plural)
in assembly...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17/02/2011 01:48 PM, Mike the Elder wrote:
> Opinions are like anthills?
Everybody makes mountains out of them?
No, wait, that's molehills...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> >> This only matters if you're interested in performance.
> >
> > Why else would you use assembly?
> Perhaps because you need to perform specific hardware-level operations
> that C doesn't support. (E.g., selecting a different processor mode or
> something.) There's usually a few bits of the OS written in assembly
> because they do very low-level stuff.
It's not like you need to write the entire program in assembly just
because you need to execute one asm instruction not supported by the
language. They invented inline asm for a reason.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/02/2011 04:28 PM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>>>> This only matters if you're interested in performance.
>>>
>>> Why else would you use assembly?
>
>> Perhaps because you need to perform specific hardware-level operations
>> that C doesn't support. (E.g., selecting a different processor mode or
>> something.) There's usually a few bits of the OS written in assembly
>> because they do very low-level stuff.
>
> It's not like you need to write the entire program in assembly just
> because you need to execute one asm instruction not supported by the
> language. They invented inline asm for a reason.
Sure. I was just pointing out that "performance" isn't the only possible
reason for writing assembly. My original point was that "nobody writes
assembly any more"...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/18/2011 9:59 AM, Invisible wrote:
>>> Mathematica doesn't work this way. The core implements a transformation
>>> engine, and arbitrary precision math. Beyond that, the parser, the
>>> printer, the simplification rules, *everything* is Mathematica source
>>> code, which can be altered at will (if you're so-inclined).
>>
>> Yep :) pretty much how Maxima works. You can define your own operators,
>> their associativity (if any), precedence, and a number of other things.
>> Rules are defined in much the way you described. They're all written in
>> Maxima's language. There are a few intrinsic things: assignment,
>> function calls, and some other syntax glue.... But just about anything
>> can be defined as just about anything else.
>
> I haven't tried this, but I understand that the actual input parser for
> Mathematica is user-defined. You can make it parse, e.g., chemical
> formulas rather than algebra. You can change what function-call syntax
> looks like. And so on.
It can be done with Maxima. It really depends on how far you want to
push it. What probably cannot be done is really low-level changes to the
way it handles input. e.g. altering the basic syntax of the system
without lifting the hood and tweaking the underlying lisp (Though, you
can do this from inside the workbook.
What you can do within Maxima's language is define new operators, set
that operator as postfix, infix, prefix, or nofix, and have fine-grained
control over precedence and associativity. I suppose technically you
could redefine how a function is called within its language.
I'm actually fooling with getting it to simplify boolean algebra by
messing with pattern matching and such, but I haven't wrapped my head
completely around how the matching works, and how to get it to do some
of the more interesting stuff. It's there, they have packages for all
kinds of things, including simplifying inequalities, etc all written in
Maxima's language.
I guess, technically you could do the same thing (have it manipulate
chemical equations instead of mathematical equations, it doesn't seem
like that big of a leap, given the simplifier engine) inside of Maxima.
> Then again, you don't buy a £7,000 CAS system in order to modify it into
> something that doesn't do math. ;-)
Yeah, well ;) Its like someone using 3D-Studio MAX to produce blueprints
of a mechanical part.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/20/2011 10:28 AM, Warp wrote:
>
> It's not like you need to write the entire program in assembly just
> because you need to execute one asm instruction not supported by the
> language. They invented inline asm for a reason.
>
Heh. Or that rare time when you're using an API that requires the
callbacks be naked functions and do ALL of their own handling of the
stack and everything. (Seriously, this is a requirement of the CLR
profiling API) Not only that, but the compiler will not form calls to
either CDECL or STDCall functions from a naked function properly. You
either have to modify the stack frame to work within the context of the
function, or know darn good and well how the function you're calling is
handled. How are arguments passed? who cleans the stack?
Fun stuff. :) Haven't had to break down to pure asm in ages. :D But,
then it's only a couple of functions to call a stub that delegates the
real work. it's not like I had to write pages and pages of assembly.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
