Re: [fpc-pascal] with in classes/records
> On Oct 4, 2018, at 9:19 PM, Michael Van Canneyt > wrote: > > And was this not the whole idea of introducing a default property in the > first place ? It is but I just wanted to make sure that this particular ambiguity with initializing classes wasn’t concerning for anyone. So far I’ve identified 2 instances where the default needs to be ignored: 1) Assigning the same type i.e. during copies for records or init’ing classes 2) When passing into functions (like in writeln below we need to specify the default property so we don’t try to write the actual class) Just making sure this is ok. type TWrapper = class m_value: integer; property value: integer read m_value write m_value; default; end; var wrapper: TWrapper; i: integer; begin wrapper := TWrapper.Create; wrapper := 100; wrapper := wrapper + 1; writeln(wrapper.value); i := wrapper; // error, this passes the class TWrapper end. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with in classes/records
On Thu, 4 Oct 2018, Ryan Joseph wrote: On Oct 4, 2018, at 8:34 PM, Michael Van Canneyt wrote: Technical issues aside, it kind of defeats the purpose of the default property... Then just tolerate the fact we have a dual meaning for assignments? Looks wrong but maybe not a problem. var wrapper: TWrapper; begin wrapper := TWrapper.Create; wrapper := THelperA.Create; And was this not the whole idea of introducing a default property in the first place ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with in classes/records
> On Oct 4, 2018, at 8:34 PM, Michael Van Canneyt > wrote: > > Technical issues aside, it kind of defeats the purpose of the default > property... Then just tolerate the fact we have a dual meaning for assignments? Looks wrong but maybe not a problem. var wrapper: TWrapper; begin wrapper := TWrapper.Create; wrapper := THelperA.Create; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java
On Thu, Oct 4, 2018 at 4:02 AM wrote: > This is one of the most useless collection of floating point myths I > have seen since a long time. > > With rolling a dice you mean, that the comparisons are only > randomly correct or what)? Since the floating-point numbers > are well-defined and exact (yes they are, and truncation/rounding > errors are the results from former computations and/or > the rounding of non-representable numbers). All operations > are predictable, so there is no chance for random. > > The random comes from the input, not the output. If you know the numbers going in, you know the numbers coming out, certainly. But you rarely know the numbers going in , and most people don't know the deep details of what happens behind the scenes, and so sometimes some of those numbers going in give you surprising numbers coming out. Different implementations or different languages have different details, as well, which can also be surprising. So the issue isn't technical, it is language. What was being said was vernacular, colloquial, imprecise, just to give you the impression that __unless you pay attention to the details__ the output you get could look "random" or appear to be a "crap shoot". I don't think the original poster meant that the results were truly random at all, only that if you don't take care to account for the details, you might get that impression. Jeff. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with in classes/records
On Thu, 4 Oct 2018, Ryan Joseph wrote: On Sep 26, 2018, at 1:14 AM, Benito van der Zander wrote: Hi, perhaps everything would be clearer, if the default property was accessed with ^ ? var wrapper: TWrapper; begin wrapper := TWrapper.Create; wrapper^ := THelperA.Create; end. Sorry, back to working on this today. That’s an idea. Probably the other way around though since initializing the class is the less common operation. The compiler team is busy I guess because I haven’t got any answers recently on questions. I suspect appropriating the ^ symbol will not be ok with them since it has another reserved meaning. Technical issues aside, it kind of defeats the purpose of the default property... Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with in classes/records
> On Sep 26, 2018, at 1:14 AM, Benito van der Zander wrote: > > Hi, > > perhaps everything would be clearer, if the default property was accessed > with ^ ? > > > var > wrapper: TWrapper; > begin > wrapper := TWrapper.Create; > wrapper^ := THelperA.Create; > end. > Sorry, back to working on this today. That’s an idea. Probably the other way around though since initializing the class is the less common operation. The compiler team is busy I guess because I haven’t got any answers recently on questions. I suspect appropriating the ^ symbol will not be ok with them since it has another reserved meaning. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java
This is one of the most useless collection of floating point myths I have seen since a long time. I don't know why you want to compare two floats, but you'd better use currency type. Float is for calculus, but comparing float1=float2 (or float1>float2) is rolling the dice. Obviously, the more precision, the less errors. But an accurate, intuitive result, is not guaranteed. With rolling a dice you mean, that the comparisons are only randomly correct or what)? Since the floating-point numbers are well-defined and exact (yes they are, and truncation/rounding errors are the results from former computations and/or the rounding of non-representable numbers). All operations are predictable, so there is no chance for random. People who play with maths may use something like function equal(const f1,f2:Extended; const Error:extended=1E-6):boolean; begin Result:=(abs(f1-f2) This function is non-sense and I doubt that 'math people' will use it. First: it uses only absolute errors, so 1e-7 and 1e-4000 are equal. Second: A tolerance of 1e-6 is ridiculous, given that the machine epsilon for 80-bit extended is 1.0842e-19. What does java does? I don't know. Perhaps it just rounds the output, try System.out.println(ans==0.0). Perhaps it uses a high precision that *in this case* gets always 0. As already said, you can get the same values as Java, if you use the same data types (double) and the same precision (53-bit) with Free Pascal (even with the X87 FPU) 5.10099001E+004 5.10099001E+004 5.10099001E+004 --- 0.E+000 0.E+000 0.E+000 0.E+000 0.E+000 But the question is that floating point representation can't store accurately many numbers. To begin with, 0.1 in base 10, is periodic number in binary 0.0001...001..001... so it has to truncate it, No is this only true if you use the truncate rounding mode, which is not default (default is round-to-nearest/even). and when you truncate, the result depends of the order of operations, no matter the language or precision. So, it is matter of probability to get 1. or 1.0001 or 0. Yes, but it is predictable and deterministic and no matter of probability. To conclude: The reason for the differences is the usage of intermediate elevated precision (and this can occur also e.g. for C where it is also allowed to use intermediate higher precision). For Delphi/Free Pascal this phenomenon does not occur if you always compute with the precision appropriate to the data type, as e.g. with 64-bit/SSE. Regards, Wolfgang ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
