f[t_] := UnitStep[t]*Exp[-I*t];
Table[f[n], {n,-2,2}]
{0, 0, 1, E^(-I), E^(-2*I)}
Bob Hanlon
<< How to define a function over two different ranges in mathematica.
For example
f(t):= Exp[-i*t] for t > 0 and
= 0 for t < 0
>>
====
> I have a For loop storing data in a {x,y} list (where x is time and y
> is
> temperature), and I would like to get the x at which a certain
> threshold
> y occurs without stoping the loop.
You can use Sow and Reap to record the {x,y} pair that meets your
criteria.
For example,
Reap[Table[If[i>10,Sow[i],i],{i,12}]]
Returns
{{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12}, {{11, 12}}}
====
> I have a For loop storing data in a {x,y} list (where x is time and y is
> temperature), and I would like to get the x at which a certain threshold
> y occurs without stoping the loop.
hi.
you could get this value inside the for loop itself using a standard
procedural algorithmic technique such as:
1. first set a flag variable Found = False outside the loop.
2. within the for loop, after you calculate the {time, temp}, you could
write an If statement like:
If [temp > threshold && Found == False,
(resultTime = time;
Found = True;)]
the other, more elegant (but possibly equally computationally expensive)
way could be to t
am assuming that your final data list looks like:
data = { {time1, temp1}, {time2, temp2}, ...}
Select[data, (#[[2]] >= threshold)&, 1] [[1,1]]
This statement creates a list of the first 1 element (thats what the , 1
does inside the Select statement) that meets the condition that its
second part (the temp) is greater than a threshold. The [[1, 1]] at the
end pulls out the first part of the first (and only) element of this list.
Hope this helps.
- sujai
====
Put Throw[] and Catch[] functions inside your loops. Look in the help to
learn how to use the functions.
-----Original Message-----
====
Andrzej removed my private response about the packet so I'll share it
for everyone's benefit.
>I think there might be a new bug in getting the state of these menus
>items in 5.0. The Notation package looks at them to determine which
>form to create the notation in. It looks like this low level packet
>has changed or has some glitch. In the meantime you can get around
>this problem by adding the option WorkingForm->TraditionalForm
It turns out there was no error at all in Mathematica. (I was working
on something experimental and it turned out that my initial
impression that there was an issue in AbsoluteOptions[$FrontEnd,
CommonDefaultFormats] was wrong.) Thus there was no problem at all in
Mathematica 5.0 in this case.
>>Right now the working form is determined from the output format type
>>only. That is since your default output format was TraditionalForm
>>then the input and output rules were created only for traditional
>>form. If you are going to use mixed forms you should create two
>>statements. one for each form.
>>e.g.
>>Cell[BoxData[
>> RowBox[{Symbolize, [,
>> TagBox[[Placeholder],
>> NotationBoxTag,
>> TagStyle->NotationTemplateStyle], , ]}]],
Input]
>>and
>>Cell[BoxData[
>> FormBox[
>> RowBox[{Symbolize, [,
>> RowBox[{
>> TagBox[[Placeholder],
>> NotationBoxTag,
>> TagStyle->NotationTemplateStyle], , ,,
>> RowBox[{
>> WorkingForm, , [Rule], ,
TraditionalForm}]}],
>> ]}], TraditionalForm]], Input]
>>
I should point out as well that Symbolizing in both forms is slightly
problematic. (Note Notations are immune to this artifact.) I can go
into more technical detail about this if necessary, but for now if
you are using Symbolizations its best to have the Default Input
FormatType and Default Output FormatType the same.
>Okay, now I understand what has happened. It took me a long time to
>accept what Paul has been arguing for years: that TraditionlForm is
>a good thing. Until about a year ago I worked exclusively in
>StandardForm, only occasionally converting certain cells to
>TraditionalForm. Only fairly recently I started using
>TraditionalForm as the default for output but I still kept
>StandardForm for input. It is this change that must have caused my
>problems with the Notation package, which are therefore not related
>to any changes in Mathematica.
I am still not convinced that TraditionalForm makes good input. It
>hides too much of the underlying Mathematica code, it makes it
>difficult to copy and paste cells and, it seems to me, is more prone
>to corruption. Besides, I do tend to think of input and output as
>performing a different role, with input being essentially source
>code.
But its very nice to be able to edit the output as new input, thus
they are highly linked in an interactive system such as Mathematica's.
>Even when I teach undergraduate classes I prefer StandardForm for
>input, since it reveals much more of the Mathematica programming
>language and hence is more instructive. So it seems to me that the
>mixed form (Standard for input, Traditional for output) is the most
>natural setup.
Yep. Its on my list :)
-------------
====
> Right now the working form is determined from the output format type
> only. That is since your default output format was TraditionalForm
> then the input and output rules were created only for traditional
> form. If you are going to use mixed forms you should create two
> statements. one for each form.
e.g.
Cell[BoxData[
> RowBox[{Symbolize, [,
> TagBox[[Placeholder],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle], , ]}]], Input]
and
Cell[BoxData[
> FormBox[
> RowBox[{Symbolize, [,
> RowBox[{
> TagBox[[Placeholder],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle], , ,,
> RowBox[{
> WorkingForm, , [Rule], ,
TraditionalForm}]}],
> ]}], TraditionalForm]], Input]
>
Okay, now I understand what has happened. It took me a long time to
accept what Paul has been arguing for years: that TraditionlForm is a
good thing. Until about a year ago I worked exclusively in
StandardForm, only occasionally converting certain cells to
TraditionalForm. Only fairly recently I started using TraditionalForm
as the default for output but I still kept StandardForm for input. It
is this change that must have caused my problems with the Notation
package, which are therefore not related to any changes in Mathematica.
I am still not convinced that TraditionalForm makes good input. It
hides too much of the underlying Mathematica code, it makes it
difficult to copy and paste cells and, it seems to me, is more prone to
corruption. Besides, I do tend to think of input and output as
performing a different role, with input being essentially source
code. Even when I teach undergraduate classes I prefer StandardForm
for input, since it reveals much more of the Mathematica programming
language and hence is more instructive. So it seems to me that the
mixed form (Standard for input, Traditional for output) is the most
natural setup.
Andrzej Kozlowski
> I have added it to my list of updates that for the next major
> revision if the user has differing forms for Input and Output then
> the notations / symbolizations will be created in both forms. That is
> the WorkingForm option will be able to take a list and the Automatic
> value is substituted for the list of forms used. That is if Cell- Default Input FormatType and Cell-> Default Output FormatType
> differ then the notation statements should be created in both types.
Thus at present there is no bug per say, its working as I
> originally intended. However, this came up once before as a source of
> frustration for users so I guess we should be more forgiving and just
> generate the notations in all the forms involved.
> I am afraid it is not going to be that simple. It seems that my
> repeated attempts to use Symbolize caused me to enter the
> NotationBoxTag wrapper twice, but this is a red herring and has
> nothing to do with the problem. (It is actually rather unlikely
> that I would have the habit of entering this tag twice. It was just
> one of those unlikely coincidences that keep happening, that when I
> decide to post the error to the MathGroup this kind of thing
> happens which obscures the whole problem.)
>> I know the feeling first hand only too well... :)
> In any case, the point is that with only a fresh kernel and only
> the following input:
> In[1]:=
> < In[2]:=
> Cell[BoxData[
> RowBox[{Symbolize, [,
> TagBox[
> SubscriptBox[x, _],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle], ]}]], Input,
> CellLabel->In[2]:=]
> whcih you can now see is quite correct I still get:
>> In[3]:=
> !(f[(x_1) : _] := x_1^2)
> !(*FormBox[
> RowBox[{(Syntax::sntxf), ((:)( )),
> followed by
!(TraditionalForm`(((x_1 :
> _))]))
> .!(TraditionalForm`)
> !(*ButtonBox[MoreÉ,
> ButtonStyle->RefGuideLinkText, ButtonFrame->None,
> ButtonData:>General::sntxf])>}],
TraditionalForm])
> !(*
> StyleBox[
> RowBox[{
> RowBox[{f, [,
> ErrorBox[((x_1) : _)], ]}], :=,
(x_1^2)}],
> ShowStringCharacters->True])
>> Ahh I think I might know what the problem is what are your settings
>> for forms? That is look in menu Cell->Default Input FormatType
>> and Cell->Default Output FormatType what are these set to?
>> StandardForm or TraditionalForm or mixed?
>> I am guessing these are both TraditionalForm from your output?
>> I think there might be a new bug in getting the state of these menus
>> items in 5.0. The Notation package looks at them to determine which
>> form to create the notation in. It looks like this low level packet
>> has changed or has some glitch. In the meantime you can get around
>> this problem by adding the option WorkingForm->TraditionalForm
>> Cell[BoxData[
>> FormBox[
>> RowBox[{Symbolize, [,
>> RowBox[{
>> TagBox[
>> SubscriptBox[x, _],
>> NotationBoxTag,
>> TagStyle->NotationTemplateStyle], ,,
>> RowBox[{WorkingForm, [Rule], TraditionalForm}]}],
>> ]}],
>> TraditionalForm]], Input,
>> CellLabel->In[5]:=]
>> I am going to investigate the packet and I'll get back to you
>>
> Andrzej
> [Notation example snipped]
> On my system this example just fails miserabley (the
>> definiton of transmissionCoefficient does not parse) although it
>> once
>> used to work. (Actually, I would like to hear from other people,
>> because either the Notation package is no longer working or
>> something
>> is wrong with my installation).
> I know these things can appear frustrating at times, but the
> Notation
> package is working fine. In the example you have given, you have
> managed to include the box wrapper twice in your Symbolize
> statement.
> (You likely did this through copying the k subscript including box
> wrapper and pasted it into a new Symbolize statement.)
> Anyway, if this works on your system than the problem is solved.
>> You
>> can symbolize subscripted variables and use them as if they were
>> symbols. On the other hand, in the past, when this package used
>> to work
>> on my system, I got myself into a huge mess when I tried to
>> evaluate
>> again a notebook that had previously worked correctly.
> If there is some notebook corruption going on then we definitely
> want
> to know about this. In the example you have given it is extremely
> likely that you inadvertently caused the error with a copy and paste
> from one symbolize statement to another. (I know notation statements
> can be tricky and it is not all that hard to hang yourself.)
> Because of that I finally decided that relying on a package like
>> this is
>> just too risky if you are doing any serious work.
> Hmm... Actually I personally think its just the opposite. If you are
> really doing serious work you need to know about typesetting and how
> to enter expressions in notations which are familiar to
> Mathematicians, physicists, and other users and have these notations
> function correctly.
> First a general comment:
> When you are troubleshooting problems with setting up notations it
> is
> often necessary to look at the underlying boxes representing the
> typeset expression. You can do this through either the command key
> shortcut of cmd-shift-E (OSX) and I think cntrl-shift-E (Win), or
> through the menu item Format -> Show Expression...
> Looking at the underlying boxes shows you how the typeset expression
> is represented. As a Mathematica programmer you no doubt use
> FullForm
> at times to examine how a certain pattern is structured. Its really
> not too different with typesetting in that Mathematica functions
> through
> MakeBoxes and MakeExpression which operate on these box structures.
> If
> you don't have the correct structures, the boxes will not be
> interpreted as they should be.
> In a Symbolize statement waiting to be filled in the underlying
> structure is
> Cell[BoxData[
> RowBox[{Symbolize, [,
> TagBox[[Placeholder],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle], ]}]], Input]
> To see this load the notation package, type Esc-symb-Esc and then
> show
> the underlying expression. The box structure to be symbolized must
> be
> the first argument of this TagBox.
> The tag box wrapper, NotationBoxTag, is necessary so you can enter
> typeset expressions into Mathematica that are not currently
> syntactically valid. Then once the Notation package gets a hold of
> them, it compiles / translates these into corresponding rules for
> MakeExpression and MakeBoxes that do what you instructed. The tag
> box
> wrapper inertizes the box structure so it becomes syntactically
> valid
> Mathematica input.
> You can see this by copying out the box wrapper into a new cell and
> entering some syntactically invalid input into the wrapper, say x
> followed by *, and then viewing how it is interpreted by
> Mathematica. E.g. after loading the notation package paste the
> following cell into Mathematica and interpret it:
> Cell[BoxData[
> TagBox[
> RowBox[{x, *}],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle]], Input]
> Then evaluate this interpreted cell. Then start a new cell and
> evaluate FullForm[%]. The answer will be
> NotationBoxTag[RowBox[List[x, *]]]
> Thus the TagBox wrapper, NotationBoxTag, has allowed us to enter
> something that is syntactically invalid and get the box structure
> into
> the kernel. (Incidentally you can programmatically create symbolize
> and notation statements this way.) The TagBox wrapper NotationBoxTag
> can do this miraculous feat because it itself has a corresponding
> notation. (The TagStyle option is set so you can get some visual
> indication of where these tag box wrappers occur.)
> So anyway getting back to your example if you look at the underlying
> boxes you will see that instead of having
> Cell[BoxData[
> RowBox[{Symbolize, [,
> TagBox[
> SubscriptBox[k, _],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle], ]}]], Input]
> You had
> Cell[BoxData[
> RowBox[{Symbolize, [,
> TagBox[
> TagBox[
> SubscriptBox[k, _],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle], ]}]], Input]
> i.e. the wrapper was in there twice. Fixing this mistake resolves
> your problem.
>
> -------------
> Harris
> Wolfram Research
>> Andrzej Kozlowski
> Yokohama, Japan
> http://www.mimuw.edu.pl/~akoz/
http://www.mimuw.edu.pl/~akoz/
====
> Ahh I think I might know what the problem is what are your settings
> for forms? That is look in menu Cell->Default Input FormatType
> and Cell->Default Output FormatType what are these set to?
> StandardForm or TraditionalForm or mixed?
I am guessing these are both TraditionalForm from your output?
I was using StandardForm for Input and TraditionalForm for output. I
changed both to StandardForm and everything is now working fine. Looks
like a bug in v. 5.0 to me?
http://www.mimuw.edu.pl/~akoz/
====
I am afraid it is not going to be that simple. It seems that my
repeated attempts to use Symbolize caused me to enter the
NotationBoxTag wrapper twice, but this is a red herring and has nothing
to do with the problem. (It is actually rather unlikely that I would
have the habit of entering this tag twice. It was just one of those
unlikely coincidences that keep happening, that when I decide to post
the error to the MathGroup this kind of thing happens which obscures
the whole problem.)
In any case, the point is that with only a fresh kernel and only the
following input:
In[1]:=
<NotationTemplateStyle], ]}]], Input,
CellLabel->In[2]:=]
whcih you can now see is quite correct I still get:
In[3]:=
!(f[(x_1) : _] := x_1^2)
!(*FormBox[
RowBox[{(Syntax::sntxf), ((:)( )),
RefGuideLinkText, ButtonFrame->None,
ButtonData:>General::sntxf])>}],
TraditionalForm])
!(*
StyleBox[
RowBox[{
RowBox[{f, [,
ErrorBox[((x_1) : _)], ]}], :=,
(x_1^2)}],
ShowStringCharacters->True])
Andrzej
[Notation example snipped]
> On my system this example just fails miserabley (the
>> definiton of transmissionCoefficient does not parse) although it once
>> used to work. (Actually, I would like to hear from other people,
>> because either the Notation package is no longer working or something
>> is wrong with my installation).
I know these things can appear frustrating at times, but the Notation
> package is working fine. In the example you have given, you have
> managed to include the box wrapper twice in your Symbolize statement.
> (You likely did this through copying the k subscript including box
> wrapper and pasted it into a new Symbolize statement.)
>> Anyway, if this works on your system than the problem is solved. You
>> can symbolize subscripted variables and use them as if they were
>> symbols. On the other hand, in the past, when this package used to
>> work
>> on my system, I got myself into a huge mess when I tried to evaluate
>> again a notebook that had previously worked correctly.
If there is some notebook corruption going on then we definitely want
> to know about this. In the example you have given it is extremely
> likely that you inadvertently caused the error with a copy and paste
> from one symbolize statement to another. (I know notation statements
> can be tricky and it is not all that hard to hang yourself.)
>> Because of that I finally decided that relying on a package like
>> this is
>> just too risky if you are doing any serious work.
Hmm... Actually I personally think its just the opposite. If you are
> really doing serious work you need to know about typesetting and how
> to enter expressions in notations which are familiar to
> Mathematicians, physicists, and other users and have these notations
> function correctly.
First a general comment:
> When you are troubleshooting problems with setting up notations it is
> often necessary to look at the underlying boxes representing the
> typeset expression. You can do this through either the command key
> shortcut of cmd-shift-E (OSX) and I think cntrl-shift-E (Win), or
> through the menu item Format -> Show Expression...
Looking at the underlying boxes shows you how the typeset expression
> is represented. As a Mathematica programmer you no doubt use FullForm
> at times to examine how a certain pattern is structured. Its really
> not too different with typesetting in that Mathematica functions
> through
> MakeBoxes and MakeExpression which operate on these box structures. If
> you don't have the correct structures, the boxes will not be
> interpreted as they should be.
In a Symbolize statement waiting to be filled in the underlying
> structure is
Cell[BoxData[
> RowBox[{Symbolize, [,
> TagBox[[Placeholder],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle], ]}]], Input]
To see this load the notation package, type Esc-symb-Esc and then show
> the underlying expression. The box structure to be symbolized must be
> the first argument of this TagBox.
The tag box wrapper, NotationBoxTag, is necessary so you can enter
> typeset expressions into Mathematica that are not currently
> syntactically valid. Then once the Notation package gets a hold of
> them, it compiles / translates these into corresponding rules for
> MakeExpression and MakeBoxes that do what you instructed. The tag box
> wrapper inertizes the box structure so it becomes syntactically valid
> Mathematica input.
You can see this by copying out the box wrapper into a new cell and
> entering some syntactically invalid input into the wrapper, say x
> followed by *, and then viewing how it is interpreted by
> Mathematica. E.g. after loading the notation package paste the
> following cell into Mathematica and interpret it:
Cell[BoxData[
> TagBox[
> RowBox[{x, *}],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle]], Input]
Then evaluate this interpreted cell. Then start a new cell and
> evaluate FullForm[%]. The answer will be
NotationBoxTag[RowBox[List[x, *]]]
Thus the TagBox wrapper, NotationBoxTag, has allowed us to enter
> something that is syntactically invalid and get the box structure into
> the kernel. (Incidentally you can programmatically create symbolize
> and notation statements this way.) The TagBox wrapper NotationBoxTag
> can do this miraculous feat because it itself has a corresponding
> notation. (The TagStyle option is set so you can get some visual
> indication of where these tag box wrappers occur.)
So anyway getting back to your example if you look at the underlying
> boxes you will see that instead of having
Cell[BoxData[
> RowBox[{Symbolize, [,
> TagBox[
> SubscriptBox[k, _],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle], ]}]], Input]
You had
Cell[BoxData[
> RowBox[{Symbolize, [,
> TagBox[
> TagBox[
> SubscriptBox[k, _],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle],
> NotationBoxTag,
> TagStyle->NotationTemplateStyle], ]}]], Input]
i.e. the wrapper was in there twice. Fixing this mistake resolves your
> problem.
-------------
> Harris
> Wolfram Research
http://www.mimuw.edu.pl/~akoz/
====
I would like to put some comments in here concerning the Notation package.
I
think the package tackles a very useful and a very complicated problem. I
doubt if there are many people who could carry out what you have done.
Still I find severe problems with the package. It is difficult to put my
finger accurately on them but I will make an attempt. I have, on a number
of
occasions, spent many hours and even days trying to use the package and
have
always given up in frustration. Perhaps my intellectual capability just
isn't up to it.
User interface and documentation are very important for a package.
Let's talk about user interface first. The first thing that will happen
when
a user is trying to learn a package like this is that he will make
mistakes.
You can count on it. But there appears to be no easy method to undo the
mistakes. If a specific notation or Symbol has been entered incorrectly,
there doesn't seem to be any good way to get rid of it without killing the
kernel and starting over. When I tried to use RemoveNotation or
RemoveSymbol
it did not get rid of the underlying built_up symbols so errors or warning
messages were generated when I tried again to define a notation. One should
be able to easily undo one's mistakes and continue on.
It would be very helpful if one did not have to use the palette to enter a
notation or symbol. People do seem to have trouble in selecting the correct
box. It might be better if one could type in the command to establish a
notation and perhaps use Headers to distinguish special input.
Much of the Mathematica pattern capability appears to be lost in the
Notations package. Or else it isn't very clear how to use it. Can we use
the
general patterns, for example multiple arguments, arguments with specified
heads, or conditional patterns when establishing Symbols and Notations? Can
we use Rule based programming with entities established with Symbolize or
Notation? Without the use of general patterns I think that Notations is too
severely limited. I'm hoping that you will tell me that I am wrong here and
one can make general use of patterns! But it should be as easy as using
general patterns in regular Mathematica.
The modification of the notebook style sheet may be necessary and harmless
but it certainly does raise eyebrows with the user. It probably needs more
explanation in the documentation. Does it add a style sheet to the notebook
or does it modify the underlying style sheet? This is why I still question
if the palette is the best method for entering notations.
I still think that the documentation is not good enough. The very first
thing that a new user might try is the first example under Symbolize. I
defy
anyone to freshly type that example in, and not just evaluate the example
in
the Help notebook. It is definitely not What You See Is What You Type! If a
user can't get beyond that example what chance does he have?
As you explain below, the user has to be instructed about the use of the
underlying cell expressions. And once these are brought in the Notations
package is not quite the shortcut that users might have been hoping for. It
may be all right but it has to be explained and there have to be numerous
and COMMON examples.
In summary
1) I would like to see a better user interface and usability.
2) This is a difficulty subject and requires extra good documentation.
3) We need to know how to use general patterns and rule based programming
with notations.
I would dearly love to be able to use Notations. Renan Cabrera,
Jean-Francois Gouyet and I have a Tensorial package where we use Format
statements to format tensor output, and a number of other things such as
absolute derivatives, Lie derivatives or colored indices. It looks nice and
works, but the output cannot be copied and pasted. I was able to write some
MakeBoxes and MakeExpression statements that did allow the copying of
output
and tab entry on indices, but it was delicate and version dependent so we
didn't include it in the package. It would be very nice to make Notations
work on something like this.
David Park
djmp@earthlink.net
http://home.earthlink.net/~djmp/
managed to include the box wrapper twice in your Symbolize statement.
(You likely did this through copying the k subscript including box
wrapper and pasted it into a new Symbolize statement.)
> Anyway, if this works on your system than the problem is solved. You
> can symbolize subscripted variables and use them as if they were
> symbols. On the other hand, in the past, when this package used to work
> on my system, I got myself into a huge mess when I tried to evaluate
> again a notebook that had previously worked correctly.
If there is some notebook corruption going on then we definitely want
to know about this. In the example you have given it is extremely
likely that you inadvertently caused the error with a copy and paste
from one symbolize statement to another. (I know notation statements
can be tricky and it is not all that hard to hang yourself.)
> Because of that I finally decided that relying on a package like this is
> just too risky if you are doing any serious work.
Hmm... Actually I personally think its just the opposite. If you are
really doing serious work you need to know about typesetting and how
to enter expressions in notations which are familiar to
Mathematicians, physicists, and other users and have these notations
function correctly.
First a general comment:
When you are troubleshooting problems with setting up notations it is
often necessary to look at the underlying boxes representing the
typeset expression. You can do this through either the command key
shortcut of cmd-shift-E (OSX) and I think cntrl-shift-E (Win), or
through the menu item Format -> Show Expression...
Looking at the underlying boxes shows you how the typeset expression
is represented. As a Mathematica programmer you no doubt use FullForm
at times to examine how a certain pattern is structured. Its really
not too different with typesetting in that Mathematica functions through
MakeBoxes and MakeExpression which operate on these box structures. If
you don't have the correct structures, the boxes will not be
interpreted as they should be.
In a Symbolize statement waiting to be filled in the underlying
structure is
Cell[BoxData[
RowBox[{Symbolize, [,
TagBox[[Placeholder],
NotationBoxTag,
TagStyle->NotationTemplateStyle], ]}]], Input]
To see this load the notation package, type Esc-symb-Esc and then show
the underlying expression. The box structure to be symbolized must be
the first argument of this TagBox.
The tag box wrapper, NotationBoxTag, is necessary so you can enter
typeset expressions into Mathematica that are not currently
syntactically valid. Then once the Notation package gets a hold of
them, it compiles / translates these into corresponding rules for
MakeExpression and MakeBoxes that do what you instructed. The tag box
wrapper inertizes the box structure so it becomes syntactically valid
Mathematica input.
You can see this by copying out the box wrapper into a new cell and
entering some syntactically invalid input into the wrapper, say x
followed by *, and then viewing how it is interpreted by
Mathematica. E.g. after loading the notation package paste the
following cell into Mathematica and interpret it:
Cell[BoxData[
TagBox[
RowBox[{x, *}],
NotationBoxTag,
TagStyle->NotationTemplateStyle]], Input]
Then evaluate this interpreted cell. Then start a new cell and
evaluate FullForm[%]. The answer will be
NotationBoxTag[RowBox[List[x, *]]]
Thus the TagBox wrapper, NotationBoxTag, has allowed us to enter
something that is syntactically invalid and get the box structure into
the kernel. (Incidentally you can programmatically create symbolize
and notation statements this way.) The TagBox wrapper NotationBoxTag
can do this miraculous feat because it itself has a corresponding
notation. (The TagStyle option is set so you can get some visual
indication of where these tag box wrappers occur.)
So anyway getting back to your example if you look at the underlying
boxes you will see that instead of having
Cell[BoxData[
RowBox[{Symbolize, [,
TagBox[
SubscriptBox[k, _],
NotationBoxTag,
TagStyle->NotationTemplateStyle], ]}]], Input]
You had
Cell[BoxData[
RowBox[{Symbolize, [,
TagBox[
TagBox[
SubscriptBox[k, _],
NotationBoxTag,
TagStyle->NotationTemplateStyle],
NotationBoxTag,
TagStyle->NotationTemplateStyle], ]}]], Input]
i.e. the wrapper was in there twice. Fixing this mistake resolves your
problem.
-------------
====
I've always wondered a good way to do this too. You'll probably get lots
of
responses here but researching Google led me to a past post from this
group:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=b3v7s4%24ka
f%241%40smc.vnet.net&rnum=3
(If you prefere instant clickability: http://tinyurl.com/v0n1 )
in which Carl Woll explains the matter nicely.
--
could somebody help me with the following issue?:
Regarding the package Statistics'NonlinearFit, is it possible to fit
> an
> array of preexisting data with a function defined by NDSolve?
Example:
f[y_,a_,b_] :=NDSolve[x'[y] == (y^2/2 + a y + b)/Sqrt[1 -(y^2/2 + a y +
> b)^2], x[0] == .6}, y, {y, 0, 1.5}];
Lautaro
====
>
> I have not tried this in a few years, but I remember that NotebookFind
> shares the global option Wraparound with the Find dialog. You can set the
> option False in the Options Inspector or uncheck the appropriate box in
the
> Find dialog.
>
> Tom Burton
>
Very interesting: Works exactly as you say.
I have an existing palette which has a couple of NotebookFind buttons to
jump forward or back one section in whatever notebook I'm working in.
If I open one of these notebooks and the palette, then turn off Wrap
Around in the Find dialog box, the palette buttons no longer wrap around.
Haven't tried converting the palette back to a notebook, resetting the
option false in the palette notebook, then converting it back to a
notebook, but I'll try that next.
====
Why can't I plot the function and find the solution to the equation below
using SetDelayed functions? Below is just an example, the real functions
are symbolically non-integrable.
s[t_] :=NIntegrate[t^2 - z*Log[t] , {z, 0, k[t]}]
i[t_] := D[s[t],t] /. {k[t] ->2t,k'[t]->Sin[t]}
Plot[i[t], {t, 1, 10}]
Solve[i[t]==300, t]]
All I get is an empty graph because I have not machine real size
numbers
and my equation appears to be solved essentially in non-algebraic way.
If I rewrite the code using simple Set I get my graph and solutions.
s=Integrate[t^2 - z*Log[t] , {z, 0, k[t]}]
i=D[s,t] /. {k[t]->2t,k'[t]->Sin[t]}
Plot[i, {t, 1, 10}]
Solve[i==300, t]]
====
Here's a much better Pade approximation, if you're willing to build a
little more complexity into your function (including a square root).
It eliminates the vertical at x==1, and that helps a lot.
<< Calculus`Pade`
<< Graphics`Colors`
rootPade = Sqrt[1 - x^2]*Pade[ArcCos[x]/Sqrt[1 - x^2],
{x, 0, 6, 6}]
Plot[Evaluate[rootPade - ArcCos[x]], {x, 0, 1},
PlotStyle -> {Red, Blue, Black}, PlotRange -> All]
There's a temptation to use Simplify when defining rootPade. But if
you do, the result isn't as robust numerically:
rootPade = Simplify[Sqrt[1 - x^2]*
Pade[ArcCos[x]/Sqrt[1 - x^2], {x, 0, 6, 6}]]
Plot[Evaluate[rootPade - ArcCos[x]], {x, 0, 1},
PlotStyle -> {Red, Blue, Black}, PlotRange -> All]
Bobby
>
> I would like to implement an arc cos function on a 16 bits
[Micro]controller
> (optimized sin() and cos() function are welcome).
>
> Does someone have some sources or an algorythm in this way ?
>
>
====
You can get a very good rational function approximation as follows:
<< Calculus`Pade`
<< Graphics`Colors`
pade = Pade[ArcCos[x], {x, 0, 6, 6}] // Simplify
series = Normal@Series[ArcCos[x], {x, 0, 19}]
Plot[{pade, series} - ArcCos[x] // Evaluate, {x, 0, 1}, PlotStyle -> {Red,
Blue}]
The Pade approximation of order {6,6} looks better than the series of order
19.
Bobby
>
> I would like to implement an arc cos function on a 16 bits
[Micro]controller
> (optimized sin() and cos() function are welcome).
>
> Does someone have some sources or an algorythm in this way ?
>
>
====
My Mathematica 5.0 kernel doesn't seem to have that problem. I'd suggest
eliminating the new-lines embedded in the equation list, as that can
sometimes lead to problems.
I get this error instead:
NDSolve::underdet: There are more dependent variables, {p[y, t, x],
u[y, t,
x], v[y, t, x]}, than equations, so the system is underdetermined.
Bobby
> NDSolve::deqn: Equation or list of equations expected instead of 0 in
the
> first argument
>
> ------------------------------------------------------------------------
>
> CreatedBy='Mathematica 5.0'
>
> Mathematica-Compatible Notebook
>
> This notebook can be used with any Mathematica-compatible
> application, such as Mathematica, MathReader or Publicon. The data
> for the notebook starts with the line containing stars above.
>
> To get the notebook into a Mathematica-compatible application, do
> one of the following:
>
> * Save the data starting with the line of stars above into a file
> with a name ending in .nb, then open the file inside the
> application;
>
> * Copy the data starting with the line of stars above to the
> clipboard, then use the Paste menu command inside the application.
>
> Data for notebooks contains only printable 7-bit ASCII and can be
> CR, LF or CRLF (Unix, Macintosh or MS-DOS style).
>
> NOTE: If you modify the data for this notebook not in a Mathematica-
> compatible application, you must delete the line below containing
> try to use invalid cache data.
>
> For more information on notebooks and Mathematica-compatible
> applications, contact Wolfram Research:
> web: http://www.wolfram.com
> phone: +1-217-398-0700 (U.S.)
>
> Notebook reader applications are available free of charge from
> Wolfram Research.
> *******************************************************************)
>
>
>
> (*NotebookFileLineBreakTest
> NotebookFileLineBreakTest*)
> (*NotebookOptionsPosition[ 8798, 217]*)
> (*NotebookOutlinePosition[ 9438, 239]*)
> (* CellTagsIndexPosition[ 9394, 235]*)
> (*WindowFrame->Normal*)
>
>
>
> Notebook[{
>
> Cell[CellGroupData[{
> Cell[BoxData[
> (c = 100.0; [Omega] = 100.0)], Input],
>
> Cell[BoxData[
> (100.`)], Output]
> }, Open ]],
>
> Cell[CellGroupData[{
>
> Cell[BoxData[
> (NDSolve[{[PartialD]_t u[t, x, y] +
> Cos[x]*Sin[y]*[PartialD]_x u[t, x, y] -
> Sin[x]*Cos[y]*[PartialD]_y u[t, x, y] -
> Sin[x]*Sin[y]*u[t, x, y] + Cos[x]*Cos[y]*v[t, x, y] -
> Sin[x]*Cos[x]/c2*
> p[t, x, y] == (-[PartialD]_x p[t, x,
> y]),
[IndentingNewLine][IndentingNewLine][PartialD]_t
> v[t, x, y] + Cos[x]*Sin[y]*[PartialD]_x v[t, x, y] -
> Sin[x]*Cos[y]*[PartialD]_y v[t, x, y] -
> Cos[x]*Cos[y]*u[t, x, y] + Sin[x]*Sin[y]*v[t, x, y] -
> Sin[y]*Cos[y]/c2*
> p[t, x, y] == (-[PartialD]_y p[t, x,
> y]),
[IndentingNewLine][IndentingNewLine][PartialD]_t p[
> t, x, y] +
> c2*(([PartialD]_x u[t, x, y] + [PartialD]_y v[t, x,
y])) +
> Cos[x]*Sin[y]*[PartialD]_x p[t, x, y] ==
> Sin[x]*Cos[
> y]*[PartialD]_y p[t, x,
> y], [IndentingNewLine][IndentingNewLine]u[0, x, y]
[Equal]
> 0, v[0, x, y] == 0, p[0, x, y] == 0,
> u[t, 0, y] ==
> Cos[[Omega]*t]*((1 - Exp[(-t)/0.1]))*DiracDelta[y] ,
> v[t, 0, y] == 0,
> p[t, 0, y] ==
> Sin[[Omega]*t]*((1 - Exp[(-t)/0.1]))*DiracDelta[y],
> u[t, x, 1000] == 0, v[t, x, 1000] == 0, p[t, x, 1000] == 0,
> u[t, x, (-1000)] == 0, v[t, x, (-1000)] == 0,
> p[t, x, (-1000)] == 0}, {u, v, p}, {x, 0, 100}, {y, (-1),
1}, {t,
> 0, 1000}])], Input],
>
> Cell[BoxData[
> RowBox[{(NDSolve::deqn), ((:)( )),
equations expected instead of !(0) in the first argument
!({(
> [LeftSkeleton] 1 [RightSkeleton])}).
!(*ButtonBox[More
> [Ellipsis], ButtonStyle->RefGuideLinkText,
ButtonFrame->None,
> ButtonData:>NDSolve::deqn])>}]],
Message],
>
> Cell[BoxData[
> RowBox[{NDSolve, [,
> RowBox[{
> RowBox[{{,
> RowBox[{
> RowBox[{
>
> RowBox[{((-0.0001`) Cos[x] p[t, x, y] Sin[x]),
> -, (Sin[x] Sin[y] u[t, x, y]),
> +, (Cos[x] Cos[y] v[t, x, y]), -,
> RowBox[{(Cos[y]), , (Sin[x]), ,
> RowBox[{
> SuperscriptBox[u,
> TagBox[((0, 0, 1)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}]}],
> +,
> RowBox[{(Cos[x]), , (Sin[y]), ,
> RowBox[{
> SuperscriptBox[u,
> TagBox[((0, 1, 0)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}]}],
> +,
> RowBox[{
> SuperscriptBox[u,
> TagBox[((1, 0, 0)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}]}],
> [Equal],
> RowBox[{-,
> RowBox[{
> SuperscriptBox[p,
> TagBox[((0, 1, 0)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}]}]}],
> ,,
> RowBox[{
>
> RowBox[{((-0.0001`) Cos[y] p[t, x, y] Sin[y]),
> -, (Cos[x] Cos[y] u[t, x, y]),
> +, (Sin[x] Sin[y] v[t, x, y]), -,
> RowBox[{(Cos[y]), , (Sin[x]), ,
> RowBox[{
> SuperscriptBox[v,
> TagBox[((0, 0, 1)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}]}],
> +,
> RowBox[{(Cos[x]), , (Sin[y]), ,
> RowBox[{
> SuperscriptBox[v,
> TagBox[((0, 1, 0)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}]}],
> +,
> RowBox[{
> SuperscriptBox[v,
> TagBox[((1, 0, 0)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}]}],
> [Equal],
> RowBox[{-,
> RowBox[{
> SuperscriptBox[p,
> TagBox[((0, 0, 1)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}]}]}],
> ,,
> RowBox[{
> RowBox[{
> RowBox[{(Cos[x]), , (Sin[y]), ,
> RowBox[{
> SuperscriptBox[p,
> TagBox[((0, 1, 0)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}]}],
> +,
> RowBox[{10000.`, ,
> RowBox[{(,
> RowBox[{
> RowBox[{
> SuperscriptBox[v,
> TagBox[((0, 0, 1)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}],
> +,
> RowBox[{
> SuperscriptBox[u,
> TagBox[((0, 1, 0)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}]}],
> )}]}], +,
> RowBox[{
> SuperscriptBox[p,
> TagBox[((1, 0, 0)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}]}],
> [Equal],
> RowBox[{(Cos[y]), , (Sin[x]), ,
> RowBox[{
> SuperscriptBox[p,
> TagBox[((0, 0, 1)),
> Derivative],
> MultilineFunction->None], [, (t, x, y),
]}]}]}],
> ,, (u[0, x, y] [Equal] 0), ,, (v[0, x, y]
[Equal] 0),
> ,, (p[0, x, y] [Equal] 0),
> ,, (u[t, 0,
> y] [Equal] ((1 - [ExponentialE]^((-10.`)
t))) Cos[
> 100.` t] DiracDelta[y]), ,, (v[t, 0, y]
[Equal] 0),
> ,, (p[t, 0,
> y] [Equal] ((1 - [ExponentialE]^((-10.`)
t)))
> DiracDelta[y] Sin[100.` t]), ,, 0, ,, 0, ,,
0, ,, 0, ,,
> 0, ,, 0}], }}], ,, ({u, v, p}), ,,
({x, 0, 100}),
> ,, ({y, (-1), 1}), ,, ({t, 0, 1000})}],
]}]], Output]
> }, Open ]]
> },
> ScreenRectangle->{{38, 1280}, {0, 1002}},
> WindowSize->{1086, 806},
> WindowMargins->{{35, Automatic}, {Automatic, 64}}
> ]
>
> (*******************************************************************
> the top of the file. The cache data will then be recreated when
> you save this file from within Mathematica.
> *******************************************************************)
>
> (*CellTagsOutline
> CellTagsIndex->{}
> *)
>
> (*CellTagsIndex
> CellTagsIndex->{}
> *)
>
> (*NotebookFileOutline
> Notebook[{
>
> Cell[CellGroupData[{
> Cell[1776, 53, 60, 1, 27, Input],
> Cell[1839, 56, 39, 1, 27, Output]
> }, Open ]],
>
> Cell[CellGroupData[{
> Cell[1915, 62, 1559, 29, 224, Input],
> Cell[3477, 93, 372, 5, 21, Message],
> Cell[3852, 100, 4930, 114, 135, Output]
> }, Open ]]
> }
> ]
> *)
>
>
>
> (*******************************************************************
> End of Mathematica Notebook file.
> *******************************************************************)
====
Here's a easy one ...
How do I stop Out[..] from printing? I want to
do something at In[..] but I don't want to see
the results.