Squish Fields Together If Blank Space in BizTalk - xsd

0000103100USD0.00 000000000000.00 0.00 0.00 0.00 0.00 0.00 0000000000000000000000000000000000000000000000000000000 00000000000000
0000051400USD0.00 000000000000.00 0.00 0.00 0.00 0.00 0.00 0000000000000000000000000000000000000000000000000000000 00000000000000
I'm new to BizTalk, so I'm not sure if this is a common thing that can be solved by flipping an attribute around, or if I need to handle this in the map itself.
I have a map that outputs a flat file that looks something like this. What I need is for all of the blank space between fields to disappear.
I've had an idea to check the length of each string with 0's in it and add 0's to the front for the numbers e.g. 0000000.00, but certainly BT has an easier solution... I would think.

Actually the blank spaces are not blank, they are actually part of your data. You could use xslt to trim the input text if you want to get rid of the white spaces.

I ended up using Padding, Padding Character, and Justification to get to the answer.

Related

How to panic when a NaN is created?

I'm trying to find where a NaN is created in a huge codebase. Is there some compiler flag or something I can use to panic on NaN so I can find what line it's on?
There's no compiler flag. The best you can do is to wrap your floats in noisy_float newtype.

Is it possible to store any PETSCII character in a DATA statement string in Commodore BASIC?

I would like to store some binary data in a BASIC program on the Commodore 64 as DATA statements. To save space, I'd prefer to store as a string, rather than as a sequence of numbers.
Is it possible to store any character, from CHR$(0) through CHR$(255), in a DATA statement, or are certain characters impossible to represent this way? What is the complete list of characters that cannot be represented in a DATA statement (if any)?
I'm particularly wondering about CHR$(0), double quote ("), newline and carriage return. If these can be represented, how?
Short answer: No. And you said why: the double-quote character inside a string generates an error: there are no quote-escape characters. For every Other value, you might be able to poke stuff into your DATA statement strings and then just never touch those lines again with the C64 BASIC editor, but the double quotes would kill you.
The best and fastest solution I've yet to think up is poor mans hex. It works like this:
Take each binary byte. Separate it into its two hex digits (/16 and keep the remainder for the second digit).
For each hex digit, take the binary value and add 48.
Now you have two characters in the set (0,1,2,3,4,5,6,7,8,9,:,;,<,=,>,?) that represent one byte.
Those two characters go into your data statement string.
Reverse the process to read them and poke them out.
There is a way to do this, you can POKE bytes directly into RAM. It's a bit of a long way around though, and you need to know where you're POKEing the bytes to. You could negate the need for lots of zeros in your DATA statement though, like this:
0 FOR I=0 TO 7
1 READ A(I)
2 NEXT I
3 PRINT A(0), A(4)
63998 PRINT "FIN"
63999 DATA ,,,,4,,7,8
We know that 2048 is the start of the BASIC area (unless you've moved the pointers), so at a guess, one could do this:
0 DATA" "," "," "," "," "
Then POKE around 2050 or 2051 with a character that you'd recognise and then list it. If you see the character added in between the double quotes then you win. Of course, then you need to calculate each position between the quotes thereafter. When you're done, renumber your line number and carry on programming. I'm not sure how you'd POKE a double quote in between a double quote as there is no notion of escaping a string in Commodore BASIC as far as I know.
I'd personally just use numbers though.
I have stored the following data statement, each element as a string, in a C64 program. I chose CHR$(172) - CHR$(190), and two above CHR$(4000).
100 data "©","ª","«","¬"," ","®","¯","¶","¼","½","¾","™","ח","⦁"
And I ran the following code:
10 FOR X=1 TO 14
20 READ A$
30 PRINT ASC(A$)
40 NEXT X
100 data "©","ª","«","¬"," ","®","¯","¶","¼","½","¾","™","ח","⦁"
The results were mixed. I knew it would not recognize anything above 255. But the CHR$(173) printed as a 32 instead:
RUN
169
170
171
172
32
174
175
182
188
189
190
?SYNTAX ERROR IN 100
READY.
I resisted the program, and my DATA statement now looks like this:
100 DATA "©","ª","«","¬"," ","®","¯","¶","¼","½","¾",""","",""
Using another BASIC dialect, one more modern and written in the past few years, this was my output of the CHR$ for 172 to 190:
The ASCII value of A is: 65
The ASCII value of A should be 65, like it is on a PC.
If it is not 65, then a conversion table must be loaded
and the results converted to match the PC so code
CHR$ VALUES
—————————————————
CHR$(169)=© CHR$(170)=ª CHR$(171)=« CHR$(172)=¬ CHR$(173)=­
CHR$(174)=® CHR$(175)=¯ CHR$(176)=° CHR$(177)=± CHR$(178)=²
CHR$(179)=³ CHR$(180)=´ CHR$(181)=µ CHR$(182)=¶ CHR$(183)=·
CHR$(184)=¸ CHR$(185)=¹ CHR$(186)=º CHR$(187)=» CHR$(188)=¼
CHR$(189)=½ CHR$(190)=¾
For C64 BASIC, you either must use the string of numbers, or you will have to use the HEX values and store the actual characters as I have done in my original C64 DATA statement.
I don't know exactly how much space you think you are going to save, but it will be minimal at best, as C64 can't go past CHR$(255).
However, the other dialect I used, SmartBASIC, I went out past CHR$(20480).
I hope this helps.

JsonSlurper avoid trimming last zero in a string

I am using JsonSlurper in groovy to convert a json text to a map.
def slurper = new JsonSlurper();
def parsedInput = slurper.parseText("{amount=10.00}");
Result is
[amount:10.0]
I need result without trimming last zero. Like
[amount:10.00]
Have checked various solutions but this is not getting converted without trimming last zero. Am I missing something here.
One of the ways I have found is to give input as:
{amount="10.00"}
In numbers and maths, 10.00 IS 10.0
They are exactly the same number.
They just have different String representations.
If you need to display 10.0 to the user as 10.00 then that is a conversion thing, as you will need to convert it to a String with 2 decimal places
Something like:
def stringRepresentation = String.format("%.02f", 10.0)
But for any calculations, 10.0 and 10.00 are the same thing
Edit -- Try again...
Right so when you have the json:
{"amount"=10.00}
The value on the right is a floating point number.
To keep the extra zero (which is normally dropped by every sane representation of numbers), you will need to convert it to a String.
To do this, you can use the String.format above (other methods are available).
You cannot keep it as a floating point number with an extra zero.
Numbers don't work like that in every language I can think of... They might do in COBOL from the back of my memory, but that's way off track
The issue (GROOVY-6922) was fixed in Groovy version 2.4.6. With 2.4.6 the scale of the number should be retained.

Printing out 178-character string in 270 characters of brainf*ck

I’m trying to print out a 178-character string in brainfuck. This wouldn’t be a problem except I’m limited to using 270 characters of brainfuck. I was thinking of hashing the 178-character string using a two-way hashing function, but I've been having trouble finding a solution that works. Here is the string: "Wikipedia is the best thing ever. Anyone in the world can write anything they want about any subject, so you know you are getting the best possible information." - Michael Scott.
Running the string straight-up in some ascii->brainfuck programs is giving me about 1,409 characters, far off from my target of 270. I think I should be able to create the brainfuck code with a string of about 60 characters. So my question is, is there any way to convert the above string to a string of 60 characters that can later be decoded back to the string?
It's most probably impossible. Brainfuck isn't magic. The current record for shortest code to print the 13-char string "Hello, World!" is an entire 78 bytes.:
--<-<<+[+[<+>--->->->-<<<]>]<<--.<++++++.<<-..<<.<+.>>.>>.<<<.+++.>>.>>-.<<<+.
I suggest you read the post, but a TL;DR for you is that the tape is first initialized with a recurrence relation, then poke around the tape to print the appropriate characters.
78 bytes for thirteen characters. On a relatively simple string. That's 6 bytes for each character. Using the same metric as a rough guide (and this result is an underestimate), your string would take 1068 characters--at a minimum. Given that, however, the tape initialization occurs only once, and this can be surprisingly small, you may (may) be able to get it down to the high 900 or 800s. Your string also happens to be more complex and differ very widely in ASCII values, something even a recurrence relation is unlikely to solve. I however have no example that small.

Number Pattern Recognition. How?

I got a string of many numbers and was wondering how to go about finding a pattern if there is one without knowing in advance what the pattern might be and what the length of the pattern might be. All it know is that there are only numbers and the maximum range of any given number is 1 - 59.
Example:
12 13 34 45 48 51 56 22 37 30 8 5 47
Although I am starting to think if this was possible it'd be like predicting the future which I don't think it's possible.
If I understand your question correctly, I guess you would like to do something as they do here:
http://alteredqualia.com/visualization/hn/sequence/
http://www.algebra.com/algebra/homework/Sequences-and-series/Sequences-and-series.faq.question.155130.html
That is, looking at the differences between the numbers 1 or more times, and finding patterns. Writing a program to do this for arbitrary sequences is quiet challenging however.

Resources