PureBasic Forums - English

Kick you? Heck no, I'll chase after you with a stick!! Just kiddin

On a serious note, though, what are your thoughts on the whole unsigned var situation? Think it's something that might make it into PB? Was I incorrect as to the reasons it's not in there now?

Again.. Thanks Fred!

PS. Drop me that CVS account for the docs!

Kick hard, and use steel enforced boots

He always do that with me

Inner wrote:matthew180 : I didn't know this was such a saw point .. maybe I should be making a bigger thing over it!.. I shall write more after tea I think.

Well, I don't like to suggest something without a solution, and I like to make sure everyone understands exactally what I'm trying to point out.

Fred wrote:I was talking about MIXING unsigned and signed numbers in expressions, comparisons and more. Doing all in unsigned is of course very easy. Think than even VC++ warns you when you do a such comparison between signed and unsigned because performances and unexpected result and ask for cast. Do you want casts be introduced in a basic langage ? Anyway, if you can give the solution, I'm will be of course very glad.

I still don't understand what you mean by "performance" problems? No matter what compiler or language you use, variables of different types will be converted to the same type before being compared. And this conversion can be done at compile time (usually with the selection of JLE or JBE, etc.), so I don't see where that slows things down.

As for casting, yes, I think you need to introduce it. You ask "Do you want casts be introduced in a basic langage ?" as if casting is something that should not be in a BASIC language, but pointers, structures, and linked lists should be... I've already argued that PB is way beyond BASIC already and adding these additional features makes it more usable.

http://www.wikipedia.org/wiki/BASIC

The eight design principles of BASIC were:

1. Be easy for beginners to use
2. Be a general-purpose language
3. Allow advanced features to be added for experts (while keeping the language simple for beginners)
4. Be interactive
5. Provide clear and friendly error messages
6. Respond fast for small programs
7. Not require an understanding of computer hardware
8. Shield the user from the operating system

Well, PB already blows this list... Look at number 7 for example and try to do games without knowing anything about your hardware... And number 8, well, that's a utopia of computer languages. To sheild someone from the OS you can't add things like graphic or sound. However, number 3 allows you to add anything to PB that you want! The only thing BASIC about PB anymore is the name...

So, again, yes, I want casting. You can't have more types without it. You have already crossed the line with sizes anyway, allowing the user to worry about .b or .w or .l size types. I would also like to see quads (64-bit) integers and floats added to PB. Since the IA32 processors have commands to directly supporting such types, this would again be choices the PB compiler makes at compile time.

For people who don't give a crap about types and casting, they can just use the default .l type, and they will never have any problems. For those who *need* bigger types, or unsigned types, etc., it should be there, otherwise we have to go use other languages...

As for implementation, I can't do it for you unless you give me read access to the PB compiler source... But, I can give you the rules for casting, which should make initial implementation easy since PB only has a small subset of types compared to C.

---

Any expression to be calculated breaks down into a series of operations between two operands. For example, the expression 2*3-4+5 amounts to the series 2*3 resulting in 6, 6-4 resulting in 2, and finally 2+5 resulting in 7. Thus, the rules for casting operands where necessary only need to be defined in terms of decisions about pairs of operands. So, for any pair of operands of different types, the following rules are checked in the order shown, and when one rules applies, that rule is used.

Rules for Casting Operands

1. If either operand is of type "long double", the other is converted to "long double".

2. If either operand is of type "double", the other is converted to "double".

3. If either operand is of type "float", the other is converted to "float".

4. Any operand of type "char", "signed char", "unsigned char", "short", or "unsigned short" is converted to type "int".

5. An enumeration type is converted to the first of "int", "unsigned int", "long", or "unsigned long" that accommodates the range of the enumerators.

6. If either operand is of type "unsigned long", the other is converted to "unsigned long".

7. If one operand is of type "long" and the other is of type "unsigned int", then both operands are converted to type "unsigned long".

8. If either operand is of type "long", the other is converted to type "long".


This is not as complex as it looks. The basic principle is to always convert the value that has the type that is of a more limited range, to the type of the other value. This maximizes the likelihood of being able to accommodate the result.


Matthew

Wow, Mathew your intelagant , even I as stuppid as I am understood that

so just to clearify, that I did understand you.

long foo;
long nut;

nut=foo+3 ; so the compiler holds the result in unsgined long ? or did I traggically miss something?

PB already does most of these casts automatically, I just would like to find a fully automatic solution which seems not possible.

Things that are automatically breeds lazyness, lazyness breeds bad coding, bad coding leads to software failures, software failure reflect not only on the programmer but on the compiler they use.

There are some compilers is history that have such a bad reputation that if an end users knew it was compiled in (x) compile refused to run it, I am like that today, I refuse to run anything written in Visual Basic.

But this isn't about history, or reputation it's about finding a salution to the problem.

Inner wrote:Things that are automatically breeds lazyness, lazyness breeds bad coding, bad coding leads to software failures

Either that, or you get offered a job by Microsoft

Was it just me or did that sound like Yoda? 8O

Yoda: “Pain leads to anger, anger leads to hate, hate leads to sufferingâ€

Inner wrote:Wow, Mathew your intelagant , even I as stuppid as I am understood that

so just to clearify, that I did understand you.

long foo;
long nut;

nut=foo+3 ; so the compiler holds the result in unsgined long ? or did I traggically miss something?

You know, I'm only trying to help, so if you are flaming me then make your point or do it in private, but don't make jokes about people in public unless you can offer something better. If I have made a mistake, then fine, just let me know so I can correct myself...

If your question about foo=nut+3 is legitimate, then yes, you missed something. Immediate numbers (like the 3) will take on the smallest type that will hold the data, in PB's case that would be a byte. So, according to the rules, it would fit rule 4, then 8, which makes it a long. But PB does not have ints, so rule 4 would just convert it to a long and stop.

Fred wrote:PB already does most of these casts automatically, I just would like to find a fully automatic solution which seems not possible.

Why would PB already have these casts if it does not have unsigned or other variable types? Or are you referring to conversion between long and float? As for automatic, I don't see a problem with that. C is automatic 99% of the time, unless the programmer does something that the compiler can't figure out, at which time it blows a warning. A good programmer won't get warnings and a sloppy programmer will...

Fred, if you are not going to support other types, please let the PB community know. If you are, then pick whatever language you like the best that already has multiple types, and copy how they do it. Don't try to make something up since it will be unfamiliar to everyone. But, with PB's current limit on types, it makes it impossible to choose PB for certain tasks, such as dealing with files greater than 2G, doing any kind of precision math, etc..

Matthew

Fred, I like PB, I think it is a great piece of software! As far as I am concerned, anyone who writes a language is a guru in their own right, and I applaude your efforts with PB!!

I'm posting this because I get the feeling some of you out there have been offended by my posts... I'm *not* tying to say "look stupid, this is how easy it is..." My intent is to provide the technical logic to support an idea, in this case other data types for PB. I'm not saying Fred or anyone else is stupid or unknowledgeable, I know everyone here is a competent programmer. I also know that English is not a first language for many people on the forum, and I very much appreciate the fact that everyone is willing to use English as the common language.

I'll be less verbose from now on, and wait until asked instead of suggesting...

Matthew

I'll be less verbose from now on, and wait until asked instead of suggesting...

No no no... Keep the info/suggestions coming! Fred can only say no, can't he? I like to read and learn and take advantage of other people's knowledge and then try and contribute. So please don't stop.

The point isn't to be more verbose or not. About the limitation you raise up (no precise math, files over 2G) are not signed/unsigned issue and I already say than it will be done. I didn't get offended by your posts, just a bit surprised to see how you say it was 'easy', even if you don't know anything about PB internals. And yes, my english is bad .

Fred wrote:The point isn't to be more verbose or not. About the limitation you raise up (no precise math, files over 2G) are not signed/unsigned issue and I already say than it will be done. I didn't get offended by your posts, just a bit surprised to see how you say it was 'easy', even if you don't know anything about PB internals. And yes, my english is bad .

Is there a list someplace that tells what you are planning on adding, so we don't keep asking for something that you are already going to do?

You mentioned a performance problem with signed/unsigned types and I was not sure what you meant, so I tried to provide a technical solution to the problem...

As for the files over 2G, etc., I only meant that in order to maintian a byte offset into a 2G < file < 4G, you need an unsigned 32-bit number, and of course I know that you are well aware of that...

I'm sorry I implied that implementing new types should be "easy." That was not my intent. I know nothing about PB internals, so of course I have no idea what might be involved. I assumed that since you already support signed longs, and that the only difference between signed and unsigned is the choice of jump instructions (and of course MUL, DIV, and SAR), that it might be rather simple to implement... But only you can know for sure.

And as for your English, it is better than my French, and I'm grateful that you support English!

Matthew

matthew180: noooo, oh help.. NOOO!!! I wasn't I swear, I was just writing something that sounded like what you was talking about, and I would asking if that is what you ment.. ( no flame ) honest... I don't do flames

Inner wrote:matthew180: noooo, oh help.. NOOO!!! I wasn't I swear, I was just writing something that sounded like what you was talking about, and I would asking if that is what you ment.. ( no flame ) honest... I don't do flames

Thank you! I'm glad I simply misunderstood you. I feel better already!

Matthew