![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 20/02/2011 04:28 PM, Warp wrote:
> Invisible<voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |