• Fractalsaremylife (unregistered)

    The level of wrong in this is fractal. No matter how deep you go there is always more wrongness to find.

    inb4 incredibly overused inception joke.

  • (cs) in reply to Tim
    Tim:
    obviously a hoax, but a hilarious one :-)
    Not necessarily. It could be a near-direct conversion from a COBOL program for converting numbers into 'amounts in words' to print out on bank cheques. I once had to write something similar (but rather better than the OP's version, obviously!).
  • (cs) in reply to MikeN
    MikeN:
    My favorite part is that it's version 15.1.

    What about the fact that it's the Enterprise Edition? I'd hate to see the Lite Edition...

  • (cs) in reply to mschaad
    mschaad:
    I just appreciated the fact that the English output is still wrong.

    [GrammarNazi] 13,387,281 rendered as words should read "thirteen million three hundred eighty-seven thousand two hundred eighty-one". Note that the word "and" is not in there at all, and tens are properly hyphenated. :-) [/GrammarNazi]

    In the USA, yes, BUT:

    [UKGrammarNazi] In the UK, 13,387,281 rendered as words should read "thirteen million, three hundred and eighty-seven thousand, two hundred and eighty-one" (yes, including the commas). [/UKGrammarNazi]

    The American tic of removing "and" from such phrases is one of the many reasons I loathe so-called "American (or "US") English."

    I wish someone would have the guts to just call their variant of the language "American," since many of the idioms, phraseology, and even words are not English in the sense that any UK speaker would understand. For example, try asking for a "fanny pack" in a shop in England and see what you get (possibly including being thrown out of the shop!).

  • Anymouse (unregistered)

    C'mon. The number of VB fails is approaching the number of VB "programmers" in the world. They're hardly worth mentioning any more. Programmers need software engineers to tell them what to do, otherwise they end up writing crap. Software engineers do not allow VB in their engineered creations. Ergo, virtually all VB is crap.

    A real WTF would be any well-written VB, since that's an infinitely rarer animal.

    Captcha: minim -- the amount of education necessary to write VB.

  • (cs) in reply to the beholder
    the beholder:
    MikeN:
    My favorite part is that it's version 15.1.
    I bet that "bug fixes" section is gonna be quite long by the time he puts 10^8 in the range.

    Whoever wrote this code should be thrown out the window... of a orbital station.

    You crazy? That would screw up the structural integrity of the whole place!

    Much better to use an airlock.

  • sod (unregistered) in reply to Cad Delworth
    Cad Delworth:
    mschaad:
    I just appreciated the fact that the English output is still wrong.

    [GrammarNazi] 13,387,281 rendered as words should read "thirteen million three hundred eighty-seven thousand two hundred eighty-one". Note that the word "and" is not in there at all, and tens are properly hyphenated. :-) [/GrammarNazi]

    In the USA, yes, BUT:

    [UKGrammarNazi] In the UK, 13,387,281 rendered as words should read "thirteen million, three hundred and eighty-seven thousand, two hundred and eighty-one" (yes, including the commas). [/UKGrammarNazi]

    The American tic of removing "and" from such phrases is one of the many reasons I loathe so-called "American (or "US") English."

    I wish someone would have the guts to just call their variant of the language "American," since many of the idioms, phraseology, and even words are not English in the sense that any UK speaker would understand. For example, try asking for a "fanny pack" in a shop in England and see what you get (possibly including being thrown out of the shop!).

    Give me a moment to put on my rubbers before I give you your fanny pack.

  • Peter (unregistered) in reply to Michal
    Michal:
    He meant definitely "parameter" when writing "perimeter". Then it starts making sense.
    No shit, Sherlock?
  • F (unregistered) in reply to mschaad
    mschaad:
    I just appreciated the fact that the English output is still wrong.

    [GrammarNazi] 13,387,281 rendered as words should read "thirteen million three hundred eighty-seven thousand two hundred eighty-one". Note that the word "and" is not in there at all, and tens are properly hyphenated. :-) [/GrammarNazi]

    Also, to render numbers correctly as words (with the hyphens and everything) is a harder trick than you might think. Thankfully, standard English style dictates that you pretty much never spell out any numbers above nine.

    So where would you need a library like this, unless your app writes checks?

    You clearly don't know about standard English style in writing numbers. AFAICT you are confusing it with standard American style.

  • Larry (unregistered)

    Oh, I see it now. It should be:

    get_words_from_a_number_which_is_past_as_a_perimeter_into_this_function

  • Jack (unregistered) in reply to vt_mruhlin
    vt_mruhlin:
    'Sometimes a 'four' would be outputted when '5' was passed through the perimeter
    Can we all take a moment to imagine just how bad the original version of this must have been if that particular problem only reproed sometimes?
    That was probably before he fixed it by putting in all the "p_mode = p_mode" stuff.
  • (cs) in reply to Spider Flyer
    Spider Flyer:
    Wow...

    ...How old is this code? Because I saw working code that would do this in a '79 or '80 copy of 'Creative Computing'.

    Also, you can find working code online if you search for a one of the 'large' number suffixes plus the name of your favorite computer language.

    For example, while searching for 'septillion c#', I found: http://www.vb-helper.com/howto_net_number_to_words2.html

    In '79 or '80 would you really have had enough memory to waste 73 characters on the name of the function?

  • Jay (unregistered) in reply to Decius
    Decius:
    Anon:
    'Establish p_mode to define correct perimeter If p_mode = "" Then p_mode.Replace("", "No perimeter was passed through") Else p_mode = p_mode End If
    If p_mode = "No perimeter was passed through" Then
        p_mode = ""
    Else
        If p_mode = "" Then
            p_mode.Replace("", "No perimeter was passed through")
        Else
            p_mode = p_mode
        End If
    End If</div></BLOCKQUOTE>
    

    I can't even begin to understand the thought process here. 15 lines that do absolutely nothing. It simplifies to p_mode = p_mode which is a NOP.

    Not quite nothing- if you pass "no perimeter ...", it changes to an empty string.

    Granted, it doesn't do anything remotely useful, but that's not the same thing as a NOP.

    Ha ha! Excellent point! This is exactly the sort of thing that, if I was trying to clean up the function, would have me wondering, Is there some call where an insane person actually passed in "no perimeter ...", and if I cleaned up the code, I'd break that call.

  • (cs) in reply to Coyne
    Coyne:
    Enterprisey. Very enterprisey. Also shtupid.
    Hmm ... that would be an Arte-fact.
  • (cs) in reply to Anymouse
    Anymouse:
    C'mon. The number of VB fails is approaching the number of VB "programmers" in the world. They're hardly worth mentioning any more. Programmers need software engineers to tell them what to do, otherwise they end up writing crap. Software engineers do not allow VB in their engineered creations. Ergo, virtually all VB is crap.

    A real WTF would be any well-written VB, since that's an infinitely rarer animal.

    Captcha: minim -- the amount of education necessary to write VB.

    So you are saying that without logic changes this code would be ok if only it were in C or C#? And any engineer that is not designing in a language agnostic fashion is doing it wrong. Design is agnostic, and it shouldn't matter the language just as long as design is followed.

  • Ryan (unregistered) in reply to mschaad
    mschaad:
    So where would you need a library like this, unless your app writes checks?
    I worked with a guy (long ago) who had to write exactly that for a COBOL shop. He tediously generated code for all the common words and punctuation, all in capital letters of course because the mainframe printer didn't do lower case.

    Problem is, this was a government facility, so the check amounts were usually pretty big numbers. And those printers that don't do lower case don't do fonts either. So before long the text wouldn't fit in the allotted space. The fix, sadly, was to print the numeric amount both in the box where it originally was, and on the "text" line.

    I don't know if he ever recovered from seeing all that work go to waste.

  • mschaad (unregistered) in reply to F

    Sorry for the imprecision. I indeed meant "standard American English style", meaning "what you use in writing," as opposed to "what you use in math." So I suppose I should have said "standard (American) writing style."

    And yes, you can include the commas in American English too, if you like. Just make sure to get those hyphens in there. ;-)

  • Jay (unregistered)

    There is some dumb coding that at least I can comprehend. Like, when I've had to write a function like this, I've always created an array for 1 to 20 and then pulled the text from the array so it can be done with one line of code rather than a long if/then/else. But I can comprehend someone just not thinking of that, and writing the if/then/else.

    But what in the world motivates someone to write "p_mode=p_mode"? Was he concerned that there might be some situation where p_mode<>p_mode? Did he have a bug where p_mode didn't appear to contain the right value, and so, just to be sure you know, he set it to itself?

    There are some mistakes that indicate failure to think through the implications, or to consider beter alternatives, or maybe just a moment of sloppiness. But other mistakes ... I can only ask, Do you know what a computer is for?

  • LANMind (unregistered) in reply to geoffrey, MCP, PMP
    geoffrey:
    Jaunticed:
    I'm banking on this being just a joke. Evidence?
    'Shortened name of the function due to errors on polling the function
    

    Considering that the EXAMPLE USAGE shows what we can guess was the previous function name, and how the new name is needlessly verbose... yeah.

    One of Visual Basic's many useful features is an Eval function, which executes any text string you hand to it as code. The original author is probably using Eval, and has discovered a limitation on length for the argument.

    There hasn't been an eval in VB since v6.

  • Anon (unregistered) in reply to Jay
    Jay:
    But what in the world motivates someone to write "p_mode=p_mode"? Was he concerned that there might be some situation where p_mode<>p_mode? Did he have a bug where p_mode didn't appear to contain the right value, and so, just to be sure you know, he set it to itself?

    Obviously it supposed to be for thread safety. In case p_mode changes between retrieving the value and setting it back again.

  • Tasty (unregistered) in reply to KattMan
    KattMan:
    Honestly it's a language parser, should be easy to do all numbers with little more code.

    Go 1-9, then 10-12, then 13-19 becomes easy (nine) + (teen) After that everything else is easy 21, 31 are (twenty) + (one) or (thirty) + (one).

    Yeah this function is a serious WTF, even in its name, sounds like the forgot to name it and just put the comment as the name.

    Never depend on logic when using natural languages!

    Your 13-19 range doesn't quite work. For example:

    three+teen != "thirteen" five+teen != "fifteen"

    Bonus Spanish language oddity: The "hundreds" in Spanish have an irregular 500.

    cien (100) dos cientos (200) tres cientos (300) ... quinentos (500) (the first N is N+~)

  • Tasty (unregistered) in reply to Cad Delworth
    Cad Delworth:
    mschaad:
    I just appreciated the fact that the English output is still wrong.

    [GrammarNazi] 13,387,281 rendered as words should read "thirteen million three hundred eighty-seven thousand two hundred eighty-one". Note that the word "and" is not in there at all, and tens are properly hyphenated. :-) [/GrammarNazi]

    In the USA, yes, BUT:

    [UKGrammarNazi] In the UK, 13,387,281 rendered as words should read "thirteen million, three hundred and eighty-seven thousand, two hundred and eighty-one" (yes, including the commas). [/UKGrammarNazi]

    The American tic of removing "and" from such phrases is one of the many reasons I loathe so-called "American (or "US") English."

    I wish someone would have the guts to just call their variant of the language "American," since many of the idioms, phraseology, and even words are not English in the sense that any UK speaker would understand. For example, try asking for a "fanny pack" in a shop in England and see what you get (possibly including being thrown out of the shop!).

    Ask for an American rubber and you'll prevent pregnancy.

    The Canadians use our "phraseology" and your spelling. so, maybe that's the common English.

  • squidfood (unregistered)

    Ah, I see someone's found some of Ada Lovelace's old code:

    Function 1 - In which our values are initialized, and we meet our hero, the object X

  • coyo (unregistered) in reply to DaveK
    DaveK:
    Passed as a perimeter? Sounds kinda edgy to me.

    ++

  • LANMind (unregistered) in reply to Anymouse
    Anymouse:
    C'mon. The number of VB fails is approaching the number of VB "programmers" in the world. They're hardly worth mentioning any more. Programmers need software engineers to tell them what to do, otherwise they end up writing crap. Software engineers do not allow VB in their engineered creations. Ergo, virtually all VB is crap.

    A real WTF would be any well-written VB, since that's an infinitely rarer animal.

    Captcha: minim -- the amount of education necessary to write VB.

    I automatically assume that anyone who blames bad code on the language is as dumb as tits on bull as an analyst. There is a possibility that you're just an an elitist jackass, however.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)

    Yeah, I remember ol' HX_373. He was THX_1138's granddad, ya know. And when he got to drinking, he would get as pissed as a parameter!

  • Nagesh (unregistered)

    I am not seeing a problem here. It is always being recommened to use long names for better code clarification, even names of perineters and function.

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Looks like something Nagesh would write; isn't that the type of Hinglish that he writes in?

    Exception because Nagesh kabhi VB mein programming nahi karta!!! :}

  • (cs) in reply to Jay
    Jay:
    Decius:
    Anon:
    'Establish p_mode to define correct perimeter If p_mode = "" Then p_mode.Replace("", "No perimeter was passed through") Else p_mode = p_mode End If
    If p_mode = "No perimeter was passed through" Then
        p_mode = ""
    Else
        If p_mode = "" Then
            p_mode.Replace("", "No perimeter was passed through")
        Else
            p_mode = p_mode
        End If
    End If</div></BLOCKQUOTE>
    

    I can't even begin to understand the thought process here. 15 lines that do absolutely nothing. It simplifies to p_mode = p_mode which is a NOP.

    Not quite nothing- if you pass "no perimeter ...", it changes to an empty string.

    Granted, it doesn't do anything remotely useful, but that's not the same thing as a NOP.

    Ha ha! Excellent point! This is exactly the sort of thing that, if I was trying to clean up the function, would have me wondering, Is there some call where an insane person actually passed in "no perimeter ...", and if I cleaned up the code, I'd break that call.

    It could still be replaced for a single line though.
  • no (unregistered) in reply to Bleat
    Bleat:
    'API call removed due to high demand
    1) How much was this used that this was ever in 'high demand'

    Well, it never was defined what kind of 'high demand' - as in 'all his colleagues demanded that his hands be separated from his arms before being allowed near a computer again'

  • (cs) in reply to MeesterTurner
    MeesterTurner:
    What about the fact that it's the Enterprise Edition?
    The Enterprise edition was slightly better than the Reliant edition, but much worse than the Excelsior edition.
  • geoffrey, MCP, PMP (unregistered) in reply to Anymouse
    Anymouse:
    C'mon. The number of VB fails is approaching the number of VB "programmers" in the world. They're hardly worth mentioning any more. Programmers need software engineers to tell them what to do, otherwise they end up writing crap. Software engineers do not allow VB in their engineered creations. Ergo, virtually all VB is crap.

    A real WTF would be any well-written VB, since that's an infinitely rarer animal.

    Captcha: minim -- the amount of education necessary to write VB.

    sigh

    To accept this argument, one would have to ignore the fact that Visual Basic applications have delivered more business value, in the aggregate, than all other platforms combined.

  • (cs) in reply to Cad Delworth
    Cad Delworth:
    [UKGrammarNazi] In the UK, 13,387,281 rendered as words should read "thirteen million, three hundred and eighty-seven thousand, two hundred and eighty-one" (yes, including the commas). [/UKGrammarNazi]

    The American tic of removing "and" from such phrases is one of the many reasons I loathe so-called "American (or "US") English."

    Get over yourself, ignorant limey. The form with the ands is in fact exactly how I, an American, was taught to write out large numbers. If they're being left out, that's just laziness and/or ignorance, something that members of your own population are equally susceptible to.

    You also seem to have a shaky grasp of the proper application of "so-called".

  • geoffrey, MCP, PMP (unregistered) in reply to LANMind
    LANMind:
    geoffrey:
    Jaunticed:
    I'm banking on this being just a joke. Evidence?
    'Shortened name of the function due to errors on polling the function
    

    Considering that the EXAMPLE USAGE shows what we can guess was the previous function name, and how the new name is needlessly verbose... yeah.

    One of Visual Basic's many useful features is an Eval function, which executes any text string you hand to it as code. The original author is probably using Eval, and has discovered a limitation on length for the argument.

    There hasn't been an eval in VB since v6.

    Which is why this re-envisioned ".Net" pales in comparison to classic Visual Basic.

  • radarbob (unregistered) in reply to 3rd Ferguson

    I had a coworker (not student, not off-the-street-rookie) who used the same "style" to code if/else. That is, he didn't seem to know that an else clause is not required. He also like to phrase the if-condition as a negative.

    When I tried to explain this to him he said "why are you telling me this."

  • rick (unregistered) in reply to itsmo

    And did no one notice that the example at the end uses the word "and" incorrectly in the number?

  • Gavin (unregistered)

    Here is my quick attempt at a proper implementation of this function in Python. Note that I'm using the American method without 'and'.

  • Croswold (unregistered) in reply to Zylon
    Zylon:
    Get over yourself, ignorant limey. The form with the ands is in fact exactly how I, an American, was taught to write out large numbers. If they're being left out, that's just laziness and/or ignorance, something that members of your own population are equally susceptible to.

    You also seem to have a shaky grasp of the proper application of "so-called".

    I was taught to write it out without "and." The justification is that "and" adds nothing. The number is perfectly intelligible with or without.

    Since "and" is way of reading "+" ("1 + 1 = 2" can be read as "one and one is two"), then really, you could put as many "and's" as you wanted.

  • Gavin (unregistered)

    I'd also like to add that this wikipedia article seems to agree that omitting the "and" is valid in American English.

  • Nigel (unregistered)

    This function's great because it goes all the way to eleevn

  • Neuratypical (unregistered) in reply to Zylon
    Zylon:
    Cad Delworth:
    [UKGrammarNazi] In the UK, 13,387,281 rendered as words should read "thirteen million, three hundred and eighty-seven thousand, two hundred and eighty-one" (yes, including the commas). [/UKGrammarNazi]

    The American tic of removing "and" from such phrases is one of the many reasons I loathe so-called "American (or "US") English."

    Get over yourself, ignorant limey. The form with the ands is in fact exactly how I, an American, was taught to write out large numbers. If they're being left out, that's just laziness and/or ignorance, something that members of your own population are equally susceptible to.

    You also seem to have a shaky grasp of the proper application of "so-called".

    Check you out, all grammary and shit.

  • (cs) in reply to Cad Delworth
    Cad Delworth:
    I wish someone would have the guts to just call their variant of the language "American,"
    That's why you have “en_GB” and “en_US” locales.
  • Matt (unregistered) in reply to MikeN
    MikeN:
    My favorite part is that it's version 15.1.
    15 typos fixed plus one edited comment
  • (cs) in reply to Larry
    Larry:
    Oh, I see it now. It should be:

    get_words_from_a_number_witchispast_as_a_perimeter_into_this_function

    FTFY

  • Fred (unregistered) in reply to radarbob
    radarbob:
    I had a coworker (not student, not off-the-street-rookie) who used the same "style" to code if/else. That is, he didn't seem to know that an else clause is not required. He also like to phrase the if-condition as a negative.

    When I tried to explain this to him he said "why are you telling me this."

    I think I knew him, sorta! He left before I arrived, but his code lived on. The usual pattern:

    If not (condition) else ...

    That's right, no then clause, just straight to the else.

    I asked my coworkers if they had ever questioned him. Yes, they had. Many times. The only answer he ever offered was "for readability."

  • Kammat (unregistered)

    Heck, is it even returning anything beyond the "bad perimeter" message? It looks like it checks if p_mode = "pass_a_number," and only starts crunching to text if it does match.

  • Ben Jammin (unregistered) in reply to Cad Delworth
    Cad Delworth:
    The American tic of removing "and" from such phrases is one of the many reasons I loathe so-called "American (or "US") English."

    One thing I dislike is improperly embedded quotation marks. Does that use different rules across the pond as well?

    By the way, "loathe" is a pretty heavy word. I'd loathe someone who shot my dog or burnt my house. Getting that angry over grammar rules that we Americans supposedly don't even know of anyways and much less follow points to other issues in the psyche.

  • Coder (unregistered)

    I do love it when a method is self-commenting.

  • Somebody (unregistered)

    I actually felt good about the code below when I wrote it a long time ago. Converting a dollar amount to text for a check. Reading it today, I am glad we didn't have many zero dolllar checks coming through.

        private const string DOLLARS_AND = " DOLLARS AND ";
        private const string CENTS = " CENTS";
        private const string HUNDRED = " HUNDRED";
        private const string THOUSAND = " THOUSAND";
        private const string MILLION = " MILLION";
        private string[] strNonIrtyNumberText = {" ZERO"," ONE"," TWO"," THREE"," FOUR"," FIVE",
                     " SIX"," SEVEN"," EIGHT"," NINE"," TEN"," ELEVEN",
                     " TWELVE"," THIRTEEN"," FOURTEEN"," FIFTEEN",
                     " SIXTEEN"," SEVENTEEN"," EIGHTEEN"," NINETEEN"};
        private string[] strIrtyNumberText = {" ZERO"," TEN"," TWENTY"," THIRTY"," FORTY"," FIFTY",
                     " SIXTY"," SEVENTY"," EIGHTY"," NINETY"};
        
        private void ConvertAmountToText(decimal decCheckAmount)
        {
            string Temp = "";
            int intDollarAmount = (int)decCheckAmount;
            int intIntegerWholeAmount = int.Parse(((int)(decCheckAmount * 100)).ToString());
            int intCents = intIntegerWholeAmount - (intDollarAmount * 100);
            string strDollarAmount = intDollarAmount.ToString().PadLeft(7, '0');
    
            if (intDollarAmount == 0)
                Temp = strNonIrtyNumberText[0] + DOLLARS_AND + intCents.ToString().PadLeft(2, '0') + CENTS;
    
            int intCheckOne;
            int intCheckTwo;
            int intCheckTeen;
            bool bolIrtyValue = false;
    
            for (int x = 0; x < 7; x++)
            {
                intCheckOne = int.Parse(strDollarAmount[x].ToString());
                intCheckTwo = x == 6 ? 0 : int.Parse(strDollarAmount[x + 1].ToString());
                intCheckTeen = int.Parse(intCheckOne.ToString() + intCheckTwo.ToString());
                //0000000
                if (intCheckOne != 0)
                {
                    if (x == 2 || x == 5)
                        bolIrtyValue = true;
    
                    if (bolIrtyValue && intCheckTeen < 20)
                        Temp += strNonIrtyNumberText[intCheckTeen];
                    else if (bolIrtyValue && intCheckTeen > 19)
                    { Temp += strIrtyNumberText[intCheckOne]; Temp += intCheckTwo == 0 ? "" : strNonIrtyNumberText[intCheckTwo]; }
                    else
                        Temp += strNonIrtyNumberText[intCheckOne];
    
                    if (bolIrtyValue)
                        x++;
    
                    Temp += x == 0 ? MILLION : "";
                    Temp += x == 1 || x == 4 ? HUNDRED : "";
                    Temp += x == 3 && intDollarAmount > 999 ? THOUSAND : "";
    
                }
                Temp += x == 6 ? DOLLARS_AND : "";
                bolIrtyValue = false;
            }
            Temp += intCents.ToString().PadLeft(2, '0') + CENTS;
            return = Temp.Trim();
        }
    
  • (cs)

    @. --- English numbers ---

    @0 There is another thing controlled by the .{(English)} parameter. Converting numbers to words is also conditionally enabled. These can be grouped into three kinds: 1'' toone'', 1'' tofirst'', and 1'' to1st''.

    @E English (English)L @<

    @0 The last case, 1'' to1st'', is simplest, so it comes first.

    @S 1_1st @. ( number -- text ) <[th]s0[st]s1[nd]s2[rd]s3 dBr 100%d10%r10/1-1 0 1i* d3-1d0i* `0+L+>

    @0 The other two are also simple, if they are done using a word form table. So, that is what we will do. Word form table 1 will be used for numbers into words.

    @W #1

    2:0]:] 2:1]:one 2:2]:two 2:3]:three 2:4]:four 2:5]:five 2:6]:six 2:7]:seven 2:8]:eight 2:9]:nine 3:10]:ten 3:11]:eleven 3:12]:twelve 3:13]:thirteen 3:14]:fourteen 3:15]:fifteen 3:16]:sixteen 3:17]:seventeen 3:18]:eighteen 3:19]:nineteen 4:2t]:twenty 4:3t]:thirty 4:4t]:forty 4:5t]:fifty 4:6t]:sixty 4:7t]:seventy 4:8t]:eighty 4:9t]:ninety 5:-th]:th 5:ty-th]:tieth 5:one-th]:first 5:two-th]:second 5:three-th]:third 5:five-th]:fifth 5:eight-th]:eighth 5:nine-th]:ninth 5:twelve-th]:twelvth

    @0 Now we have the definition for .{(1_one)} and .{(1_first)}. The second one is mostly like the first one, so it will call the first one. You should not input negative numbers to these subroutines, because it will just assume it is zero.

    @S 1_one @. ( number -- text ) d[D[zero]]d[<s1 l1100%B1WD@. Get words for number 1-19 l1100%20-dix@. Deal with prefix for 20-90 l1100/10%s2hundredx@. Deal with hundreds l11000/1000%s2thousandx@. Deal with thousands l11000000/1000%s2millionx@. Deal with millions l11000000000/s2billionx@. Deal with billions

    ]ix

    @S 1_one_20to99 AD@. Remove the tens digit left from before l110/10%B[t]+1WD@. Make word for 20-90 rdZ0[][-]ir+@. Figure out whether a hyphen should be added +@. Join the tens word with the ones word

    @S 1_one_1000 l20[D][ l2(1_one)x@. A recursive call, get word for this number [ ]+r+@. Add the suffix rdZ0[][ ]ir+@. Figure out if a space is needed +@. Join the result ]ix

    @S 1_first @. ( number -- text ) (1_one)x[-th]+1WD

    @>

Leave a comment on “get_words_from_a_number_which_is_passed_as_a_perimeter_into_this_function”

Log In or post as a guest

Replying to comment #379222:

« Return to Article