Using Latex algorithmic package for switch statement? - algorithm

My googling didn't come up with how to do a switch statement in an algorithm using the algorithm and algorithmic packages, but I'm assuming you can. Most guides just didn't mention it either way.
\begin{algorithm}
\caption{send(...) method}
\begin{algorithmic}
\IF{dest equals..}
%\SWITCH{nature}
\STATE cast data...
\STATE extract data...
\STATE copy...
%\ENDSWITCH
\ELSE
\STATE match dest....
%\SWITCH{nature}
\STATE cast data...
\STATE extract data...
\STATE send...
%\ENDSWITCH
\ENDIF
\end{algorithmic}
\end{algorithm}
Thanks!

I wrote the following definitions in my latex document.
It seems that they work.
Just insert the above lines anywhere after your inclusion statement of the algorithmic package. Especially, to make the algorithm presentation concise, I distinguish between compound cases and one-line cases. The one-line cases begin with \CASELINE. The compound cases begin with \CASE and end with \ENDCASE. Similar to the default statements.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% The following definitions are to extend the LaTeX algorithmic
%% package with SWITCH statements and one-line structures.
%% The extension is by
%% Prof. Farn Wang
%% Dept. of Electrical Engineering,
%% National Taiwan University.
%%
\newcommand{\SWITCH}[1]{\STATE \textbf{switch} (#1)}
\newcommand{\ENDSWITCH}{\STATE \textbf{end switch}}
\newcommand{\CASE}[1]{\STATE \textbf{case} #1\textbf{:} \begin{ALC#g}}
\newcommand{\ENDCASE}{\end{ALC#g}}
\newcommand{\CASELINE}[1]{\STATE \textbf{case} #1\textbf{:} }
\newcommand{\DEFAULT}{\STATE \textbf{default:} \begin{ALC#g}}
\newcommand{\ENDDEFAULT}{\end{ALC#g}}
\newcommand{\DEFAULTLINE}[1]{\STATE \textbf{default:} }
%%
%% End of the LaTeX algorithmic package extension.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
You can try the following example.
\SWITCH {$\theta$}
\CASE {1}
\STATE Hello
\ENDCASE
\CASELINE {2}
\STATE Good-bye
\DEFAULT
\STATE Again ?
\ENDDEFAULT
\ENDSWITCH
Farn Wang
Dept. of Electrical Eng.
National Taiwan University

If you have a look at the official documentation from CTAN on the algorithm package you will notice, that there is no default SWITCH-CASE-statement. I assume that to be the reason, why it is left out in so many documentations ;)

Related

! Missing number, treated as zero error in latex when using for loop

\begin{algorithm}
\caption{AlgorithmCH election algorithm}
\label{algorithm}
\begin{algorithmic}[1]
\Procedure{CHElection}
\For{each node i }
\EndFor
\EndProcedure
\end{algorithmic}
\end{algorithm}
I have this code used to write an algorithm in LATEX but I received this error (! Missing number, treated as zero error) when I point to the error, I saw it at \End for. Can anyone tell me why I am getting this error please?
This are the packages I added for writing an algorithm
\usepackage[noend]{algpseudocode}
\usepackage[ruled,noresetcount,noend]{algorithm2e}
Don't load algorithm2e when you're using algpseudocode. The former creates an algorithm floating environment, but in order to use algorithmic from algpseudocode, you should load algorithm instead (from the algorithms bundle).
\documentclass{article}
\usepackage{algorithm}
\usepackage[noend]{algpseudocode}
\begin{document}
\begin{algorithm}
\caption{AlgorithmCH election algorithm}
\label{algorithm}
\begin{algorithmic}[1]
\Procedure{CHElection}{}
\For{each node~$i$}
\EndFor
\EndProcedure
\end{algorithmic}
\end{algorithm}
\end{document}
Note also the second (mandatory) argument for \Procedure, which designates the arguments passed to the procedure. It can also be left blank, but you need to explicitly include this.
I just removed that error by placing the packages in the folloing order
\usepackage{algopseudocode}
%\usepackage{algorithmic} not required
\usepackage{algorithm}

Rewriting sentences while retaining semantic meaning

Is it possible to use WordNet to rewrite a sentence so that the semantic meaning of the sentence still ways the same (or mostly the same)?
Let's say I have this sentence:
Obama met with Putin last week.
Is it possible to use WordNet to rephrase the sentence into alternatives like:
Obama and Putin met the previous week.
Obama and Putin met each other a week ago.
If changing the sentence structure is not possible, can WordNet be used to replace only the relevant synonyms?
For example:
Obama met Putin the previous week.
If the question is the possibility to use WordNet to do sentence paraphrases. It is possible with much grammatical/syntax components. You would need system that:
First get the individual semantics of the tokens and parse the sentence for its syntax.
Then understand the overall semantics of the composite sentence (especially if it's metaphorical)
Then rehash the sentence with some grammatical generator.
Up till now I only know of ACE parser/generator that can do something like that but it takes a LOT of hacking the system to make it work as a paraphrase generator. http://sweaglesw.org/linguistics/ace/
So to answer your questions,
Is it possible to use WordNet to rephrase the sentence into alternatives? Sadly, WordNet isn't a silverbullet. You will need more than semantics for a paraphrase task.
If changing the sentence structure is not possible, can WordNet be used to replace only the relevant synonyms? Yes this is possible. BUT to figure out which synonym is replace-able is hard... And you would also need some morphology/syntax component.
First you will run into a problem of multiple senses per word:
from nltk.corpus import wordnet as wn
sent = "Obama met Putin the previous week"
for i in sent.split():
possible_senses = wn.synsets(i)
print i, len(possible_senses), possible_senses
[out]:
Obama 0 []
met 13 [Synset('meet.v.01'), Synset('meet.v.02'), Synset('converge.v.01'), Synset('meet.v.04'), Synset('meet.v.05'), Synset('meet.v.06'), Synset('meet.v.07'), Synset('meet.v.08'), Synset('meet.v.09'), Synset('meet.v.10'), Synset('meet.v.11'), Synset('suffer.v.10'), Synset('touch.v.05')]
Putin 1 [Synset('putin.n.01')]
the 0 []
previous 3 [Synset('previous.s.01'), Synset('former.s.03'), Synset('previous.s.03')]
week 3 [Synset('week.n.01'), Synset('workweek.n.01'), Synset('week.n.03')]
Then even if you know the sense (let's say the first sense), you get multiple words per sense and not every word can be replaced in the sentence. Moreover, they are in the lemma form not a surface form (e.g. verbs are in their base form (simple present tense) and nouns are in singular):
from nltk.corpus import wordnet as wn
sent = "Obama met Putin the previous week"
for i in sent.split():
possible_senses = wn.synsets(i)
if possible_senses:
print i, possible_senses[0].lemma_names
else:
print i
[out]:
Obama
met ['meet', 'run_into', 'encounter', 'run_across', 'come_across', 'see']
Putin ['Putin', 'Vladimir_Putin', 'Vladimir_Vladimirovich_Putin']
the
previous ['previous', 'old']
week ['week', 'hebdomad']
One approach is grammatical analysis with nltk read more here and after analysis convert your sentence in to active voice or passive voice.

Fortran: FORMAT statement over two lines

I have an old Fortran 77 code, which I would like to run in a F90-Compiler, and my goal is to change the code as less as possible. It works quite well, but I have some problem with format statements in the code. And I don't understand what's the problem. I work with Eclipse, and gfortran. I use free form.
Question 1
This compiles fine:
program HelloWorld
400 FORMAT(7HK GAMMA,2X,G13.5,7H P0,2X,G13.5,6H A1,2X,G13.5)
end program
This doesn't compile
program HelloWorld
400 FORMAT(7HK 'GAMMA',2X,G13.5,7H 'P0',2X,G13.5,6H 'A1',2X,G13.5)
1
end program
The Error is
P descriptor needs leading scale factor in format string at (1)
(the error is translated from german, might not be exactly the same words in english) What is wrong?
Question 2
This also compiles fine:
program HelloWorld
400 FORMAT(7HK GAMMA,2X,G13.5,7H P0, &
2X,G13.5,6H A1,2X,G13.5)
end program
If I add more code to the last code:
program HelloWorld
400 FORMAT(7HK GAMMA,2X,G13.5,7H P0,2X,G13.5,6H A1,2X,G13.5, &
2X,7HK,ALPHA-1,2X,G13.5,7H BETA-4,2X,G13.5 )
end program
it doesn't compile anymore. The error is:
P Edit descriptor expected in the format string* at (1)
whereas the (1) is placed at the third line after the closing bracket.
*I'm not sure about the translation of "format string", as my console is in german.
What is the problem there?
Your format statements have an H (for Hollerith) edit descriptors - the things in the format statements that have a number followed immediate by a H. The descriptor results in the characters (including blanks) following the H and counted by the leading number being output to the file.
This language feature was made obsolescent in Fortran 90 and removed completely from the language in Fortran 95.
They are very error prone. Since Fortran 77 a far better way of achieving the same result has been to use character constant edit descriptors.
The problem is that you have (or are creating) a mismatch between the number of characters indicated by the leading number and the actual count of characters that apparently were in the descriptor. For example, your second FORMAT statement is copied below, showing the seven characters that would be in the descriptor. You can see how that appears to end in the middle of a "string". This then confuses what the compiler sees for the remainder of the format specification.
400 FORMAT(7HK 'GAMMA',2X,G13.5,7H 'P0',2X,G13.5,6H 'A1',2X,G13.5)
1234567
As I write in the comment it looks more like FORTRAN66 than 77 because the Hollerith H descriptor and data type was used before introducing the CHARACTER data type to the language. It was also used to assign character data to integer variables, but fortunately that is very rare to encounter. The use as an edit descriptor is however more common, although very obsolete.
It is not clear what you want to achieve, good example of the desired output would be helpful.
Do you meant:
400 FORMAT(7HK GAMMA,2X,G13.5,3H P0,2X,G13.5,3H A1,2X,G13.5)
so that
print 400, 1. ,2. ,3.
outputs
K GAMMA 1.0000 P0 2.0000 A1 3.0000
Or should the P0 and A1 serve as edit descriptors?
What was the original code in the legacy software?
The nH Hollerith descriptor just outputs n next characters so it can unintentionally "eat" some of your descriptors and just print them.
That is the problem that causes that your examples do not compile, because the n before H is too large and the rest of the format then has no sense.
The next one could be
400 FORMAT(8H 'GAMMA',2X,G13.5,5H 'P0',2X,G13.5,5H 'A1',2X,G13.5)
to print
'GAMMA' 1.0000 'P0' 2.0000 'A1' 3.0000
The effect of the above in Fortran 95 and above is better achieved by
print '(A0,2X,G13.5,A0,2X,G13.5,A0,2X,G13.5)', " 'GAMMA'",1.," 'P0'", 2.0, " 'A1'", 3.0
and maybe you would rather use just:
print '(A0,2X,G13.5,A0,2X,G13.5,A0,2X,G13.5)', "GAMMA",1.,"P0", 2.0, "A1", 3.0
for printing
GAMMA 1.0000 P0 2.0000 A1 3.0000
or even
print *, "GAMMA",1.,"P0", 2.0, "A1", 3.0

Is there a general way to do symbolic integrations in real domains, just like the way maple do[Assumptions don't work]

Integrate[m^2/((x - m^2)^2 + y^2), m]
mathematica gives me a complex-valued reuslt, but maple 17 gives me what I want, see the attached picture.
I tried using assumptions, but it doesn't work.
In MMA, is there a general way to do integrations in real domains, just like maple.
Can this wrap bulit-in command proposed by Todd Gayley (see: What is in your Mathematica tool bag?) do the trick?
Message[args___] := Block[{$inMsg = True, result},
"some code here";
result = Message[args];
"some code here";
result] /; ! TrueQ[$inMsg]`
Perhaps the reason for the complex-valude result is the invovled power calculation during the integration, so maybe what I really need is a general way to do symbolic power calculation in real domains?
thanks :)

Localized exponential notation?

i'm trying to convert numbers into localized strings.
For integers and money values it's pretty simple, since the string is just a series of digits and digit grouping separators. E.g.:
12 345 678 901 (Bulgarian)
12.345.678.901 (Catalan)
12,345,678,901 (English)
12,34,56,78,901 (Hindi)
12.345.678.901 (Frisian)
12?345?678?901 (Pashto)
12'345'678'901 (German)
i use the Windows GetNumberFormat function to format integers (and GetCurrencyFormat to format money values).
But some numbers cannot be reasonably represented in fixed notation, and require scientific notation:
6.0221417930×1023
or more specifically E notation:
6.0221417930E23
How can i get the localized version of scientific notation?
i suppose i could construct it using localized numbers:
6.0221417930E23
6,0221417930E23
6.0221417930e23
6·0221417930E23
6·0221417930e23
6,0221417930e23
6,,0221417930e23
6.0221417930E+23
6,0221417930E+23
6.0221417930e+23
6,0221417930e+23
6·0221417930E+23
6·0221417930e+23
6,,0221417930e+23
6.0221417930E23
6,0221417930E23
6.0221417930e23
6,0221417930e23
6·0221417930E23
6·0221417930e23
6,,0221417930e23
6.0221417930X10^23
6,0221417930X10^23
6.0221417930x10^23
6,0221417930x10^23
6·0221417930X10^23
6·0221417930x10^23
6,,0221417930x10^23
6.0221417930·10^23
6,0221417930·^23
6.0221417930.10^23
6,0221417930.10^23
6·0221417930·^23
6·0221417930.10^23
6,,0221417930.10^23
but i don't know if other cultures (cultures besides mine) use an E for exponentiation.
To the best of my knowledge, exponentiation notation is not part of Windows or .NET locale data. However, the Unicode CLDR can help once again: Its <numbers> sections contains what you are looking for:
/numbers/symbols/exponential says E or its equivalent in the given culture.
/numbers/scientificFormats/ shows the exponentiation pattern.
You'll need to download the zipped core CLDR data and extract the file for each culture you're interested in from the common/main directory.
If you want to be able to support all cultures, you'll have to gather the relevant info from all culture files and pack it into your own specific DB. Not quite a trivial work but it's possible.
I gave a quick look to the data in a few very different cultures such as en, fr, zh, ru, vi, ar: They all contain the same pattern: #E0. It looks like either the data is not accurate (I seriously doubt.) or you don't have to care really: Everybody does it the same way and you shouldn't actually care.
For Polish it should be 6,0221417930·1023.
I don't think CLDR mentioned by Serge (great answer BTW) is valid here. However, it is still the best source of information. Otherwise you would need to ask your translators to translate the pattern for you (which would require a comment with good explanation what you are up to).

Resources