Timeline



02/02/19:

20:51 Changeset [852] by Maciej Komosinski
Dictionary.find() now also works for null values stored in a dictionary (now that they can be officially stored)
20:50 Changeset [851] by Maciej Komosinski
Getting int or float value casted from null or invalid is an ERROR (but still returns 0)

01/31/19:

03:48 Changeset [850] by Maciej Komosinski
LoggerBase::handle() calling handleSingleLine() stops when paused
03:47 Changeset [849] by Maciej Komosinski
Added Dictionary.hasKey(). Accessing non-existent dictionary keys becomes an error.
03:45 Changeset [848] by Maciej Komosinski
2D operations with more granular types of arguments
03:43 Changeset [847] by Maciej Komosinski
Code formatting

01/07/19:

22:50 Ticket #43 (ModelGeometry: sizes and orientations depend on sampling density and ...) closed by Maciej Komosinski
fixed: After improving the serialization of Orient (so that it uses full precision) and using custom floating-point printing procedure (Dragon4), the results became identical for gcc (linux) and VS2017 (windows). C++Builder 10.3 (windows) which uses the clang compiler yields usually very similar results (with minor differences ~10e-13) and in rare cases, very different results. For example, for Foraminifera (twisted biserial) with genotype id=458, differences in area, volume, sizesaxes are in the range of 0.1. Another example is Worm with genotype id=465, where only the area differs significantly from gcc/VS2017 (the difference is ~0.1). Anyway I am closing this issue since we are aware that different compilers may use different implementations of floating point operations. The main issue was that "sizes and orientations depend on sampling density and model orientation", and this is caused by the very nature of the method responsible for geometry calculations (and using floating point values), unfortunately.

01/06/19:

02:44 Changeset [846] by Maciej Komosinski
- Added support for ternary conditional operator a?b:c - Fixed incorrect stack allocation in some cases of && ||, and for(x in null) - && and || operators always return one of the input expressions (previously the result was in some cases simplified to 0 or 1)
02:41 Changeset [845] by Maciej Komosinski
Made strings at least slightly comparable with zero so 'Math.pi && "xyz" && [9,9,7]' can work as expected in FramScript?
Note: See TracTimeline for information about the timeline view.