ToddAndMargo, this should handle any kind of columns separated data (or any table). If some column (commonly separated with a constant character as "\t", ";", "|", ....) has different types (char, text, int, boolean, ...) in a single column, then it should be treated as a character, but if it has only float (in all rows/lines) then the parser checks all rows for a same column (in this example case all them are float) and assign the column as float contain column. Example:
NAME(long char);NICK(char);AGE(natural/positive integer);HEIGHT(float m);WEIGHT(float kg) John Lovegood;JoL;23;1.80;85.283 Marry Lockheart;Marry_L;35;1.68;63,125 You may see that the first line must be a header, all lines have 5 fields separated by ";" and each field has a unique type (the specifications not aways be declared on the data or file). Paul Proacci, thank you for a lot. I agree with you. Then, float, integer, boolean and char are the most commons and probably better to assign. But persist the question, which is the best strategy to define with which type assign some column? On Mon, Jan 13, 2020 at 11:28 PM Paul Procacci <pproca...@gmail.com> wrote: > >> what is the best strategy? > > My general rule of thumb: > > If you control the value then you can pick whatever data type that has the > largest number of bits to hold your largest value.[1] > If you don't control the value, stick with an Int (or Uint). > > If you stick with Int you can later modify it to use more tailor made type > as necessary, but Int is always going to be the safest bet. > > Hope this helps you. > > [1] I never use unsigned variants of integers where arithmetic may be > involved do to overflow and use variants of signed integers instead > whenever possible. > > On Mon, Jan 13, 2020 at 11:09 PM Aureliano Guedes < > guedes.aureli...@gmail.com> wrote: > >> About the Raku typing, suppose I'll write a library to deal with data >> frames/tables (as PDL - Perl(5) Data Language), something like >> Pandas-Python or R. >> After reading the file (csv; tsv ....) I'd like that some routine >> identifies the best type to fix each column (especially in cases like Unit, >> unit, int, ....) what is the best strategy? >> >> On Mon, Jan 13, 2020 at 10:51 PM ToddAndMargo via perl6-users < >> perl6-us...@perl.org> wrote: >> >>> >> On Mon, Jan 13, 2020 at 9:51 PM ToddAndMargo via perl6-users >>> >> <perl6-us...@perl.org <mailto:perl6-us...@perl.org>> wrote: >>> >> >>> >> On 2020-01-13 18:46, ToddAndMargo via perl6-users wrote: >>> >> > On 2020-01-13 17:13, ToddAndMargo via perl6-users wrote: >>> >> >> And, no one is telling me percisely what the difference >>> >> >> between UInt and uint is other than one is a subset of >>> >> >> Int and the other is a native type. They act exactly >>> >> >> the same. >>> >> > >>> >> > Hi All, >>> >> > >>> >> > Off line, Paul told me what the difference is >>> >> > between a UInt and a uint. >>> >> > >>> >> > uint is constrained: >>> >> > >>> >> > p6 'my uint $c = 0x0; $c = $c +| 0x1FFFFFFFFFFFFFFFF;' >>> >> > Cannot unbox 65 bit wide bigint into native integer >>> >> > in block <unit> at -e line 1 >>> >> > >>> >> > UInt uses magic Larry Wall powder to remove the constraints >>> >> > from the variable. (Same powder he uses to create nils.) >>> >> > >>> >> > p6 'my UInt $c = 0x0; $c = $c +| >>> >> > 0x1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF; >>> say >>> >> $c' >>> >> > >>> 862718293348820473429344482784628181556388621521298319395315527974911 >>> >> > >>> >> > Other than the constrains, they act exactly the same. >>> >> > Oh, and they are both (generic programming term) unsigned >>> integers >>> >> > (cardinals) >>> >> > >>> >> > :-) >>> >> > >>> >> > -T >>> >> >>> >> >>> >> And good luck, all you who told me to read the >>> >> documentation, trying to find the constraints >>> >> explanation in the documentation: >>> >> >>> >> https://docs.raku.org/type/UInt >>> >> >>> >> Have fun! >>> >> >>> >> But it does say "The UInt is defined as a subset of Int:" >>> >> and Int is definitely constrained. >>> >> >>> >>> On 2020-01-13 19:13, Paul Procacci wrote: >>> > >> trying to find the constraints explanation in the documentation: >>> > >>> > https://docs.raku.org/language/nativetypes >>> > >>> > "Raku offers a set of /native/ types with a fixed, and known, >>> > representation in memory" >>> > and >>> > "However, these types do not necessarily have the size that is >>> required >>> > by the NativeCall <https://docs.raku.org/language/nativecall> >>> interface >>> > (e.g., Raku's |int| can be 8 bytes but C's |int| is only 4 bytes)" >>> > >>> > Took me all of 30 seconds to find. Obviously that page has much more >>> > information to offer than just those couple of sentences, but ALL >>> native >>> > types are constrained by a certain number of bits. >>> >>> >>> Hi Paul, >>> >>> For those of you who were no privy to Paul and my >>> offline discussion, he must have wrote me 10 >>> times trying to explain things to me before >>> I got it. He is a real mensch. >>> >>> 30 seconds! Yikes! I never found it. >>> >>> https://docs.raku.org/type/UInt >>> should have stated that directly, but did not. >>> >>> And to add injury, >>> >>> https://docs.raku.org/language/nativetypes >>> "Raku offers a set of /native/ types with a fixed, >>> and known, representation in memory" >>> >>> Did not state who they were. Sort of like when I >>> want the salt, I always reach for the pepper! >>> >>> The state of the documentation drives me ... >>> >>> <Editorial comment> AAAAAAHHHHHH!!!!! </editorial comment> >>> >>> -T >>> >> >> >> -- >> Aureliano Guedes >> skype: aureliano.guedes >> contato: (11) 94292-6110 >> whatsapp +5511942926110 >> > > > -- > __________________ > > :(){ :|:& };: > -- Aureliano Guedes skype: aureliano.guedes contato: (11) 94292-6110 whatsapp +5511942926110
